Ci sono vantaggi vantaggiosi nella creazione di un container docker separato per gestire http?

Ci sono una serie di ragioni:

• Le istanze possono essere ridimensionate in modo diverso. Ad esempio, i database di solito richiedono un minimo di 3 nodi separati fisicamente per la durata, in cui un server web risiede solitamente in memoria e può essere riavviato rapidamente, quindi è possibile mantenerlo solo su un nodo durante i periodi di traffico ridotto e ridimensionarlo fino a più nodi durante il traffico di punta.
• È possibile utilizzare una configurazione più standard. Se si utilizza solo un contenitore nginx, è possibile estrarlo direttamente dall'hub docker e utilizzare la stessa immagine che milioni di altre persone hanno testato, con solo le proprie personalizzazioni specifiche dell'applicazione. Nessun edificio e test dei tuoi Dockerfiles, con tutti i problemi e i rischi concomitanti.
• Riduci la superficie di attacco di ogni vulnerabilità. Se il tuo database ha un exploit, il tuo attaccante non avrà accesso a nulla di privato nel tuo contenitore nginx e viceversa.
• La tua orchestrazione può aiutarti più facilmente a controllare lo stato di salute e a riavviare i singoli componenti. Ad esempio, Kubernetes può essere configurato per verificare periodicamente un 200 OK e riavviare nginx se non lo riceve.
• Hai una separazione più "fisica" tra i componenti, il che rende un po 'più facile rafforzare le interfacce tra di loro, farli sviluppare da diversi team, essere aggiornati su diversi programmi, essere controllati in repository separati e così via.

Naturalmente, c'è un compromesso in quanto hai più parti mobili e ora hai bisogno di una sorta di orchestrazione per coordinare tra loro. Questo sforzo non dovrebbe essere sottovalutato. Tuttavia, oltre una certa complessità, i vantaggi della modularità superano la complessità extra introdotta.

Ecco alcuni vantaggi di eseguire Nginx o Apache al di fuori dell'applicazione:

• Si desidera ospitare diverse applicazioni in esecuzione sulla stessa porta su domini diversi (proxy inverso).
• Si desidera che le risposte agli errori HTTP si verifichino anche se il contenitore dell'applicazione ha esito negativo. Il contenitore Apache o Nginx restituirà 502 se il contenitore dell'applicazione ha esito negativo o non è in esecuzione. Ciò può essere utile durante le ridistribuzioni (se non si è provveduto a ridistribuire senza tempi di fermo). 502 È una risposta molto migliore rispetto a nessuna connessione.
• Separazione delle preoccupazioni. IMO è l'architettura migliore per separare i pezzi in parti che hanno un'unica responsabilità.
• Immagini e finestra mobile più piccole build più veloci. Se non si deve impacchettare il server HTTP in ciascuna immagine di finestra mobile creata, è necessario risparmiare tempo.
• Agnostico al server HTTP. Se non impacchettate il server HTTP con la vostra applicazione, è molto più semplice cambiare quel livello.
• Possibilità di aggiungere livelli tra Apache e la tua applicazione. Se decidi di aggiungere altro software (registrazione, limitazione della velocità, firewall, ecc.) Tra il livello HTTP e la tua applicazione, puoi farlo se i tuoi contenitori sono separati.