J'essaie, Ringo. J'essaie vraiment d'être le berger - Jules Winnfield [Pulp Fiction, 1994]
Pendant des années, il y a eu une guerre communautaire dans les messages, les discussions et les tweets, où systemd est discrédité et critiqué, mais est-ce vraiment si mauvais ? Je ne sais pas vraiment, mais en tant qu'administrateur système, l'une de mes tâches principales est de gérer et de surveiller les services sur chacun de mes serveurs, et ces dernières années, la plupart des distributions ont implémenté ce systemd en standard.
Les administrateurs système se réinventent constamment, et nous recherchons et apprenons toujours. Alors, allons-y pour mettre en pratique systemd et développer de nouvelles compétences. Contrairement au traditionnel init , où le processus de démarrage est séquentiel, systemd utilise le concept de démarrage parallélisation en créant des sockets pour le démarrage de chaque service qui en a besoin. À son tour, ce comportement lui permet d'interagir avec d'autres démons en faisant abstraction de ces sockets et en affectant leurs processus à des groupes de contrôle. Les processus sont ensuite suivis à l'aide de ces groupes de contrôle, plutôt que par leurs ID de processus (PID), ce qui se traduit par un processus de démarrage plus simple et moins de temps pour démarrer.
Dans systemd , les services sont définis dans des fichiers unitaires avec leurs démons et leurs directives de comportement. Le /etc/systemd/system/ est réservé aux fichiers d'unité que vous créez ou personnalisez.
Pour créer un service, vous devez le créer avec le formulaire :<unit_name>.<service> .
Ce fichier unité lance le script indiqué dans le ExecStart option avec le <user> défini avec User . Si le script échoue ou s'arrête, une tentative sera faite pour redémarrer comme indiqué dans le Restart option. Le StandardOutput et StandardError les options garantissent que la sortie standard et d'erreur du script sera écrite dans le systemd journal.
Dans mon expérience la plus récente, à titre d'exemple de la vie réelle, au jour le jour, j'avais un serveur avec un petit service Web fonctionnant à l'intérieur d'un conteneur (oui, je sais, mais vous connaissez les clients). Pour optimiser et automatiser le service, j'ai créé un systemd fichier d'unité pour un conteneur Podman permettant aux utilisateurs de contrôler le cycle de vie du conteneur via systemctl .
Après avoir copié le fichier d'unité dans /etc/systemd/system/myhttpservice.service , rechargez le systemd configuration du gestionnaire avec la commande :systemctl daemon-reload . Ensuite, vous pouvez gérer le conteneur en tant que systemd -service géré :
# 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 fonctionnalité du conteneur n'est pas affectée lorsqu'il est géré par systemd . Vous pouvez même utiliser les commandes Podman pour surveiller l'état du conteneur :
[root@server ~]# podman healthcheck run myhttpservice
healthy
Alors ne vous inquiétez pas. Systemd peut vous aider, faites-lui confiance. Si vous voulez en savoir plus :
- Principes de base du système RHEL7
- Démystifier systemd
- Aide-mémoire systemd pour Red Hat Enterprise Linux 7
- Introduction à Podman
- Surveiller la vitalité et la disponibilité des conteneurs avec Podman
- Comment puis-je contrôler les conteneurs podman via systemd ?
J'espère que ces informations vous aideront.