GitLab CI with Docker - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to specify the Docker image used in the GitLab CI job.

Docker

image: [1]

Drag options to blanks, or click blank then click option'

Adocker:latest

Bubuntu:20.04

Cpython:3.12

Dnode:latest

Attempts:

3 left

💡 Hint

Common Mistakes

Using an image without Docker installed, so Docker commands fail.

Choosing an unrelated image like node or python when Docker is needed.

The image keyword in GitLab CI specifies the Docker image to use for the job. Using docker:latest allows Docker commands inside the job.

2fill in blank

medium

Complete the code to enable Docker commands in the GitLab CI job by specifying the service.

Docker

services:
  - [1]

Drag options to blanks, or click blank then click option'

Apostgres:latest

Bdocker:latest

Cubuntu:20.04

Ddocker:dind

Attempts:

3 left

💡 Hint

Common Mistakes

Using the main Docker image as a service instead of the Docker-in-Docker service.

Using unrelated services like Postgres.

The docker:dind service runs Docker-in-Docker, allowing Docker commands to run inside the CI job.

3fill in blank

hard

Fix the error in the GitLab CI job to allow Docker commands by setting the correct variable.

Docker

variables:
  [1]: "/certs"

Drag options to blanks, or click blank then click option'

ADOCKER_DRIVER

BDOCKER_HOST

CDOCKER_TLS_CERTDIR

DDOCKER_TLS_VERIFY

Attempts:

3 left

💡 Hint

Common Mistakes

Setting unrelated Docker environment variables that do not enable TLS certs.

Omitting this variable causing Docker commands to fail.

Setting DOCKER_TLS_CERTDIR to "/certs" enables TLS certificates for secure Docker daemon communication in GitLab CI.

4fill in blank

hard

Fill both blanks to define a job that builds a Docker image and pushes it to a registry.

Docker

build_image:
  stage: build
  script:
    - docker build -t [1] .
    - docker push [2]

Drag options to blanks, or click blank then click option'

Amyregistry/myimage:latest

Bmyregistry/myimage:stable

Dmyregistry/myimage:dev

Attempts:

3 left

💡 Hint

Common Mistakes

Using different tags for build and push causing push to fail.

Using invalid image tags.

Both build and push commands must use the same image tag to ensure the correct image is pushed.

5fill in blank

hard

Fill all three blanks to define a GitLab CI job that logs in to Docker registry, builds, and pushes an image.

Docker

deploy:
  stage: deploy
  script:
    - echo $[1] | docker login -u $[2] --password-stdin $CI_REGISTRY
    - docker build -t [3] .
    - docker push [3]

Drag options to blanks, or click blank then click option'

A$CI_REGISTRY_PASSWORD

B$CI_REGISTRY_USER

Cmyregistry/myapp:prod

D$CI_REGISTRY_TOKEN

Attempts:

3 left

💡 Hint

Common Mistakes

Mixing up username and password variables.

Using different tags for build and push.

Forgetting to pipe the password to docker login.

The job uses $CI_REGISTRY_PASSWORD to login, $CI_REGISTRY_USER as username, and tags the image consistently for build and push.

Practice

1. What is the main purpose of using docker:dind service in a GitLab CI pipeline?

easy

A. To send notifications after the pipeline finishes

B. To deploy the application to production automatically

C. To run Docker commands inside the CI job container

D. To store build artifacts permanently

Solution

1. Step 1: Understand the role of docker:dind

   The docker:dind (Docker-in-Docker) service allows Docker commands to run inside a container, which is essential for building and managing Docker images during CI jobs.

2. Step 2: Identify the purpose in GitLab CI context

   In GitLab CI, using docker:dind lets the pipeline build, run, and push Docker images isolated from the host system.

3. Final Answer:

   To run Docker commands inside the CI job container -> Option C

4. Quick Check:

   docker:dind = run Docker commands in CI [OK]

Hint: Remember: dind means Docker runs inside Docker [OK]

Common Mistakes:

• Confusing dind with deployment step
• Thinking dind stores artifacts
• Assuming dind sends notifications

2. Which of the following is the correct way to specify the Docker service in a GitLab CI job to enable Docker commands?

easy

A. services:
- docker:dind

B. services:
- docker:latest

C. services:
- docker:build

D. services:
- docker:run

Solution

1. Step 1: Recall the correct service name for Docker-in-Docker

   The official Docker-in-Docker service image is docker:dind, which must be specified exactly to enable Docker commands in GitLab CI.

2. Step 2: Compare options to find exact match

   Only services: - docker:dind uses the correct service name docker:dind. Other options are invalid or do not exist as official images.

3. Final Answer:

   services: - docker:dind -> Option A

4. Quick Check:

   Correct service name = docker:dind [OK]

Hint: Use exact service name 'docker:dind' for Docker commands [OK]

Common Mistakes:

• Using 'docker:latest' instead of 'docker:dind'
• Adding extra tags like 'build' or 'run'
• Omitting the services section

3. Given this GitLab CI job snippet, what will be the output of the docker ps command inside the job?

job:
  image: docker:latest
  services:
    - docker:dind
  script:
    - docker info
    - docker ps

medium

A. Shows an error: Docker daemon not running

B. Lists running containers inside the dind service (likely empty)

C. Lists containers on the host machine

D. Outputs the Docker version only

Solution

1. Step 1: Understand the environment of the job

   The job uses docker:dind service, which runs a Docker daemon inside the CI environment. The docker ps command connects to this daemon.

2. Step 2: Predict the output of docker ps

   Since the job just started and no containers were run inside the dind daemon, docker ps will list running containers inside the dind environment, which is likely empty.

3. Final Answer:

   Lists running containers inside the dind service (likely empty) -> Option B

4. Quick Check:

   docker ps inside dind = running containers (empty if none) [OK]

Hint: docker ps shows containers inside dind, not host [OK]

Common Mistakes:

• Expecting error about Docker daemon
• Thinking it lists host machine containers
• Confusing docker info output with docker ps

4. You have this GitLab CI job configuration:

build:
  image: docker:latest
  script:
    - docker build -t myapp .
  services:
    - docker:dind

The job fails with error: Cannot connect to the Docker daemon. What is the most likely fix?

medium

A. Add variables:
DOCKER_HOST: tcp://docker:2375 to the job

B. Change image to docker:dind

C. Remove the services section

D. Add docker login before build

Solution

1. Step 1: Identify cause of Docker daemon connection error

   The error means the Docker client inside the job cannot reach the Docker daemon running in the docker:dind service container.

2. Step 2: Fix connection by setting DOCKER_HOST variable

   Setting DOCKER_HOST: tcp://docker:2375 tells the Docker client to connect to the dind service over TCP, enabling communication.

3. Final Answer:

   Add variables: DOCKER_HOST: tcp://docker:2375 to the job -> Option A

4. Quick Check:

   Set DOCKER_HOST to connect client to dind daemon [OK]

Hint: Set DOCKER_HOST to tcp://docker:2375 to fix connection [OK]

Common Mistakes:

• Changing image to docker:dind instead of using service
• Removing services section disables Docker daemon
• Adding docker login does not fix daemon connection

5. You want to build a Docker image and push it to GitLab Container Registry in a GitLab CI job. Which snippet correctly sets up the job with Docker-in-Docker and pushes the image?

build_and_push:
  image: docker:latest
  services:
    - docker:dind
  variables:
    DOCKER_HOST: tcp://docker:2375
    DOCKER_TLS_CERTDIR: ""
  script:
    - docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" $CI_REGISTRY
    - docker build -t $CI_REGISTRY_IMAGE:latest .
    - docker push $CI_REGISTRY_IMAGE:latest

hard

A. No docker login command before push

B. Missing DOCKER_HOST variable, so Docker commands fail

C. Uses docker:dind as image instead of service

D. Correct setup with variables and login before build and push

Solution

1. Step 1: Check Docker-in-Docker setup

   The job uses docker:dind as a service and sets DOCKER_HOST and disables TLS cert dir, which is required for Docker commands to connect properly.

2. Step 2: Verify login and push steps

   The job logs into the GitLab Container Registry using CI variables, then builds and pushes the image with correct tags.

3. Final Answer:

   Correct setup with variables and login before build and push -> Option D

4. Quick Check:

   Proper dind setup + login + build + push = Correct setup with variables and login before build and push [OK]

Hint: Always login before push and set DOCKER_HOST for dind [OK]

Common Mistakes:

• Forgetting DOCKER_HOST causes connection errors
• Using docker:dind as image instead of service
• Skipping docker login before push