Ho appena iniziato a lavorare con Docker e Kubernetes e ho visto molte pile, in cui alcune persone costruiscono nginx + php in una singola immagine e alcune costruiscono un'immagine con nginx e un'altra con php (montando lo stesso percorso e racchiudendo entrambi i contenitori nella stessa distribuzione in Kubernetes).
Quali sarebbero i vantaggi della costruzione di due immagini docker anziché l'installazione di nginx + php nella stessa?
Risposte:
PHP con nginx viene di solito fatto usando php-fpm che è un processo separato.
Mantenere l'idea di base di una finestra mobile di un processo (vedere la fine della risposta per maggiori dettagli su questo punto) per contenitore ha senso avere il processo nginx e il processo php-fpm in contenitori separati.
Poiché la comunicazione tra nginx e php-fpm avviene attraverso fastcgi, il contenitore php-fpm può anche essere su un host separato e ciò consente di utilizzare un cluster di contenitori php-fpm dietro nginx.
Dopo il wall di commento ecco un po 'più di background, la documentazione docker contiene un paragrafo sull'idea che un container dovrebbe avere solo una preoccupazione .
L'idea principale di un contenitore linux ( lxc ) è quella di eseguire un processo in uno spazio dei nomi isolato a livello di CPU e memoria, Docker aggiunge un isolamento a livello di filesystem.
Il vantaggio è che la compromissione di un processo all'interno di questo spazio dei nomi non permetterà di leggere la memoria di altri processi e come tale dovrebbe impedire altre compromissioni sull'host.
Mentre parlano di nginx e php-fpm, funzionano in coppia ma ognuno ha le proprie preoccupazioni, nginx farà la parte HTTP, il routing, la validazione delle intestazioni, ecc. E php-fpm farà l'interpretazione del codice e restituirà la parte html a nginx . Mentre è normale avere entrambi insieme che servono un'unica applicazione che non è obbligatoria.
A seconda del contesto, potrebbe essere più semplice disporre di un contenitore comprendente l'intero stack per un'applicazione, ad esempio su una workstation di sviluppo. Ma idealmente per l'uso in produzione, cerca di mantenere una minore interazione all'interno del contenitore, avendo separato i processi nello stesso contenitore con supervisord porta la sua parte di problema in termini di processo di zombi e gestione dei registri (esempio qui a solo scopo illustrativo).
Quindi finalmente citerò la pagina della finestra mobile con una certa enfasi:
Mentre "un processo per contenitore" è spesso una buona regola empirica, non è una regola dura e veloce. Usa il tuo miglior giudizio per mantenere i contenitori il più pulito e modulare possibile .
Non esiste una "regola del proiettile d'argento" che si applica a tutto, è sempre un equilibrio tra la complessità all'interno del contenitore e la complessità che orchestra i contenitori stessi.
In realtà, un punto mancante qui è la scalabilità orizzontale. C'è un articolo di Jamie Alquiza molto tempo fa indirizzato a questo:
In breve, ridimensionate il vostro php-fpm in orizzontale per raggiungere prestazioni più elevate. Scalare Nginx + php-fpm insieme non porta alcun vantaggio. Vi incoraggio a fare alcuni test di stress (ad esempio Tsung, Gatling, ecc .; per favore non fare Apache ab, che è un giocattolo molto vecchio) per verificare ciò che l'articolo ha dichiarato. Personalmente ho diverse esperienze nel mondo reale che hanno dimostrato che l'articolo è vero in generale.
Ma ci sono due svantaggi (forse non per Kubernetes) per le macchine / macchine virtuali bare metal:
EDITED: ora è quasi la metà dell'anno 2019. Il vecchio modello, php-fpm + nginx nello stesso pod, ha un uso diverso. Se hai familiarità con la mesh del servizio, allora nginx (o quella che viene chiamata Nginmesh) funge da sidecar per gestire il traffico diretto da est a ovest. Il traffico diretto da est-ovest veniva utilizzato principalmente per l'autenticazione tra servizi o altre funzionalità fantasiose, mentre php-fpm puro non poteva farlo.
Non vi è alcun vantaggio significativo che superi la necessità di gestire due container. Finché hai una relazione 1: 1 tra i processi e servono a un unico scopo, inseriscili nello stesso contenitore.