Uso del supervisore nella finestra mobile

Non sto chiedendo l’uso del supervisore con i dockers ma voglio solo che la mia comprensione sia convalidata.

Comprendo che la finestra mobile esegue un singolo processo quando viene eseguito. Inoltre, il supervisore viene utilizzato quando è necessario eseguire più processi all’interno del contenitore.

Ho visto diversi esempi in cui un contenitore viene avviato dall’immagine di base e diversi servizi sono installati e il contenitore è impegnato a formare una nuova immagine, il tutto senza supervisore.

Quindi, il mio dubbio fondamentale era qual è la differenza tra entrambi gli approcci.

La mia comprensione è che quando il container docker viene arrestato invia un segnale kill al processo con PID 1, PID 1 gestisce il processo figlio e interrompe tutto il child che è esattamente ciò che viene fatto dal supervisore, mentre possiamo installare più processi senza supervisore solo uno il processo può essere eseguito quando viene eseguita l’esecuzione della finestra mobile e quando il contenitore viene arrestato, solo il PID 1 verrà inviato segnali e l’altro processo in esecuzione non verrà arrestato correttamente.

Per favore conferma quanto la mia comprensione dell’uso di supervisord sia corretta.

Grazie

mentre è ansible installare più processi senza supervisore, è ansible eseguire un solo processo quando viene eseguita l’esecuzione della finestra mobile e quando il contenitore viene arrestato, solo il PID 1 verrà inviato segnali e l’altro processo in esecuzione non verrà arrestato correttamente.

Sì, anche se dipende da come viene eseguito il processo principale (in primo piano o in background) e da come raccoglie i processi figli.

Questo è quanto descritto in ” Trapping signals in Docker containers ”

docker stop arresta un contenitore in esecuzione inviandolo segnale SIGTERM , lascia che sia il processo principale a elaborarlo e, dopo un periodo di SIGKILL utilizza SIGKILL per terminare l’applicazione.

Il segnale inviato al contenitore viene gestito dal processo principale in esecuzione (PID 1).

Se l’applicazione è in primo piano, ovvero l’applicazione è il processo principale in un contenitore (PID1), può gestire direttamente i segnali.

Ma:

Il processo da segnalare potrebbe essere quello di sfondo e non è ansible inviare direttamente alcun segnale. In questo caso, una soluzione consiste nell’impostare uno script di shell come punto di accesso e orchestrare tutta l’elaborazione del segnale in quello script.

Il problema è ulteriormente descritto in ” Docker and the PID 1 zombie miete problem ”

Unix è progettato in modo tale che i processi parent devono esplicitamente “attendere” la terminazione del processo figlio, al fine di raccogliere il suo stato di uscita. Il processo zombie esiste fino a quando il processo padre ha eseguito questa azione, utilizzando la famiglia waitpid() delle chiamate di sistema.

L’azione di chiamare waitpid () su un processo figlio per eliminare il suo zombi, viene chiamata “mietitura”.

Il processo init – PID 1 – ha un compito speciale. Il suo compito è di “adottare” processi figli orfani.

https://blog.phusion.nl/wp-content/uploads/2015/01/adoption.png

Il sistema operativo si aspetta che anche il processo di init raccolga bambini adottati.

Problema con Docker:

Vediamo che molte persone eseguono solo un processo nel loro contenitore e pensano che quando eseguono questo singolo processo, hanno finito.
Ma molto probabilmente, questo processo non è scritto per comportarsi come un vero processo di init.
Cioè, invece di appropriarsi correttamente dei processi adottati, probabilmente si aspetta un altro processo di init per fare quel lavoro, e giustamente.

L’utilizzo di un’immagine come phusion/baseimage-docker gestire uno o più processi mantenendo un processo principale conforms a init.

Utilizza runit posto di supervisord , per la gestione multi-processo:

Runit non è lì per risolvere il problema dei mietitori . Piuttosto, è per supportare più processi. Sono incoraggiati più processi per la sicurezza (attraverso il processo e l’isolamento dell’utente).
Runit utilizza meno memoria di Supervisord perché Runit è scritto in C e Supervisord in Python.
E in alcuni casi d’uso, il riavvio del processo nel contenitore è preferibile rispetto ai riavvii di interi contenitori.

Quell’immagine include uno script my_init che si occupa del problema del “mietere”.

In baseimage-docker, incoraggiamo l’esecuzione di più processi in un singolo contenitore. Non necessariamente servizi multipli però.
Un servizio logico può essere costituito da più processi del sistema operativo e forniamo le funzionalità per farlo facilmente.

Aggiornamento settembre 2016 per finestra mobile 1.12 (4 ° trimestre 2016 / Q1 2017)

Arnaud Porterie ha appena twittato :

[🐳] Semplicemente uniti: con docker run --init , Rick Grimes si prenderà cura di tutti i tuoi zombi.

( commit eabae09 )

Vedi PR 26061 : ” Aggiungi processo di inizializzazione per combattimento zombi e gestione del segnale ” (e PR 26736 )

Questo aggiunge un piccolo binario C per combattere gli zombi. È montato sotto / dev / init e viene anteposto agli argomenti specificati dall’utente. Lo abiliti tramite un flag daemon, dockerd – init, dato che è disabilitato di default per compat retro.

È inoltre ansible sovrascrivere l’opzione daemon o specificarla in base al contenitore con la docker run --init=true|false .

Puoi testare questo eseguendo un processo come questo come il pid 1 in un contenitore e vedere lo zombi extra che appare nel contenitore mentre è in esecuzione.

 int main(int argc, char ** argv) { pid_t pid = fork(); if (pid == 0) { pid = fork(); if (pid == 0) { exit(0); } sleep(3); exit(0); } printf("got pid %d and exited\n", pid); sleep(20); } 

Il daemon docker ora ha l’opzione

 --init 

Esegui un init all’interno di contenitori per inoltrare i segnali e raccogliere i processi