Docker CI/CD Integration

# CHAPTER 17

Docker CI/CD Integration #

1. Introduction #

2. Learning Objectives #

• Define Continuous Integration (CI) and Continuous Deployment (CD).

• Understand the role of Docker in a CI/CD pipeline.

• Identify popular CI/CD platforms (GitHub Actions, Jenkins, GitLab CI).

• Architect an automated image building pipeline.

• Understand automated deployment triggers.

3. Beginner-Friendly Explanation #

• Manual Workflow: An author writes a book. They print the pages, drive to the factory, bind the book by hand, drive to the bookstore, and place it on the shelf.

• CI/CD Workflow: The author writes the book and drops the manuscript in a digital inbox (GitHub).

• The CI Robot (Testing): Instantly picks up the manuscript, scans it for spelling errors, and automatically binds it into a finished, standardized book (The Docker Image).

• The CD Robot (Deployment): Takes the finished book and teleports it directly onto the shelves of 1,000 bookstores worldwide simultaneously. The author never leaves their desk.

4. Continuous Integration (The Build & Test Phase) #

1. 1. A developer pushes code to the main branch on GitHub.

1. 2. The CI server (e.g., GitHub Actions) detects the push.

1. 3. The CI server boots up an invisible, temporary Linux machine.

1. 4. It runs docker build to create the image.

1. 5. It runs automated Unit Tests *inside* the container.

1. 6. If the tests pass, it runs docker login and docker push to upload the verified image to Docker Hub. If the tests fail, it halts the pipeline and emails the developer.

5. Continuous Deployment (The Release Phase) #

1. 1. Pull-based Deployment: A tool on the production server (like Watchtower) polls Docker Hub every 5 minutes. When it sees a newer image tag, it automatically downloads it, kills the old container, and starts the new one.

1. 2. Push-based Deployment: The CI/CD server uses SSH to log directly into the production AWS server, runs docker pull, and executes docker-compose up -d to refresh the stack.

6. GitHub Actions: The Modern Standard #

7. Mini Project: A Docker CI Pipeline (Conceptual) #

Step-by-Step Conceptual Tutorial:

1. 1. In your GitHub repository, create a file: .github/workflows/docker-build.yml.

1. 2. Add the pipeline architecture:

name: Build and Push Docker Image

# Trigger the robot when code is pushed to the 'main' branch
on:
  push:
    branches:
      - main

jobs:
  build:
    runs-on: ubuntu-latest # The invisible server provided by GitHub
    
    steps:
      - name: Checkout Code
        uses: actions/checkout@v3

      - name: Login to Docker Hub
        uses: docker/login-action@v2
        with:
          username: ${{ secrets.DOCKERHUB_USERNAME }}
          password: ${{ secrets.DOCKERHUB_TOKEN }}

      - name: Build and Push
        uses: docker/build-push-action@v4
        with:
          context: .
          push: true
          tags: yourusername/my-app:latest

1. 3. In your GitHub repository settings, you securely store your Docker Hub password in the "Secrets" vault.

1. 4. You commit a change to your HTML code.

1. 5. The Magic: Go to the "Actions" tab in GitHub. You will watch the robot automatically execute the steps, log into Docker Hub, build your image, and push it. Your new code is published in 45 seconds!

8. Real-World Scenarios #

9. Best Practices #

• Immutable Tags: Never use the :latest tag in a CI/CD deployment pipeline. If you rollback a server, and both the broken code and the working code are tagged :latest, the server won't know the difference. The best practice is to tag the image with the unique Git Commit Hash (e.g., my-app:a1b2c3d). This creates a mathematically unique, immutable version history.

10. Common Mistakes #

• Bloated Build Contexts: When the CI server runs docker build, it sends the entire directory to the Docker Daemon. If you accidentally include a 5GB node_modules folder or hidden .git history, the pipeline will take 10 minutes just to start! Always use a .dockerignore file (exactly like .gitignore) to exclude massive folders from the build process.

11. Exercises #

1. 1. What is the primary purpose of executing automated testing (CI) *before* executing the docker push command in a deployment pipeline?

1. 2. Explain why storing the Docker Hub password in the GitHub Repository "Secrets" vault is required, rather than hardcoding it into the docker-build.yml file.

12. FAQs #

13. Interview Questions #

• Q: Describe the lifecycle of a code commit passing through a modern Docker-centric CI/CD pipeline. Identify the specific fail-safes designed to prevent buggy code from reaching production.

• Q: Explain the necessity of utilizing a .dockerignore file within an automated build pipeline. How does ignoring local dependency folders impact image size and build execution times?

14. Summary #

15. Next Chapter Recommendation #