Podman Conocido por su perfecta integración con los sistemas Linux modernos, el soporte para systemd es la piedra angular de estos esfuerzos. Linux generalmente usa el sistema systemd init para administrar servicios locales como servidores web, motores de contenedores, demonios de red y todas sus interdependencias. Extender estas prácticas de administración de sistemas Linux más tradicionales al mundo moderno de contenedores es una evolución natural.
Hay dos casos de uso comunes para combinar systemd y contenedores:
- Ejecutando systemd dentro de un contenedor
- Ejecución de aplicaciones en contenedores con systemd
El primer escenario es ejecutar systemd dentro de un contenedor. Como explicó Dan Walsh, Ejecutando systemd dentro de un contenedor Es tan fácil como usar Podman. Podman configura automáticamente varios montajes en el contenedor y systemd funciona muy bien. Si bien es una característica de Podman relativamente pequeña, fue un gran avance cuando se introdujo para ejecutar cargas de trabajo en contenedores.
Históricamente, otras herramientas de contenedor no eran compatibles con systemd. Los usuarios enfrentan el desafío de escribir scripts de inicialización personalizados, que son propensos a errores y suponen una carga de soporte para los proveedores de software. Con Podman, todos estos problemas se resuelven. Los usuarios pueden usar systemd para instalar y ejecutar sus aplicaciones en contenedores como en cualquier otro lugar, y los proveedores de software no tendrán que lidiar con scripts de inicio personalizados escritos por los usuarios.
El segundo caso es usar systemd para ejecutar y administrar aplicaciones en contenedores. Esto significa que systemd inicia una aplicación en contenedores y administra todo su ciclo de vida. Podman vía podman generate systemd comando que genera un archivo de unidad systemd para el contenedor o pod especificado. Podman v1.7 y versiones posteriores admiten la generación de dichas unidades. Con el tiempo, nuestro equipo ha mejorado esta función y ha generado archivos unitarios systemd que se pueden ejecutar en otras máquinas, de forma similar al uso de archivos YAML o Compose de Kubernetes. Además, la estrecha integración con systemd proporciona la base para actualizaciones automáticas y reversiones simples, compatibles desde Podman v3.4.
Si bien hay muchos blogs y artículos iniciales sobre la generación de unidades systemd para contenedores, ninguno para pods. Pero antes de discutir esos detalles, quiero repasar qué es un pod.
[ Getting started with containers? Check out this free course. Deploying containerized applications: A technical overview. ]
¿Qué son las vainas?
Hay varias partes diferentes en una cápsula, creo que Brent Baude mejor explicado La imagen de abajo es genial:
Lo primero que hay que notar es que un pod consta de uno o más contenedores. El grupo comparte grupos de control (cgroups) y espacios de nombres específicos, como espacios de nombres PID, red e IPC. Los cgroups compartidos aseguran que todos los contenedores tengan las mismas restricciones de recursos. Los espacios de nombres compartidos permiten que los contenedores se comuniquen entre sí más fácilmente (por ejemplo, a través de localhost o comunicación entre procesos).
También puede ver un contenedor de infraestructura especial. Su objetivo principal es mantener abiertos los recursos específicos asociados con un pod, como puertos, espacios de nombres o cgroups. El contenedor de infraestructura es el contenedor de nivel superior del pod, se crea antes que otros contenedores y finalmente se destruye. Está utilizando el contenedor de infraestructura cuando genera la unidad systemd para el pod, así que tenga en cuenta que este contenedor se ejecuta durante la vida útil del pod.Esto también significa que no puede generar unidades systemd para pods que no tienen contenedores de infraestructura (por ejemplo, --infra=false).
Por último, pero no menos importante, verá múltiples conmon Procesos en ejecución, uno por contenedor. «Común» es la abreviatura de monitor de contenedor, que resume sus funciones principales. También es responsable de reenviar registros y realizar operaciones de limpieza después de que sale el contenedor.Esta conmon El proceso comienza antes que el contenedor e instruye al tiempo de ejecución del contenedor subyacente (p. runc o crun) para crear e iniciar el contenedor. También sale con el código de salida del contenedor, lo que permite usarlo como proceso principal para los servicios de systemd.
Generar unidades systemd para pods
Podman solo genera una unidad de sistema para un contenedor.Después de la instalación, utilice systemctl Iniciar, detener y comprobar servicios. El PID principal de cada celda es el proceso común del contenedor. De esta forma, systemd puede leer el código de salida del contenedor y actuar de acuerdo con la política de reinicio configurada. Para obtener más detalles sobre las unidades, consulte Ejecución de contenedores con Podman y servicios compartidos systemd y Uso de systemd Podman mejorado de Podman 2.0.
Generar una unidad para un pod es muy similar a iniciar un contenedor. Cada contenedor en un pod tiene una unidad systemd dedicada, y cada unidad depende de la unidad systemd principal del pod.De esta manera puedes seguir usando systemctl Inicie, detenga y verifique el servicio principal del pod; systemd se encargará de (re)iniciar y detener el servicio del contenedor, así como el servicio principal.
Este ejemplo crea un pod con dos contenedores, genera un archivo de unidad para el pod y luego instala los archivos para el usuario actual:
$ podman pod create --name=my-pod
635bcc5bb5aa0a45af4c2f5a508ebd6a02b93e69324197a06d02a12873b6d1f7
$ podman create --pod=my-pod --name=container-a -t centos top
c04be9c4ac1c93473499571f3c2ad74deb3e0c14f4f00e89c7be3643368daf0e
$ podman create --pod=my-pod --name=container-b -t centos top
b42314b2deff99f5877e76058ac315b97cfb8dc40ed02f9b1b87f21a0cf2fbff
$ cd $HOME/.config/systemd/user
$ podman generate systemd --new --files --name my-pod
/home/vrothberg/.config/systemd/user/pod-my-pod.service
/home/vrothberg/.config/systemd/user/container-container-b.service
/home/vrothberg/.config/systemd/user/container-container-a.serviceComo era de esperar, Podman generó tres .service archivos, uno por contenedor, más los archivos de nivel superior para el pod. Consulte el apéndice al final del artículo para ver el contenido completo del archivo de la unidad. La unidad generada para ambos contenedores parece una unidad de contenedor estándar más las siguientes dependencias systemd:
BindsTo=pod-my-pod.service: La unidad contenedora está «vinculada» a la unidad del pod. Si la unidad de un pod se detiene, esa unidad también se detendrá.After=pod-my-pod.service: La unidad del contenedor comienza después de la unidad de la cápsula.
La dependencia del servicio principal del Pod garantiza además que si una unidad contenedora no se inicia correctamente, la unidad principal del Pod principal también fallará.
Eso es todo lo que necesita saber para usar Podman para generar unidades systemd para pods. Una vez que recarga systemd a través de systemctl --user daemon-reloadempezar y parar pod.service aleatorio. Echa un vistazo a:
# Reload the daemon
$ systemctl --user daemon-reload
# Start the pod service and make sure the service is running
$ systemctl --user start pod-my-pod.service
$ systemctl --user is-active pod-my-pod.service
active
# Make sure the pod and its containers are running
$ podman pod ps
POD ID NAME STATUS CREATED INFRA ID # OF CONTAINERS
6dd1090d4ca6 my-pod Running 2 minutes ago 85f760a5cfe5 3
user $ podman container ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
85f760a5cfe5 localhost/podman-pause:4.0.2-1646319369 5 minutes ago Up 5 minutes ago 6dd1090d4ca6-infra
44a7e60b9563 quay.io/centos/centos:latest top 5 minutes ago Up 5 minutes ago container-b
31f24bdff747 quay.io/centos/centos:latest top 5 minutes ago Up 5 minutes ago container-aGenial, todo funciona como se esperaba.puedes usarlo systemctl Inicie el servicio y Podman listará correctamente los Pods y sus contenedores. Para mantener la coherencia, un vistazo final a cómo detener un servicio de pod.
# Stop the pod service
$ systemctl --user stop pod-my-pod.service
# Make sure the pod and its containers are removed
$ podman pod ps -q
$ podman container ps -q
# Make sure the services are inactive
$ systemctl --user is-active pod-my-pod.service container-container-a.service container-container-b.service
inactive
inactive
inactiveEl mensaje final es que Podman genera unidades systemd para pods al igual que lo hace para contenedores. Las dependencias entre estas unidades están configuradas para que solo necesite interactuar con la unidad principal del pod, la unidad que systemd se encarga de iniciar y detener el contenedor.
apéndice
Podman genera los siguientes archivos de unidad para un pod y dos contenedores relacionados.
pod-my-pod.servicio
Description=Podman pod-my-pod.service
Documentation=man:podman-generate-systemd(1)
Wants=network-online.target
After=network-online.target
RequiresMountsFor=
Requires=container-container-a.service container-container-b.service
Before=container-container-a.service container-container-b.service
[Service]
Environment=PODMAN_SYSTEMD_UNIT=%n
Restart=on-failure
TimeoutStopSec=70
ExecStartPre=/bin/rm -f %t/pod-my-pod.pid %t/pod-my-pod.pod-id
ExecStartPre=/usr/bin/podman pod create --infra-conmon-pidfile %t/pod-my-pod.pid --pod-id-file %t/pod-my-pod.pod-id --name=my-pod --replace
ExecStart=/usr/bin/podman pod start --pod-id-file %t/pod-my-pod.pod-id
ExecStop=/usr/bin/podman pod stop --ignore --pod-id-file %t/pod-my-pod.pod-id -t 10
ExecStopPost=/usr/bin/podman pod rm --ignore -f --pod-id-file %t/pod-my-pod.pod-id
PIDFile=%t/pod-my-pod.pid
Type=forking
[Install]
WantedBy=default.targetcontainer-container-a.service
[Unit]
Description=Podman container-container-a.service
Documentation=man:podman-generate-systemd(1)
Wants=network-online.target
After=network-online.target
RequiresMountsFor=%t/containers
BindsTo=pod-my-pod.service
After=pod-my-pod.service
[Service]
Environment=PODMAN_SYSTEMD_UNIT=%n
Restart=on-failure
TimeoutStopSec=70
ExecStartPre=/bin/rm -f %t/%n.ctr-id
ExecStart=/usr/bin/podman run --cidfile=%t/%n.ctr-id --cgroups=no-conmon --rm --pod-id-file %t/pod-my-pod.pod-id --sdnotify=conmon -d --replace --name=container-a -t centos top
ExecStop=/usr/bin/podman stop --ignore --cidfile=%t/%n.ctr-id
ExecStopPost=/usr/bin/podman rm -f --ignore --cidfile=%t/%n.ctr-id
Type=notify
NotifyAccess=all
[Install]
WantedBy=default.targetcontenedor-contenedor-b.servicio
[Unit]
Description=Podman container-container-b.service
Documentation=man:podman-generate-systemd(1)
Wants=network-online.target
After=network-online.target
RequiresMountsFor=%t/containers
BindsTo=pod-my-pod.service
After=pod-my-pod.service
[Service]
Environment=PODMAN_SYSTEMD_UNIT=%n
Restart=on-failure
TimeoutStopSec=70
ExecStartPre=/bin/rm -f %t/%n.ctr-id
ExecStart=/usr/bin/podman run --cidfile=%t/%n.ctr-id --cgroups=no-conmon --rm --pod-id-file %t/pod-my-pod.pod-id --sdnotify=conmon -d --replace --name=container-b -t centos top
ExecStop=/usr/bin/podman stop --ignore --cidfile=%t/%n.ctr-id
ExecStopPost=/usr/bin/podman rm -f --ignore --cidfile=%t/%n.ctr-id
Type=notify
NotifyAccess=all
[Install]
WantedBy=default.target
