We quite often receive requests like:
- "Do you support Docker?"
- "How can we run Docker on our Managed Server?"
- "Do you offer Managed Docker?"
These requests kept growing, and unfortunately, we always had to respond:
"No, sorry! It's not possible at the moment because Docker needs to be run as root. With such a service running as root, we would not be able to maintain our security standards. Containers are only possible on a nine Managed Google Kubernetes Cluster."
However, starting now(!), we now can respond with:
"HELL YEAH! WE CAN! :D"
Realistically, we should possibly respond a little more professionally. 😉
Nevertheless, now we can deliver you a fully daemonless and rootless container runtime called "Podman".
You may be thinking right now: "Wait...this isn't Docker? I wanted Docker"
And yes, you’re right! But please, sit tight, keep reading, and I will explain everything to you. What you need to know at this point is, Podman will allow you to deploy your apps more easily, test production deployments more quickly, cut deployment times dramatically, and even allow you to run services that are not (yet) available as managed services.
Sound good? Great, then let us now dive into the more exciting part!
Podman and the difference to Docker
First of all: Podman is nearly functionally identical to Docker. Both solutions are container runtimes and they are able to use the same OCI images. Hence, even the syntax is mostly the same.
The key difference is how they handle the container stack.
Let's take a step back and look at how Docker works, this will help us to understand what’s so unique about Podman.
Docker uses a client-server architecture. The Docker client talks to the Docker daemon, which does the heavy lifting of building, running, and distributing your Docker containers.
The Docker daemon also communicates with other daemons to manage Docker services.
This means, when you use commands such as “docker run”, the client sends these commands via API requests to dockerd (the Docker daemon), which carries them out.
Now let us compare to Podman and have a look at its architecture:
The most significant difference is the absence of a centralized daemon. As previously mentioned, Podman is a daemonless Container Runtime, and that's the really cool part about it!
First (and this one is huge!), containers can be run by any user, with or without root privileges.
Second, no more centralized daemon process. Each container spawns its own child processes and handles the requests by itself (this is called a fork/execution model).
This architecture leads to a much more robust and secure container runtime.
On Docker, if one container has a problem that affects the centralized daemon, it could affect all other containers as well. On Podman, this can not happen.
Furthermore, running a container as root can be a serious security risk.
Depending on the image and services used, some design issues could possibly be exploited to “escape” a container and gain root privileges on the host system. Given this, it is best practice to run all containers as a non-root user.
There is one more big advantage for Podman over Docker: Podman can run containers like Docker but can also run Pods as you find on Kubernetes (Hence, the name “Podman”).
A Pod encapsulates an application's container (or, in some cases, multiple containers), including storage resources, a unique network identity (IP address), as well as options that control how the container(s) should run.
As an example, take the diagram to the right:
Here we have a Pod that contains two containers and one volume. One container runs a web server while the other container operates a file puller application.
The file puller extracts some files from the content manager and stores them in the shared volume. The web server accesses the files from the shared volume and delivers the files to the consumer.
Despite the three distinct internal objects, from an external point-of-view this is seen as just one entity as everything runs in the same namespace and has, therefore, only one external IP.
Source: https://kubernetes.io/docs/concepts/workloads/pods/pod-overview
When should I use Podman?
At this point, some of you may ask: "So… is this the perfect solution for everything or are there any downsides?"
Well, if you want to deploy a more complex infrastructure with high availability and great scalability, then you should consider using our Managed GKE (Google Kubernetes Engine): https://www.nine.ch/en/products/gke
However, for many use cases, this solution is perfect! Let’s look at a few examples:
- Are your deployments of a new version always painful, requiring a lot of time, often with a long downtime as well?
- Perhaps you want to set up a new Website with as little hassle as possible. Ideally, this would be an out-of-the-box solution that just works.
- Maybe you are already using Docker locally on your machine to test and develop your new application, and now you want to deploy it in your production environment.
- Do you still have an old application that requires PHP 5? Podman covers you there too!
Take an image that has the needed PHP version included, or create one yourself, and deploy your application inside the container.
Bonus: Using this method you can reduce the security risk of using an obsolete version because the old PHP version is sealed away from your host system.
Of course, sometimes there are still a few configurations needed here and there to be able to run your application in a container. But for a lot of mainstream applications, there are ready-to-use images already available.
- Perhaps you are planning to migrate your application to our nine Managed GKE service? Most likely, your application will require some tweaking and refactoring to be able to run perfectly on GKE.
The possibilities with Podman are endless and will help you in many ways.
You will 💙it!
Why are solutions like Podman only available now?
Containers and Security are a complex topic.
The demand for a rootless container runtime from the community has been growing steadily.
Docker has been adapted to be run as a non-root user, however, it was not designed for this scenario and therefore reduces the usability and functionality. Even then, there are still some security issues left, and as such, this wasn’t a solution we wanted to endorse as a managed service.
Today, many different container runtimes are available, including CRI-O, LXC, rtk and containerd, to name a few of the most popular ones. As you may have noticed, none of these solutions have emerged as the clear leader. Some of them can run rootless, but the extensive functionality or convenience of this easy-to-use design, as Docker provides, has not yet been achieved by any of it.
In mid-2017, a new competitor appeared in the arena - Podman:
Podman wanted to solve the fundamental architecture problems of Docker while offering the same functionalities. Already back then, it seemed to be an interesting concept with great potential.
This concept was proven correct over the ensuing years, and with the latest releases, Podman is now solidly established in terms of security, functionality, and stability. As a result of this maturity, we are now able to provide you Podman as one of our managed services.
On a side note: Red Hat heavily supports the Podman project. The company released Podman in RHEL 7.6 and even dropped Docker support completely starting with RHEL 8.
Get started
Did we spark your interest? Then let’s start having some fun with containers!
Our new Managed Simple Service “Podman” is available for all managed servers with Ubuntu 18.04 or newer for currently CHF 30.- per month.
Podman can be installed on your system in no-time, simply write us a support ticket and we will get you “containerized”!
If you’d like, you can already have a sneak peek at it with our step-by-step guide for setting up a Ghost CMS in a Podman Pod: https://support.nine.ch/a/4a1j_NF4fOQ
We’ll provide some additional examples of use cases and how to implement them with Podman in the coming weeks.
And as always, if you have any questions about our products, just let us know. We’re happy to help!
