Docker Image vs Container: Everything You Need to Know

Docker is a powerful tool for creating and deploying applications. It simplifies rolling out applications across multiple systems and is a useful tool for integrating new technologies. An application that runs using Docker will start up the same every time on every system. This means that if the application works on your local computer, it’ll work anywhere that supports Docker. That’s great news! It simplifies your development process and can be a powerful tool for continuous delivery.

As you begin to understand Docker, you need to grasp two key facets of how Docker works. Docker image vs container — it can be a little bit complicated at first. In this post, we break them down and make them easy to understand.

What are images?

If you’ve ever used virtual machines aside from Docker, you’ll be familiar with Docker images. In other virtual machine environments, images would be called something like “snapshots.” They’re a picture of a Docker virtual machine at a specific point in time. Docker images are a little bit different from a virtual machine snapshot, though. For starters, Docker images can’t ever change. Once you’ve made one, you can delete it, but you can’t modify it. If you need a new version of the snapshot, you create an entirely new image.

This inability to change (called “immutability”) is a powerful tool for Docker images. An image can never change. So, if you get your Docker virtual machine into a working state and create an image, you know that image will always work, forever. This makes it easy to try out additions to your environment. You might experiment with new software packages, or try to reorganize your project files. When you do this, you can be sure that you won’t break your working instance, because you can’t. You will always be able to shut down your Docker virtual machine and restart it using your existing image, and it’ll be like nothing ever changed.

Sharing images

What’s more, you can share images with other people. Once you’ve created an image of a Docker virtual machine, you can send that image to someone else. That person can start a new virtual machine using your image, and their Docker virtual machine will run exactly the same as yours. This is why Docker is so powerful for creating and deploying applications. Every developer on a team will have the exact same development instance. Each testing instance is exactly the same as the development instance. Your production instance is exactly the same as the testing instance. Because your systems are identical, you don’t need to spend time troubleshooting issues that only exist in one environment.

Developers around the world capitalized on this ability to share images with one another to create Docker Hub. Docker Hub holds images for a plethora of different Docker virtual machines. There are images for just about any common software system in the world. Setting up a new application that runs on Docker is as simple as inserting a few lines into a Docker configuration setup file and waiting for a short download. Much like other repositories, it’s possible for anyone to publish an image on Docker Hub. This means that it’s easy for your team to create a new Docker image and share it with team members around the world. Your testing and production servers can also download from Docker Hub to get their images. And like we mentioned, that image will run exactly the same no matter where it’s been downloaded.

What’s a container?

We use the phrase “Docker virtual machine,” but the better way to say that is “Docker container.” If a Docker image is a digital photograph, a Docker container is like a printout of that photograph. In technical terms, we call it an “instance” of the image. Each Docker container runs separately, and you can modify the container while it’s running. Modifications to a Docker container aren’t saved unless you create another image, as we noted. Most Docker images include full operating systems to allow you to do whatever you need on them. This makes it easy to start up a program—like a command line—on the running container. Inside that command line, you can do some work like installing a new software package or configuring the system’s security. Then you can save another image and upload it to somewhere like Docker Hub to share it with people who can make use of your work.

Sometimes, you need to do things on a container that you need to save, but can’t become part of the Docker image. A good example is building a web application, where you’ll probably have a Docker container that holds your database. Databases need to be able to write data to the hard drive so that it can be retrieved later. Docker has the ability to configure containers and “share” folders between the container and the host computer. One of the most common use cases for this is to share a directory that holds your application code. You modify the application code on your host machine, and those changes are detected by the application server running inside the Docker container.

Working with and sharing containers

Unlike images, it isn’t intended to share Docker containers. They’re much larger, containing all sorts of installed applications and configuration information. Also, as we mentioned, they don’t save their state. If you were to try to transfer a Docker container from one computer to another, you’d find that when you started it on the second computer, it would revert back to the original installed image. Instead, if you need to share your work on a container, you should create an image, and share that. Conversely, your work inside a container shouldn’t modify the container. Like previously mentioned, files that you need to save past the end of a container’s life should be kept in a shared folder. Modifying the contents of a running container eliminates the benefits Docker provides. Because one container might be different from another, suddenly your guarantee that every container will work in every situation is gone.

Using containers has a number of other benefits as a developer. For instance, your computer isolates each Docker container from the others on your computer. Need to set things up in a very specific way to support your database server? You don’t have to worry about those changes bleeding over to your web application server, because the two will never share memory or a file system.

Containers and images work together

Docker containers and images work together to unlock the potential of Docker. Each image provides an infinitely reproducible virtual environment shareable across the room or around the world. Containers build on those images to run applications—both simple or very complicated. What’s more, some terrific tools like Docker Compose make it simple to “compose” novel Docker systems encompassing multiple containers using a small config file. You can easily use images for a database, web server, caching server and message queue to easily configure a web application, for instance. Once all of those pieces come together, monitoring them with a Docker-aware application monitoring platform like Retrace is simple. Docker shortens your development times and accelerates your testing processes by making it easy to set up new, identical systems.

The best news is that Docker is free and runs just about anywhere. So, here’s nothing stopping you from getting started and finding out more differences for yourself!

Author

[email protected]

More articles by [email protected]