Building images in CI pipeline in Docker - Commands & Configuration

Introduction

Building images in a CI pipeline automates creating container images whenever code changes. This ensures your app is always packaged and ready to run in any environment without manual steps.

When you want to automatically create a new app version image after every code update.

When you need to test your app inside a container before deploying it.

When you want to push the built image to a registry for sharing or deployment.

When you want to catch build errors early by building images in a controlled environment.

When you want to keep your deployment process consistent and repeatable.

Config File - Dockerfile

Dockerfile

FROM python:3.11-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
CMD ["python", "app.py"]

This Dockerfile starts from a small Python 3.11 image.

It sets the working folder to /app inside the container.

It copies the requirements file and installs Python packages.

Then it copies the app code and sets the command to run the app.

Commands

This command builds a Docker image named 'my-app-image' with tag '1.0' from the current folder where the Dockerfile is located.

Terminal

docker build -t my-app-image:1.0 .

Expected Output

Sending build context to Docker daemon  12.3MB

Step 1/5 : FROM python:3.11-slim

 ---> 123abc456def

Step 2/5 : WORKDIR /app

 ---> Using cache

 ---> 789def012abc

Step 3/5 : COPY requirements.txt .

 ---> Using cache

 ---> 345abc678def

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

 ---> Running in 456def789abc

Collecting flask

Installing collected packages: flask

Successfully installed flask-2.2.2

Removing intermediate container 456def789abc

 ---> 901abc234def

Step 5/5 : COPY . .

 ---> 567def890abc

Successfully built 567def890abc

Successfully tagged my-app-image:1.0

→

-t - Assigns a name and tag to the image for easy reference.

This command lists the Docker images filtered by the name 'my-app-image' to verify the image was built successfully.

Terminal

docker images my-app-image

Expected Output

REPOSITORY      TAG       IMAGE ID       CREATED          SIZE

my-app-image    1.0       567def890abc   10 seconds ago   120MB

This runs the built image in a container to test if the app starts correctly. The --rm flag removes the container after it stops.

Terminal

docker run --rm my-app-image:1.0

Expected Output

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

→

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

Key Concept

If you remember nothing else from this pattern, remember: building images in CI automates packaging your app so it runs the same everywhere.

Common Mistakes

Not specifying the build context as '.' in the docker build command.

Docker won't find the Dockerfile or app files, causing the build to fail.

Always include '.' at the end of 'docker build' to specify the current folder as context.

Forgetting to tag the image with -t during build.

Without a tag, the image gets a random ID making it hard to reference later.

Use '-t name:tag' to give your image a clear name and version.

Running the image without testing it first.

You might deploy a broken image if you don't verify it runs correctly.

Run the image locally with 'docker run' to confirm it works before pushing or deploying.

Summary

Use 'docker build -t name:tag .' to create a container image from your app code.

Verify the image exists with 'docker images name'.

Test the image by running it with 'docker run --rm name:tag' to ensure it works.

Practice

1. What is the main purpose of building Docker images in a CI pipeline?

easy

A. To automate packaging the app for consistent deployment

B. To manually upload files to the server

C. To write application code faster

D. To monitor server health

Solution

1. Step 1: Understand CI pipeline role

   CI pipelines automate tasks like testing and packaging to ensure consistency.

2. Step 2: Identify Docker image purpose

   Docker images package the app and its environment for reliable deployment.

3. Final Answer:

   To automate packaging the app for consistent deployment -> Option A

4. Quick Check:

   CI builds images to package apps consistently [OK]

Hint: CI builds images to package apps consistently [OK]

Common Mistakes:

• Confusing image building with code writing
• Thinking CI uploads files manually
• Mixing deployment with monitoring

2. Which of the following is the correct command to build a Docker image named myapp with tag v1 from the current directory?

easy

A. docker build -t myapp:v1 .

B. docker create -t myapp:v1 .

C. docker run -t myapp:v1 .

D. docker push -t myapp:v1 .

Solution

1. Step 1: Identify Docker build syntax

   The correct syntax to build an image is docker build -t name:tag path.

2. Step 2: Match command to syntax

   docker build -t myapp:v1 . uses docker build -t myapp:v1 . which matches the syntax and current directory.

3. Final Answer:

   docker build -t myapp:v1 . -> Option A

4. Quick Check:

   Build command uses 'docker build -t name:tag path' [OK]

Hint: Use 'docker build -t name:tag path' to build images [OK]

Common Mistakes:

• Using 'docker create' instead of 'docker build'
• Confusing 'docker run' with building images
• Trying to push before building

3. Given this CI script snippet:

docker build -t myapp:latest .
docker tag myapp:latest myapp:build-123

What will be the result after running these commands?

medium

A. An error because tagging must happen before building

B. Only one image named 'myapp:build-123' exists

C. Two images: 'myapp:latest' and 'myapp:build-123' pointing to the same image

D. Two images with different contents

Solution

1. Step 1: Understand docker build output

   The build creates an image tagged 'myapp:latest'.

2. Step 2: Understand docker tag effect

   Tagging 'myapp:latest' as 'myapp:build-123' creates a new tag pointing to the same image.

3. Final Answer:

   Two images: 'myapp:latest' and 'myapp:build-123' pointing to the same image -> Option C

4. Quick Check:

   Tag duplicates image reference, no new image created [OK]

Hint: Tagging duplicates image reference, no new image built [OK]

Common Mistakes:

• Thinking tagging creates a new image
• Assuming error if tag after build
• Believing images have different contents after tag

4. A CI pipeline script has this line:

docker build -t myapp .

But the build fails with error: "Cannot locate Dockerfile". What is the likely cause?

medium

A. The tag name 'myapp' is invalid

B. Dockerfile is missing in the current directory

C. The docker daemon is not running

D. The build command syntax is wrong

Solution

1. Step 1: Analyze error message

   "Cannot locate Dockerfile" means Docker can't find the Dockerfile in the build context.

2. Step 2: Check build context and files

   Since the path is '.', Docker expects a Dockerfile in the current directory, which is missing.

3. Final Answer:

   Dockerfile is missing in the current directory -> Option B

4. Quick Check:

   Missing Dockerfile causes this error [OK]

Hint: Check Dockerfile presence in build directory [OK]

Common Mistakes:

• Blaming tag name for Dockerfile error
• Assuming daemon not running without checking
• Thinking build syntax is incorrect

5. In a CI pipeline, you want to tag Docker images with the build number stored in the environment variable BUILD_ID. Which command correctly builds and tags the image myapp with this dynamic tag?

hard

A. docker build -t 'myapp:${BUILD_ID}' .

B. docker build -t myapp:BUILD_ID .

C. docker build -t myapp:$(BUILD_ID) .

D. docker build -t myapp:$BUILD_ID .

Solution

1. Step 1: Understand shell variable syntax

   In shell scripts, environment variables are accessed with $VAR or ${VAR}.

2. Step 2: Identify correct variable usage in command

   docker build -t myapp:$BUILD_ID . uses $BUILD_ID which is valid and common in CI scripts.

3. Final Answer:

   docker build -t myapp:$BUILD_ID . -> Option D

4. Quick Check:

   Use $VAR to insert env variable in commands [OK]

Hint: Use $VAR to insert env variable in commands [OK]

Common Mistakes:

• Using literal 'BUILD_ID' instead of variable
• Using incorrect syntax like $(BUILD_ID)
• Forgetting to expand variable in tag