Continuous Integration with Docker

# CHAPTER 9

Continuous Integration with Docker #

1. Introduction #

2. Learning Objectives #

• Understand the operational benefits of executing CI pipelines inside Docker containers.

• Differentiate between the CI Runner host and the Docker Container environment.

• Use Docker to execute test suites in isolated environments.

• Build a Docker Image as the final Build Artifact of a CI pipeline.

• Push a Docker Image to a Container Registry (e.g., Docker Hub) using GitHub Actions.

3. Beginner-Friendly Explanation #

• The Problem: The Chef is baking a delicate cake, but someone else just chopped onions on the same cutting board. The cake tastes like onions. (Software conflicts on a shared CI server).

• The Docker Solution: The Chef brings their own impenetrable, plastic bubble to work. Inside the bubble is a brand new, perfectly clean cutting board, the exact brand of flour they need, and an oven set to the exact temperature. They bake the cake inside the bubble. When the cake is done, the bubble is destroyed.

Docker ensures your code is built and tested in a perfectly sterile, custom-made environment, completely isolated from the CI server it runs on.

4. Running Tests Inside Docker #

jobs:
  test-in-docker:
    runs-on: ubuntu-latest
    
    # This forces the ENTIRE job to run inside a specific Docker container!
    container:
      image: php:8.1-cli 
      
    steps:
      - uses: actions/checkout@v4
      
      # We don't need 'setup-php' because PHP is already in the container!
      - name: Verify Environment
        run: php -v
        
      # (Install zip/unzip which Composer needs, then run Composer and PHPUnit)

5. Docker as the Final Artifact #

If we build a Docker image, the goal of the CI pipeline is to execute docker build, and then upload that image to a Container Registry (like Docker Hub or AWS ECR) so the Production servers can download it later.

6. Mini Project: Build and Push Docker CI Workflow #

Step-by-Step Architecture Concept:

1. 1. Ensure your repository has a valid Dockerfile at its root.

1. 2. Store your Docker Hub username and password in GitHub Secrets.

1. 3. Create the Workflow:

name: Docker Build and Push Pipeline

on:
  push:
    branches: [ "main" ]

jobs:
  build-container:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout Code
        uses: actions/checkout@v4

      # 1. Login to the Docker Registry securely
      - name: Log in to Docker Hub
        uses: docker/login-action@v3
        with:
          username: ${{ secrets.DOCKER_USERNAME }}
          password: ${{ secrets.DOCKER_PASSWORD }}

      # 2. Build the Docker Image AND Push it to the Registry
      - name: Build and Push Docker Image
        uses: docker/build-push-action@v5
        with:
          context: .
          push: true # This tells it to upload the image!
          # Tag the image with the GitHub commit hash for unique versioning
          tags: myusername/myapp:${{ github.sha }}

*When this finishes, your fully compiled application, along with its entire operating system environment, is safely stored in Docker Hub, ready to be deployed anywhere in the world.*

7. Real-World Scenarios #

8. Best Practices #

• Tagging with the Commit Hash (github.sha): In the mini-project, we tagged the Docker image with ${{ github.sha }}. This is a crucial best practice. Never just tag an image as latest. If you deploy latest, and it breaks, and you try to rollback to the previous latest... you can't, because it was overwritten. Tagging images with the unique Git commit hash creates a permanent, traceable link between the Docker Image in production and the exact code commit in GitHub.

9. Security Recommendations #

• Scanning Docker Images: Just because an application is in a container doesn't mean it is secure. The base image (e.g., ubuntu:20.04) might contain critical vulnerabilities. Modern CI pipelines include a step *after* the docker build but *before* the push to run a container vulnerability scanner like Trivy or Clair. If the scanner finds a critical CVE (vulnerability) in the Docker image, it fails the pipeline and blocks the upload to the registry.

10. Troubleshooting Tips #

• Docker in Docker (DinD): If you are running a self-hosted Jenkins server *inside* a Docker container, and you try to run docker build inside your Jenkins pipeline, it will fail because a container cannot easily run Docker commands inside itself. You must map the host's Docker socket (/var/run/docker.sock) into the Jenkins container to allow the pipeline to communicate with the host's Docker engine.

11. Exercises #

1. 1. Explain the operational difference between compiling a release.zip Artifact and compiling a Docker Image Artifact in a CI pipeline.

1. 2. What is the operational purpose of a Container Registry (like Docker Hub) in the CI/CD lifecycle?

12. FAQs #

13. Interview Questions #

• Q: Describe the environmental and consistency benefits of executing CI testing and build stages inside a Docker Container rather than directly on the bare-metal CI Runner.

• Q: Explain the enterprise best practice for versioning/tagging Docker images during a CI build phase. Why is the latest tag considered an anti-pattern for production deployments?

14. Summary #

15. Next Chapter Recommendation #