Deploying from CI/CD pipeline in Docker - Commands & Configuration

Introduction

Deploying from a CI/CD pipeline means automatically building and sending your app to a server or cloud when you update your code. This saves time and avoids mistakes from doing it by hand.

When you want your app to update automatically after you push code changes to your repository

When you want to build a new version of your app image and run it without manual steps

When you want to test your app in a clean environment every time you change code

When you want to avoid forgetting steps or making errors during deployment

When you want to deliver updates faster and more reliably to users

Config File - docker-compose.yml

docker-compose.yml

version: '3.8'
services:
  webapp:
    image: my-app:latest
    ports:
      - "8080:80"
    restart: always

This docker-compose.yml file defines a service named webapp that runs the my-app:latest Docker image. It maps port 8080 on your machine to port 80 inside the container, so you can access the app in a browser at localhost:8080. The restart: always ensures the container restarts automatically if it stops.

Commands

This command builds a Docker image named 'my-app' with the 'latest' tag from the current folder. It packages your app and its environment into one image.

Terminal

docker build -t my-app:latest .

Expected Output

Sending build context to Docker daemon  10.24MB

Step 1/5 : FROM python:3.10-slim

 ---> 123abc456def

Step 2/5 : COPY . /app

 ---> Using cache

Step 3/5 : WORKDIR /app

 ---> Using cache

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

 ---> Using cache

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

 ---> Using cache

Successfully built abcdef123456

Successfully tagged my-app:latest

This command starts the services defined in the docker-compose.yml file in detached mode, running your app in the background.

Terminal

docker-compose up -d

Expected Output

Creating network "default" with the default driver

Creating webapp ... done

→

-d - Run containers in the background (detached mode)

This command lists running Docker containers so you can check if your app container is running.

Terminal

docker ps

Expected Output

CONTAINER ID   IMAGE          COMMAND                  CREATED          STATUS          PORTS                  NAMES

abcdef123456   my-app:latest  "python app.py"          10 seconds ago   Up 9 seconds    0.0.0.0:8080->80/tcp   myproject_webapp_1

This command shows the live logs of your app container so you can see what it is doing or if there are errors.

Terminal

docker-compose logs -f

Expected Output

Attaching to myproject_webapp_1

webapp_1  | Starting app...

webapp_1  | App running on port 80

→

-f - Follow log output live

Key Concept

If you remember nothing else from this pattern, remember: automate building and running your app with Docker commands in your CI/CD pipeline to deploy reliably and quickly.

Common Mistakes

Not tagging the Docker image with a consistent name and tag

The pipeline won't know which image to deploy or may deploy an old version

Always use a clear image name and tag like 'my-app:latest' or version numbers

Running 'docker-compose up' without '-d' in CI/CD

The command will block the pipeline and never finish because it runs in the foreground

Use 'docker-compose up -d' to run containers in the background

Not checking container status with 'docker ps' after deployment

You might miss that the container failed to start or crashed

Always verify running containers with 'docker ps' to confirm deployment success

Summary

Build your Docker image with 'docker build' to package your app.

Use 'docker-compose up -d' to start your app container in the background.

Check running containers with 'docker ps' to confirm deployment.

Follow logs with 'docker-compose logs -f' to monitor your app.

Practice

1. What is the main purpose of using a CI/CD pipeline when deploying Docker applications?

easy

A. To manually update Docker images on each server

B. To write Dockerfiles faster

C. To automate building, testing, and deploying Docker containers

D. To monitor server hardware performance

Solution

1. Step 1: Understand CI/CD pipeline role

   A CI/CD pipeline automates repetitive tasks like building and deploying software.

2. Step 2: Apply to Docker deployment

   For Docker apps, it automates building images, pushing them, and deploying containers.

3. Final Answer:

   To automate building, testing, and deploying Docker containers -> Option C

4. Quick Check:

   Automation = CI/CD pipeline purpose [OK]

Hint: CI/CD pipelines automate repetitive Docker deployment tasks [OK]

Common Mistakes:

• Thinking CI/CD is for manual updates
• Confusing CI/CD with monitoring tools
• Believing CI/CD only speeds up coding

2. Which of the following is the correct Docker command to push an image to a registry in a CI/CD pipeline?

easy

A. docker run myimage:latest

B. docker pull myimage:latest

C. docker build myimage:latest

D. docker push myimage:latest

Solution

1. Step 1: Identify the command to upload images

   The docker push command uploads images to a registry.

2. Step 2: Confirm correct syntax

   docker push myimage:latest correctly pushes the image tagged 'latest'.

3. Final Answer:

   docker push myimage:latest -> Option D

4. Quick Check:

   Push = upload image [OK]

Hint: Push uploads images; pull downloads images [OK]

Common Mistakes:

• Using pull instead of push to upload
• Using build or run commands to push
• Missing image tag in push command

3. Given this snippet in a CI/CD pipeline YAML file:

steps:
  - name: Build image
    run: docker build -t myapp:1.0 .
  - name: Push image
    run: docker push myapp:1.0
  - name: Deploy
    run: kubectl set image deployment/myapp myapp=myapp:1.0

What will happen after this pipeline runs successfully?

medium

A. The Kubernetes deployment will update to use the new Docker image tagged 1.0

B. The Docker image will be deleted from the registry

C. The deployment will roll back to the previous image

D. The Docker image will only be built locally without pushing

Solution

1. Step 1: Analyze build and push steps

   The pipeline builds the image tagged 'myapp:1.0' and pushes it to the registry.

2. Step 2: Analyze deployment step

   The command updates the Kubernetes deployment to use the new image 'myapp:1.0'.

3. Final Answer:

   The Kubernetes deployment will update to use the new Docker image tagged 1.0 -> Option A

4. Quick Check:

   Build + push + deploy = update deployment [OK]

Hint: Build, push, then deploy updates the app [OK]

Common Mistakes:

• Assuming image is only local, not pushed
• Thinking deployment rolls back automatically
• Confusing deployment update with image deletion

4. A CI/CD pipeline fails at the deployment step with the error: kubectl: error: no deployment found. What is the most likely cause?

medium

A. The Docker image failed to build

B. The Kubernetes deployment name is incorrect or missing

C. The Docker push command was missing

D. The pipeline YAML syntax is invalid

Solution

1. Step 1: Understand the error message

   The error says no deployment found, meaning Kubernetes cannot find the named deployment.

2. Step 2: Identify cause in deployment step

   This usually happens if the deployment name in the kubectl set image command is wrong or missing.

3. Final Answer:

   The Kubernetes deployment name is incorrect or missing -> Option B

4. Quick Check:

   No deployment found = wrong deployment name [OK]

Hint: Check deployment name spelling in kubectl command [OK]

Common Mistakes:

• Blaming build or push steps for deployment error
• Ignoring error details about deployment not found
• Assuming YAML syntax error without checking logs

5. You want to deploy a new version of your Docker app automatically only if tests pass in your CI/CD pipeline. Which sequence of steps is best to ensure this?

hard

A. Run tests -> Build Docker image -> Push image -> Deploy to production

B. Build Docker image -> Push image -> Run tests -> Deploy to production

C. Push image -> Run tests -> Build Docker image -> Deploy to production

D. Deploy to production -> Run tests -> Build Docker image -> Push image

Solution

1. Step 1: Understand the logical order for safe deployment

   Tests must run first to verify code correctness before building and deploying.

2. Step 2: Confirm correct step sequence

   After tests pass, build the Docker image, push it to the registry, then deploy to production.

3. Final Answer:

   Run tests -> Build Docker image -> Push image -> Deploy to production -> Option A

4. Quick Check:

   Tests first, then build, push, deploy [OK]

Hint: Always test before building and deploying [OK]

Common Mistakes:

• Building or pushing before tests pass
• Deploying before tests run
• Running tests after deployment