- Buildah to facilitate building of OCI images
Skopeo for sharing/finding container images on Docker registries, the Atomic registry, private registries, local directories and local OCI-layout directories.
Podman for running containers without need for daemon.
https://computingforgeeks.com/how-to-install-podman-on-ubuntu/
- How Docker CLI Works
The Docker CLI is a client/server operation and the Docker CLI communicates with the Docker engine when it wants to create or manipulate the operations of a container. This client/server architecture can lead into problems in production because one, you have to start the Docker daemon before Docker CLI comes alive. The Docker CLI then sends an API call to the Docker Engine to launch Open Container Initiative (OCI) Container runtime, in most cases runc, to start the container (projectatomic.io). What this means is that the launched containers are child processes of the Docker Engine.
What is Podman?
What then is Podman? Podman is a daemonless container engine for developing, managing, and running OCI Containers on your Linux System
Docker vs Podman
The major difference between Docker and Podman is that there is no daemon in Podman. It uses container runtimes as well for example runc but the launched containers are direct descendants of the podman process. This kind of architecture has its advantages such as the following:
Applied Cgroups or security constraints still control the container: Whatever cgroup constraints you apply on the podman command, the containers launched will receive those same constraints directly.
Advanced features of systemd can be utilized using this model: This can be done by placing podman into a systemd unit file and hence achieving more.
What about Libpod?
Libpod just provides a library for applications looking to use the Container Pod concept, popularized by Kubernetes.
It allows other tools to manage pods/container (projectatomic.io). Podman is the default CLI tool for using this library.
There are other two important Libraries that make Podman possible:
containers/storage – This library allows one to use copy-on-write (COW) file systems, required to run containers.
containers/image – This library that allows one to download and install OCI Based Container Images from containers registries like Docker.io, Quay, and Artifactory, as well as many others (projectatomic.io).
A good example is that you can be running a full Kubernetes environment with CRI-O, building container images using Buildah and managing your containers and pods with Podman at the same time (projectatomic.io).
https://computingforgeeks.com/using-podman-and-libpod-to-run-docker-containers/
- Podman helps users move to Kubernetes
Podman provides some extra features that help developers and operators in Kubernetes environments. There are extra commands provided by Podman that are not available in Docker. If you
are familiar with Docker and are considering using Kubernetes/OpenShift as your container platform, then Podman can help you.
Podman can generate a Kubernetes YAML file based on a running container using podman generate kube. The command podman pod can be used to help debug running Kubernetes pods along with the standard container commands.
You can either build using a Dockerfile using podman build or you can run a container and make lots of changes and then commit those changes to a new image tag
What is Buildah and why would I use it?
Podman does do builds and for those familiar with Docker, the build process is the same. You can either build using a Dockerfile using podman build or you can run a container and make lots of changes and then commit those changes to a new image tag
Buildah can be described as a superset of commands related to creating and managing container images and, therefore, it has much finer-grained control over images. Podman’s build command contains a subset of the Buildah functionality. It uses the same code as Buildah for building.
The most powerful way to use Buildah is to write Bash scripts for creating your images—in a similar way that you would write a Dockerfile.
When Kubernetes moved to CRI-O based on the OCI runtime specification, there was no need to run a Docker daemon and, therefore, no need to install Docker on any host in the Kubernetes cluster for running pods and containers.
Kubernetes could call CRI-O and it could call runC directly.This, in turn, starts the container processes.
However, if we want to use the same Kubernetes cluster to do builds, as in the case of OpenShift clusters, then we needed a new tool to perform builds that would not require the Docker daemon and subsequently require that Docker be installed.
Such a tool, based on the containers/storage and containers/image projects, would also eliminate the security risk of the open Docker daemon socket during builds, which concerned many users
There are a couple of extra things practitioners need to understand about Buildah:
It allows for finer control of creating image layers.
Buildah’s run command is not the same as Podman’s run command. Because Buildah is for building images, the run command is essentially the same as the Dockerfile RUN command.
Buildah can build images from scratch, that is, images with nothing in them at all.
In fact, looking at the container storage created as a result of a buildah from scratch command yields an empty directory. This is useful for creating very lightweight images that contain only the packages needed in order to run your application.
A good example use case for a scratch build is to consider the development images versus staging or production images of a Java application. During development, a Java application container image may require the Java compiler and Maven and other tools. But in production, you may only require the Java runtime and your packages. And, by the way, you also do not require a package manager such as DNF/YUM or even Bash. Buildah is a powerful CLI for this use case
Now that we had solved the Kubernetes runtime issue with CRI-O and runC, and we had solved the build problem with Buildah, there was still one reason why Docker was still needed on a Kubernetes host: debugging
How can we debug container issues on a host if we don’t have the tools to do it? We would need to install Docker, and then we are back where we started with the Docker daemon on the host. Podman solves this problem.
Podman becomes a tool that solves two problems. It allows operators to examine containers and images with commands they are familiar with using. And it also provides developers with the same tools.
https://developers.redhat.com/blog/2019/02/21/podman-and-buildah-for-docker-users/
When considering how to implement something like this, we considered the following developer and user workflow:
Create containers/pods locally using Podman on the command line.
Verify these containers/pods locally or in a localized container runtime (on a different physical machine).
Snapshot the container and pod descriptions using Podman and help users re-create them in Kubernetes.
Users add sophistication and orchestration (where Podman cannot) to the snapshot descriptions and leverage advanced functions of Kubernetes
https://developers.redhat.com/blog/2019/01/29/podman-kubernetes-yaml/
- The main motivation was to move away from the need of having a daemon that requires root access.
Podman, Skopeo and Buildah are a set of tools that you can use to manage and run container images
https://itnext.io/podman-and-skopeo-on-macos-1b3b9cf21e60
