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?


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).

running docker with containerd

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 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 --recv-keys 0x018BA5AD9DF57A4448F0E6CF8BECF1637AD8C79D
# sudo sh -c "echo 'deb 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, 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 trusty main" /etc/apt/sources.list'
$ sudo apt-key adv --keyserver --recv-keys 93C4A3FD7BB9C367
$ sudo apt-get update && sudo apt-get install -y ansible 

We proceed to download the environment and configure Ansible:

$ git clone
$ cd disasterproject/ansible
$ chmod 600 files/insecure_private_key

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

          memory: MEMORY_IN_MB
          vcpus: vCPUS_FOR_VM
          vm_ip: "IP_VM_MACHINA_NAME1"
          linux_flavor: "debian|centos"
          container_engine: "docker|podman"
          memory: MEMORY_IN_MB
          vcpus: vCPUS_FOR_VM
          vm_ip: "IP_VM_MACHINA_NAME2"
          linux_flavor: "debian|centos"
          container_engine: "docker|podman"
        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, 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.
Read the rest “Choose between Docker or Podman for test and development environments”

Linux virtual machine with KVM from the command line

If we want to raise virtual machines in a Linux environment that does not have a graphical environment, we can raise virtual machines using the command line with a XML template.

This article explains how the deployment performed with Ansible-libvirt at KVM, Ansible and how to deploy a test environment works internally

Install Qemu-KVM and Libvirt

Linux virtual machine with KVM from the command line 1

First: we must to install libvirt and Qemu-KVM. In Ubuntu / Debian is installed with:

$ sudo apt-get install -y libvirt-daemon-system python-libvirt python-lxml

And in CentOS / Redhat with:

$ sudo yum install -y libvirt-daemon-kvm python-lxml

To launch the service we must do: $ sudo systemctl enable libvirtd && sudo systemctl start libvirtd

Configure a network template

Libvirt provides us with a powerful tool for managing virtual machines called ‘virsh’, which we must use to be able to manage KVM virtual machines from the command line.

For a virtual machine we mainly need three elements, the first is a network configuration that provides IP to virtual machines via DHCP. To do this libvirt needs XML template like the next template (which we will designate “net.xml”):

<network<nameNETWORK_NAME</name<forward mode='nat'<nat<port start='1' end='65535'/</nat</forward<bridge name='BRIDGE_NAME' stp='on' delay='0'/<ip address='IP_HOST' netmask='NETWORK_MASK'<dhcp<range start='BEGIN_DHCP_RANGE' end='END_DHCP_RANGE'/</dhcp</ip</network

Whose main elements are:

  • NETWORK_NAME: Descriptive name that we are going to use to designate the network, for example, “test_net” or “production_net”.
  • BRIDGE_NAME: Each network creates an interface on the host server that will serve as gateway of the input/output packets of that previous network to the outside. Here we assign a descriptive name that let as identify the interface.
  • IP_HOST: The IP that such interface will have on the host server and that will be the gateway of the virtual machines.
  • NETWORK_MASK: Depends on the network, usually for testing must be use a class C (
  • BEGIN_DHCP_RANGE: To assign IPs to virtual machines using libvirt, there are an internal DHCP server (dnsmasq based), here we define the first IP of the range that we can serve to virtual machines.
Read the rest “Linux virtual machine with KVM from the command line”

KVM, Ansible and how to deploy a test environment

In local development environments there is always a need for simulation of more powerful environments, as usually happens in the making of demos.

For this we’ll always follow the “KISS” philosophy (keep it simple stupid!) And we will use those services so that our Linux requires the least use of possible resources. We’ll need two tools to simplify the work that are Ansible for deployment and KVM as a hypervisor.

Images for the test environment

The first step is to raise a system that provides us with images in the simplest way possible. We’ll find that Vagrant as a wonderful source of images. We have two ways to use it:

  1. Download from and install (with sudo dpkg -i vagrant_VERSION_x86_64.deb in Debian / Ubuntu environments or with sudo rpm -i vagrant_VERSION_x86_64.rpm in RHEL / Centos environments), to get an image as small as possible we will make use of a debian 9.9.0 with the following command:
    $ vagrant box add --provider libvirt debian/stretch64
    ==> box: Loading metadata for box 'debian/stretch64'
    box: URL:
    ==> box: Adding box 'debian/stretch64' (v9.9.0) for provider: libvirt
    box: Downloading:
    box: Download redirected to host:
    ==> box: Successfully added box 'debian/stretch64' (v9.9.0) for 'libvirt'!
    The downloaded image will be in ~/.vagrant.d/boxes/debian-VAGRANTSLASH-stretch64/9.9.0/libvirt, in the form of three files, being the one that interests us: box.img which is an image with QCOW format.

  2. Directly download the images that we will use, for example a Centos image: and a Debian image:
    To make the deployment easier, Ansible has been configured to download automatically and save the image in /root/.images and use it directly without need to do anything else.

The next thing we need is to download the Ansible tasks that will allow us to launch our test environment, the “package” is formed by a file that will be really important called “inventory.yml” where we will really define how our demo will be, it is formed by a “creation” and a “destruction” file of the virtualized environment.… Read the rest “KVM, Ansible and how to deploy a test environment”

Posts navigation

1 2
Scroll to top