Docker containers are built from specifications called images. You can think of the relationship between containers and an image as that between cakes and their recipe.

  • A recipe tells you how to bake a cake, and an image tells you how to make a container.
  • Just as you can take one recipe and make several cakes from it, you can also take one image and make several containers from it. In such a case, each container will be a separate instance of the image.
  • Just like recipes, Docker images are specified by lines of instructions. ("First add X, then add Y", etc.). The files containing these lines are called Dockerfiles, and they are covered in more detail on this page.

Try Docker

There are three ways you can install Docker:

  • Rancher Desktop: This is the recommended choice. It is a program that, in addition to running Docker, lets you also run a Kubernetes cluster locally.
  • Docker Desktop: Docker's official desktop app which has much the same functionality as Rancher Desktop. You may need a paid subscription to use it; see this page for details.
  • Docker CLI: This is the terminal/command line interface for Docker. Installing and running either Rancher Desktop or Docker Desktop will also automatically start up the Docker CLI, so you don't need to install it separately. Installing it alone won't let you run a local Kubernetes cluster, but if that's not something you care about, this is a fine choice.

This document will assume you choose Rancher Desktop.

Installing Rancher Desktop on mac

The easiest way to install Rancher Desktop is via Homebrew. If you don't have Homebrew, install it by running the command on the Homebrew site.

Once you have Homebrew, run brew install --cask rancher. This will install Rancher Desktop.

Installing Rancher Desktop on Windows

Since containers need to use a Linux kernel, some virtualization is required to run Docker on Windows. Allow this by enabling Hyper-V. More information can be found here.

You can then install Rancher Desktop via the installer downloaded on this page.

Running a Docker container

Run Rancher Desktop, which will also start Docker. It'll prompt you with some default settings, which you should accept. Wait for it to start up. Then you can test a container by running the following:

docker run bmcase/hello-world-app

You'll notice that it first downloads the image and then creates a container off of it, which it runs. If all goes well, it should display the following output:

-------------------
|  Hello, World!  |
-------------------

Tags

Suppose you create a microservice, and then create an image for making containers that run that microservice. Then a few weeks later you add a feature to your microservice and build another image. You'll want some way of versioning to distinguish the old image from the new one.

This is done by using tags. Tags can be added by using the -t argument with the docker build command (discussed on this page) or by using the docker tag command. Below are some examples of images that have versioned tags pinned to them:

  • nginx:1.17.8
  • nginx:1.17.8-alpine
  • nginx:1.17.8-perl

But tags are not just used for versioning. Because a single image can have multiple tags, you can do something like the following:

  • You create an image for version 0.8.0 of your web server, which is in "beta" phase. You name the image "webserver" and give it both the "0.8.0" tag and the "beta" tag. Therefore, when you want to run a container based on that image, you can use either docker run webserver:0.8.0 or docker run webserver:beta.
  • At some later point you make changes to your web server, bringing it up to version 0.9.0. When creating this image, you give it the "0.9.0" tag, and the "beta" tag since it's still in beta. You can then get a container based on this image from docker run webserver:0.9.0 or docker run webserver:beta. If you want to use the 0.8.0 version, you can no longer do so using "beta" but now can only get it using the "0.8.0" tag.

Registries

Docker images are kept in remote stores called registries. They operate similarly to the remote repositories used by package managers.

  • If you're familiar with Java, registries store images in the same way a Maven repository stores Java artifacts.
  • If you're familiar with Python, registries store images in the same way PyPI stores Python packages.
  • If you're familiar with JavaScript, registries store images in the same way as npm registries store packages.
  • If you're not familiar with any of these, that's no problem! Read on.

The default, publicly available Docker registry is called Docker Hub. Registries can be on-prem (e.g. managed by your organization) or off-prem (e.g. Docker Hub). Follow this link to see a search for Docker images on Docker Hub:
https://hub.docker.com/search?q=redis&type=image
Each search result on this page is a repository. Click on the first one, which should be the official repository of Redis. You'll see a list of tags on this page, such as "7.2.5". If you want to get this image from the repository, you'd use the following command:

docker pull redis:7.2.5

This will download the image from the repository and let you use it. Note that the repository name is on the left side of the colon (':') and the tag is on the right.

If you just want to run a container based on the image, you don't even have to use docker pull first. Just do docker run and it'll automatically pull the image if you don't already have a copy locally:

docker run redis:7.2.5

If you use a registry other than Docker Hub (such as the GitHub Container Registry), then the registry will be given prior to the repository, as indicated below by "ghcr.io/myregistry":

docker pull ghcr.io/myregistry/myimage:1.0.0