Bienvenidos a la página personal de José Domingo Muñoz Rodríguez, aquí podrás encontrar…

Accede a las entradas de mi blog donde escribo de Informática y Educación.

Blog Pledin

Accede a los materiales de los cursos que he impartido.

Plataforma Pledin

Accede a los contenido de los módulos de FP que estoy impartiendo en la actualidad.

Módulos FP

Microblog

Fundamentos de Sistemas Operativos

Fundamentos de Sistemas Operativos: Una Aproximación Práctica Usando Linux, es un libro libre y gratuito, que se distribuye bajo una licencia Creative Commons. Es un libro de sistemas operativos, centrado en sistemas GNU/Linux.

Descarga el PDF.

Detalle

SSH Túnel

A veces es útil enrutar el tráfico a través de una máquina diferente para pruebas o desarrollo. Una alternativa es el uso de una VPN, pero es más sencillo usar un túnel proxy SOCKS encriptado, usando una conexión SSH. De esta forma, todas las aplicaciones que utilicen el proxy se conectarán al servidor SSH y el servidor reenviará todo el tráfico a su destino real. Para ello, seguimos los siguientes pasos:

  1. En un terminal, realizamos una conexión SSH a un servidor remoto. Al conectar a localhost al puerto indicado se transmitirá al servidor remoto: 
      ssh -ND 9999 [USER]@[SERVER_IP]
  2. Dejamos la terminal abierta, y configuramos el proxy en el navegador web, por ejemplo en Firefox:

Detalle

Podman in Action

Un interesante libro para introducirse en el funcionamiento de los contenedores con Podman. Muestra de una manera muy clara las diferencias y similitudes con Docker y las funcionalidades más importantes de este gestor de contenedores.

Descargar “Podman in Action”

Detalle

Blog

Integración de Podman con systemd usando Quadlet

podman

Introducción a Quadlet

Systemd

Systemd es un sistema de inicio y administración de servicios para sistemas operativos basados en Linux. Además de ser el sistema de inicio que se usa actualmente en las distribuciones Linux, ofrece un conjunto de servicios básicos para el sistema.

Systemd utiliza las Unidades de Servicios: Cada servicio o recurso que Systemd administra está definido por un archivo de unidad (unit file) que especifica cómo debe ser gestionado. Estos archivos pueden configurar el comportamiento del servicio, sus dependencias, el entorno en el que se ejecuta y otras opciones.

Política de reinicio de los contenedores Podman

Un inconveniente de que Podman no utilice un demonio que controla la ejecución de los contenedores, es que si reiniciamos el host, los contenedores no se inician.

Una posible solución es activar el servicio podman-restart que reinicia los contenedores cuya política de reinicio esté activa, con el parámetro --restart=always de podman run. Por ejemplo:

$ sudo podman run -d --name c1 --restart=always quay.io/libpod/banner
$ podman run -d --name c2 --restart=always quay.io/libpod/banner

Para activar el servicio:

  • En entorno rootful: 
    $ sudo systemctl enable podman-restart
$ sudo systemctl start podman-restart
  • En entorno rootless: 
    $ systemctl --user enable podman-restart
$ systemctl --user start podman-restart

    Ahora puedes comprobar que los contenedores se inician de forma automática tras el reinicio del host.

Otra solución al inicio automático de los contenedores después de un reinicio sería integrar la ejecución de contenedores con Systemd. Para conseguir este objetivo vamos a usar Quadlet.

Quadlet

Desde su inicio Podman se ha integrado muy bien con Systemd, posibilitando la gestión de contenedores con unidades de servicios. En un principio se creaban una unidad Systemd que llamaba a Podman con el subcomando run. Podman también proporcionaba podman generate systemd para crear fácilmente dicho archivo Systemd.

Sin embargo, esta opción no es la recomendada, y actualmente se prefiere el uso de Quadlet (que ha sido integrado en Podman) para gestionar la ejecución de contenedores Podman con Systemd.

Quadlet permite la generación automática de unidades de servicio de Systemd, a partir de unas plantillas que nos permiten definir de manera sencilla el recurso de Podman que queremos controlar con Systemd. Los recursos que actualmente podemos controlar con Quadlet y Systemd son los siguientes:

  • Contenedores
  • Volúmenes
  • Redes
  • Pods
Seguir leyendo...

Trabajando con Pods en Podman

podman

¿Qué es un Pod?

  • Un Pod es un concepto que proviene de Kubernetes.
  • En Kubernetes los contenedores se ejecutan en Pods. En inglés Pod significa “vaina”, y podemos entender un Pod como una envoltura que contiene uno o varios contenedores.
  • Un Pod representa un conjunto de contenedores que comparten almacenamiento y una única IP.
  • Un Pod recibe una dirección IP que es compartida por todos los contenedores.
  • Esto significa que todos los servicios que se ejecutan en los diferentes contenedores pueden referirse entre sí como localhost, mientras que los contenedores externos seguirán contactando con la dirección IP del Pod.

Gestión de Pods con Podman

pod

  • Cada Pod en Podman incluye un contenedor llamado “infra”.
    • Este contenedor no hace nada más que dormir.
    • Su propósito es mantener los espacios de nombres asociados con el pod y permitir a Podman conectar otros contenedores al pod.
    • Esto le permite iniciar y detener contenedores dentro del Pod.
    • El contenedor infra por defecto está basado en la imagen localhost/podman-pause.
  • Como vemos en la imagen el Pod puede estar formada por varios contenedores:
    • Si seguimos la filosofía de Kubernetes cada Pod tendrá un contenedor principal encargado de ofrecer el servicio.
    • Si necesitamos realizar procesos auxiliares fuertemente acoplados con el principal, podemos tener contenedores secundarios que llamamos contenedores sidecar. Por ejemplo: Un servidor web nginx con un servidor de aplicaciones PHP-FPM, que se implementaría mediante un solo Pod, pero ejecutando un proceso de nginx en un contenedor y otro proceso de php-fpm en otro contenedor.
    • Evidentemente también podemos utilizar Pods multicontenedores para desplegar aplicaciones que necesitan más de un servicio para su funcionamiento.
  • En el diagrama anterior, también observamos el proceso conmon, este es el monitor del contenedor. Es un pequeño programa en C cuyo trabajo es monitorizar los contenedores y permitimos conectarnos a ellos. Cada contenedor tiene su propia instancia de conmon, independientemente se ejecute dentro de un Pod: 
      $ podman run -d quay.io/libpod/banner
    
  $ pstree
  systemd─┬─...
          ├─conmon───nginx───2*[nginx]
  • En Podman podemos trabajar con Pods en entornos rootful y rootless.
Seguir leyendo...

Redes en contenedores rootless con Podman

podman

Podman nos ofrece distintos mecanismos de red para ofrecer conectividad al contenedor:

  • netavark: Podman 4.0 utiliza un driver de red llamado netavark para ofrecer a los contenedores una dirección IP enrutable. El driver netavark sigue las especificaciones establecidas por el proyecto CNI (Container Network Interface) que estandariza los medios de comunicación de red que utilizan los contenedores OCI.
  • slirp4netns: Cuando usamos contenedores rootless, tenemos una limitación debida a que los usuarios sin privilegios no pueden modificar el espacio de nombres de red del host. Por lo tanto necesitamos un mecanismos en el espacio de usuario que haga de proxy para conexiones de red del contenedor.
    • En Podman 4, se utiliza, por defecto el proyecto slirp4netns que nos proporciona conectividad a los contenedores pero sin ofrecerles una dirección IP enrutable.
    • En Podman 5 este proyecto se ha sustituido por otro proyecto con las mismas características llamado pasta.

Tipos de redes en Podman

  • Red Bridge: Nos permite que los contenedores estén conectados a una red privada, con un direccionamiento privado conectado al host mediante un Linux Bridge.
    • Nos permiten aislar los contenedores del acceso exterior.
    • Los contenedores conectados a un red bridge tienen acceso a internet por medio de una regla SNAT.
    • Usamos el parámetro -p en podman run para exponer algún puerto. Se crea una regla DNAT para tener acceso al puerto.
  • Red Host: La pila de red de ese contenedor no está aislada del host, es decir, el contenedor no tiene asignada su propia dirección IP. Por ejemplo, si ejecutas un contenedor que ofrece su servicio en al puerto 80/tcp y utilizas el modo de red host, la aplicación del contenedor estará disponible en el puerto 80/tcp de la dirección IP del host.
  • Redes macvlan o ipvlan: Son configuraciones más avanzadas de red, donde se permite que el contenedor esté conectado directamente a la red donde está conectado el host. La diferencia entre las dos, es que mientras macvlan permite la comunicación entre contenedores, ipvlan aísla completamente a cada contenedor.
  • Red slirp4netns: Es la opción por defecto cuando trabajamos con contenedores rootless. Crea un túnel desde el host al contenedor para reenviar el tráfico.
Seguir leyendo...

Más posts en el Blog...

Más post en el Microblog...

Últimos cursos...

cc

Licencia

Licencia: Puedes copiar y modificar todos los contenidos, pero siempre respetando los términos de la licencia CC-BY-SA.

Ver

Mastodon