Deploy a Pod on CentOS with Podman
If you’ve been following along in the open source news cycle lately, you’ve probably heard that Red Hat has dropped the docker container runtime engine from both its Red Hat Enterprise Linux (RHEL) and CentOS Linux distributions. That being the case, what do you do when you need to deploy containers? Fortunately, they’ve created a near drop-in replacement for docker, called Podman.
Podman is very similar to docker. Even the command structure is similar. However, under the hood, things are quite different. For example, instead of relying on a daemon, Podman deploys containers as their own child process.
Because its developers went this route, Podman had to have the ability for containers to operate together (otherwise the Podman system wouldn’t be very useful). Imagine, only being able to deploy a single container without other, interconnected containers (such as a WordPress container with a MySQL database). That solution is pods. Pods are a way to group containers such that they can operate together.
I’m going to walk you through the process of deploying a pod with Podman on CentOS 8.
What You’ll Need
The only thing you’ll need to deploy a pod with Podman is a running instance of CentOS 8 with Podman installed.
Creating a Pod
The first thing we’ll do is create a pod. The basic command structure is:
podman pod create
If you run the command without any arguments, it will create a pod with a random name. You might, however, want to give your pod a meaningful name. You could name your pod based on the function of the containers it will house, or a client, etc. Say, for instance, I want to deploy a pod named new_stack. That command would be:
podman pod create --name new_stack
The pod will be created and will report back to you the ID of the pod (Figure 1).
Figure 1: Our new pod, named new_stack, has been created.
There are other options you can use with the podman command. Those options are:
- –cgroup-parent value — Set the parent cgroup for the pod.
- –infra — Create an infra container associated with the pod that will share namespaces.
- –infra-command value — A command that will automatically run on the infra container when the pod is started (such as “/pause”).
- –infra-image value — The infra container image to be associated with the pod.
- –label value — Set the metadata for a pod.
- –label-file value — Set the metadata for a pod using a line-delimited file of labels.
- –pod-id-file value — Write the pod ID to a file.
- –publish value — Publish a container’s port (or a range of ports) to the host.
- –share value — A comma-delimited list of kernel namespaces to be shared.
We can view our newly created pod with the command:
podman pod list
This will show our newly created pod running, as well as its ID, name, status, and more (Figure 2).
Figure 2: Our newly created pod has been deployed.
In the pod details, you probably noticed that it already includes one container. But we have yet to deploy a container to the pod. What gives? This random container is an infra container. Every podman pod includes this infra container. These containers do nothing but go to sleep. Their purpose is to hold the namespaces associated with the pod and to allow Podman to connect other containers to the pod. The other purpose of the infra container is to allow the pod to keep running when all associated containers have been stopped.
To view the infra container, issue the command:
podman ps -a --pod
You should see any running pods, including the infra pod (Figure 3), which will be labeled as -infra.
Figure 3: Our infra pod is 50bca5875229-infra.
Add a Container
For our next trick, we’ll add a container to the newly deployed pod. Remember, we named that pod new_stack. That’s important, as you’ll need that name in order to deploy containers to that pod. We’ll use the official ubuntu image and deploy a container using it running the top command. This isn’t a very useful example, but it’s simple enough to show you how containers are deployed to pods. That command would be:
podman run -dt --pod new_stack ubuntu top
You will be returned with the container ID (Figure 4).
Figure 4
Figure 4: We’ve successfully deployed our container.
We can now check to see that our pod has more than one container with the command:
podman pod ps
Our new_stack pod now has two containers (the Infra container and the Ubuntu container running the top command — Figure 5).
Figure 5: Our pod now has two containers.
You can also view the individual containers within a pod with the command:
podman ps -a --pod
You’ll notice that Podman assigned a random name to the Ubuntu top container (in this case, fervent_jones — Figure 6).
Figure 6: All of the currently running containers.
All in One
Podman has a nifty trick up its sleeve in that it can create a pod and deploy a container to said pod with a single command. Let’s say you want to deploy an NGINX container, exposing external port 8080 to internal port 80 to a new pod named web_server. That command would be:
podman run -dt --pod new:web_server -p 8080:80 nginx
Check to see that your new pod was created with the command:
podman pod list
You should now see the web_server pod listed (Figure 7).
Figure 7: Our new web_server pod has been created and includes two containers.
Stopping Pods
Let’s stop our pods (and all of their associated containers). In order to do this, you need to find the name of the pods to be stopped. Issue the command:
podman pod list
You should see a list of running pods, in the same fashion as you saw before. However, to stop the pods (and all of its associated containers), you must use the INFRA ID with the command:
podman stop ID
Where ID is the INFRA ID for the pod in question.
You can then restart the pod (and its associated containers) with the command:
podman start ID
And that’s the fundamentals of using pods with Podman. You are now ready to deploy containers within pods on RHEL or CentOS 8.