Avengers of the Container World, Episode 1: Podman Hands-On
CRI-O and Podman have been widely adapted by most of the modern container platforms. In this blog, we will deep-dive on Podman with a hands-on session.
Join the DZone community and get the full member experience.Join For Free
CRI-O and Podman have been widely adapted by most of the modern container platforms. In this blog, I will explore why everybody is gaga about this new ecosystem of tools/utilities and share some of my experience in this series.
I got a lot of feedback, after I published my blog on Containers and evolution of Containers (you can read it here 'Evolution of k8s worker nodes - CRI-O'). One of the common questions asked, is how Podman is different from Docker and how the new ecosystem of podman+buildah+cri-o+skopio different from what we do with docker... so I wanted to do a deep dive on these things, and share some of my experiences with this new ecosystem of container runtime and management tools/utilities.
I am planning to split this series into 2 episodes:
- Episode 1: We will setup Podman and run a tomcat image
- Episode 2: We will use Buildah to build our own images and also explore Skopeo (you can read it here)
Podman is an OCI (Open Container Initiative) complaint Container Engine. (I had published a blog on CRI-O, where I took a deep dive on Docker architecture and evolution of CRI and OCI, you can read it here.)
Docker is one f the most widely used container runtimes in the world, and no doubt, it transformed the way we build cloud-native applications. Docker provided a very good end-to-end architecture for building, deploying, and managing containers.
Docker architecture is based on a daemon that runs as a service in the background. Docker daemon is responsible for running the commands, push/pull images to/from the registry, manage the containers and images on the local machine.
It looks like a very neat architecture.
So what are the shortcomings of this approach??
- Single point of failure: Docker is based on a typical client/server architecture, Docker CLI issues commands to Docker daemon, and Docker Daemon has all the logic to run and manage the images and containers. Docker daemon pretty much ended up as a fat monolith. Docker daemon controls all the child processes; a failure in docker daemon crashes all the child processes, including running containers.
- Root access: All the docker operations are conducted as a root user; this is practically an issue in enterprises, where root access is normally controlled due to security and compliance issues.
Podman works differently. Podman does not need a daemon, and it has decentralized the functionality. Podman does not need root access and can run with local user privileges, and the best part is the users can only view and manage containers that they have in their local login.
Podman does all that Docker does, and I know of a lot of us who do an alias of Podman with Docker do not even know the difference. Podman not only can run containers but also can run Pods. This is very powerful to run and manage multiple containers in a single pod (especially the side-car containers, which is very critical for ServiceMesh kind of architectures).
Now let's get hands-on. Podman only runs on Linux; for the rest of the blog, I will walk through how to run Podman. I am going to setup CentOS on VirtualBox/MacOS. I am going to use Vagrant to provision the virtual machines.
Step 1: Prepare Your Machine
- Download and install VirtualBox (here is the quick link).
- Download and install Vagrant (here is the quick link).
- Create a directory and move to that directory (optional).
- Initialize Vagrant.
Vagrant is a super powerful tool, that helps provision environments, very quickly with very simple declarative config file. You can read more about Vagrant here.
$ vagrant init centos/8
This creates a Vagrant file with the following content.
Now let's provision CentOS. This will install, download, and provision the CentOS VM in the Virtual Box.
$ vagrant up
You can check the VM in the VirtualBox.
Now that CentOS is up and running let's install Podman.
Step 2: Install Podman
Once Vagrant installs the CentOS, you can login to the CentOS with Shell with the following command:
Once you execute this command, Vagrant takes care of all the complexity of login credentials and will log you on to the CentOS shell.
Kubic project provides more latest updates to Podman, though this is not officially tested by RH. You can find more details about the Kubic project.
This step is optional!!!
Now we can install Podman with the following command:
Once Podman is installed, you can test if the installation with the following commands:
Step 3: Pull and Run Tomcat
Now let's pull the tomcat image; before that, you can search available images in the registry with the search command:
Before we pull the images, we have to login to the respective registries (refer to the Podman architecture). You can login to various registries.
In this case, I am logging in with my dockerhub.
Now let's pull the tomcat image:
Let's check if the image is pulled properly:
Let's run the container:
- -d option to run in detached mode.
- -t allocates a pseudo TTY for the process.
- what we see as the output is the containerid.
Lets now check if the container is running:
Finally, we got the tomcat running. Let's check if we can access it with CURL:
We can see that we are getting a 404 from the tomcat server.
Step 4: Access Container From the Host (macOS)
Remember, this CentOS is running inside VirtualBox. By default, the VirtualBox image would have been set as a NAT Networking setup; we will have to shut down the VirtualBox CentOS Image and then change the network settings before we can access the tomcat server.
Let's exit the ssh and shutdown the image:
Here is how the Vagrant file looks now:
Now let's start the image and check what the IP we got is.
As you notice, now the CentOS virtual machine has a network IP that can be accessed in the local network.
If we now start the tomcat container and access it from macOS using http://192.168.1.139:8080, we should be able to access the tomcat server.
(Of course, you will see a 404 page, as we have not deployed any web application yet, which we will be doing in the next episode).
That's it for the first episode... In the next episode, we will walk through building our own images using Buildah... and also explore Skopeo... it's going to be fun.
Published at DZone with permission of A B Vijay Kumar. See the original article here.
Opinions expressed by DZone contributors are their own.