Definitions and basic concepts

Academisque definitions

What is DevOps?

Before we get started with Docker let's lay the groundwork for learning the right mindset. Defining DevOps is not a trivial task but the term itself consists of two parts, Dev and Ops. Dev refers to the development of software and Ops to operations. Simple definition for DevOps would be that it means the release, configuring, and monitoring of software is in the hands of the very people who develop it.

A more formal definition is offered by Jabbari et al.: "DevOps is a development methodology aimed at bridging the gap between Development and Operations, emphasizing communication and collaboration, continuous integration, quality assurance and delivery with automated deployment utilizing a set of development practices".

Image of DevOps toolchain by Kharnagy from wikipedia

Sometimes DevOps is regarded as a role that one person or a team can fill. Here's some external motivation to learn DevOps skills: Salary by Developer Type in StackOverflow survey. You will not become a DevOps specialist solely from this course, but you will get the skills to help you navigate in the increasingly containerized world.

During this course we will focus mainly on the packaging, releasing and configuring of the applications. You will not be asked to plan or create new software. We will go over Docker and a few technologies that you may see in your daily life.

DevOps is not a role

Docker

What is Docker?

"Docker is a set of platform as a service (PaaS) products that use OS-level virtualization to deliver software in packages called containers." - from Wikipedia.

So stripping the jargon we get two definitions:

Docker is a set of tools to deliver software in containers.
Containers are packages of software WITH dependencies.

The above image illustrates how containers include the application and its dependencies. These containers are isolated so that they don't interfere with each other or the software running outside of the containers. In case you need to interact with them or enable interactions between them, Docker offers tools to do so.

Why

Benefits from containers

Containers package applications. Sounds simple, right? To illustrate the potential benefits let's talk about different scenarios.

Scenario 1: Works on my machine

Let's first take a closer look into what happens in web development without containers following the chain above starting from "Plan".

First you plan an application. Then your team of 1-n developers create the software. It works on your computer. It may even go through a testing pipeline working perfectly. You send it to the server and...

...it does not work.

This is known as the "works on my machine" problem. The only way to solve this is by finding out what in tarnation the developer had installed on their machine that made the application work.

Containers solve this problem by allowing the developer to personally run the application inside a container, which then includes all of the dependencies required for the app to work.

You may still occasionally hear about "works in my container" issues - these are often just usage errors.

Scenario 2: Isolated environments

You have 5 different Python applications. You need to deploy them to a server that already has an application requiring Python 2.7 and of course none of your applications are 2.7. What do you do?

Since containers package the software with all of its dependencies, you package the existing app and all 5 new ones with their respective python versions and that's it.

I can only imagine the disaster that would result if you try to run them side by side on the same machine without isolating the environments. It sounds more like a time bomb. Sometimes different parts of a system may change over time, possibly leading to the application not working. These changes may be anything from an operating system update to changes in dependencies.

Scenario 3: Development

You are brought into a dev team. They run a web app that uses other services when running: a postgres database, mongodb, redis and a number of others. Simple enough, you install whatever is required to run the application and all of the applications that it depends on...

What a headache to start installing and then managing the development databases on your own machine.

Thankfully, by the time you are told to do that you are already a docker expert. With one command you get an isolated application, like postgres or mongo, running in your machine.

Scenario 4: Scaling

Starting and stopping a docker container has little overhead. But when you run your own Netflix or Facebook, you want to meet the changing demand. With some advanced tooling that we will learn about in parts 2 and 3, we can spin up multiple containers instantly and load balance traffic between them.

Container orchestration will be discussed in parts 2 and 3. But the simplest example: what happens when one application dies? The orchestration system notices it, splits traffic between the working replicas, and spins up a new container to replace the dead one.

Virtual machines

Isn't there already a solution for this? Virtual Machines are not the same as Containers - they solve different problems. We will not be looking into Virtual Machines in this course. However, here's a diagram to give you a rough idea of the difference.

The difference between a virtual machine and docker solutions arises after moving Application A to an incompatible system "Operating System B". Running software on top of containers is almost as efficient as running it "natively" outside containers, at least when compared to virtual machines.

So containers have a direct access to your own Operating Systems kernel and resources. The resource usage overhead of using containers is minimized, as the applications behave as if there were no extra layers. As Docker is using Linux kernels, Mac and Windows can't run it without a few hoops and each have their own solutions on how to run Docker.

Docker CLI basics

The Docker CLI is usually referenced as the "docker engine", see docs at https://docs.docker.com/engine/reference/commandline/cli/

The commmand docker has plenty of sub commands that are given when you just run docker

Let's see what's happening in our docker environment by running

docker info

Running this gives us information from our docker daemon (server) and from this info we can see our current server version

...
Server Version: 25.0.2
...

and that we have something like

...
CPUs: 5
Total Memory: 7.667GiB
...

available for our containers. On Linux these numbers will match the host machine, but on Mac/Win this will be the number of the CPUs/RAM in the virtual machine ("hidden" inside of docker)

Mac/Windows only

Before moving forward, you might want to change the defaults: On a Mac open the Docker preferences from the top menu icon. And on Windows right-click the icon on the task tray.

Then, under "Resources" increase/decrease the number of CPUs and memory. If you don't know what to put here it's okay, now you'll know where to find these settings later.

If you change something and hit Apply & Restart. Then while the internal hidden magic virtual machine is restarting the docker info will return:

...
Server:
ERROR: Error response from daemon: Bad response from Docker engine
errors pretty printing info

Which means that the docker command (which is in your Mac/Windows) can not connect to the docker daemon (which is in the magic virtual machine hidden inside of Docker Desktop).

After the machine has restarted, we can see that the docker info will match with our settings.

You already have Docker installed so let's run our first container!

The hello-world is a simple application that outputs "Hello from Docker!" and some additional info.

Simply run docker container run hello-world, the output will be the following:

$ docker container run hello-world
  Unable to find image 'hello-world:latest' locally
  latest: Pulling from library/hello-world
  478afc919002: Pull complete
  Digest: sha256:4bd78111b6914a99dbc560e6a20eab57ff6655aea4a80c50b0c5491968cbc2e6
  Status: Downloaded newer image for hello-world:latest

  Hello from Docker!
  This message shows that your installation appears to be working correctly.

  To generate this message, Docker took the following steps:
  1. The Docker client contacted the Docker daemon.
  2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
      (arm64v8)
  3. The Docker daemon created a new container from that image which runs the
      executable that produces the output you are currently reading.
  4. The Docker daemon streamed that output to the Docker client, which sent it
      to your terminal.

  To try something more ambitious, you can run an Ubuntu container with:
  $ docker run -it ubuntu bash

  Share images, automate workflows, and more with a free Docker ID:
  https://hub.docker.com/

  For more examples and ideas, visit:
  https://docs.docker.com/get-started/

If you already ran hello-world previously it will skip the first 5 lines. The first 5 lines tell that an image "hello-world:latest" wasn't found and it was downloaded. Try it again:

$ docker container run hello-world

  Hello from Docker!
...

It found the image locally so it skipped right to running the hello-world.

So what's an image?

Image and containers

Since we already know what containers are it's easier to explain images through them: Containers are instances of images. A basic mistake is to confuse images and containers.

Cooking metaphor:

Image is pre-cooked, frozen treat.
Container is the delicious treat.

With the cooking metaphor, the difficult task is creating the frozen treat while warming it up is relatively easy. Images require some work and knowledge to be created, but when you know how to create images you can leverage the power of containers in your own projects.

Image

A Docker image is a file. An image never changes; you can not edit an existing file. Creating a new image happens by starting from a base image and adding new layers to it. We will talk about layers later, but you should think of images as immutable, they can not be changed after they are created.

From image to containerS

Containers are created from images, so when we ran hello-world twice we downloaded one image and created two of them from the single image.

Well then, if images are used to create containers, where do images come from? This image file is built from an instructional file named Dockerfile that is parsed when you run docker image build.

Dockerfile is a file named Dockerfile, that looks something like this

Dockerfile

FROM <image>:<tag>

RUN <install some dependencies>

CMD <command that is executed on `docker container run`>

and is the instruction set for building an image. We will look into Dockerfiles later when we get to build our own image.

If we go back to the cooking metaphor, Dockerfile is the recipe.

Container

Containers only contain that which is required to execute an application; and you can start, stop and interact with them. They are isolated environments in the host machine with the ability to interact with each other and the host machine itself via defined methods (TCP/UDP).

List all your containers with docker container ls

$ docker container ls
  CONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES

And we get back nothing! Luckily for every docker subcommand there is additional help available:

$ docker container ls --help

Usage:  docker container ls [OPTIONS]

List containers

Aliases:
  ls, ps, list

Options:
  -a, --all             Show all containers (default shows just running)
  -f, --filter filter   Filter output based on conditions provided
      --format string   Pretty-print containers using a Go template
  -n, --last int        Show n last created containers (includes all states) (default -1)
  -l, --latest          Show the latest created container (includes all states)
      --no-trunc        Don't truncate output
  -q, --quiet           Only display container IDs
  -s, --size            Display total file sizes

From this list we'll learn that without the flag --all (or -a) it will only print the running containers and the hello-worlds we ran have already exited. So let's add -a:

$ docker container ls -a
  CONTAINER ID   IMAGE         COMMAND    CREATED         STATUS                     PORTS     NAMES
  8103afbd2352   hello-world   "/hello"   2 seconds ago   Exited (0) 1 second ago              cranky_bartik
  48c3d11acdc7   hello-world   "/hello"   7 minutes ago   Exited (0) 7 minutes ago             nifty_mclean

And now we'll see the exited containers.

Let's remove the image since we will not need it anymore, docker image rm hello-world sounds about right. However, this should fail with the following error:

$ docker image rm hello-world
  Error response from daemon: conflict: unable to remove repository reference "hello-world" (must force) - container <container ID> is using its referenced image <image ID>

This means that a container that was created from the image hello-world still exists and that removing hello-world could have consequences. So before removing images, you should have the referencing container removed first.

Run docker container ls -a to list all containers again.

$ docker container ls -a
  CONTAINER ID   IMAGE           COMMAND        CREATED          STATUS                      PORTS     NAMES
  b7a53260b513   hello-world     "/hello"       35 minutes ago   Exited (0) 35 minutes ago             brave_bhabha
  1cd4cb01482d   hello-world     "/hello"       41 minutes ago   Exited (0) 41 minutes ago             vibrant_bell

Notice that containers have a CONTAINER ID and NAME. The names are currently autogenerated. When we have a lot of different containers, we can use the option--filter or pipe to grep (or another similar utility) to filter the list.

Let's start with --filter - you can see the possible filters from https://docs.docker.com/engine/reference/commandline/ps/#filtering - and you may notice that the filters are under ps which is the historical shorthand for container ls which is confusing. More on the shorthands later.

Anyway, by specifying --filter ancestor=hello-world we'll list all the containers that share hello-world as an ancestor:

docker container ls -a --filter ancestor=hello-world

Let's remove the container with docker container rm command. It accepts a container's name or ID as its arguments.

Notice that the command also works with the first few characters of an ID. For example, if a container's ID is 3d4bab29dd67, you can use docker container rm 3d to delete it. Using the shorthand for the ID will not delete multiple containers, so if you have two IDs starting with 3d, a warning will be printed, and neither will be deleted.

You can also use multiple arguments: docker container rm id1 id2 id3. This is especially handy when combined with xargs, but before we can use xargs we need to list just the plain ids.

To list the plain ids docker uses --quiet or -q (which is not very quiet..).

$ docker container ls -a -q
  1cd4cb01482d
  b7a53260b513

If you already removed the containers and have no output, then you might want to run a couple of more:

$ docker container run hello-world
...
$ docker container run hello-world
...

xargs (on Linux/Mac)

Now this output is great for xargs! If you don't see any output, check that your have that -a in there as well.

$ docker container ls -a -q | xargs docker container rm
  1cd4cb01482d
  b7a53260b513

docker container rm returns the ids it removed. If you run the command again it will not list any containers and therefore xargs does not run docker container rm, either

Let's try starting a new container with a version specified:

docker container run nginx:1.15.7

With some containers the command line appears to freeze after pulling and starting the container. This is because that particular container is now running in the current terminal, blocking the input. You can observe this with docker container ls from another terminal. In this situation one can exit by pressing control + c and try again with the -d flag.

$ docker container run -d nginx:1.15.7
  c7749cf989f61353c1d433466d9ed6c45458291106e8131391af972c287fb0e5

The -d flag starts a container detached, meaning that it runs in the background. The container can be seen with

$ docker container ls
  CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS               NAMES
  c7749cf989f6        nginx               "nginx -g 'daemon of…"   35 seconds ago      Up 34 seconds       80/tcp              blissful_wright

Now if we try to remove it, it will fail:

$ docker container rm blissful_wright
  Error response from daemon: You cannot remove a running container c7749cf989f61353c1d433466d9ed6c45458291106e8131391af972c287fb0e5. Stop the container before attempting removal or force remove

We should first stop the container using docker container stop blissful_wright, and then use rm.

Forcing is also a possibility and we can use docker container rm --force blissful_wright safely in this case. Again for both of them instead of name we could have used the ID or parts of it, e.g. c77.

It's common for the docker daemon to become clogged over time with old images and containers.

Now if we run the nginx image without specifying the version:

$ docker container run nginx
  Unable to find image 'nginx:latest' locally
  latest: Pulling from library/nginx
  dd6189d6fc13: Already exists
  45b405c6807d: Already exists
  0885cedf6b8e: Already exists
  5ef23c5804a6: Already exists
  31f35a1c1556: Already exists
  2b1ef5bc2771: Already exists
  Digest: sha256:943c25b4b66b332184d5ba6bb18234273551593016c0e0ae906bab111548239f
  Status: Downloaded newer image for nginx:latest
  /docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
  /docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
  /docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh
  10-listen-on-ipv6-by-default.sh: info: Getting the checksum of /etc/nginx/conf.d/default.conf
  10-listen-on-ipv6-by-default.sh: info: Enabled listen on IPv6 in /etc/nginx/conf.d/default.conf
  /docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh
  /docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh
  /docker-entrypoint.sh: Configuration complete; ready for start up
  2022/11/08 11:20:58 [notice] 1#1: using the "epoll" event method
  2022/11/08 11:20:58 [notice] 1#1: nginx/1.23.2
  2022/11/08 11:20:58 [notice] 1#1: built by gcc 10.2.1 20210110 (Debian 10.2.1-6)
  2022/11/08 11:20:58 [notice] 1#1: OS: Linux 5.10.104-linuxkit
  2022/11/08 11:20:58 [notice] 1#1: getrlimit(RLIMIT_NOFILE): 1048576:1048576
  2022/11/08 11:20:58 [notice] 1#1: start worker processes
  2022/11/08 11:20:58 [notice] 1#1: start worker process 32
  2022/11/08 11:20:58 [notice] 1#1: start worker process 33
  2022/11/08 11:20:58 [notice] 1#1: start worker process 34
  2022/11/08 11:20:58 [notice] 1#1: start worker process 35

We can see that it automatically adds :latest as the version, which is the image last built (not necessarily the latest version of nginx. More on this later.)

And the container doesn't seem to be as stuck as the one created from nginx:1.15.7 because it outputs a bunch of logs. Actually, the container behavior is exactly the same in both :latest and :1.15.7 - the level of output verbosity of nginx image was changed in 1.19.0 https://github.com/docker-library/docs/pull/1735/files and our :latest is newer than that. However, we'll learn later why :latest might not be as :latest as you think.

Most used commands

command	explain	shorthand
`docker image ls`	Lists all images	`docker images`
`docker image rm <image>`	Removes an image	`docker rmi`
`docker image pull <image>`	Pulls image from a docker registry	`docker pull`
`docker container ls -a`	Lists all containers	`docker ps -a`
`docker container run <image>`	Runs a container from an image	`docker run`
`docker container rm <container>`	Removes a container	`docker rm`
`docker container stop <container>`	Stops a container	`docker stop`
`docker container exec <container>`	Executes a command inside the container	`docker exec`

For all of them container can be either the container id or the container name. Same for images. In the future we may use the shorthands in the material.

Some of the shorthands are legacy version of doing the same thing. You can use either.

Mac/Windows only part 2

While the user is not expected/required ever to go inside of this magical virtual machine, we, as brave container specialists can do so by using docker (huh).

Now just blindly copy/paste the following without thinking too much. It will make a lot more sense later.

$ docker run -it --rm --privileged --pid=host justincormack/nsenter1
  Unable to find image 'justincormack/nsenter1:latest' locally
  latest: Pulling from justincormack/nsenter1
  726619a9fa8c: Pull complete
  Digest: sha256:e876f694a4cb6ff9e6861197ea3680fe2e3c5ab773a1e37ca1f13171f7f5798e
  Status: Downloaded newer image for justincormack/nsenter1:latest
/ #

Then we can see how long the virtual machine has been running

/ # uptime
 10:18:14 up 2 min,  load average: 0.02, 0.02, 0.00

And what version of Linux we are running

/ # uname -a
  Linux docker-desktop 5.15.49-linuxkit #1 SMP PREEMPT Tue Sep 13 07:51:32 UTC 2022 aarch64 Linux
/ # cat /etc/os-release
  PRETTY_NAME="Docker Desktop"

So, Docker Desktop ships with a virtual machine based on LinuxKit.

As the output above is from my Apple Silicon Mac, the architecture is aarch64 (ARM) also for our magical Linux virtual machine. On a older Intel based Mac the architecture would be x86. More on these architecture implications later.

You have reached the end of this section! Continue to the next section:

2. Running and stopping containers