Why Docker in CI/CD matters - Why It Works

Introduction

CI/CD pipelines automate software building and delivery. Docker helps by packaging apps with everything they need, so they run the same everywhere. This solves problems of different environments causing bugs.

When you want to ensure your app runs the same on your laptop, test server, and production.

When you need to speed up testing by running isolated app versions quickly.

When you want to avoid 'it works on my machine' problems during deployment.

When you want to easily roll back to a previous app version if something breaks.

When you want to share your app environment with teammates without setup hassle.

Commands

This command builds a Docker image named 'my-app' with tag '1.0' from the current folder. It packages your app and its environment for consistent runs.

Terminal

docker build -t my-app:1.0 .

Expected Output

Sending build context to Docker daemon  5.12MB

Step 1/5 : FROM python:3.10-slim

 ---> 123abc456def

Step 2/5 : WORKDIR /app

 ---> Using cache

 ---> 789def123abc

Step 3/5 : COPY . /app

 ---> Using cache

 ---> 456abc789def

Step 4/5 : RUN pip install -r requirements.txt

 ---> Running in 1a2b3c4d5e6f

Collecting flask

Installing collected packages: flask

Successfully installed flask-2.1.0

Removing intermediate container 1a2b3c4d5e6f

 ---> 0f1e2d3c4b5a

Step 5/5 : CMD ["python", "app.py"]

 ---> Running in 7f8e9d0c1b2a

Removing intermediate container 7f8e9d0c1b2a

 ---> 9a8b7c6d5e4f

Successfully built 9a8b7c6d5e4f

Successfully tagged my-app:1.0

→

-t - Names and tags the image for easy reference

Runs the Docker image 'my-app:1.0' in a container to test the app works as expected before deployment.

Terminal

docker run --rm my-app:1.0

Expected Output

 * Running on http://0.0.0.0:5000/ (Press CTRL+C to quit)

 * Restarting with stat

 * Debugger is active!

 * Debugger PIN: 123-456-789

→

--rm - Automatically removes the container after it stops to keep the system clean

Uploads the Docker image to a remote registry so the CI/CD pipeline or production servers can pull the exact app version.

Terminal

docker push my-app:1.0

Expected Output

The push refers to repository [docker.io/library/my-app]

9a8b7c6d5e4f: Pushed 

1.0: digest: sha256:abcdef1234567890 size: 1234

Downloads the Docker image from the registry to the deployment server, ensuring the app runs exactly as built in CI.

Terminal

docker pull my-app:1.0

Expected Output

1.0: Pulling from library/my-app

Digest: sha256:abcdef1234567890

Status: Downloaded newer image for my-app:1.0

Key Concept

If you remember nothing else from this pattern, remember: Docker packages your app and its environment so CI/CD pipelines deliver consistent, reliable software everywhere.

Common Mistakes

Not tagging Docker images with version numbers

Without tags, it's hard to track which app version is deployed or tested, causing confusion and errors.

Always use meaningful tags like version numbers or commit hashes when building images.

Skipping the test run of the Docker image before pushing

You might push broken images to the registry, causing failures in later pipeline stages or production.

Run the image locally with 'docker run' to verify it works before pushing.

Not pushing the image to a registry accessible by deployment servers

Deployment servers cannot pull the image, so the app won't deploy correctly.

Push images to a shared registry like Docker Hub or a private registry accessible by all pipeline stages.

Summary

Build a Docker image to package your app and its environment.

Run the image locally to test it works before deployment.

Push the image to a registry so CI/CD and production can use the exact app version.

Pull the image on deployment servers to ensure consistent app runs.