¿Cuando elegimos Docker o Podman? Muchas veces nos encontramos que tenemos muy pocos recursos y necesitamos un entorno para realizar una completa demostración de producto a un cliente. En esos casos vamos a necesitar simular un entorno de la manera más sencilla y con menos recursos posibles y para ello usaremos contenedores, pero ¿cual es la mejor solución para esos pequeños entornos? Docker Docker es el entorno de contedores estandar en el mercado, es el más extendido y conforma un conjunto de herramientas extraordinariamente potentes como son un cliente desde linea de comandos, un API server, un gestor del ciclo de vida de los contenedores (containerd), un lanzador de contenedores (runc). Instalar docker es realmente fácil, ya que docker suministra un script que realiza el proceso de preparar y configurar los requisitos y los repositorios necesario y por último instala y configura docker dejando el servicio listo para usar. Podman Podman es un entorno de contenedores que no utiliza un servicio y por lo tanto no dispone de un API server, las peticiones se hacen únicamente desde la linea de comandos, lo que tiene ventajas y desventajas que explicaremos al final. Instalar podman es fácil en un entorno Centos (yum install -y podman para Centos 7 y yum install -y container-tools para Centos 8) pero necesita cierto trabajo en un entorno Debian: Despliegue con Ansible En nuestro caso hemos utilizado los roles Ansible desarrollados en https://github.com/aescanero/disasterproject, para desplegar dos máquinas virtuales, una con podman y la otra con docker. En el caso de usar una distribución basada en Debian instalamos Ansible: Procedemos a descargar el entorno y configurar Ansible: Editamos el archivo inventory.yml y le ponemos el siguiente formato: Existen algunas variables globales que cuelgan de “vars:”, que son: network_name: Nombre descriptivo de la red de libvirt que crearemos y que además será el nombre del interface que se configurará en el anfitrión KVM y que servirá de puerta de enlace de las máquinas virtuales network: los tres primeros campos de la dirección IPv4 para confirmar una red con máscara 255.255.255.0, las máquinas virtuales deberán tener una IP de dicho rango (menos 0,1 y 255) El formato de cada equipo se define por los siguientes atributos: nombre: Nombre descriptivo de la máquina virtual a desplegar, será además el hostname del equipo memory: Memoria de la máquina virtual en MB vcpus: Número de CPUs virtuales en la máquina virtual vm_ip: IP […]
Categoría: Series
Series de artículos explicativos sobre un tema tecnológico con un objetivo común.
Máquina virtual linux con KVM desde linea de comandos
Si queremos levantar máquinas virtuales en un entorno Linux KVM que no disponga de entorno gráfico podemos levantar máquinas virtuales desde linea de comando usando una plantilla XML. Este artículo explica como funciona internamente el despliegue que se realiza con Ansible-libvirt en https://www.disasterproject.com/index.php/2019/06/entorno-minimo-kvm-y-ansible/ Instalar Qemu-KVM y Libvirt Primero debemos tener instalado libvirt y Qemu-KVM que en Ubuntu/Debian se instala con: Y en CentOS/Redhat con: Para iniciar el servicio haremos $ sudo systemctl enable libvirtd && sudo systemctl start libvirtd Configurar una plantilla de red Libvirt nos provee de una poderosa herramienta para gestión de las máquinas virtuales llamada ‘virsh’, la cual debemos de utilizar para poder gestionar las máquinas virtuales KVM desde la linea de comandos. Para una máquina virtual necesitamos principalmente tres elementos, el primero es una configuración de red que entre otras cosas provea a las máquinas virtuales de IP vía DHCP. Para ello libvirt necesita de una plantilla XML como la siguiente (que llamaremos net.xml): Cuyos elementos principales son: NOMBRE_DE RED: Nombre descriptivo que vamos a dar a la red, por ejemplo red_pruebas o red_producción. NOMBRE_DEL_BRIDGE: Cada red crea una interfaz en el servidor anfitrión que servirá para dar salida y entrada a los paquetes de dicha red hacia el exterior. Aquí le asignamos un nombre descriptivo que nos permita identificar el interfaz. IP_HOST: La IP que dicho interfaz tendrá en el servidor anfitrión y que será la puerta de enlace de las máquinas virtuales MASCARA_RED: Depende de la red, habitualmente para pruebas y demos siempre una clase C (255.255.255.0) INICIO_RANGO_DHCP: Para asignar IPs a las máquinas virtuales libvirt usa un servidor DHCP interno (basado en dnsmasq), aquí definimos la primera IP que podemos servir a las máquinas virtuales. FIN_RANGO_DHCP: Y aquí le decimos la última IP que podemos servir a las máquinas virtuales para su uso. Preparando la imagen del sistema operativo El segundo elemento es la imagen de la máquina virtual, la imagen se puede crear o descargar, siendo recomendable lo segundo para reducir el tiempo de despliegue. Una fuente de imágenes para máquinas virtuales con KVM/libvirt es Vagrant ( https://app.vagrantup.com/boxes/search?provider=libvirt ), para obtener una imagen de la máquina virtual que nos interese de las que existen en dicha página nos las descargaremos de https://app.vagrantup.com/NOMBRE_APP/boxes/ETIQUETA_APP/versions/VERSION_APP/providers/libvirt.box siendo NOMBRE_APP el nombre de la aplicación que queremos utilizar (p.e. debian), ETIQUETA_APP es la distribución de dicha aplicación (p.e. stretch64) y por último VERSION_APP es la versión de la […]
KVM, Ansible y como hacer un entorno de pruebas
Vamos a seguir siempre la filosofía “KISS” (keep it simple stupid!)” para la creación de entornos de desarrollo locales con máquina virtuales, nos centraremos en el rendimiento que nos da KVM y las capacidades de Ansible.