Introducing kpod^Hpodman
NOTE: Edited to change name of kpod to podman
The world of software-as-a-service, containers, serverless and beyond do not obviate the need for lower level debugging capabilities. As well, it is important for both developers and operators to reason about their environment when it gets into unforeseen states. A systems thinking design approach is most applicable. From @rands;
We are building a tool called podman as part of the CRI-O (“Container Runtime Interface — Open container initiative”) effort. We realized early on that when administrators set up and run Kubernetes, they often need to debug issues, or at least give themselves the warm and fuzzies about what is going on on a particular host.
Currently Kubernetes defaults to running on the upstream docker engine. Thus administrators rely on the upstream docker CLI for looking at their container infrastructure, “under the hood.”
Since CRI-O is an effort to build a different container runtime, we needed a tool to allow administrators and developers a better experience.
There are tools in CRI-O like crictl and crioctl, which talk to the CRI-O daemon, which do an excellent job of showing you what Kubernetes is seeing. However, they don’t allow you to inspect lower in the stack and they also don’t work if the CRI-O daemon is broken or hung up.
Thus ‘podman’ was born.
The initial version of podman is just about managing containers and container images. We want to match what the Kubernetes administrators are already comfortable with. For example, if you’ve been using the ‘docker pull’ command to grab container images, you’ll be able to use ‘podman pull’ to retrieve the same container image. If you want to run a container, you can use ‘podman run…’
We also plan on going beyond the current tools you’re used to, and adding commands. For example, if you’d like to examine a container without running it, podman mount/umount allow you to mount and examine and manipulate container images. Eventually we want to bring more of the Kubernetes “pod” concepts into podman, to allow administrators to list, create, remove, start, and stop pods, and to add/remove containers to/from pods.
Podman is different though, as it does not require a daemon to run. There is no client/server interface. Basically, its commands will work directly with github.com/containers/storage and github.com/containers/image and the OCI Runtimes, using the same backends as the CRI-O daemon.
Over the next few weeks we will be writing up a series of blogs and demonstrations to show each command as they come online. Expect the first articles to hit this blog later this month.
As always we are looking for help in building out the podman command suite. Patches are always welcome at https://github.com/projectatomic/libpod.
