Red Hat replaces Docker with Podman
It is clear that at the moment passions around Red Hat have a very different and very global focus , but we are still talking about our local and applied from the world of containers. Since the beginning of this year, Red Hat has been actively working on a replacement for Docker called Podman (or libpod ). For some reason, they did not write about this project on Habré, and now it is a very good time to get to know him, learn about his background and think about prospects. Go!
If you take a look at the modern world of Linux containers, it is easy to see that the topic of today's article is just one of the steps in the Red Hat long-term strategy. A striking confirmation of this is the CRI-O project , which we wrote about a year ago. In short, CRI-O is a implementation of the Kubernetes CRI (Container Runtime Interface) interface for launching executable container environments that are compatible with the OCI (Open Container Initiative) standard. If it is even shorter, then this is a replacement for Docker as a Kubernetes runtime. (A technically similar initiative for K8s on the part of Docker Inc. is cri-containerd , which we also wrote about ; in the same article there is a comparison of the performance of these two solutions.)
The story behind CRI-O is such that while OCI was preparing standards for containers ( Runtime Specification and Image Specification ) [which, incidentally, was also happening with the participation of Red Hat] , they created and placed a new project called OCID in Kubernetes in an incubator ( Open Container Initiative Daemon), which was later [at the request of OCI] renamed CRI-O. Its purpose sounded like “the implementation of a standard interface for the executable environment for containers in Kubernetes”, and promotion to the “technical masses” was carried out as part of a larger project on the creation of an operating system for containers - Project Atomic .
Caps with CRI-O logo on KubeCon + CloudNativeCon North America 2017
Over the past time, CRI-O matured to version 1.0 , I have received support in Minikube, and his latest achievement is the adoption as an interface for the runtime default container in Kubic project , which is especially remarkable, evolving community competition (for Red Hat) Linux distribution - openSUSE.
Returning to the topic of the article: Podman was originally part of CRI-O.
The official announcement of the project Podman (the name is short for “pod manager”) took place in February of this year:
For this reason, the announcement itself was titled as “ reintroduction” . And the first public release of Podman - v0.2 - took place 2 weeks before this announcement. So what is the essence of Podman?
The goal of Podman is to provide a console interface for running containers outside the orchestration system. It is noteworthy that launched containers can be combined into special groups with common namespaces, i.e. pods - this concept has already become well known thanks to Kubernetes. The project follows the ideology of UNIX-commands, where each utility does only one thing, but well. Another important detail, which the developers constantly emphasize, was already cited above in the announcement: Podman can be used both with CRI-O and independently of it.
In general, the main idea of Podman is to provide Kubernetes users, who chose CRI-O as an executable environment for containers, with an analogue of the Docker CLI console interface (to interact with containers and images running in clusters):
Docker and Podman command comparison table fragment: most of them are the same, but there are differences.
However, behind this apparent identity in the interface lies the fundamental difference in architecture: if the Docker CLI communicates with the Docker daemon to execute commands, then Podman is an independent utility that does not require any demons for their work.
At least because of this architectural difference, it would be more correct to compare Podman not with Docker per se, but with crictl, a console utility from the cri-tools (it is used, in particular, to integrate containerd with Kubernetes). And there are functional differences: Podman can restart the stopped containers, and also provides image container management. (For a more detailed comparison, seeOpenshift blog . )
With the release of Fedora 28 Atomic Host (May of this year), Podman has become the default Linux distribution tool for managing containers. And just recently, in September, at the Linux conference All Systems Go! in Berlin, Dan Walsh, head of the Red Hat Container Engineering team, introduced Podman to an even wider audience - a recording of the performance can be seen here (and only the presentation here ).
Presentation of Podman on All Systems Go! 2018
The latest release of Podman is v0.10.1.3 (of October 18), and the latest with new features is v0.10.1 (of October 12), which absorbed several new commands and additional flags.
The Podman code is written in the Go language and is distributed under the terms of the free Apache License 2.0. Ready-to-install packages are available for Fedora version 27 and higher (there is also a Ubuntu installation guide ). Among the dependent components for the operation of Podman are utilities for Linux containers like runc and conmon , as well as CNI network plugins .
Both the launch of the container with Podman and the subsequent work with it are similar to the usual usage scenario
For a practical introduction to Podman, you can also use the corresponding online script on Katacoda: “ Containers without Docker - Launching Containers using Podman and Libpod ”.
Finally, a separate mention is made of the pypodman project , which is under active development and offers an interface written in Python for remote execution of Podman commands.
In the article, more than once along with Podman there was a mention of the libpod project. What is the difference?
If we talk about the “full” Red Hat project, then it is actually called libpod and is placed on GitHub under this name. Today, libpod is positioned as a “library for applications that need to work with the concept of pods from containers, popularized by Kubernetes”. Podman itself is a utility included in the libpod library.
If you go back to a wider view of the containers, then Red Hat has its own vision, which is realized by a whole set of utilities for all occasions. Most of them are concentrated in the repositories with the speaking name github.com/containers , and this alone shows the obvious ambitions of the company(By the way, some of these projects used to be located on github.com/projectatomic ) .
Red Hat's views on the standardization and development of the container ecosystem are formulated directly in the libpod project README:
We have already written about almost all these projects (runc, containers / image, containers / storage, CNI, conmon) in the CRI-O review , but not least. Since then, it has become a utility for building images of containers called buildah . In addition, Red Hat already has ready-made answers to some other needs of the modern world of containers, such as udica for generating SELinux and skopeo security profiles. for working with remote image registries.
Just as Red Hat is not only behind its enterprise-wide platform for OpenShift containers, it also takes an active part in the life of Kubernetes, the underlying Open Source project, an American company realizes its view on modern IT infrastructure and on a more fundamental level - the containers themselves, which DevOps and SRE engineers are so concerned about. Podman and libpod are important components of the entire ecosystem that Red Hat forms in the world of open standards containers. If you look at it this way, then the IBM deal mentioned at the very beginning of the article, which is presented as an initiative to form a leading provider of solutions in the field of hybrid clouds, looks even more interesting throughout the industry ...
Finally, I offer a small survey about the awareness of Habra readers about the Podman project before the appearance of this article. Thanks for participating!
Read also in our blog:
CRI-O as prehistory
If you take a look at the modern world of Linux containers, it is easy to see that the topic of today's article is just one of the steps in the Red Hat long-term strategy. A striking confirmation of this is the CRI-O project , which we wrote about a year ago. In short, CRI-O is a implementation of the Kubernetes CRI (Container Runtime Interface) interface for launching executable container environments that are compatible with the OCI (Open Container Initiative) standard. If it is even shorter, then this is a replacement for Docker as a Kubernetes runtime. (A technically similar initiative for K8s on the part of Docker Inc. is cri-containerd , which we also wrote about ; in the same article there is a comparison of the performance of these two solutions.)
The story behind CRI-O is such that while OCI was preparing standards for containers ( Runtime Specification and Image Specification ) [which, incidentally, was also happening with the participation of Red Hat] , they created and placed a new project called OCID in Kubernetes in an incubator ( Open Container Initiative Daemon), which was later [at the request of OCI] renamed CRI-O. Its purpose sounded like “the implementation of a standard interface for the executable environment for containers in Kubernetes”, and promotion to the “technical masses” was carried out as part of a larger project on the creation of an operating system for containers - Project Atomic .
Caps with CRI-O logo on KubeCon + CloudNativeCon North America 2017
Over the past time, CRI-O matured to version 1.0 , I have received support in Minikube, and his latest achievement is the adoption as an interface for the runtime default container in Kubic project , which is especially remarkable, evolving community competition (for Red Hat) Linux distribution - openSUSE.
Returning to the topic of the article: Podman was originally part of CRI-O.
The appearance and essence of Podman
The official announcement of the project Podman (the name is short for “pod manager”) took place in February of this year:
“Podman (formerly known as kpod) has existed since last summer. Initially, it was part of the CRI-O project . We selected podman into a separate project - libpod . We wanted both Podman and CRI-O to evolve with their speed. Both work fine both individually (as independent utilities) and together. ”
For this reason, the announcement itself was titled as “ reintroduction” . And the first public release of Podman - v0.2 - took place 2 weeks before this announcement. So what is the essence of Podman?
The goal of Podman is to provide a console interface for running containers outside the orchestration system. It is noteworthy that launched containers can be combined into special groups with common namespaces, i.e. pods - this concept has already become well known thanks to Kubernetes. The project follows the ideology of UNIX-commands, where each utility does only one thing, but well. Another important detail, which the developers constantly emphasize, was already cited above in the announcement: Podman can be used both with CRI-O and independently of it.
In general, the main idea of Podman is to provide Kubernetes users, who chose CRI-O as an executable environment for containers, with an analogue of the Docker CLI console interface (to interact with containers and images running in clusters):
“Podman implements 38 of the 40 Docker CLI commands defined in Docker 1.13 (at the time of the announcement in February - approx. Transl. ), But we did not specifically repeat some of them. For example, those related to Docker Swarm - instead, for pods / containers that need orchestration, we suggest using Kubernetes. Also, some commands for the Docker Plugins like volume plug-ins and for the network were not implemented. A complete list of Podman commands and their equivalents in Docker can be found on the Podman Usage Transfer page . ”
Docker and Podman command comparison table fragment: most of them are the same, but there are differences.
However, behind this apparent identity in the interface lies the fundamental difference in architecture: if the Docker CLI communicates with the Docker daemon to execute commands, then Podman is an independent utility that does not require any demons for their work.
At least because of this architectural difference, it would be more correct to compare Podman not with Docker per se, but with crictl, a console utility from the cri-tools (it is used, in particular, to integrate containerd with Kubernetes). And there are functional differences: Podman can restart the stopped containers, and also provides image container management. (For a more detailed comparison, seeOpenshift blog . )
With the release of Fedora 28 Atomic Host (May of this year), Podman has become the default Linux distribution tool for managing containers. And just recently, in September, at the Linux conference All Systems Go! in Berlin, Dan Walsh, head of the Red Hat Container Engineering team, introduced Podman to an even wider audience - a recording of the performance can be seen here (and only the presentation here ).
Presentation of Podman on All Systems Go! 2018
Technical Notes
The latest release of Podman is v0.10.1.3 (of October 18), and the latest with new features is v0.10.1 (of October 12), which absorbed several new commands and additional flags.
The Podman code is written in the Go language and is distributed under the terms of the free Apache License 2.0. Ready-to-install packages are available for Fedora version 27 and higher (there is also a Ubuntu installation guide ). Among the dependent components for the operation of Podman are utilities for Linux containers like runc and conmon , as well as CNI network plugins .
Both the launch of the container with Podman and the subsequent work with it are similar to the usual usage scenario
docker:$ sudo podman run -dt -e HTTPD_VAR_RUN=/var/run/httpd -e HTTPD_MAIN_CONF_D_PATH=/etc/httpd/conf.d \
-e HTTPD_MAIN_CONF_PATH=/etc/httpd/conf \
-e HTTPD_CONTAINER_SCRIPTS_PATH=/usr/share/container-scripts/httpd/ \
registry.fedoraproject.org/f27/httpd /usr/bin/run-httpd
$ sudo podman ps
...
$ sudo podman inspect -l
...
$ sudo podman logs --latest
10.88.0.1 - - [07/Feb/2018:15:22:11 +0000] "GET / HTTP/1.1" 200 612 "-""curl/7.55.1""-"
10.88.0.1 - - [07/Feb/2018:15:22:30 +0000] "GET / HTTP/1.1" 200 612 "-""curl/7.55.1""-"
10.88.0.1 - - [07/Feb/2018:15:22:30 +0000] "GET / HTTP/1.1" 200 612 "-""curl/7.55.1""-"
10.88.0.1 - - [07/Feb/2018:15:22:31 +0000] "GET / HTTP/1.1" 200 612 "-""curl/7.55.1""-"
10.88.0.1 - - [07/Feb/2018:15:22:31 +0000] "GET / HTTP/1.1" 200 612 "-""curl/7.55.1""-"
$ sudo podman top <container_id>
UID PID PPID C STIME TTY TIME CMD
0 31873 31863 0 09:21 ? 00:00:00 nginx: master process nginx -g daemon off;
101 31889 31873 0 09:21 ? 00:00:00 nginx: worker process
For a practical introduction to Podman, you can also use the corresponding online script on Katacoda: “ Containers without Docker - Launching Containers using Podman and Libpod ”.
Finally, a separate mention is made of the pypodman project , which is under active development and offers an interface written in Python for remote execution of Podman commands.
Not only Podman: libpod and ecosystem
In the article, more than once along with Podman there was a mention of the libpod project. What is the difference?
If we talk about the “full” Red Hat project, then it is actually called libpod and is placed on GitHub under this name. Today, libpod is positioned as a “library for applications that need to work with the concept of pods from containers, popularized by Kubernetes”. Podman itself is a utility included in the libpod library.
If you go back to a wider view of the containers, then Red Hat has its own vision, which is realized by a whole set of utilities for all occasions. Most of them are concentrated in the repositories with the speaking name github.com/containers , and this alone shows the obvious ambitions of the company(By the way, some of these projects used to be located on github.com/projectatomic ) .
Red Hat's views on the standardization and development of the container ecosystem are formulated directly in the libpod project README:
We have already written about almost all these projects (runc, containers / image, containers / storage, CNI, conmon) in the CRI-O review , but not least. Since then, it has become a utility for building images of containers called buildah . In addition, Red Hat already has ready-made answers to some other needs of the modern world of containers, such as udica for generating SELinux and skopeo security profiles. for working with remote image registries.
Summarizing
Just as Red Hat is not only behind its enterprise-wide platform for OpenShift containers, it also takes an active part in the life of Kubernetes, the underlying Open Source project, an American company realizes its view on modern IT infrastructure and on a more fundamental level - the containers themselves, which DevOps and SRE engineers are so concerned about. Podman and libpod are important components of the entire ecosystem that Red Hat forms in the world of open standards containers. If you look at it this way, then the IBM deal mentioned at the very beginning of the article, which is presented as an initiative to form a leading provider of solutions in the field of hybrid clouds, looks even more interesting throughout the industry ...
Finally, I offer a small survey about the awareness of Habra readers about the Podman project before the appearance of this article. Thanks for participating!
PS
Read also in our blog:
- " CRI-O - Docker alternative to launch containers in Kubernetes ";
- “ Containd integration with Kubernetes, replacing Docker, is ready for production ”;
- “ What is the essence of the Moby project and why did the main Docker repository suddenly become moby / moby? ";
- “The Linux distribution from scratch for building Docker images is our experience with dappdeps ”;
- “ The smallest Docker image is less than 1000 bytes ”;
- “ Container Networking Interface (CNI) is a network interface and standard for Linux containers .”
Only registered users can participate in the survey. Sign in , please.
Your knowledge of Podman (before this article):
- 92.3% I hear for the first time 613
- 6.9% Random mentions without immersion 46
- 0.1% Theoretical Introduction 1
- 0.4% Practical Experiments 3
- 0.1% Real usage (in production or close) 1