“Everything You Need To Know About Docker” is a series of articles (so far 6) that explains different parts of **Docker **in a very simple and straightforward way. Here are the parts so far:
Containers are hugely helpful for improving security, reproducibility, and scalability in software development and data science. Their rise is one of the most important trends in technology today.
Docker is a platform to develop, deploy, and run applications inside containers. Docker is essentially synonymous with containerization. If you’re a current or aspiring software developer or data scientist, Docker is in your future.
Don’t fret if you aren’t yet up to speed — this article will help you understand the conceptual landscape — and you’ll get to make some pizza along the way.
In the next five articles in this series we’ll jump into Docker terms, Dockerfiles, Docker images, Docker commands, and data storage.
By the end of the series (and with a little practice) you should know enough Docker to be useful!
First, I’m going to shed some light on Docker metaphors.
Google’s second definition for Metaphor is what we want:
Originally published by Jeff Hale at https://towardsdatascience.com
Metaphors help us make sense of new things. For example, the metaphor of a physical container helps us quickly grasp the essence of a virtual container.
A physical container
Like a physical plastic container, a Docker container:
Unlike a virtual Docker container, a new plastic container from Amazon will cost you money and won’t come with a copy of your goods inside. Sorry 💸.
A second way you can think of a Docker container is as** an instance of a living thing**. An instance is something that exists in some form. It’s not just code. It’s code that has brought something to life. Like other living things, the instance will eventually die — meaning the container will shut down.
A Docker container is a Docker image brought to life.
In addition to the container metaphor and the living instance metaphor, you can think of a Docker container as a software program. After all, it is software. At its most basic level a container is a set of instructions that manipulate other bits.
Containers are code
While a Docker container is running, it generally has programs running inside it. The programs in a container perform actions so your application will do something.
For example, the code in a Docker container might have sent you the content you are reading on this webpage right now. Or it might take your voice command to Amazon Alexa and decode it into instructions another program in a different container will use.
With Docker you can run multiple containers simultaneously on a host machine. And like other software programs, Docker containers can be run, inspected, stopped, and deleted.
Virtual machines are the precursors to Docker containers. Virtual machines also isolate an application and its dependencies. However, Docker containers are superior to virtual machines because they take fewer resources, are very portable, and are faster to spin up.
I mentioned images above. What’s an image? I’m glad you asked! The meaning of the term image in the context of Docker doesn’t map all that well to a physical image.
Images
Docker images are more like blueprints, cookie cutters, or molds. Images are the immutable master template that is used to pump out containers that are all exactly alike.
Cookie cutters
An image contains the Dockerfile, libraries, and code your application needs to run, all bundled together.
A Dockerfile is a file with instructions for how Docker should build your image.
The Dockerfile refers to a base image that is used to build the initial image layer. Popular official base images include python, ubuntu, and alpine.
Additional layers can then be stacked on top of the base image layers, according to the instructions in the Dockerfile. For example, a Dockerfile for a machine learning application could tell Docker to add NumPy, Pandas, and Scikit-learn in an intermediate layer.
Finally, a thin, writable layer is stacked on top of the other layers according to the Dockerfile code. (You understand that a thin layer is small in size because you intuitively understand the thin metaphor, right 😃?)
I’ll explore Dockerfiles in more depth in future articles in this series.
A Docker image plus the command docker run image_name
creates and starts a container from an image.
Container Registry
If you want other people to be able to make containers from your image, you send the image to a container registry. Docker Hub is the largest registry and the default.
Phew! That’s a lot of pieces. Let’s put this all together in terms of making a pizza.
Landscape Metaphor
Think of the recipe and the ingredients combined as an all-in-one pizza-making-kit. It’s the Docker image.
The recipe (Dockerfile) tells us what we’re going to do. Here’s the plan:
Alright, let’s get cooking.
Oven
Like making a pizza, making an app in a Docker container takes some work, but at the end you have something great. Enjoy 🍕!
That’s the conceptual framework. In Part 2 of this series I clarify some of the terms you’ll see in the Docker ecosystem. Follow me to make sure you don’t miss it!
Hopefully this overview has helped you better understand the Docker landscape. I also hope it has also opened your eyes to the value of metaphors in understanding new technologies.
If you found this helpful please share it on your favorite social media so other people can find it, too. 👏
#docker #devops #kubernetes #machine-learning #data-science