Docker

Basic actions on Docker containers are:

• Create a docker container

Following command creates the docker container with the required images.

docker create --name <container-name> <image-name>

• Run docker container

Following command helps  to execute the container

docker run -it -d --name <container-name> <image-name> bash

Main steps involved in the run command is

1. Pulls the image from Docker Hub if it’s not present in the running environment
2. Creates the container.
3. The file system is allocated and is mounted on a read/write layer.
4. A network interface is allocated that allows docker to talk to the host.
5. Finds an available IP address from pool.
6. Runs our application in our case “bash” shell.
7. Captures application outputs

• Pause container

Processes running inside the container is paused. Following command helps us to achieve this.

docker pause <container-id/name>

Container can’t be removed if in a paused state.

• Unpause container

Unpause moves the container back to run the state. Below command helps us to do this.

docker unpause <container-id/name>

• Start container

If container is in a stopped state, container is started.

docker start <container-id/name>

• Stop container

Container with all its processes is stopped with below command.

docker stop <container-id/name>

To stop all the running Docker containers use the  below command

docker stop $(docker ps -a -q)

• Restart container

Container along with its processes are restarted

docker restart <container-id/name>

• Kill container

A container can be killed with below command

docker kill <container-id/name>

• Destroy container

The entire container is discarded. It is preferred to do this when the container is in a stopped state rather than do it forcefully.

docker rm <container-id/name>

Like any other technologies, Docker has its own advantages and disadvantages. Docker is not a silver bullet and needs care in architecting and orchestrating docker containers keeping below points in mind.

• Docker is not so fast compared to bare metal servers. Even though containers are lightweight and so easy to boot up it is subjected to decreased network performance. Performance of the containers are affected as a single operating system caters to multiple containers.
• Integrability: Even though Docker is open source some of the container products don’t work with all. This may be due to the competition prevailing in the market. For eg:  OpenShift which is a container-as-a-service platform from Red Hat, only works with the Kubernetes.
• Data loss in containers: When the container exits the data will be lost. Data could be saved through volume mounting like Docker Data Volumes but more hard work needs to be done in this space.
• Poor or no GUI: Containers were used mainly for deploying server application that doesn't require GUI. There are some methods to run GUI app inside containers but it’s somewhat clumsy these days.
• More suitable for applications that use microservices: Generally the docker’s benefit is to ease the application delivery by providing a packaging mechanism but the true benefit comes when we use microservices.
• There are other virtualization techniques like unikernels which is based on library operating systems. Unikernels provide improved security, more optimisation and boots faster.

A Docker image is an executable file, that creates a Docker container. An image is built from the executable version of an application together with its dependencies and configurations. Running instance of an image is a container.

Docker image includes system libraries, tools, and other files and dependencies for the application. An image is made up of multiple layers. Layered structure helps the developers to reuse already available static image layers from the Docker Hub, for different projects. This saves the developers time. Each image has a base layer which could be already available in Docker Hub or built from scratch. Then a readable/writable layer over the static layer is created that helps to customise the container. Each layer of the docker image could be verified in /var/lib/docker/aufs/diff, or via the Docker history command.

Storage drivers are used to managing the image layers. A writable layer created while creating the container is called the container layer. Multiple containers can share the same base layer and have their own writable layer. Few commands that can be used with images are:

• docker history shows the history of an image and its layers.
• docker update helps to update the container configurations.
• docker tag creates a tag for the container and organizes container images.
• docker search looks for the image in Docker Hub
• docker save allows saving of images.
• docker rmi removes one or multiple images.

The ADD instruction is used to copy files from build context to the image. Apart from regular files, it also allows URL and archive (tar, gzip, etc) files as the <source> parameter.

When a URL is provided, a file is downloaded from the URL and copied to the <destination>.It automatically unpacks compressed files, if the <source> argument is a local file in a recognized compression format (tar, gzip, bzip2, etc).

Whereas COPY does a straight-forward, as-is copy of files and folders from the build context into the container. It doesn't support URLs or gives any special treatment to archives.

Anything that you want to COPY into the container must be present in the local build context. The recommendation from the Docker team is to use COPY in almost all cases.

ENTRYPOINT is a definition in Dockerfile that specifies a command that will always be executed when the container starts. It allows us to configure a command along with its parameters that will run as an executable in a container. Even if we do not specify any ENTRYPOINT, we may inherit it from the base image specified using the FROM keyword in your Dockerfile. Most of the official Docker base images have an ENTRYPOINT of /bin/sh or /bin/bash.

To override the ENTRYPOINT at runtime, we can use --entrypoint.

Whereas, the main purpose of a CMD is to provide defaults for an executing container. These defaults can include an executable or for executing an ad-hoc command in a container. It can omit the executable as well, in which case we must specify an ENTRYPOINT instruction as well specified with the JSON array format.

The thumb rule is that every Dockerfile should specify at least one of CMD or ENTRYPOINT commands.

Though Docker is a great tool for quick development and environment setup, it cannot be used in production directly. It needs a layer of orchestration for container management.

That’s where Kubernetes comes into the picture. Kubernetes is an open source orchestration system for Docker containers. It manages containerized applications across multiple hosts and provides basic mechanisms for deployment, maintenance, and scaling of applications.

In a Kubernetes environment, one or more docker containers are run inside a ‘pod’. A pod is a basic unit that Kubernetes deals with and it represents one or more containers that should be controlled as a single "application".

Swarm is the native way provided by docker for implementing clusters for Docker containers. Basically, it allows a group of machines that are running Docker to join as a single cluster. Docker commands executed on a cluster are implemented on all the hosts by the swarm manager. Machines in a swarm can either be physical or virtual. After joining a swarm, they are referred to as nodes.

It also provides built-in load balancing and Service Discovery for the applications running as containers.

However, a more popular way of implementing clustering in production is achieved using Kubernetes. It is technically superior to Docker Swarm as it provides better health checking provisions at the pod level, better container scheduling and scaling.

A Chef is a Configuration Management tool which is primarily used by admins and DevOps teams to manage the application environments, web-server configuration, databases, and load balancers. Instructions are created in the form of recipes, that defines the components in the infrastructure and how those components can be deployed, configured and managed. In a nutshell, it makes it automates the rolling out of changes to various environments or machines.

Whereas Docker is a way to package code into consistent units of work known as containers. These units of work can then be deployed to development, QA and production environments with far greater ease and consistency.

Continuous Integration is a mechanism used to enable DevOps methodology in development process i.e. helps to obtain immediate feedback on the changes made in the code by executing unit and acceptance tests, as soon as the code changes are checked-in to the repository.

A typical process involves developers merging their changes to the branch as often as possible and they are validated by building, running and executing automated tests against the application.

Docker plays a key role in enabling CI, as it can seamlessly integrate with any popular CI tools like Jenkins or TeamCity. Also, several Gradle plugins like Palantir, trans mode are available for automating the docker build and publish images by creating respective Gradle tasks.

We can then define stages in Jenkins to perform tasks like building Docker images, starting containers using compose and executing Acceptance tests to validate the application changes.

1. Docker has a huge user base in comparison with its competitors. According to a recent report, by an infrastructure monitoring tool company, it claims 25 % of companies are already using containerization technology. Out of which 83 % of containers are docker containers. This user base includes big banks, manufacturing companies, large product firms, etc. Hence Docker is the most popular option to choose from the existing container technologies.
2. Docker being an open source technology enjoys huge community support and hence it has been the most preferred containerization tool in the industry. Docker was primarily developed for Linux but now supports Windows and Mac OS environments.
3. There is no container limitation on running Docker as the underlying could be anything like a laptop/cloud system. It only depends on the host system’s OS resources.
4. Docker HUB forms the repository of docker images. Docker Hub users can upload and download the docker images. A lot of applications are released as docker images which enable reusability and interoperability.
5. Docker is extensively documented technology available in the containerization space. That makes it easy for even the first time users to work with it.
6. Docker works very well with Google Cloud Platform and by Google Kubernetes Engine and across different cloud platform providers. Docker is also well supported by other configuration management platforms like Chef, Ansible, Puppet, etc

Data is not persistent inside a container. One of the most used methods is Volume mounting. Another method for persisting data is to include data in the writable layer but that layer is tightly coupled with the host machine where the container is running, thus the data couldn’t be managed easily. Also writing into the writable layer is complex and needs to use a driver.

To retain data, the best-preferred way is to use a Docker volume mount where it mounts another directory into your container. This directory is on the host which could be seen within the container. The main advantage of volume mounting is

• Easy to manage using Docker CLI commands.
• We have support for both Windows and Linux systems
• Multiple containers can share the volumes.
• Volumes are easier to back up
• Volume drivers are present to encrypt volume contents and to store on cloud systems etc
• The container can pre-populate the new volumes with its contents
• Volumes don't increase the size of the containers.

Following commands could be used to manage volumes:

• docker volume create <name> to create the volume
• docker volume ls to list the volumes available to you
• docker volume inspect <name> to get more details about the volume like path, drivers etc.
• docker volume rm <name> to remove the container.
• docker volume prune to remove unused volumes

• Kernel namespaces

Namespaces define the context in which names are defined whether it be variable names or function names. In other words, namespace defines the scope of the names. For eg: namespaces are like surnames. Suppose we have two people with the same name “John “ their surname differentiates them.

Each container in docker creates a set of namespaces specific to the container. Hence is the first and a great method of security between containers.

• Control Groups

Control groups facilitate resource accounting and limiting. Control Groups doesn’t allow a container to exhaust the host system’s CPU, memory, disk I/O, etc. It also doesn’t allow data and processes of container to be accessed by another container.

• Docker daemon attack surface

When a “docker run “ command is performed docker client speaks to docker daemon who manages the images and containers. Docker daemon needs root privileges. Extra precaution must be taken to give access only to trusted users to control docker daemon. A  container could even be started from the root directory on your host and the container can alter your host filesystem without any restriction.

• Linux Kernel Capabilities

Containers could be started with a reduced set of capabilities. This would mean that “root” within a container has fewer privileges than the real “root”. This, in turn, reduces the damage by an intruder with root privileges.

This is one of the common Docker tricky interview questions and answers for experienced professionals, don't miss this one. 

Built-in Public Key Infrastructure System helps to secure the deployment of container orchestration systems. Transport Layer Security (TLS) is used in Public Key Infrastructure to communicate with other nodes in a swarm.

When a swarm is initialized with “docker swarm init” command in a docker host, root Certificate Authority (CA) with a key pair is created. This is for securing nodes that join the particular swarm.

“--external-ca” flag is used with docker swarm init command to use external root CA.

Manager node generates worker token and manager token. Each token has the digest of the root CA certificate and a randomly generated secret. When a new node joins the docker swarm with the worker token the node uses the digesting part to verify the root CA from the manager node. While the leader node uses the secret to approve the new joining node. Manager node issues a certificate to the joining node with a randomly generated node ID

By default, swarm performs the renewal of the certificate every three months but it can be modified with the command

“docker swarm update --cert-expiry <TIME PERIOD> “

In case if the leader-manager node is down we can rotate the root CA within the swarm so that no nodes trust the certificate signed by old root CA. This can be done by the command “docker swarm ca --rotate”.

This command thus creates a cross signed certificate telling the nodes that still trusted old CA to start verification against new root CA

• FROM instruction    

Usage :

FROM <image> [AS <name>]

Or

FROM <image>[:<tag>] [AS <name>]

Or

FROM <image>[@<digest>] [AS <name>]

FROM helps to set the base image for the following instructions in the Dockerfile. The base image could be one pulled from the remote public repository or a local image built by the user. FROM can appear multiple times in Dockerfile and each time it appears it clears any stage created from previous instructions. Hence usually an AS <NAME> is added to the FROM instruction to identify the last image created just before the FROM instruction.  

• RUN instruction

Usage:

• RUN <command> (shell form, the command is run in a shell, which by default is /bin/sh -c on Linux or cmd /S /C on Windows)
• RUN ["executable", "param1", "param2"] (exec form)

RUN instruction creates a new layer on the current image which is used for the next step in Dockerfile.RUN cache is valid for the next build provided “docker build” command is not run with “--no-cache” flag.

RUN in the executable form doesn’t do shell processing like variable substitution.

• CMD instruction

Usage:

• CMD ["executable","param1","param2"] (exec form, this is the preferred form)
• CMD ["param1","param2"] (as default parameters to ENTRYPOINT)
• CMD command param1 param2 (shell form)

CMD provides defaults for executing container. There could only be one CMD instruction but if there are many, only the last one has the effect. If CMD is providing default arguments for the ENTRYPOINT instruction, then the CMD and ENTRYPOINT instructions should be specified with the JSON array format.  

• ADD instruction

Usage:

• ADD [--chown=<user>:<group>] <src>... <dest>
• ADD [--chown=<user>:<group>] ["<src>",... "<dest>"] (this form is required for paths containing whitespace)

The ADD instruction copies new files, directories or remote file URLs from <src> and adds them to the filesystem of the image at the path <dest>.

• COPY instruction

Usage:

• COPY [--chown=<user>:<group>] <src>... <dest>
• COPY [--chown=<user>:<group>] ["<src>",... "<dest>"] (this form is required for paths containing whitespace)

The COPY instruction copies new files or directories from <src> and adds them to the filesystem of the container at the path <dest>.Main difference between COPY and ADD is that ADD supports the source to be a URL or tar file.

• ENTRYPOINT

Usage:

• ENTRYPOINT ["executable", "param1", "param2"] (exec form, preferred)
• ENTRYPOINT command param1 param2 (shell form)

An ENTRYPOINT allows you to configure a container that will run as an executable. As a best practice ENTRYPOINT should be defined when using the container as an executable and CMD should be used as a way of defining default arguments for an ENTRYPOINT command.CMD could be overridden while running a container with arguments.

• WORKDIR

Usage:

• WORKDIR /path/to/workdir
• The WORKDIR instruction sets the working directory for RUN, CMD, ENTRYPOINT, COPY and ADD instructions in the Dockerfile.

One of the most frequently posed Docker scenario based interview questions, be ready for this conceptual question.

Docker builds command builds the images from Dockerfiles and “context”.A build’s context is the set of files located in the specified PATH or URL. The PATH is a directory on your local host filesystem while the URL could be a Git repository location, pre-packaged tarball contexts, and plain text files. COPY instruction could be used to reference a file in the context.

In the case of Git repositories, first the repository is pulled into a temporary directory on your local host then after it’s successful, the directory is sent to the Docker daemon as the context.

For eg: docker build https://github.com/dockersample/test.git#container:docker uses a directory called docker in the branch container as the context.

In the tarball context. For eg: docker build http://server/context.tar.gz   

sends the URL itself to docker daemon.Tar file is downloaded on the host the Docker daemon is running on, which need not be the same host from which the build command is being issued.

In text files context a single Dockerfile could be passed in the URL or pipe the file in via STDIN. For eg: To pipe a Dockerfile from STDIN we use the instruction: docker build - < Dockerfile

While building a docker image Docker steps through the instructions in the Dockerfile adding layers to the base image. Every time Docker encounters a new instruction it checks for an existing image in its cache which it can reuse locally. Thus helping to build the final docker image quickly. If you don't want to use cache “ --no-cache=true” option with docker build command is used. Basic rules about cache are as follows:

• After the parent image is in the cache, the next instruction is compared against all child images derived from that parent image to see if anyone of them was built using the next instruction. If not, the Docker builds the image at this step once again and the cache is invalidated.
• For the ADD and COPY instructions, the contents of the file(s) in the image are examined and a checksum is calculated for each file. Last-modified and last-accessed times of the file(s) are not considered in these checksums. These checksums are compared with checksums of the existing images. If there are changes cache is invalidated.
• Unlike the ADD and COPY commands, in the case of a RUN  command, the files updated in the container are not examined to determine if a cache hit exists. In that case, just the command string itself is used to find a match.
• Once the cache is invalidated, all the following Dockerfile commands generate new images.

A staple in Docker advanced interview questions and answers, be prepared to answer this one using your hands-on experience.

When a Docker Swarm is created or a docker host joins the swarm two networks are created.

• an overlay network called ingress, which manages control and data traffic related to swarm services. This is the default network unless the user specifies other user-defined overlay networks. User-defined overlay networks could be created by using the command “docker network create”ingress network facilitates load balancing among a service’s nodes.
• To encrypt the application data traffic on a given overlay network, use the --opt encrypted flag on docker network create.
• To attach a service to an existing overlay network, use the --network flag to docker service create, or the --network-add flag to docker service update command. Service containers connected to an overlay network can communicate with each other through it.
• a bridge network called docker_gwbridge, which connects the Docker daemon to the other docker daemons in a swarm. docker_gwbridge connects the overlay networks (including the ingress network) to an individual Docker daemon’s physical network. It is a virtual bridge that exists in the kernel of the docker host. For customising the bridge network we have to do that before docker host joins the swarm or by temporarily removing the host from the swarm.

There are three mount types available in Docker   

• Volume mounts are the best way to persist data in Docker. Data are stored in a part of the host filesystem which is managed by Docker containers. (/var/lib/docker/volumes/ on Linux).Main advantages of using volume mounts are
  • Easy to use and backup
  • Docker CLI commands or the Docker API can be used to manage volume mounts.
  • Linux and Windows containers support volume mounts.
  • Volumes could be shared securely among multiple containers.
  • New volumes can use pre-populated content by a container.

Starting with Docker 17.06, -v or --volume flag and --mount flag could be used for docker swarm services and standalone containers. To create a docker volume. For eg:

“docker volume create my-vol” creates new volume  “my-vol”.

We can inspect a volume with the command “docker volume inspect”

For eg:

“docker volume inspect my-vol “ gives the output

[
{
    "Driver": "local",
    "Labels": {},
    "Mountpoint": "/var/lib/docker/volumes/my-vol/_data",
    "Name": "my-vol",
    "Options": {},
    "Scope": "local"
}
]

If we need to start a container with “my-vol”

• With -v flag

“docker run -d  --name devtest -v my-vol:/app nginx:latest”. Here nginx images with the latest tag are executed with using volume mount “my-vol”

• With --mount flag

“docker run -d --name devtest --mount \ source=my-vol,target=/app nginx:latest”

• Bind mounts may be stored anywhere on the host system. A file or directory on the host machine is mounted into a container unlike volume mounts where a new directory is created within Docker’s storage directory on the host machine, and Docker manages that directory’s contents. Non-Docker processes on the Docker host or a Docker container can modify them at any time.
• tmpfs mounts are stored in the host system’s memory only and are never written to the host system’s file system. When the container stops, the tmpfs mount is removed, and files won’t persist.

Whenever a “docker builds” command is executed we see a line that tells uploading context. This refers to the creation of a .tar file by including all files in the directory where the Dockerfile is present and uploading them to docker daemon. Consider if we are putting Dockerfile in home directory entire files in your home and in all subdirectories would be included in the creation of a .tar file. Thus before updating the context docker daemon checks for the .dockerignore file. All files that match the data in the .dockerignore file would be neglected. Hence sensitive information is not sent to the Docker daemon.

sample .dockerignore file looks like this:

# comment
*/temp*
*/*/temp*
Temp?

This .dockerignore file ignores all files and directories whose names start with temp in any immediate subdirectory of the root or from any subdirectory that is two levels below the root. It also excludes files and directories in the root directory whose names are a one-character extension of temp. Everything that starts with # is ignored.

This, along with other Docker practical interview questions for freshers, is a regular feature in Docker interviews. Be ready to tackle it with the approach mentioned above.