Perché si consiglia di eseguire solo un processo in un contenitore?

In molti post di blog e opinione generale, c'è un detto che dice "un processo per contenitore".

Perché esiste questa regola? Perché non eseguire ntp, nginx, uwsgi e altri processi in un unico contenitore che deve avere tutti i processi per funzionare?

post di blog che menzionano questa regola:

• "Il processo singolo per contenitore è un modello di progettazione consigliato per le applicazioni Docker."
• "Docker è solo per la creazione di contenitori a processo singolo o singolo servizio."
• "meglio usare un processo per contenitore"
• "Esegui un singolo servizio come contenitore"
• "Un processo per contenitore"
• "un processo per contenitore"

Dimentichiamo gli argomenti architettonici e filosofici di alto livello per un momento. Mentre ci possono essere alcuni casi limite in cui più funzioni in un singolo contenitore possono avere un senso, ci sono ragioni molto pratiche per cui potresti voler considerare di seguire una "funzione per contenitore" come una regola empirica:

• Il ridimensionamento dei contenitori in orizzontale è molto più semplice se il contenitore è isolato in una singola funzione. Hai bisogno di un altro contenitore Apache? Girane uno altrove. Tuttavia, se il mio contenitore Apache ha anche il mio DB, il cron e altri pezzi dentro, questo complica le cose.
• Avere una singola funzione per container consente di riutilizzare facilmente il container per altri progetti o scopi.
• Inoltre, rende gli sviluppatori più portatili e prevedibili per eliminare un componente dalla produzione per risolvere i problemi localmente piuttosto che un intero ambiente applicativo.
• Patch / upgrade (sia il sistema operativo che l'applicazione) possono essere eseguiti in modo più isolato e controllato. La manipolazione di più bit e bob nel contenitore non solo consente di ottenere immagini più grandi, ma collega anche questi componenti. Perché chiudere l'applicazione X e Y solo per aggiornare Z?
  • Quanto sopra vale anche per distribuzioni di codice e rollback.
• La suddivisione delle funzioni in più contenitori consente una maggiore flessibilità dal punto di vista della sicurezza e dell'isolamento. Potresti voler (o richiedere) che i servizi siano isolati a livello di rete - fisicamente o all'interno di reti overlay - per mantenere una solida posizione di sicurezza o conformarsi a cose come PCI.
• Altri fattori minori come la gestione di stdout / stderr e l'invio di registri nel registro contenitore, mantenendo i contenitori il più effimeri possibile ecc.

Nota che sto dicendo funzione, non processo. Quella lingua è obsoleta. La documentazione ufficiale sulla finestra mobile si è spostata dal dire "un processo" a raccomandare invece "un problema" per container.

Avendo ucciso un contenitore di "due processi" qualche giorno fa, ci sono alcuni punti dolenti per me che mi hanno fatto usare due contenitori invece di uno script Python che ha avviato due processi:

1. Docker è bravo a riconoscere i contenitori danneggiati. Non può farlo quando il processo principale sembra a posto, ma qualche altro processo è morto in modo orribile. Certo, puoi monitorare il tuo processo manualmente, ma perché reimplementarlo?
2. i registri della finestra mobile diventano molto meno utili quando più processi inviano i loro registri alla console. Ancora una volta, puoi scrivere il nome del processo nei log, ma anche la finestra mobile lo può fare.
3. Testare e ragionare su un container diventa molto più difficile.

La raccomandazione deriva dall'obiettivo e dal design della virtualizzazione a livello di sistema operativo

I contenitori sono stati progettati per isolare un processo per altri, dandogli il proprio spazio utente e filesystem.
Questa è la logica evoluzione del chrootfornire un filesystem isolato, il passo successivo è stato isolare i processi dagli altri per evitare sovrascritture di memoria e consentire di utilizzare la stessa risorsa (ad esempio la porta TCP 8080) da più processi senza conflitti.

L'interesse principale in un contenitore è quello di impacchettare la libreria necessaria per il processo senza preoccuparsi dei conflitti di versione. Se esegui processi multipli che richiedono due versioni della stessa libreria nello stesso spazio utente e nello stesso filesystem, avresti dovuto modificare almeno LDPATH per ciascun processo in modo da trovare prima la libreria corretta e alcune librerie non possono essere modificate in questo modo, poiché il loro percorso è hard coded nell'eseguibile al momento della compilazione, vedere questa domanda SO per maggiori dettagli.
A livello di rete dovrai configurare ogni processo per evitare di usare le stesse porte.

L'esecuzione di più processi nello stesso contenitore richiede alcune pesanti modifiche e alla fine della giornata sconfigge lo scopo dell'isolamento, se sei ok per eseguire processi multipli nello stesso spazio utente, condividendo lo stesso filesystem e le stesse risorse di rete, quindi perché non eseguirli sull'host stesso?

Ecco l'elenco non esaustivo delle modifiche / insidie ​​pesanti che mi vengono in mente:

• Gestire i registri

  O essere con un volume montato o interleaved su stdout questo porta un po 'di gestione. Se si utilizza un volume montato, il proprio contenitore dovrebbe avere il proprio "posto" sull'host o due contenitori stessi combatteranno per la stessa risorsa. Quando interleaving su stdout per trarne vantaggio docker logspuò diventare un incubo per l'analisi se le fonti non possono essere identificate facilmente.

• Fai attenzione ai processi di zombi

  Se uno dei tuoi processi si interrompe in un contenitore, supervisord potrebbe non essere in grado di ripulire i bambini in uno stato di zombi e l'iniz host non li erediterà mai. Una volta esaurito il numero di pid disponibili (2 ^ 22, quindi circa 4 milioni), un sacco di cose falliranno.

• Separazione degli interessi

  Se esegui due cose separate, come un server apache e logstash all'interno dello stesso contenitore, ciò potrebbe facilitare la gestione dei log, ma devi chiudere apache per aggiornare il logstash. (In realtà, è necessario utilizzare il driver di registrazione di Docker). Sarà un arresto grazioso in attesa che le sessioni attuali finiscano o no? Se si tratta di un arresto grazioso, potrebbe essere necessario un po 'di tempo e potrebbe richiedere molto tempo per eseguire il lancio della nuova versione. Se esegui un'uccisione, avrai un impatto sugli utenti per un mittente di log e questo dovrebbe essere evitato IMHO.

Infine, quando hai più processi, stai riproducendo un sistema operativo, e in questo caso l'utilizzo di una virtualizzazione hardware sembra più in linea con questa necessità.

Come nella maggior parte dei casi, non è tutto o niente. La guida di "un processo per contenitore" nasce dall'idea che i contenitori dovrebbero servire a uno scopo distinto. Ad esempio, un contenitore non dovrebbe essere sia un'applicazione Web che un server Redis.

Ci sono casi in cui ha senso eseguire più processi in un singolo contenitore, purché entrambi i processi supportino un'unica funzione modulare.

Il processo che chiamerò qui come servizio, 1 contenitore ~ ​​1 servizio , se uno qualsiasi dei miei servizi è fallito, farò girare solo quel rispettivo contenitore e entro pochi secondi tutto sarà di nuovo attivo. Quindi, non ci saranno dipendenze tra i servizi. È consigliabile mantenere dimensioni del contenitore inferiori a 200 MB e max 500 MB (ad eccezione dei contenitori nativi di Windows più di 2 GB), altrimenti sarà simile alla macchina virtuale, non esattamente, ma le prestazioni sono sufficienti. Inoltre, prendi in considerazione alcuni parametri come il ridimensionamento, come posso rendere resilienza dei miei servizi, distribuzione automatica, ecc.

Inoltre, è semplicemente una tua chiamata il modo in cui devi realizzare i tuoi modelli architettonici come il micro-servizio in un ambiente poligot usando la tecnologia dei contenitori che meglio si adatta al tuo ambiente e automatizzerà le cose per te.