Pushing images from CI in Docker - Commands & Configuration

Introduction

When you build software, you often create a package called a container image. Pushing images from CI means automatically sending these images to a storage place called a registry, so others can use them easily.

When you want to automatically update your app's container image after every code change.

When you need to share your container image with your team or deployment systems.

When you want to keep your images safe and organized in a central place.

When you want to avoid manual steps and speed up your release process.

When you want to use the latest image in your testing or production environments.

Commands

This command builds a container image named 'my-app' with the tag '1.0' from the current folder. It packages your app code and dependencies.

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 : COPY . /app

 ---> Using cache

 ---> 789def123abc

Step 3/5 : WORKDIR /app

 ---> Using cache

 ---> 456abc789def

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

 ---> Using cache

 ---> 321fed654cba

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

 ---> Using cache

 ---> 654fed321cba

Successfully built 654fed321cba

Successfully tagged my-app:1.0

→

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

This command logs you into the container registry so you can upload images securely.

Terminal

docker login -u myuser -p mypassword registry.example.com

Expected Output

Login Succeeded

→

-u - Specifies the username for the registry.

→

-p - Specifies the password for the registry.

This command tags your local image with the registry address and your username, preparing it for upload.

Terminal

docker tag my-app:1.0 registry.example.com/myuser/my-app:1.0

Expected Output

No output (command runs silently)

This command uploads your tagged image to the registry so others can download and use it.

Terminal

docker push registry.example.com/myuser/my-app:1.0

Expected Output

The push refers to repository [registry.example.com/myuser/my-app]

1.0: Pushed

This command logs you out from the registry to keep your credentials safe after pushing.

Terminal

docker logout registry.example.com

Expected Output

Removing login credentials for registry.example.com

Key Concept

If you remember nothing else from this pattern, remember: build your image, log in to your registry, tag your image with the registry path, push it, then log out.

Common Mistakes

Trying to push an image without logging into the registry first.

The registry will reject the upload because it does not recognize you as an authorized user.

Always run 'docker login' with your credentials before pushing images.

Pushing an image without tagging it with the registry address.

Docker will try to push to the default Docker Hub instead of your intended registry, causing errors or pushing to the wrong place.

Tag your image with the full registry path before pushing.

Using the 'latest' tag unintentionally or without versioning.

It can cause confusion about which image version is deployed and may overwrite important versions.

Use explicit version tags like '1.0' to keep track of image versions.

Summary

Build your container image with 'docker build' and assign a clear tag.

Log in to your container registry using 'docker login' to authenticate.

Tag your image with the full registry path before pushing.

Push the image to the registry with 'docker push' so it can be shared.

Log out from the registry after pushing to keep credentials safe.

Practice

1. What is the main purpose of pushing Docker images from a CI pipeline?

easy

A. To delete old images from the local Docker cache

B. To run containers automatically on the local machine

C. To upload built images to a remote registry for sharing and deployment

D. To build images only on the developer's computer

Solution

1. Step 1: Understand CI pipeline role

   A CI pipeline automates building and testing code changes, including Docker images.

2. Step 2: Purpose of pushing images

   Pushing images uploads them to a remote registry so others can use or deploy them.

3. Final Answer:

   To upload built images to a remote registry for sharing and deployment -> Option C

4. Quick Check:

   Pushing images = Upload to registry [OK]

Hint: Pushing means sending images to a remote place [OK]

Common Mistakes:

• Confusing pushing with running containers
• Thinking pushing deletes images
• Assuming pushing only builds images locally

2. Which command correctly pushes a Docker image named myapp:latest to Docker Hub in a CI script?

easy

A. docker publish myapp:latest

B. docker upload myapp:latest

C. docker send myapp:latest

D. docker push myapp:latest

Solution

1. Step 1: Identify Docker push syntax

   The correct command to upload images to a registry is docker push <image>.

2. Step 2: Verify other options

   Commands like upload, send, and publish are not valid Docker commands.

3. Final Answer:

   docker push myapp:latest -> Option D

4. Quick Check:

   Push = docker push [OK]

Hint: Use 'docker push' to send images to registry [OK]

Common Mistakes:

• Using 'docker upload' instead of 'docker push'
• Confusing push with publish or send commands
• Missing image tag in push command

3. Given this CI script snippet:

docker build -t myuser/myapp:1.0 .
docker login -u myuser -p $DOCKER_PASS
docker push myuser/myapp:1.0

What will happen if $DOCKER_PASS is empty?

medium

A. The push will fail due to authentication error

B. The image will push successfully without login

C. The build command will fail before push

D. The image will be pushed anonymously

Solution

1. Step 1: Understand docker login with empty password

   If $DOCKER_PASS is empty, login will fail because no valid password is provided.

2. Step 2: Effect on docker push

   Without successful login, pushing to Docker Hub requires authentication and will fail.

3. Final Answer:

   The push will fail due to authentication error -> Option A

4. Quick Check:

   Empty password = login fail = push fail [OK]

Hint: Empty password means login fails, so push fails [OK]

Common Mistakes:

• Assuming push works without login
• Thinking build fails due to empty password
• Believing anonymous push is allowed

4. You have this CI step:

docker push myuser/myapp:latest

But the push fails with denied: requested access to the resource is denied. What is the most likely cause?

medium

A. The image tag latest is invalid

B. You forgot to run docker login before pushing

C. The Dockerfile has syntax errors

D. The Docker daemon is not running

Solution

1. Step 1: Analyze error message meaning

   The error means Docker Hub denied access, usually due to missing or wrong authentication.

2. Step 2: Check common causes

   Not running docker login before push is the most common cause of access denial.

3. Final Answer:

   You forgot to run docker login before pushing -> Option B

4. Quick Check:

   Access denied = missing login [OK]

Hint: Always login before pushing images [OK]

Common Mistakes:

• Blaming image tag for access denied
• Assuming Dockerfile errors cause push failure
• Ignoring Docker daemon status

5. In a CI pipeline, you want to push a Docker image only if the build and tests succeed. Which is the best way to ensure this?

hard

A. Add a separate job that depends on build and test jobs and pushes the image

B. Push the image immediately after the build step without waiting for tests

C. Push the image before running tests to save time

D. Push the image manually after the pipeline finishes

Solution

1. Step 1: Understand CI job dependencies

   To push only after build and tests succeed, create a job that runs after those jobs complete successfully.

2. Step 2: Why other options fail

   Pushing before tests risks pushing broken images; manual push loses automation benefits.

3. Final Answer:

   Add a separate job that depends on build and test jobs and pushes the image -> Option A

4. Quick Check:

   Push after success = dependent job [OK]

Hint: Use dependent jobs to control push timing [OK]

Common Mistakes:

• Pushing before tests complete
• Manual push breaks automation
• Ignoring job dependencies in CI