Deploying from CI/CD pipeline in Docker - Step-by-Step Execution

Process Flow - Deploying from CI/CD pipeline

Code Commit

↓

CI Pipeline Trigger

↓

Build Docker Image

↓

Run Tests

↓

Stop

↓

Deploy to Server

↓

Run Container

↓

Deployment Done

This flow shows how code changes trigger a CI/CD pipeline that builds, tests, pushes a Docker image, and deploys it by running a container.

Execution Sample

Docker

git push origin main
# CI triggers
docker build -t myapp:latest .
docker push myapp:latest
ssh deploy@server 'docker pull myapp:latest && docker run -d myapp:latest'

This code pushes changes, triggers CI to build and push a Docker image, then deploys it by pulling and running on the server.

Process Table

Step	Action	Command/Process	Result/Output
1	Code pushed to repo	git push origin main	Triggers CI pipeline start
2	Build Docker image	docker build -t myapp:latest .	Image built successfully
3	Run tests	CI test scripts	Tests pass
4	Push image to registry	docker push myapp:latest	Image uploaded to registry
5	Connect to server	ssh deploy@server	Connected to deployment server
6	Pull image on server	docker pull myapp:latest	Latest image downloaded
7	Run container	docker run -d myapp:latest	Container started in detached mode
8	Deployment complete	N/A	App running on server with new version

💡 Deployment stops after container runs successfully and app is live

Status Tracker

Variable	Start	After Step 2	After Step 4	After Step 7	Final
Docker Image	None	myapp:latest (built)	myapp:latest (pushed)	myapp:latest (pulled on server)	myapp:latest (running container)
Tests Status	Not run	Running	Passed	Passed	Passed
Deployment Status	Not started	Building	Pushing	Running container	Complete

Key Moments - 3 Insights

Why does the deployment stop if tests fail?

Because the pipeline checks test results at step 3; if tests fail, it does not push the image or deploy, preventing broken code from reaching production.

Why do we pull the image on the server after pushing it to the registry?

The server needs the latest image locally to run the updated container; pulling downloads the new image from the registry as shown in step 6.

What does running the container in detached mode mean?

Detached mode (step 7) means the container runs in the background, so the deployment process can continue without waiting for the container to stop.

Visual Quiz - 3 Questions

Look at the execution table, what is the status of tests at step 3?

A Tests pass

B Tests fail

C Tests not started

D Tests skipped

💡 Hint

Check the 'Result/Output' column for step 3 in the execution table.

At which step does the Docker image get uploaded to the registry?

A Step 2

B Step 4

C Step 6

D Step 7

💡 Hint

Look for the action 'Push image to registry' in the execution table.

If tests fail at step 3, what happens next in the pipeline?

A Image is pushed and deployed anyway

B Container runs with old image

C Pipeline stops and deployment does not continue

D Server pulls old image

💡 Hint

Refer to the key moment about test failure stopping deployment and the flow diagram.

Concept Snapshot

Deploying from CI/CD pipeline:
1. Push code triggers CI pipeline
2. Build Docker image
3. Run tests; stop if fail
4. Push image to registry
5. Deploy by pulling image on server
6. Run container in detached mode
7. Deployment complete and app live

Full Transcript

Deploying from a CI/CD pipeline means automating the process of taking code changes, building a Docker image, testing it, pushing it to a registry, and then deploying it by running a container on a server. The flow starts when code is pushed to the repository, triggering the CI pipeline. The pipeline builds the Docker image and runs tests. If tests pass, the image is pushed to a registry. Then the deployment server pulls the latest image and runs it as a container in detached mode. This process ensures that only tested and verified code is deployed, making deployment reliable and repeatable.

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