How Docker & Containers Can Make Deployment A Picnic 🥳
If you, or a loved one, have ever deployed code, developed locally, to a production server, only for it to not work, then this is the article for you.
When this occurs, it seldom has anything to do with the code itself and more to do with the server the code has been deployed to. Maybe you developed the application locally on one Node version, but the regression or production server is using another Node version, causing weird compilation issues. Other times, the Node versions may be correct, but there are conflicting versions of some tools or libraries. This tends to lead to a young developer uttering the phrase, “…but, it works on MY machine!”.
Docker, and more specifically, containers, seek to eliminate this issue entirely.
But, what is Docker, anyway?
Put simply, Docker is a container technology. It’s a tool for creating and managing containers.
Ok, uh, what are containers?
A container is a standardized unit of software (Doesn’t that just sound neat?). It’s a package of code, and dependencies to run that code.
Containers are very strict. By that I mean that the same container will always yield the same application and execution behavior. There is no exception to this.
A common analogy is to image a container as a picnic basket. It contains food (code), a blanket to sit on (an environment), and utensils to eat with (tools). If you gave the same picnic basket to one of your friends, they would be able to have that same experience.
They’d eat the same food, on the same blanked, with the same utensils.
This speaks to the standardization of containers.
Ideally, we want to be building, testing and deploying code on the same environment. In the absence of such standardization, we get a lot of annoying and sometimes difficult compilation or even runtime issues. Sometimes, there are even environment issues within the same development team. Every team member should work on the same environment. Unfortunately, since we are often working on our local machines, this is difficult to maintain.
If you’ve worked in software development for some time, by now you must be wondering if Virtual Machines don’t already solve this problem for us, and they do, but there’s a catch!
Virtual Machines allow us to create environments to deploy our code to. This is not dissimilar to containers. Unfortunately, there is a caveat and, depending on your resources, it might be a deal-breaker.
With a Virtual Machine, you essentially have your own host Operating System, then on top of that you have a whole other Virtual Operating System installed and running inside the VM, along with any n number of tools that may come with that default OS installation.
This may not seem like a huge problem, but the problem is compounded when you need multiple Virtual Machines for different purposes because each Virtual Machine is another OS installation. This creates massive overhead, as we essentially will have various stand-alone machines running on top of our machine. Needless to say, this wastes a lot of space on our hard drive and tends to be slow.
On the other hand, containers don’t have this type of overhead. Modern Operating Systems have support for containers built in.
When you create and run a container, we still have our host OS, but we don’t have another OS installed on our running container. This is also where Docker comes into play. Rather than install an entire OS in the container, we utilize the built-in OS support or emulated container support, and the Docker Engine, which is a very lightweight tool for managing containers. The container doesn’t have a bloated OS installation. They might contain a small OS layer, but even this is much smaller than installing an entire OS. You can also easily share container configuration via DockerFiles.
Pros & Cons of VMs
Benefits of Containers
Ultimately, whether you use containers or VMs is a decision you will need to discuss with your team (DevOps). It is clear, however, that if you want a solution without the potential for great overhead, Docker and containers might be the way to go.
By the way, fun fact, but there’s a common misconception that Docker is only for NodeJS apps, when in actuality it can be used for a plethora of frameworks and languages, like Python, Ruby, Java, etc.
Good luck developing more code, and I hope the next time you deploy, it works on the prod server just as well as it does locally!
