Ed Santiago (@edsantiago) needed help with his New York Times crossword puzzle. So naturally he turned to Podman to save the day. Read about it in his blog post: Podman Saves My Crossword Habit. Many thanks to Ed for sharing this innovative use of Podman.
It's in German, but a worthy read Podman: Linux containers made easy, part 1. Valentin Rothberg (@vrothberg) introduces Podman to the reader and talks about how it fits in the container eco-system. If your German is a little rusty, you may need to lean on Google Translate.
A new article about how Docker users can use Podman and Buildah on the Red Hat Developer Site. William Henry (@ipbabble) introduces the two tools to Docker users and explains how they can be used to replace Docker and how the two tools are related.
Commands used by container runtimes to create containers have become complex. It is on purpose of course. When creating containers, we want the ability to specify various security or network attributes. But if you are in the unenviable position to have to keystroke in some of these lengthy commands, it can grow tiresome. Defining labels on the container image is a great way to define how the container should be run; however, now with Podman we can read and execute that label saving you potential command line bloat.
We are seeing a proliferation of Podman usage in users' daily workflows. As such, these workflows are often scripted -- in something like bash -- and clear exit codes from the applications being run are paramount. One of the tasks we often see is a user wanting to verify if an image or a container exists in local storage. We saw several different approaches approaches to solving this including running podman ps or podman images with filters or complex uses of grep.
Libpod development is still very much active and on-going. We often have folks who are looking to test out the latest libpod and Podman for either new features or bug fixes. We typically build RPMs for distributions like Fedora on a release cadence, which used to be weekly but now has slowed down as libpod has stabilized. Building libpod from source is not difficult, but sometimes the user's environment will not allow them to install all the packages needed; or perhaps the user is intimidated by building from source; or perhaps the user would prefer the RPM package because it will make the upgrade process easier down the road.
To solve this problem, I have created a series of container images for CentOS7, Fedora 28, and Fedora 29 that are capable of building a development Podman RPM and associated packages.
Kubernetes installations can be complex with multiple runtime dependencies and runtime engines. CRI-O was created to provide a lightweight runtime for Kubernetes which adds an abstraction layer between the cluster and the runtime that allows for various OCI runtime technologies. However you still have the problem of daemon dependencies in your cluster for builds - I.e. if you are using the cluster for builds you still need a Docker daemon.
Enter Buildah. Buildah allows you to have a Kubernetes cluster without any Docker daemon for both runtime and builds. Excellent. But what if things go wrong? What if you want to do troubleshooting or debugging of containers in your cluster? Buildah isn’t really built for that, what you need is a client tool for working with containers and the one that comes to mind is Docker CLI - but then you’re back to using the daemon.
This is where Podman steps in. Podman allows you to do all of the Docker commands without the daemon dependency. With Podman you can run, build (it calls Buildah under the covers for this), modify and troubleshoot containers in your Kubernetes cluster. With the two projects together, you have a well rounded solution for your OCI container image and container needs.
With the help of Checkpoint/Restore In Userspace (CRIU) I was able to add initial checkpoint/restore support to Podman. Using checkpoint/restore it is now possible to resume a container after a reboot at exactly the same point in time it was checkpointed.