Snažím se, Ringo. Usilovně se snažím být pastýřem – Jules Winnfield [Pulp Fiction, 1994]
V příspěvcích, vláknech a tweetech již léta probíhá válka komunity, kde systemd
je zdiskreditován a kritizován, ale je to opravdu tak špatné? Opravdu nevím, ale jako správce systému je jedním z mých hlavních úkolů správa a sledování služeb na každém z mých serverů a v posledních letech většina distribucí implementovala tento systemd
jako standard.
Systémoví správci se neustále znovu objevují a my neustále zkoumáme a učíme se. Pojďme tedy k praktickému použití systemd
a rozvíjet nové dovednosti. Na rozdíl od tradičního init
, kde je proces spouštění sekvenční, systemd
používá koncept paralelizace spouštění vytvořením soketů pro spuštění každé služby, která to potřebuje. Toto chování mu zase umožňuje interagovat s jinými démony tím, že tyto sokety abstrahuje a jejich procesy přiřazuje řídicím skupinám. Procesy jsou pak sledovány pomocí těchto kontrolních skupin, nikoli podle jejich ID procesů (PID), což se promítá do jednoduššího procesu spouštění a kratšího času na spuštění.

V systemd
, služby jsou definovány v souborech jednotek s jejich démony a příkazy k chování. Soubor /etc/systemd/system/
adresář je vyhrazen pro soubory jednotek, které vytváříte nebo přizpůsobujete.
Chcete-li vytvořit službu, musíte ji vytvořit ve tvaru:<unit_name>.<service>
.

Tento soubor jednotky spustí skript uvedený v ExecStart
pomocí možnosti <user>
nastavit pomocí User
. Pokud skript selže nebo se zastaví, bude proveden pokus o restart, jak je uvedeno v Restart
volba. StandardOutput
a StandardError
volby zajišťují, že standardní a chybový výstup skriptu bude zapsán do systemd
log.
Podle mé nejnovější zkušenosti jsem měl jako příklad každodenního života server s malou webovou službou spuštěnou uvnitř kontejneru (ano, já vím, ale znáte zákazníky). Pro optimalizaci a automatizaci služby jsem vytvořil systemd
unit file pro kontejner Podman, který uživatelům umožňuje řídit životní cyklus kontejneru prostřednictvím systemctl
.

Po zkopírování souboru jednotky do /etc/systemd/system/myhttpservice.service
, znovu načtěte systemd
konfiguraci správce pomocí příkazu:systemctl daemon-reload
. Poté můžete kontejner zpracovat jako systemd
-spravovaná služba:
# 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
Funkce kontejneru není při správě pomocí systemd
ovlivněna . Ke sledování stavu kontejneru můžete dokonce použít příkazy Podman:
[root@server ~]# podman healthcheck run myhttpservice
healthy
Takže se nebojte. Systemd vám může pomoci, stačí mu věřit. Pokud se chcete dozvědět více:
- Základy RHEL7 systemd
- Demystifikační systém
- systemd Cheat Sheet pro Red Hat Enterprise Linux 7
- Úvod do Podmana
- Monitorování životnosti a dostupnosti kontejneru pomocí Podman
- Jak mohu ovládat kontejnery podman prostřednictvím systemd?
Doufám, že vám tyto informace pomohou.