Containers - What? Why? How?
If you want to name a single technology, that needs to be in your portfolio, it will be containers. But, what does this mean? What is a container? What about this Docker, Kubernetes or Podman?
I am using containers, specifically Podman and Kubernetes, for all while-true-do.io deployments. This article may provide some background why this decision was made.
What are containers?
Container technology, simply known as containers, is just a method to package an application, so it can be run, with its dependencies, isolated from other processes. This technology exist for a long time in IT and people like me know container technologies like chroot, jails, LXC, flatpak, etc.
When somebody says "Container" nowadays, he often refers to application containers and even more often, he is referring to Docker. Docker Inc. is a company, that made the container approach so easy to use, that it became almost a synonym for containers in general. So, for this article I will only talk about application containers.
But what does a container do in general? How is it different from something else like a tarball, a zip file or rpm packages? Well, containers are having some benefits, that will be hard to establish with other technologies.
- A container follows a quite hard specification, which makes it deployable on a wide variety of systems.
- A container isolates the application from other processes via namespaces, cgroups, permissions, etc.
- Container technology allows to reproduce a setup without manual interaction.
- Containers can be extended with additional layers.
- Container engines / orchestrators are having a defined interface (API).
This may sound quite nice, but what does this mean exactly?
Well, in a VM or bare metal Linux setup, you will have a single Apache httpd version. If you need multiple websites, you need to configure Apache httpd accordingly, which can be tricky sometimes. Furthermore, if one of the applications needs PHP7, another one requires PHP8 and there is also an application requiring python, you will have all of these tools on the same machine. This can lead to conflicts, longer updates and other Issues.
Containers try to solve these issues.
Why does one use containers?
Now... do you need to use containers? Is "container all the things" really a thing? Yes and No. There is an arguable benefit, but you will also need to establish new processes. So when should you use containers?
- You need to deploy multiple versions of the same software on your Linux system.
- You want to package your application, so it can be deployed on Debian, Fedora and openSuSE.
- You want to use some versioning pattern for the whole deployment.
- You want to sandbox processes and tools.
- You want to scale and orchestrate your application.
- You want to remove the application and all its dependencies, when no longer needed.
All of the above is helpful in several use cases:
- developer workstations / workflows
- testing workflows (especially CI/CD)
- release workflows
- deployment to multiple stages or green-blue deployments
- updating the software and all its dependencies
Containers are not helpful, if:
- your application is slow
- your software is not prepared for containers
- your application needs special handling to run/update/migrate
- your application needs lots of manual interaction
How can you start to use them?
I thought about this part quite hard. If it comes to containers, people will often state something like: "You just need to run
docker run -dt -p 80:80 httpd, and you will have a web server." This is true, but for me, it is not the best to start with some commands and just reproduce / copy-paste something. Therefore, I am starting a series of tutorials, explaining each aspect and giving examples.
If you cannot wait, I recommend having a look at the below linked guides to get started:
Containers can provide additional sandboxing, multiple versions of different software versions and an easy way of deployment. Learning and using containers the right way can improve the overall IT experience. Getting Started may not be easy, but totally worth it.