MINI PROJECT
AUTOMATED CI/CD PIPELINE FOR WEB
APPLICATIONS
USING JENKINS AND DOCKER CONTAINERS
DEPARTMENT OF INFORMATION TECHNOLOGY
SUBJECT: DevOps (CCS342)
1. ABSTRACT
In modern software engineering, the manual deployment of applications is often the primary
cause of downtime and system inconsistencies. This project addresses these challenges by
implementing a professional DevOps CI/CD pipeline. The core objective is to automate the
entire lifecycle of a web application—from the moment a developer commits code to the
final deployment on a live server.
By integrating Jenkins as a central automation hub and Docker as the containerization
engine, we ensure that the application environment remains identical across development,
testing, and production. This "Infrastructure as Code" approach eliminates environmental
discrepancies and drastically reduces the time-to-market. The project specifically focuses on
creating lightweight, portable images and orchestrating their deployment via automated
scripts.
SOURCE
DEPLOY
TEST
Technical Logic: Centralized Automation Hub Model
2. INTRODUCTION
DevOps is not merely a set of tools but a methodology designed to unify software
development (Dev) and IT operations (Ops). Traditionally, these two departments
functioned in silos, leading to friction during releases. The DevOps philosophy promotes
collaboration and automation to solve this.
This project implements a CI/CD pipeline which is the backbone of DevOps. Continuous
Integration (CI) ensures that code changes are integrated and validated frequently.
Continuous Delivery/Deployment (CD) ensures that the code is always in a deployable
state. Using Jenkins and Docker allows us to build a robust system that is scalable and
platform-independent.
3. OBJECTIVE
The strategic objectives of this implementation include:
• Environment Parity: Ensuring the app runs the same on a developer's laptop and the
production server using Docker containers.
• Rapid Feedback: Providing immediate build status to developers using Jenkins
automation.
• Process Standardization: Creating a repeatable and documented build process.
• Reduced Human Error: Automating repetitive tasks like manual file transfers and
server restarts.
• Scalability: Designing a pipeline that can handle multiple application microservices
simultaneously.
4. TECHNOLOGY USED
The following technical stack provides the foundation for our automated infrastructure:
1. Jenkins (Orchestration Engine): An open-source server that manages the workflow.
It triggers actions based on events like code pushes.
2. Docker (Containerization): A platform that uses OS-level virtualization to deliver
software in packages called containers.
3. Git/GitHub (SCM): The version control system used to track changes in source code
and trigger the pipeline via webhooks.
4. Docker Hub (Image Registry): A centralized repository for storing and managing
Docker container images.
5. Shell Scripting & Jenkinsfile: Used to define the Pipeline-as-Code, allowing the
automation logic to be stored alongside the application.
6. Linux Environment: The project is hosted on an Ubuntu-based system to leverage its
native support for Docker and high-performance networking.
[ Tech Stack Inter-compatibility Layer ]
SCM (Git) <--> CI (Jenkins) <--> CD (Docker) <--> Host (Linux)
5. SYSTEM ARCHITECTURE
The architecture is designed as a distributed system. The Source Control (GitHub) acts as
the entry point. The Jenkins Master server processes instructions and interacts with the
Docker Daemon to build images.
SSH / API CALL
JENKINS SERVER DOCKER HOST
IMAGE PULL
Figure 5.1: Master-Worker Architectural Pattern
In this architecture, we separate the 'Build' logic from the 'Deployment' environment. This
ensures that a failure in the production environment does not impact the development
pipeline.
6. METHODOLOGY
The implementation methodology follows the "Immutable Infrastructure" principle. Instead
of updating the app on the server, we build a new image and replace the old container.
Step 1: Code Integration - Code is pushed to GitHub. A Webhook sends a POST request to
Jenkins.
Step 2: Build Automation - Jenkins executes `docker build`. This creates a localized
environment containing the OS, libraries, and code.
Step 3: Image Registry - The verified image is tagged with a version number and pushed to
Docker Hub.
Step 4: Live Deployment - The deployment server pulls the latest image and executes
`docker run`. The old container is stopped and removed, and the new version takes its place.
TRIGGER BUILD PUSH RUN
Technical Execution Sequence
7. IMPLEMENTATION
The project is implemented through two primary configuration files that drive the entire
automation.
7.1 Jenkins Pipeline Configuration (Pipeline-as-Code)
pipeline {
agent any
environment {
DOCKER_IMAGE = "ezhil/webapp-prod"
}
stages {
stage('Checkout') {
steps { git '[Link]
[Link]' }
}
stage('Build Docker Image') {
steps { sh "docker build -t ${DOCKER_IMAGE} ." }
}
stage('Production Deployment') {
steps { sh "docker run -d -p 80:80 ${DOCKER_IMAGE}" }
}
}
}
7.2 Container Specification (Dockerfile)
FROM nginx:latest
COPY ./src /usr/share/nginx/html
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]
8. INFRASTRUCTURE MONITORING
Once the pipeline is active, continuous monitoring is conducted to ensure system uptime.
We monitor two specific metrics: Pipeline Health and Container Resource Utilization.
Load
Time (Hours)
Figure 8.1: Infrastructure Load Monitoring Diagram
Jenkins provides a "Weather Report" feature that indicates the stability of builds over time.
Docker provides the `docker stats` command which is integrated into our monitoring
dashboard to track CPU, Memory, and Network I/O in real-time. This proactive approach
allows us to detect bottlenecks before they affect the end-user experience.
9. CONCLUSION
The project successfully demonstrated the implementation of a modern DevOps workflow.
By automating the integration and deployment stages, we have created a system that is
resilient, repeatable, and efficient.
The key takeaway is that automation is the only way to manage the complexity of modern
software systems. The use of Jenkins and Docker provides a low-cost yet high-performance
solution for small and medium-sized enterprises to adopt DevOps practices. This mini-
project serves as a proof of concept that can be further expanded into a full-scale
microservices architecture.
Project Status: VERIFIED & COMPLETE
10. LIMITATIONS
While the current system is robust, certain technical limitations exist that should be
addressed in future iterations:
• Security Scanning: The current pipeline does not automatically scan the Docker
images for OS-level vulnerabilities before deployment.
• Secret Management: Hard-coding credentials for Docker Hub within Jenkins files is
a security risk; a secret vault should be used.
• Zero-Downtime Deployment: The current `docker run` command causes a few
seconds of downtime while the container switches.
• Storage Persistence: Being a containerized app, any data stored within the container
is lost if the container is deleted, requiring external volume mapping.
Future work will involve integrating Kubernetes for better orchestration and SonarQube for
static code analysis.
11. RESULT
The primary result of this project is a fully functional web server that updates itself
automatically. When a change is made to the HTML source, the website reflects the update
within 45 seconds without manual intervention.
✓ 100% BUILD SUCCESS
Application Endpoint: [Link]
Docker Container Status: RUNNING (UP 24 Hours)
The console logs from Jenkins confirm that every stage—Checkout, Build, and Deploy—
was executed successfully. The Docker image was correctly pushed to the repository and the
local server was updated with the latest version of the application.
NAME:GOKUL K
CLASS:[Link] (IT)-A
SUBJECT:DEVOPS
NAME:DINESH BABU.R
CLASS:[Link] (IT-A) III YEAR
SUBJECT:DEVOPS