Ich versuche es, Ringo. Ich versuche wirklich, der Hirte zu sein – Jules Winnfield [Pulp Fiction, 1994]
Seit Jahren gibt es einen Gemeinschaftskrieg in Posts, Threads und Tweets, in denen systemd wird diskreditiert und kritisiert, aber ist es wirklich so schlimm? Ich weiß es nicht genau, aber als Systemadministrator ist es eine meiner Hauptaufgaben, die Dienste auf jedem meiner Server zu verwalten und zu überwachen, und in den letzten Jahren haben die meisten Distributionen dieses systemd implementiert standardmäßig.
Systemadministratoren erfinden uns ständig neu, und wir forschen und lernen ständig. Also, lassen Sie uns loslegen, um systemd zum Anfassen zu verwenden und neue Fähigkeiten entwickeln. Im Gegensatz zum traditionellen init , wobei der Startvorgang sequentiell ist, systemd verwendet das Boot-Konzept der Parallelisierung, indem es Sockets für den Start jedes Dienstes erstellt, der es benötigt. Dieses Verhalten ermöglicht es ihm wiederum, mit anderen Daemons zu interagieren, indem er diese Sockets abstrahiert und ihre Prozesse Steuergruppen zuweist. Die Prozesse werden dann anhand dieser Kontrollgruppen statt anhand ihrer Prozess-IDs (PIDs) verfolgt, was zu einem einfacheren Startvorgang und weniger Zeit zum Starten führt.
In systemd , Dienste sind in Unit-Dateien definiert mit ihren Daemons und Verhaltensdirektiven. Die Datei /etc/systemd/system/ Verzeichnis ist für Unit-Dateien reserviert, die Sie erstellen oder anpassen.
Um einen Dienst zu erstellen, müssen Sie ihn in folgendem Format erstellen:<unit_name>.<service> .
Diese Unit-Datei startet das in ExecStart angegebene Skript Option mit <user> mit User gesetzt . Wenn das Skript fehlschlägt oder stoppt, wird versucht, es neu zu starten, wie in Restart angegeben Möglichkeit. Die StandardOutput und StandardError Optionen stellen sicher, dass die Standard- und Fehlerausgabe des Skripts in systemd geschrieben wird log.
In meiner jüngsten Erfahrung hatte ich als Beispiel für den Alltag einen Server mit einem kleinen Webdienst, der in einem Container lief (ja, ich weiß, aber Sie kennen die Kunden). Um den Dienst zu optimieren und zu automatisieren, habe ich ein systemd erstellt Unit-Datei für einen Podman-Container, um es Benutzern zu ermöglichen, den Lebenszyklus des Containers über systemctl zu steuern .
Nach dem Kopieren der Unit-Datei nach /etc/systemd/system/myhttpservice.service , laden Sie systemd neu Manager-Konfiguration mit dem Befehl:systemctl daemon-reload . Anschließend können Sie den Container als systemd behandeln -verwalteter Dienst:
# 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
Die Funktionalität des Containers wird nicht beeinträchtigt, wenn er von systemd verwaltet wird . Sie können sogar Podman-Befehle verwenden, um den Zustand des Containers zu überwachen:
[root@server ~]# podman healthcheck run myhttpservice
healthy
Also keine Sorge. Systemd kann Ihnen helfen, vertrauen Sie ihm einfach. Wenn Sie mehr wissen möchten:
- RHEL7 systemd-Grundlagen
- Entmystifizierung des Systems
- systemd-Spickzettel für Red Hat Enterprise Linux 7
- Einführung in Podman
- Überwachung der Vitalität und Verfügbarkeit von Containern mit Podman
- Wie kann ich Podman-Container über Systemd steuern?
Ich hoffe, diese Informationen helfen Ihnen.