Choose between Docker or Podman for test and development environments

When we must choose between Docker or Podman?

A lot of times we find that there are very few resources and we need an environment to perform a complete product demonstration at customer.

In those cases we’ll need to simulate an environment in the simplest way possible and with minimal resources. For this we’ll adopt containers, but which is the best solution for those small environments?

Table of Contents

Docker

Docker is the standard container environment, it is the most widespread and put together a set of powerful tools such as a client on the command line, an API server, a container lifecycle manager (containerd), and a container launcher (runc).

Install docker is easy, since docker supplies a script that execute the process of prepare and configure the necessary requirements and repositories and finally installs and configures docker leaving the service ready to use.

Podman

Podman is a container environment that does not use a service and therefore does not have an API server, requests are made only from the command line, which has advantages and disadvantages that we will explain at the article.

Install podman is easy in a Centos environment (yum install -y podman for Centos 7 and yum install -y container-tools for Centos 8) but you need some work in a Debian environment:

# sudo apt update && sudo apt install -y software-properties-common dirmngr
# sudo apt-key adv --keyserver ha.pool.sks-keyservers.net --recv-keys 0x018BA5AD9DF57A4448F0E6CF8BECF1637AD8C79D
# sudo sh -c "echo 'deb http://ppa.launchpad.net/projectatomic/ppa/ubuntu bionic main' > /etc/apt/sources.list.d/container.list"
# sudo apt update && sudo apt install -y podman skopeo buildah uidmap debootstrap

Deploy with Ansible

In our case we have used the Ansible roles developed at https://github.com/aescanero/disasterproject, to deploy two virtual machines, one with podman and the other with docker.

In the case of using a Debian based distribution we must to install Ansible:

$ sudo sh -c 'echo "deb http://ppa.launchpad.net/ansible/ansible/ubuntu trusty main" >>/etc/apt/sources.list'
$ sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 93C4A3FD7BB9C367
$ sudo apt-get update && sudo apt-get install -y ansible

We proceed to download the environment and configure Ansible:

$ git clone https://github.com/aescanero/disasterproject
$ cd disasterproject/ansible
$ chmod 600 files/insecure_private_key

Edit the inventory.yml file which must have the following format:

all:
  children:
    vms:
      hosts:
        MACHINE_NAME1:
          memory: MEMORY_IN_MB
          vcpus: vCPUS_FOR_VM
          vm_ip: "IP_VM_MACHINA_NAME1"
          linux_flavor: "debian|centos"
          container_engine: "docker|podman"
        MACHINE_NAME2:
          memory: MEMORY_IN_MB
          vcpus: vCPUS_FOR_VM
          vm_ip: "IP_VM_MACHINA_NAME2"
          linux_flavor: "debian|centos"
          container_engine: "docker|podman"
      vars:
        network_name: NETWORK_NAME
        network: "VM_NETWORK"

There are some global variables that hang from “vars:”, which are:

network_name: Descriptive name of the libvirt network that we will use and that will also be the name of the interface that will be configured on the KVM host and that will serve as the gateway of the virtual machines
network: the first three fields of the IPv4 address to conform a network with mask 255.255.255.0, virtual machines must have an IP of that range (minus .1 and .255)

The format of each machine is defined by the following attributes:

machine_name: Descriptive name of the virtual machine to be deployed, it will also be the hostname of the virtual machine.
memory: Virtual machine memory in MB
vcpus: Number of virtual CPUs in the virtual machine
vm_ip: IP of the virtual machine, must belong to the range defined in the general variable “network”
linux_flavor: It is the linux distribution of the virtual machine, three options are allowed: debian, centos and oracle (for oracle linux 8).
container_engine: (Optional) It is the container engine that can be deployed in the virtual machine, four options are allowed: docker, podman, kubernetes and k3s

We deploy the environment with:

$ ansible-playbook -i inventory.yml create.yml --ask-become-pass

How to access

As a result, we obtain two virtual machines that we can access via ssh with ssh -i files/insecure_private_key vagrant@VIRTUAL_MACHINE_IP, in each of them we proceed to launch a container, docker run -td nginx and podman run -dt nginx. Once the nginx containers are deployed, we analyze what services are executed in each case.

Results of the comparison

Docker, start 32 processes to launch nginx:

containerd-+-containerd-shim-+-nginx---nginx
                     |                 `-10*[{containerd-shim}]
                     `-8*[{containerd}]
dockerd---9*[{dockerd}]
3194 root      20   0  546332  92220  39252 S  0.0  9.5   0:07.23 dockerd
 2314 root      20   0  463200  41696  25768 S  0.0  4.3   0:00.57 containerd
 3621 root      20   0   32648   5244   4564 S  0.0  0.5   0:00.08 nginx
 3603 root      20   0   11720   4612   3856 S  0.0  0.5   0:00.03 containerd-shim
 3500 root      20   0   20472   2692   1656 S  0.0  0.3   0:00.00 dhclient
 3479 root      20   0   20352   2676   1636 S  0.0  0.3   0:00.00 dhclient
 3656 systemd+  20   0   33100   2508   1468 S  0.0  0.3   0:00.00 nginx

Podman, start only a process to launch nginx:

conmon-+-nginx---nginx
                 `-{gmain}
 3471 root      20   0   32648   5180   4500 S  0.0  0.5   0:00.06 nginx
 3482 systemd+  20   0   33100   2420   1380 S  0.0  0.2   0:00.00 nginx
 3461 root      20   0   85800   1924   1768 S  0.0  0.2   0:00.00 conmon

About the size of the virtual machines there is only 100 MB of difference between the two:

1,5G docker.qcow2
1,4G podman.qcow2

In conclusion we have the following points:

Docker	Podman
Life cycle management, for example restart of containers that fail automatically, start containers automatically when the computer restarts, run checks on containers, start containers in a certain order, etc.	It’s compatible with Docker at the CLI level, image and load from registry. It depends on systemd to manage the life cycle management of containers.
It requires more resources, but in a demo / development environment with few containers it should not require significant resources.	It left more resources available for containers, which is ideal for a virtual machine demo environment. It occupies a smaller space and requires less dependencies.

Podman is a RedHat project that is gaining strength and many development services are considering adoption (for example the syslog-ng project: https://www.syslog-ng.com/community/b/blog/posts/replacing-docker-with-podman-in-the-syslog-ng-build-container)

More information on how to adapt Podman in Replacing Docker with Podman.