FrançaisGet started

Containers in the pipeline

Running a job in an image, adding services to it, building, tagging and pushing the image, telling a tag from a digest, promoting the same image from one environment to the next and scanning it.

  • 25 cards
  • 4 topics
  • Free
Study this deck

The outline, topic by topic

Each topic is weighted the way the exam weighs it.

  1. Concepts
  2. Questions
  3. Sort and link
  4. Scenarios

A few cards from the deck

  • Container image: what is it?

    Show the answer

    A frozen, read-only package that holds a program and everything it needs to run, from which containers are created.

    A pipeline job also runs in an image: it fixes the tools and their versions, hence the job's environment.

  • In this sequence, which image does docker pull $IMG:latest fetch at the end?

    ```bash
    IMG=registry.example.com/team/app
    docker build -t $IMG:1.2 .
    docker push $IMG:1.2
    docker tag $IMG:1.2 $IMG:latest
    docker push $IMG:latest
    # the code changes, new build
    docker build -t $IMG:latest .
    docker push $IMG:latest
    `

    • The image from the second build
    • The 1.2 image, the first one to carry latest
    • None: the registry refuses to push an existing tag again
    • The oldest one, which the registry keeps under latest
    Show the answer

    The image from the second build

    A tag moves: the second docker push $IMG:latest makes it point to the new image. $IMG:1.2 still designates the old one, which is no longer the image behind latest.

  • To deploy a precise version, the image is tagged with the … or the version number, and not with ….

    Show the answer

    To deploy a precise version, the image is tagged with the commit hash or the version number, and not with latest.

    latest changes content at every push: you no longer know which version is running, or which one to go back to.

  • Container registry: what is it?

    Show the answer

    A server that stores container images, named and versioned, where the pipeline sends them and from which machines pull them.

    It is the hand-over point between build and deployment: you push once and pull as many times as needed.

  • The docker build job stops on "Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?". What is the likely cause, and the fix?

    • No Docker daemon in the job: add the docker:dind service
    • The registry is down: rerun the job a little later
    • The Dockerfile is invalid: fix its first instruction
    • The job is not logged in to the registry: add docker login
    Show the answer

    No Docker daemon in the job: add the docker:dind service

    The job's docker client looks for a daemon on its local socket and finds none. A docker:dind service (or a daemonless builder) provides one. An invalid Dockerfile would give a build error, not a connection error.

Study this deck