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.
Accede a los materiales de los cursos que he impartido.
Accede a los contenido de los módulos de FP que estoy impartiendo en la actualidad.
Microblog
Public APIs: Una lista de APIs públicas
Esta página web y repositorio GitHub nos ofrece una lista bastante interesante de APIs públicas, que podemos usar en nuestros proyectos de programación. Puedes acceder a ellas:
- En la página web publicapis.dev.
- O en el repositorio de GitHub public-apis.
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:
- 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]
- Dejamos la terminal abierta, y configuramos el proxy en el navegador web, por ejemplo en Firefox:
Blog
Integración de Podman con systemd usando Quadlet
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
Trabajando con Pods en 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
- 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.
Redes en contenedores rootless con 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
enpodman 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.
Más posts en el Blog...
- Almacenamiento en contenedores rootless con Podman (10-05-2024)
- Introducción a los contenedores rootless con Podman (25-04-2024)
- Introducción a Podman (13-04-2024)
- Pledin estrena Microblog (20-03-2024)
- Resolución de nombres de dominios en sistemas Linux (20-02-2024)
- Configuración de SPF, DKIM y DMARC para asegurar el envío de correos (01-02-2024)
Más post en el Microblog...
- Podman in Action (09-05-2024)
- Inteligencia Artificial en la Microeducación: Transformando el Aula del Futuro (07-05-2024)
- Lanzamiento de Ubuntu 24.04 LTS (25-04-2024)
- Lanzamiento de Fedora Linux 40 (25-04-2024)
- El tiempo en tu terminal (23-04-2024)
- Inicialización de un contenedor con mariadb (17-04-2024)
Últimos cursos...
Licencia
Licencia: Puedes copiar y modificar todos los contenidos, pero siempre respetando los términos de la licencia CC-BY-SA.