WHAT IS JENKINS-
Imagine you’re building a project with your team, and every time someone makes a change, you have to manually compile the code, run tests, and deploy it. Sounds exhausting, right? That’s where Jenkins comes in, it’s like your tireless teammate who automates all of that for you.
Jenkins is an open-source automation server that helps developers and DevOps teams build, test, and deploy software faster and more reliably. Think of it as the backbone of your CI/CD pipeline: whenever you push code, Jenkins can automatically kick off a series of steps, like compiling, testing, packaging, and even deploying your app, without you lifting a finger.
It’s highly customizable, integrates with almost every tool you can think of (Git, Docker, Kubernetes, Maven, you name it), and supports both simple jobs and complex workflows. Whether you’re a solo developer or part of a large engineering team, Jenkins helps you catch bugs early, ship faster, and sleep better at night knowing your builds are in good hands.
Integrating Docker with Jenkins is a powerful way to automate the building, testing, and deployment of containerized applications.
BENEFITS OF INTEGRATING DOCKER WITH JENKINS-
1. Consistent Build Environments– Docker ensures that every Jenkins job runs in the exact same environment, reducing the chances of “it works on my machine” issues.
2. Fast Setup and Cleanup– Containers spin up quickly and are destroyed after use, allowing Jenkins to run isolated builds without leftover dependencies.
3. Parallel Execution– Multiple builds or test jobs can run simultaneously in separate containers, which speeds up the CI/CD pipeline significantly.
4. Flexible Toolchain Usage– Each stage of the pipeline can use a different Docker image—Node.js for one step, Python or Java for another—without bloating your Jenkins host.
5. Reliable Rollbacks– Since Docker images are immutable and versioned, you can easily roll back to a previous stable version if something breaks.
6. Clean Jenkins Agents– Using Docker-based agents prevents the Jenkins environment from getting cluttered with build-time tools or temporary files.
7. Enhanced Security– Containers provide isolation between jobs and the host system, minimizing risk from malicious code or configuration errors.
8. Cloud-Native Compatibility– Running Jenkins pipelines in cloud platforms or Kubernetes becomes easier with Docker’s portability and orchestration-friendly design.
9. Infrastructure as Code– You can define your entire build setup in a Dockerfile, making it reproducible, version-controlled, and easy to share.
10. Simplified Dependency Management– Build tools and runtime environments can be bundled inside containers, reducing global installs and setup time across different environments.
BASIC JENKINS ARCITECTURE
1. Jenkins Master
- Orchestrates the CI/CD pipeline.
- Stores pipeline definitions (
Jenkinsfile
), manages plugins, and schedules jobs. - Can be run inside a Docker container or on a VM.
2. Docker Host
- A machine (or VM) with Docker installed.
- Jenkins connects to this host to spin up containers for builds.
- Can be the same as the Jenkins master or a separate node.
3. Docker-Based Build Agents
- Jenkins dynamically launches containers as build agents.
- Each agent runs a specific job in an isolated environment.
- Containers are ephemeral—created for the job and destroyed afterward.
GITLAB CI (CONTINOUS INTEGRATION)-
GitLab CI (Continuous Integration) is GitLab’s built-in automation system that helps you build, test, and deploy your code every time you push changes to your repository. It’s tightly integrated with GitLab, so you don’t need to install anything extra to get started—just create a .gitlab-ci.yml
file in the root of your project, and GitLab takes it from there.
This YAML file defines your pipeline: a series of stages (like build
, test
, deploy
) and jobs (the actual tasks to run in each stage). When you push code, GitLab automatically triggers the pipeline, runs the jobs using runners (agents that execute your scripts), and shows you the results in a visual dashboard.
GitLab CI supports Docker out of the box, parallel execution, caching, artifacts, environment variables, and even manual approvals for deployment. It’s flexible enough for simple projects and powerful enough for complex enterprise workflows.
COMMANDS FOR GITLAB CI/CD
KEYWORD | PURPOSE |
stages | Defines the sequence of pipeline stages (e.g., build, test, deploy) |
script | Shell commands to execute in a job. |
before_script | Commands that run before each job’s main script. |
after_script | Commands that run after each job’s main script. |
image | Specifies the Docker image to use for the job. |
artifacts | Files or directories to save and pass between jobs. |
cache | Defines files or directories to cache between pipeline runs. |
only/ except | Controls when jobs run (e.g., only on main branch). |
rules | Advanced conditions to control job execution. |
variables | Defines environment variables for use in jobs. |
environment | Specifies the environment (e.g., staging, production) for deployment. |
when | Controls job timing (e.g., manual , on_success , always ). |
needs | Allows jobs to run out of stage order if dependencies are met. |
tags | Assigns jobs to specific runners using tags. |
retry | Automatically retries a job on failure, with a specified limit. |
timeout | Sets a custom timeout for a job. |
include | Imports configuration from other YAML files. |
extends | Inherits configuration from another job or template. |