You’ve heard of Docker containers and, maybe, you have run one or two yourself. But now, you’re at the stage where you’re wondering what the practical uses for Docker containers are.
docker run redis, what are containers really used for?
Containers are used as a way of packaging and running an application, and its dependencies, in an isolated, predictable and repeatable way.
Virtual machines can do the same things, but they take more time to create, configure, ship, and run. The advantage of the container is that it has all of these benefits, but it’s much faster and more lightweight.
Benefits of containers
Before we look at the main use cases for Docker containers, it’s a good idea to revisit the characteristics of containers.
Understanding the benefits of containers, helps us to understand why they are great for the different use cases we’ll look at further below.
Containers offer the following characteristics:
Repeatability: A container image will run the same way, wherever it is run. So once my application is built as a Docker image, I can run multiple instances of my application very easily, and they will all behave in the same way. Or, I can run my container wherever Docker is installed.
Portability: With Docker, portability comes from the Docker image format. It’s like a zip file (actually it’s a TAR archive) containing my whole application and all of its dependencies. I can pull Docker images from public or private registries, or create my own.
In addition, Docker images are comprised of several stacked layers, which saves time when moving images around, as Docker only fetches the layers which it doesn’t already have stored locally.
Isolation: A Docker container offers a certain level of isolation. This means that my application runs in its own sealed environment, and cannot affect other applications when it is running inside a container, unless I choose to allow it.
Virtual machines also have the same benefits that we’ve seen above, but a container offers a thinner level of virtualisation. It doesn’t virtualise an entire operating system, it just virtualises a process. This means that containers have a couple of additional benefits:
Lightweight: Because containers virtualise a single process, they are lightweight and more easily distributed than a virtual machine.
Composable: Since containers are lightweight, they can be easily stacked together and swapped around. This is especially useful in microservice architectures, which are made up of many self-contained services, which are independently managed and maintained. Containers are a really good technology to achieve this.
What are containers used for?
So bearing in mind the characteristics of containers, what are some practical use cases for Docker?
With any new technology, it’s good to understand the reasons why it exists, and find some practical applications. The concepts become easier to grasp when you understand what they’re used for.
So let’s see the main places where you might see containers being used in the real world.
1 Setting up a development environment
A lot of people get started with containers by using Docker while they’re developing software. People use Docker to run one or more of their application’s dependencies.
Often, we waste a lot of time installing and configuring the dependencies that we need for our application. Most applications depend on some other component to run – such as a database.
This often requires downloading and configuring a database to use in development. How many times have you needed a database, when developing an app?
I’ve spent a lot of time in the past, installing and configuring complex bits of software – such as Oracle database – just for the purposes of doing a few days of development. That time is often wasted, because you need it for a short amount of time, and you remove the database when it’s no longer needed.
But if your application uses a dependency which has been packaged into a Docker container, then you can simply pull the Docker image from a registry, run the container, and you have an instance of your dependency, ready to use immediately.
Example - running MongoDB for an application: A really good example of this is MongoDB. Thousands of applications use MongoDB as a database.
If you run an application which needs MongoDB, you could spend time downloading the MongoDB installer, running the install program, configuring the database, and setting it up.
Or, you could just pull the official MongoDB container image from the Docker Hub registry, and have a database up and running within minutes, with little configuration.
2 Building and compiling software
If you’re developing software, you might need to compile it. This is especially the case for languages like Java or C. That might be a simple task, but the dependencies needed to compile your program often run into many hundreds of megabytes, and take time to configure properly.
With Docker, this can be made a lot easier. Some people use containers as a way of creating a repeatable build environment, containing all of the build-time dependencies.
When this environment is packaged as a Docker image, it is highly predictable and easy to consume. And, more importantly, it means that you can run a build in a clean container whenever you like, avoiding the problem of having to clean up afterwards.
Example: A good example of this approach is compiling Java programs.
To build your Java app, you can use the Maven Docker image, which contains the Maven build tool pre-installed. You can mount your code inside the container, and execute a Maven build.
The result from this process is your compiled source code.
The next stage is to take this compiled source code (usually a
.jar file) and copy it into a new container, based on the OpenJDK image. This is sometimes referred to as a multi-stage Docker build.
3 Running an application in different environments
This is another example of how Docker is used when developing software. Once you have built a Docker image of your application, it will run in the same way in any environment.
This is made possible because of the standard API provided by container engines like Docker. A container will run predictably on my machine, just in the same way as it does on any other machine.
Starting a container is usually a simple matter of using the
docker run command.
This means that containers are a useful way to ship applications between different environments, while maintaining parity between them. In other words, the same application can be run in all environments, by just building one container image, and running it in each environment, with slightly different configuration.
Even if containers aren’t used to run an application in production, they can still be a really valuable way of sharing an application between different environments (e.g. dev, test, UAT) in a predictable way.
Example: Containers can be used as one way to move an application from development into test.
Developers can write code, and then ship the application to the test team as a container/Docker image. The test team then runs the container image, and tests the application, without having to follow a complex sequence of steps, configure a server, or even create a virtual machine.
The test team simply uses
docker run to run the image, and the application starts, allowing them to test.
4 Deploying to a cloud platform
Containers are often used as a unit of deployment on a cloud platform, like Kubernetes, OpenShift or AWS.
This is great for both platform admins and developers, because now there is one standard packaging format for building and running apps on the platform.
Admins don’t need to learn dozens of different types of application servers and operating systems, and developers don’t need to understand a whole range of virtualisation technologies.
This is why platforms-as-a-service have consolidated on containers, and Docker.
The real benefit to me, as a developer, is that I can package up my application, and everything it needs to run, in a very well-known, portable format. When my application package arrives on the platform, the administrators know how to run it, because it is using the Docker (or OCI) standard.
In the past, this was hard, because applications used to be deployed in many different ways, via scripts, installers, or even on a VM. But containers offer a universal approach that is understood by both developers and system administrators.
This is similar in concept to how applications run on the Apple and Android app stores. Developers package their application in a standard way, and then cell phones know how to unpack and run those applications, because they use a standard format.
Example: Kubernetes is an open source container platform. It uses containers as a way of running applications.
This means that if you want to run an application on Kubernetes, you usually need to have it packaged in a container. Kubernetes can pull your container image from a registry, schedule it on a node in the cluster, and start your container.
It can do this because a Docker container conforms to a standard (OCI), so Kubernetes doesn’t need to know a lot of detail about what’s inside the container, or how to start the program inside it.
5 Running third-party programs, apps and utilities
Up until now, I’ve covered ways in which containers are used in software development. But, the thing is, containers have really helpful, practical uses when running third-party software too.
Even if you’re not a software developer, you can still make use of containers. Docker isn’t just limited to use as a tool for coders.
Many popular applications are now available in containerised form. You might find that an application which you use regularly is available as a Docker image, which you can pull from one of the public registries.
Again, the benefit is that the application is packaged in a standard way, includes all of its dependencies, and runs very predictably, wherever it is run. Except this time, you save all the hassle of having to figure out how to install the application, or set it up manually.
Example: For example, I sometimes use the document processing utility Pandoc. It is a command-line application which produces PDFs, Word documents, and almost any other type of document you can think of. (It’s very useful!)
Pandoc requires downloading and installing a bunch of stuff onto your laptop, which can be a little complicated.
But Pandoc is also available as a container image. The image includes Pandoc and all of the dependencies it needs to run. So, whenever I need to use Pandoc to process a document, I can just pull the image, and run Pandoc to do the task I want. I don’t need to worry about whether everything is installed correctly, because the container image includes everything I need.
And at the end, when the utility finishes, the Docker container stops. I can choose to remove the container, and free up any disk space cleanly.
Some other examples of software available as Docker images are: phpMyAdmin, OpenJDK (Java), and Ubuntu (for running Linux in a container).
So, let’s just review. Containers are often used for:
Running your application’s dependencies - this is especially useful if you’re a developer and you want to set up a development environment quickly.
Creating repeatable, predictable build environments - you can compile your own programs inside a Docker container
Moving applications between environments - the Docker image is a very portable format for shipping an application between dev, test and production environments.
Packaging and deploying an application on a platform-as-a-service - PaaS platforms like Kubernetes, OpenShift and AWS now enable you to run Docker containers in the cloud.
Running utilities or programs so you don’t have to install and configure everything upfront
There are, of course, many more uses for containers. But there is something that ties all of these use cases together: the characteristics of containers, like portability, isolation and repeatability.
I hope you get inspired by seeing these examples of how people are using containers in the real world. It’s a great time to be in software development and I’m excited to see the new use cases that people will come up with for containers.
Got any thoughts on what you've just read? Anything wrong, or no longer correct? Sign in with your GitHub account to leave a comment.
(All comments get added as Issues in our GitHub repo here, using the comments tool Utterances)