Docker is definitely one of the more tricky pieces of tech to learn on your own. Since it’s so new there isn’t very much learning material on it, and many that do exist assume some DevOps knowledge or start throwing around commands without properly explaining their function or purpose.
In this article we won’t be going into any commands, instead we’re going to get an overview of the ideas and ecosystem of Docker, how it works, and why it’s useful to you in leveling up your skills as a developer.
Getting Docker can vary depending on your OS, I recommend starting out with Docker Desktop, which will differ if you’re on Windows or a Mac. Once that’s running, everything Docker-related can now be handled in the terminal of your choosing.
What is Docker?
At some point every developer pushes a project to production or sends it to a client only to have it fail on a particular OS, browser, or environment they didn’t account for. This persistent problem of “Well, it works on my machine” inspired a way of bundling our environment, dependencies, and project itself into their own independent ecosystem that will work consistently, instead of hoping the client’s system will work well with it.
What are Containers?
A container is that stable ecosystem, filled with whatever files and code we add to it, but completely sectioned off in our hard drive. Since a container is meant to be self-contained it has no connection to anything you already have installed on your machine, like Node.js. Anything like Node, Python, or Ruby would need to be installed on each individual container. It won’t even have access to the command line we would need to install anything else, since that would imply an underlying OS.
There are three ways we can handle this. We can work from outside of our container to install different programs and systems. We would install a very basic OS to give us the functionality we need to install things on a terminal from inside the container. Both of these options would work, but we may need to make more than one similar containers for other projects, or many of them for one. Instead we can create an image, which will handle the configuration for our containers and we can run a new instance of that image for each new container.
What’s an Image?
Images are container setups we can use to generate containers or combine together into single containers. They’re similar to git repos in that you have one main version that you can pull down, copy, and modify for your particular needs while the container is a particular instance of that image.
Images are available in two ways, both in the container itself and in an image cache separate from any container at all. This way if you create two containers with Python installed it would only need to be installed once in the cache and distributed to each container instance, making Docker much more efficient when generating new containers.
We don’t always need to manually create images since Open Source images can be found on DockerHub, and yes, you’ll definitely want to make an account.
How We Work with Docker
When we want to make a new container, we would need to start by adding a base image to give us the functionality to add everything else it needs. For example; if we were working with a React app, npm would be needed so we could use the official node image as our base image.
With that in place we could open a shell inside and begin working with a project similar to how we normally would.
Replicating our dev environments in containers allow our projects to be reproducible in many different environments.
Docker allows for us to isolate our project’s dependencies with much more control. For example, if you needed a library that was dependent on Python 2 but the rest of the project ran on Python 3, we could have both in their own containers in a way they wouldn’t conflict with each other.
Segmenting your app’s functionality into different containers offers some security benefits. With a well-structured project, if a container goes compromised, the others in the network can remain untouched.
Hopefully this was helpful in your decision about whether you should pursue adding Docker to your tech stack. You don’t need much to get started adding Docker to your projects, although the world of Dockers runs far deeper than just containers and images.
If you’re interested in learning more, there will be more articles going into the fun parts of working with images, containers, and even Kubernetes.
Fun fact: the Docker mascot isn’t the whale you’ll see everywhere it’s actually the developer team’s pet turtle, Gordon. He even has his own Twitter Account.