Containers have proven to be a confusing technology domain for some.
I believe this is mostly caused by bad naming and because people have a tencency to teach new concepts comparing them with the old ones.
I am no master either, the reason I am writing this post is because I have fallen into each and every one of these. Multiple times.
Containers are not “lightweight” VMs
Think of containers as stripped-down processes, not virtual machines.
They run like any other process, but they are heavily isolated from the rest of the host. They see only their own filesystem, processes, network devices… Yet they all share the same kernel, because they are just processes.
Docker this, Docker that
There’s oversubscription of the term “Docker”:
-
Docker, Inc, the company behind Docker Engine;
-
the Docker Engine, a client-server solution for containers;
-
the Docker daemon:
dockerd, the server component; -
the Docker utility:
docker, the client component; -
the Docker Swarm:
dockerd’s own container orchestrator; and -
the Docker Hub, a container registry hosted by Docker, Inc.
Find anything missing? Then it’s not a “Docker something”, it’s a “container something”, such as container registry or image.
Dockerfiles
There are two things under the Dockerfile label:
-
the imperative syntax used for writing Dockerfiles; and
-
the files themselves.
It is important to understand that Dockerfiles and container images are totally different concepts. You can build a container image without a Dockerfile, manually or with tools such as Buildah.
