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 in Habré, and now it’s 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, also happened 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 mission 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 has matured to version 1.0 , received support in Minikube, and its latest achievement can be considered as the interface for the default container executable environment in the Kubic project , which, most notably, is being developed by the competitive community (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):
Fragment of the Docker and Podman command comparison table: most of them are the same, but there are also 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 daemons to work.
At least because of this architectural difference, it would be more correct to compare Podman not with Docker as such, but with crictl, a console utility from the cri-tools (it is used, in particular, to integrate containerd with Kubernetes). And here there are functional differences: Podman can restart the stopped containers, and also provides image container management. (For a more detailed comparison, see the OpenShift 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 only 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 ).
Podman Presentation 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.
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 Podman operation are utilities for Linux containers, such as 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
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 the remote execution of Podman commands.
Along with Podman, the article has already come across 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 hosted on GitHub just under that 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 brought to life 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's README:
We have already written about all these projects (runc, containers / image, containers / storage, CNI, conmon) in the CRI-O review , however, an important addition has since become a utility for building container images called buildah . In addition, Red Hat already has ready-made answers to some of the other needs of the modern world of containers, such as udica for generating SELinux security profiles and skopeo 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, orchestrated by DevOps and SRE engineers. 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 what is happening, 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 suggest 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, also happened 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 mission 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 has matured to version 1.0 , received support in Minikube, and its latest achievement can be considered as the interface for the default container executable environment in the Kubic project , which, most notably, is being developed by the competitive community (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. It was originally 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. ”
Fragment of the Docker and Podman command comparison table: most of them are the same, but there are also 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 daemons to work.
At least because of this architectural difference, it would be more correct to compare Podman not with Docker as such, but with crictl, a console utility from the cri-tools (it is used, in particular, to integrate containerd with Kubernetes). And here there are functional differences: Podman can restart the stopped containers, and also provides image container management. (For a more detailed comparison, see the OpenShift 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 only 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 ).
Podman Presentation 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.
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 Podman operation are utilities for Linux containers, such as 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
docker usage scenario: $ 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 the remote execution of Podman commands.
Not only Podman: libpod and ecosystem
Along with Podman, the article has already come across 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 hosted on GitHub just under that 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 brought to life 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's README:
We have already written about all these projects (runc, containers / image, containers / storage, CNI, conmon) in the CRI-O review , however, an important addition has since become a utility for building container images called buildah . In addition, Red Hat already has ready-made answers to some of the other needs of the modern world of containers, such as udica for generating SELinux security profiles and skopeo 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, orchestrated by DevOps and SRE engineers. 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 what is happening, 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 suggest 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 the main Docker repository suddenly became 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) - network interface and standard for Linux-containers ."
Source: https://habr.com/ru/post/426141/
All Articles