Docker, What I learned
Getting acquainted with Docker and Containers
Disclaimer: I am a newbie to the Docker world. This article is an effort to share my understanding so far. And to make other newbies comfortable with their Docker journey.
If you are reading this article, either you are new to Docker or started playing with it. Let me share my experience so far. It can help you figure out what the buzz is all about or it will bring some confidence to move further.
By the end of this article, you most probably will agree with the header image for this article.
How I met Docker
I came to know about Docker at a developer’s meet up about four months before writing this article. Initially, I assumed it is a framework specific to a technology stack, and after some discussions during the event, I started assuming it was a tool for DevOps engineers. But later I dug deep only to find out I was insanely wrong in all my assumptions.
So, what is it actually, hmm, should I grab a definition from Wikipedia? Naah! not so attractive at all. Well, then here it is in terms of an armature Docker-er (I just made up this)
Introducing Docker
Docker is a tool to manage containers.
Exceptionally simple, right? But wait, then what is a container? Well, if we can connect these two dots, Docker will be our next good friend.
So, in simple words containers are something like an isolated process running on your machine; they use your Operating System kernel to execute task assigned to them.
Okay, but how Docker and containers relate to each other and what problem can they solve? Hold tight with me, and I will try my best to explain.
Scenarios explain it well
To understand the big picture, let’s take a scenario. Imagine you are developing a web application using some technology stack or the other. Now, of course, you want your users to use it, so you have to host it on a web server, right? But to make sure everything works fine you have to configure your web server in exactly the same way as on the machine that you were using for development. If you don’t, you can face our old friend “It works fine on my machine, but I don’t know why it fails on the server”, remember!
The Problem
We have a problem here and what should be the solution? Hmm, what if, I can take everything I need to run my application (like frameworks, binaries, packages etc. everything!) and put them all together on the web server where I am hosting the application. Fair enough, it should work. But now every time I have changes in my solution, be it a new version of a framework, or a new library, I have to go and deploy/put them again. However, installing a new version of a framework or updating a library can affect other applications running on the same web server.
Solution: Docker to rescue!
So basically, how about packaging everything you need and running it in isolation? With Docker, you can create a bundle of everything your application may need in a single file called “Image”. Consider it as a big zip of binaries. Moreover, the creation of this image file is so declarative, it is super easy to read, write and understand. Plus, you can even build a new image with a combination of two and more different images, wow right! But wait the wow factor is yet to follow!
Now as Docker generates this incredible file with everything in it, but for what good? What should Docker do with this image? Aha, we just mentioned Docker manages containers, so conceptually you can use these images to run inside a container.
Well, the dots are getting connected and things are starting making sense. So let’s recap.
Rewinding
First, use Docker to build an image of your whole application and its dependencies (which may even include the whole operating system, web server and the likes), then have Docker to execute these images inside a container. Isolated from rest of the environment, they are ready to be upgraded anytime without effecting the rest of the world.
And the beauty is, you can even have many containers running on a single machine, which means many instances of the same web application and, not to mention, it is platform independent, meaning build anywhere and deploy anywhere. Incredible!
There is much more than you can achieve with Docker like clustering, rolling updates, scaling, automatic replications etc. Since I started learning Docker I become so addicted I can’t stop taking about it . But to keep the article precise, I leave you guys with an illustration of what you have just read.
P.S.: In the header image of this article consider the containers as processes running on your machine, isolated from each other. No one knows what is there inside each container. And the dockyard is Docker that manages them.
✉️ Subscribe to CodeBurst’s once-weekly Email Blast, 🐦 Follow CodeBurst on Twitter, view 🗺️ The 2018 Web Developer Roadmap, and 🕸️ Learn Full Stack Web Development.
