ITeach Recruiters Blog (2 Part Series)
Docker has been out for a while now and is being used widely. I think an understanding of how to use Docker is starting to become as necessary a skill as version control (i.e. git) for professional software engineers.
Yet, many non-technical people don't understand Docker.
And this is not surprising because it is complex and you have to understand several layers of things to really get to what exactly Docker is doing for people.
Nevertheless, Docker is a hot technology and we have to talk about it!
Note: This article was originally written for recruiters, but I tried to break this down so that anybody working in tech (but without an engineering background) could follow it.
You probably know what an operating system (OS) is and can probably name a few. Windows, Mac OSX, Linux. Those are all operating systems. They are designed to be the software that is the base layer you install onto your physical hardware (your physical computer) and run programs inside of. The OS handles connecting your programs to your input devices like the mouse and keyboard, as well as output devices like monitors.
Pretty basic stuff right? Well the idea of a virtual machine (VM) means running an operating system virtually. You can actually install programs that let you install another operating system and run it inside of your host operating system.
So it can look like this:
- Physical Hardware: Apple MacBook
- Host OS: Mac OSX
- Virtualization Program: Virtual Box
- Virtual OS: Ubuntu Linux
I made this diagram below to explain an example of doing this:
You can think of Docker like software that runs virtual machines. Specifically it runs things called Docker containers, which are derived from things called Docker images.
To be clear, Docker is like a virtual machine runner. It's not though, it actually does something that is much more efficient than running an entire VM, but I am not going to go into those details in this post.
Docker images are like a template for a virtual machine that can contain anything you want. For example you might define these things when you make a docker image:
- A base OS, to start from such as Alpine Linux
- Programs you installed on the OS (such as Java if your program is a Java app )
- Your program’s code - which would be your Java code
Then, when you run this image, it will run your program you wrote! And it will run it anywhere Docker is installed. That is the important part: if you install Docker somewhere else you can run any docker image on that computer too.
When you "ship" code to the cloud, you are just trying to run your code on another computer in a data center somewhere. So when you read something like:
Docker helps you ship code and run applications anywhere
That is what they are talking about. You are trying to run your code for your software on another computer (probably in the cloud) and Docker helps you do this.
As I said, when you build a Docker image, you are usually doing it with the goal of building it with your application code. So when you make the template you write instructions that copies your application code into the image. You do whatever build steps need to be done (such as installing libraries or compiling code). Now you have an image.
Now that you have an image you can run it anywhere Docker is installed. So for example, on your server running out in a cloud service provider like AWS. You install Docker once, on a machine running in the cloud and then you can just update the Docker image and run the new version of the Docker image!
Here is a diagram of making a Docker image and running it:
I made a few more fancy diagrams to show what is happening when you run containers in two different scenarios. This is a more real world example how you might run multiple containers on the same Docker runtime.
These two containers (a Java application, and a Database) will be like two separate computers running on the host computer just like Virtual Machines. Except that Docker is much more efficient than running entire virtual machines. Docker containers typically run only a single process, which is the thing you want to run. So here you can do this and not experience big performance issues like you would if you were running full VMs.
Again, basically because it makes it easy to deploy apps. If you can ship your development environment exactly to your production server environment your customers are going to use (again, in the cloud) that is going to help you cut down on issues by a lot.
I will let this meme sum it up.
In addition to that there are a lot of tools built on top of the idea of running Docker containers, and containerization in general such as Kubernetes or Docker swarm, so generally people have a whole other system layer in the mix. But I will save those details for another post.
There are a lot reasons why people are using Docker:
- Makes it easier to reliably build your application
- Makes deploys easier and more reliable
- Makes it easier to share and run a complex dev environment
- Can easily run things like database servers without installation (traditionally, you could not!)
And most newer software projects have Docker somewhere in their process. Whether that is in their development environment, their production environment, or just in their CI servers, Docker is probably there.
So understanding Docker is important because more and more in the future Docker is going to be foundational to many new technologies coming out. And if you can't understand the foundation, it will be hard to understand the new things building on top of the foundation.
Did this help you? I got a lot of requests to write this post! Let me know if this cleared things up a bit. Docker is really hard to understand because you need to grok a lot of concepts first to get why you would want to have a tool like this.