Docker

Docker is a platform for building, packaging, and running containers. It gives developers commands to describe an application’s environment and build that environment into an image. From that image, developers can start and stop containers, and share the image with other machines through a registry.

Containers existed before Docker, and Docker is not the only tool that can build or run them. What made Docker important is that it packaged this workflow into commands ordinary developers could use, without requiring them to work with the host’s low-level operating-system mechanisms directly.

For our applications, this means that the university’s IT takes on a minimal role: providing a well-maintained host. The developers can dockerize the application, and the IT team can run it on a server without needing to know the details of how the application is built or what libraries it needs. Likewise, the developers do not need to know the details of the server’s operating system or how to configure it.

Two concepts matter for working with Docker: the image and the registry.

Image

A container image is a read-only template for creating a container. It can contain the application’s files, the runtime libraries it needs, and instructions for starting the application. Docker makes this process as easy as writing a text file (Dockerfile) that describes how to build that image.

The image is a blueprint from which a running application is created. That distinction is like the distinction between a program file and a running process: a program file can be copied to another machine, while a process exists only while it is running on a particular machine, with particular network connections, storage, and configuration.

This separation makes it easier to move an application between environments. The developer can build an image on a laptop, and the server can run a container from that image. It is also easier to onboard new developers: they can start from the same image as the rest of the team, rather than trying to reproduce the developer’s environment from a list of installation steps.

Registry

An image must get from the developer’s machine to the server. A container registry stores images so they can be pulled by other environments. Docker Hub is one public registry; organizations can also use private registries.

The flow is:

  1. Build the image from the source code and its Dockerfile.
  2. Test a container created from that image.
  3. Push the image to a registry.
  4. Let the server pull the selected image.
  5. Start a container from that image.

For our applications, the developers do the first three steps, and the university’s IT does the last two.