Working with Docker Registries, Images and Containers

You require access to a self-hosted registry. When must the --insecure-registry config option must be configured on the Docker daemon?

• When the registry is being served from the loopback network.

• When the registry uses a self-signed certificate for authentication.

• When the registry is configured to receive API calls over plain HTTP.

I have pulled the latest image to my machine and a new image is pushed to the registry, which now has the latest tag, what happens when I build a new container?

• Docker will fetch the latest image with the latest tag and you will get an image that is based on the newer version.

• Docker will reuse the already fetched image with the latest tag and you will get an image that is based on an old version.

• It will not build the image.

If you have a registry that services images over http, what is that called?

• Insecure registry

• Web registry

• http registry

• Private registry

Why is the domain name of the registry important?

• So users can easily use the registry API.

• It's included in the image name

• You have to configure the docker engine with it.

What is the purpose of a registry?

• To store images.

• To store dockerfiles.

• To store containers.

• To store compose files.

You are required to containerize a NodeJS application. Which base image would you choose to use to derive your application image in order to ensure fitness for purpose and to minimize the size of the resultant image?

• The official NodeJS image based on Alpine Linux from the Docker HUB registry, because Alpine Linux is highly optimized.

• The official Ubuntu image from the Docker HUB registry, because it is the most popular image available.

• The official NodeJS image based on Debian Wheezy from Docker HUB registry, because Debian has been around for more than 20 years.

• Create your own NodeJS base image, because the content of the images from the Docker HUB registry cannot be trusted.

When authoring a Docker image using a multi-stage build, the final FROM instruction should be FROM scratch, in order to produce the smallest image possible. Is this good advice?

• Sometimes - the base image for the final build stage should, ultimately, be an image that serves the purpose of the image being authored.

• Never - the artifacts contained within an image will always have a need for the content of a filesystem, that is provided by base image.

• Always - it's of the utmost importance to produce as small an image as is possible, whenever you author a Docker image.

Which of the following is an advantage of Multi-stage Builds?

• Multi-platform images

• Smaller images

• Faster image builds

• Better image documentation

Which of the following is recommended best practice?

• Use large images containing lots of tools

• Keep your images small

• Never use that latest image in a repo

• Only use Docker Hub

What's special about a multi-stage build?

• Automatically merge filesystems between stages.

• Copy files between stages.

• A process in one stage can manipulate the filesystem of another stage.

• Processes can talk to each other between stages.