I’ve made it a personal goal to finish anything that I start when it comes to IT-related topics. I find the nuggets of information that I’m trying to find to draw a picture of any specific topic can really come from anywhere.
In the most recent example of this, I’ve been struggling (A LOT) with trying to understand Kubernetes, Docker, and the whole concept of containerization. I understand it in concept and what purpose it serves, but implementing it, especially with only command-line tools, has been the really difficult part.
One of the areas of confusion for me when it came to Docker (more specifically Docker Engine) was when I would attempt to startup a new container, I would get this weird random name in the UI or the docker images command. I did not understand 1) Why did my container would exit after a reboot 2) Why when I started it up again, I’d get a weird name like “golden_eagle.” Eh?
Enter the “Arista Warrior” book by Gary A. Donohue. I’ve been reading this book off and on for most of 2024 to try and get a handle on the networking technologies that are employed at my work…while trying to learn DevOps concepts separately.
Yes, I know…what does a networking book have to do with containers and Docker? Well, Chapter 31 of the book talks about how Arista EOS can run in container form and containers can also run on the Arista platform.
In that chapter, Gary goes into examples of how to build containers on Arista. He downloads an image from Docker Hub called “ubuntu” and names its corresponding container Ubuntu (not surprising). He starts by running a container called Ubuntu inside the EOS command line and shows that it exits immediately afterwards.
He states that it exits because the container is not a VM and is not meant to persist. The first thing he states here is:
“Docker isn’t really about creating a VM: it’s about building a simple isolated environment to perform a task.”
He runs the image with the following command in a separate terminal window: Arista#bash docker run -it ubuntu which starts up the container inside a Bash shell. This allows him to interact with the container.
After running that command, he sends a “show” command to show his containers and his original container Ubuntu is in an “exited” state while a randomly named container “golden_eagle” (he has a different name for this in the book) is also listed and is in a “running” state.
He questions why there are two and he answers his own question by stating that the “exited” Ubuntu is the first container that he ran and exited immediately afterwards. The “running” golden_eagle is the container that he ran in the Bash shell in the secondary terminal window.
It’s here where he wrote what gave me a lightbulb on the topic of Docker:
“When I ran the docker run -it ubuntu command, the -it ubuntu portion specified the image that we pulled (from Docker Hub), and not the container that we made. That’s an important distinction. An image is something you either download from a repository (like Docker Hub) or make yourself, whereas a container is an environment that runs an image.”
“When I issued the docker run -it ubuntu command, Docker created a new container on the fly and made up a name for it, which was “golden_eagle.”
He also states:
“What’s not obvious reading this is that killing and starting the new container happened instantaneously. If these were VMs, it would have taken a while for the VM to boot. There is no real booting with containers, which is one of their most powerful features.”
He goes onto state that if we want the container to spin up automatically after a switch reboot, we need to add an “on-boot” command so the container knows to persist.
Now, some of this stuff may or may not be Arista-specific when it comes to the specific command being run. But the thing that I learned is that once a Docker image is on my system, I can create containers on the fly by just creating them over and over again and Docker will just assign a random name to them (I have personally observed this elsewhere).
Also, containers, at least in the Arista context, are not set to persist past a reboot of the platform. A command has to be explicitly issued in order for a container to persist after a reboot.
Obviously, there are still a ton of questions that come from this:
- Can names be assigned to new instances of Docker containers instead of having random ones created? Does this even matter in the world of containerization, when I run 10+, 20+ containers?
- Does container persistence always need to be explicitly applied or are there ways to default containers to persist past a reboot?
- How does all this fit into Kubernetes orchestration?
I’m still in over my head on this topic, but this nugget of information, coming from a networking book on Docker and containers, helped shed light for me on something that has been confusing me about Docker and containers for a while.