GNU/Linux >> Znalost Linux >  >> Linux

Jak jsem se naučil přestat se bát a milovat systemd

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.


Linux
  1. Jak vytvořit službu Systemd v Linuxu

  2. Jak zabalit službu Systemd?

  3. Jak spustit, zastavit a restartovat službu Zimbra

  1. Spuštění, zastavení a restartování služeb na systémovém serveru RHEL 7 Linux

  2. Jak přesměrovat výstup služby systemd do souboru

  3. Jak zastavit službu systemd

  1. Jak nainstalovat a nakonfigurovat Dovecot

  2. Jak napsat spouštěcí skript pro Systemd?

  3. Jak zastavit a zakázat službu ClamAV z CentOS?