Lo estoy intentando, Ringo. Me esfuerzo mucho por ser el pastor:Jules Winnfield [Pulp Fiction, 1994]
Durante años ha habido una guerra comunitaria en publicaciones, hilos y tweets, donde systemd está desacreditado y criticado, pero ¿realmente es tan malo? Realmente no lo sé, pero como administrador de sistemas, una de mis tareas principales es administrar y monitorear los servicios en cada uno de mis servidores, y en los últimos años, la mayoría de las distribuciones han implementado este systemd como estándar.
Los administradores de sistemas nos reinventamos constantemente, y siempre estamos investigando y aprendiendo. Entonces, vamos a poner manos a la obra systemd y desarrollar nuevas habilidades. Al contrario del tradicional init , donde el proceso de arranque es secuencial, systemd utiliza el concepto de arranque de paralelización al crear sockets para el inicio de cada servicio que lo necesita. A su vez, este comportamiento le permite interactuar con otros demonios abstrayendo esos sockets y asignando sus procesos a grupos de control. Luego, los procesos se rastrean utilizando estos grupos de control, en lugar de sus ID de proceso (PID), lo que se traduce en un proceso de inicio más simple y menos tiempo para comenzar.
En systemd , los servicios se definen en archivos unitarios con sus demonios y directivas de comportamiento. El /etc/systemd/system/ El directorio está reservado para los archivos de unidad que creas o personalizas.
Para crear un servicio, debe crearlo con el formulario:<unit_name>.<service> .
Este archivo de unidad inicia el script indicado en el ExecStart opción con el <user> establecer con User . Si el script falla o se detiene, se intentará reiniciar como se indica en el Restart opción. La StandardOutput y StandardError Las opciones aseguran que la salida estándar y de error del script se escribirá en el systemd registro.
En mi experiencia más reciente, como ejemplo del día a día de la vida real, tenía un servidor con un pequeño servicio web ejecutándose dentro de un contenedor (sí, lo sé, pero ya conoces a los clientes). Para optimizar y automatizar el servicio, creé un systemd archivo de unidad para un contenedor Podman que permite a los usuarios controlar el ciclo de vida del contenedor a través de systemctl .
Después de copiar el archivo de la unidad a /etc/systemd/system/myhttpservice.service , recarga el systemd configuración del administrador con el comando:systemctl daemon-reload . Luego, puede manejar el contenedor como un systemd -servicio gestionado:
# systemctl start myhttpservice.service ← to start the container
# systemctl status myhttpservice.service ← to check the container service status
# systemctl start myhttpservice.service ← to stop the container
La funcionalidad del contenedor no se ve afectada cuando es administrado por systemd . Incluso puede usar los comandos de Podman para controlar el estado del contenedor:
[root@server ~]# podman healthcheck run myhttpservice
healthy
Así que no te preocupes. Systemd puede ayudarlo, solo confíe en él. Si quieres saber más:
- Conceptos básicos del sistema RHEL7
- Desmitificando systemd
- Hoja de referencia de systemd para Red Hat Enterprise Linux 7
- Introducción a Podman
- Monitoreo de la vitalidad y disponibilidad de los contenedores con Podman
- ¿Cómo puedo controlar contenedores podman a través de systemd?
Espero que esta información te ayude.