Ci sto provando, Ringo. Sto cercando davvero di essere il pastore – Jules Winnfield [Pulp Fiction, 1994]
Per anni c'è stata una guerra della comunità in post, thread e tweet, dove systemd è screditato e criticato, ma è davvero così grave? Non lo so davvero, ma come amministratore di sistema, uno dei miei compiti principali è gestire e monitorare i servizi su ciascuno dei miei server, e negli ultimi anni la maggior parte delle distribuzioni ha implementato questo systemd di serie.
Gli amministratori di sistema si reinventano costantemente e noi siamo sempre alla ricerca e all'apprendimento. Quindi, andiamo a mettere in pratica systemd e sviluppare nuove competenze. Contrariamente al tradizionale init , dove il processo di avvio è sequenziale, systemd utilizza il concetto di avvio di parallelizzazione creando socket per l'avvio di ogni servizio che ne ha bisogno. A sua volta, questo comportamento gli consente di interagire con altri demoni astraendo quei socket e assegnando i loro processi ai gruppi di controllo. I processi vengono quindi tracciati utilizzando questi gruppi di controllo, anziché tramite i relativi ID di processo (PID), il che si traduce in un processo di avvio più semplice e in meno tempo per l'avvio.
In systemd , i servizi sono definiti in file unit con i loro demoni e le direttive di comportamento. Il /etc/systemd/system/ è riservata ai file di unità che crei o personalizzi.
Per creare un servizio, devi crearlo con il modulo:<unit_name>.<service> .
Questo file di unità avvia lo script indicato in ExecStart opzione con il <user> impostato con User . Se lo script non riesce o si interrompe, verrà effettuato un tentativo di riavvio come indicato in Restart opzione. Il StandardOutput e StandardError le opzioni assicurano che l'output standard e di errore dello script venga scritto nel systemd registro.
Nella mia esperienza più recente, come esempio di vita reale, quotidiana, ho avuto un server con un piccolo servizio web in esecuzione all'interno di un container (sì, lo so, ma conosci i clienti). Per ottimizzare e automatizzare il servizio, ho creato un systemd file unit per un contenitore Podman per consentire agli utenti di controllare il ciclo di vita del contenitore tramite systemctl .
Dopo aver copiato il file dell'unità in /etc/systemd/system/myhttpservice.service , ricarica il systemd configurazione del manager con il comando:systemctl daemon-reload . Quindi, puoi gestire il container come un systemd -servizio gestito:
# 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 funzionalità del contenitore non è influenzata quando viene gestito da systemd . Puoi persino utilizzare i comandi Podman per monitorare lo stato del container:
[root@server ~]# podman healthcheck run myhttpservice
healthy
Quindi non preoccuparti. Systemd può aiutarti, fidati. Se vuoi saperne di più:
- Nozioni di base sul sistema RHEL7
- Sistema demistificatore
- cheat sheet di systemd per Red Hat Enterprise Linux 7
- Introduzione a Podman
- Monitoraggio della vitalità e disponibilità dei container con Podman
- Come posso controllare i container Podman tramite systemd?
Spero che queste informazioni ti siano d'aiuto.