Learn Docker in 5 days (Day 1 — General Concepts)

I remember, I started using Docker containers more than two years ago. Back then I needed to know very little about it. Our DevOps team will take care of everything related to containers so that we, the dev team, would only focus on making code.

In the end, the only thing I had to do was to run a few commands, and the project was all up and running. Like magic! I didn’t realize I was missing to learn a lot about this exciting technology.

Today, in my current job, I’ve been working more intensively with Docker, and thus, I’ve had to investigate and learn more about this tool. Recently, I completed the Udemy course: Docker Mastery: The Complete Toolset From a Docker Captain, created by Bret Fisher. About this course, I can say: I loved it!

During the following five days, I’ll be explaining how to use Docker in its most elemental form, as well as its fundamental concepts. I based most of the information written here, on the Bret Fisher course and the official documentation. Hopefully, after you finish reading this series of articles, you will have a clear idea about what docker is and how to use it.

Why do we need Docker?

Let’s remember how we used to develop and deploy web applications during the good old days.

Back then, we needed to install all the necessary dependencies in our local machine. The database engines (Mongo, MySQL, Postgres, etc.), the web server or reverse proxy (apache, tomcat, nginx, etc.), our language stack (PHP, node, python, java, etc.) and any other required piece of software. Once we had everything installed, we could start coding our app.

Eventually, we would have our application project ready to be deployed. Maybe we would do this through some SFTP service. Or perhaps we would use some fancy GIT or SVN webhook. Whichever option we decided to use, the final goal was to have all our files and binaries stored in our production or staging server.

And here is where the problems started…

Do you remember we had to install all the dependencies in our local machine? Now we had to do the same in the server and make sure that everything worked flawlessly. Most of the time this ended up being a complete nightmare since the server environment was usually different from our local machine, which would lead to consuming several hours in configuring every single detail.

Configuring the server to run your app be like!

After some time, we found solutions like Vagrant, that helped to relief, to some degree, the differences among environments. But we still had to rely on heavy virtual machines running a lot of additional resources that our app was not even using.

And Docker was born

When we refer to Docker, we might be referring to Docker as a company, a service, an engine, etc. But in our case, we will be referring to the software used to build, run, and orchestrate containerized applications.

First, we need to clarify that when we talk about containerized applications, we’re not talking about apps running inside a virtual machine — this could lead to confusion — Let’s check the definition of what a container is on the Docker official page:

A container is a standard unit of software that packages up code and all its dependencies so the application runs quickly and reliably from one computing environment to another

In summary, a containerized application will run on its own context, using a minimum set of binaries. Let’s check this diagram:

Here we have several apps running; each of them has a single context, which does not share it with any other app. At the same time, all the apps are running on top of the Docker Engine, which is the layer responsible for providing an interface from the apps to the OS and vice-versa.

Any container itself is exportable, destroyable and immutable. That’s one of the most powerful features about Docker — and one of the reasons I love this technology so much — You can think of a containerized app like a little box running your app. This small box can be running on your machine, and when it’s time to deploy, the only thing you have to do is moving this box to the production server. As simple as it sounds! Isn’t that great?

Docker Images

Once you start using docker frequently, you will come across with the terms “Containers” and “Images”. I already explained what a container is, but we haven’t seen anything about “Images” yet. What are they?

A Docker Image, in a logical way, is a container’s template. Using an OOP paradigm as an example, we can think of an image as a “container class”. We instantiate containers from images just as we instantiate objects from classes.

A Docker Image contains all the instructions and binaries necessary to build and run whatever containerized app you want. You can find docker images for any technology, language, or framework. Do you want a PHP app? No problem! What about an nginx server? You got it! And a node.js app? Boom! Easy. You also have images available for the most popular database engines (MySQL, Postgres, Mongo, and so on). In conclusion, it’s very likely you will find the right image for every element of your project’s stack.

All primary images are stored in a large repository called Docker Hub, which is the official image repository maintained by Docker. You can download images from other repositories as well, and set your custom image repository if you prefer so, but 99% of the time you’ll be downloading and building images from the Docker Hub.

Wrapping up for now

And that was Docker in a few words. Are you still into it? If you are, go thru docker.com

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store