Perché posizionare Composer in un contenitore mobile separato?

1

Nota: questa domanda non è strettamente orientata a PHP, dal momento che sia Docker che Composer possono essere facilmente utilizzati al di fuori dell'ecosistema PHP (sebbene tali casi siano piuttosto IMO piuttosto rari).

In uno dei progetti per cui lavoro, l'ambiente di produzione è impostato in modo da utilizzare un'immagine solo con Composer (cioè link ) per ottenere tutte le dipendenze e successivamente le copia in un contenitore PHP / FPM (un cosiddetto build multistadio ). Non riuscivo a trovare alcun senso nel farlo vs semplicemente apk add in compositore nel contenitore principale, eseguendo composer install nel contenitore principale e quindi rimuovendo Composer da esso durante la compilazione (nota che questo non influisce né sulla dimensione dell'immagine né il conteggio dei livelli, il compositore binario potrebbe essere stato aggiunto al singolo strato RUN di tutte le altre app dell'immagine sorgente PHP / FPM o solo apk add ed successivo durante la compilazione e tutti i file immediati vengono rimossi alla fine).

Le mie attuali riflessioni sulla separazione di Composer sono:

Pro:

  • se Composer interrompe qualcosa, non si propaga fuori dal contenitore

CONS:

  • il processo di compilazione è più lento a causa della necessità di gestire un'immagine e un contenitore aggiuntivi
  • il processo di compilazione diventa più complicato a causa della necessità di gestire il contenitore aggiuntivo e la copia dei file
  • il Composer non viene eseguito sul computer di sviluppo effettivo, quindi tutti i controlli ext- non sono eseguiti e devono essere disabilitati forzatamente durante l'installazione delle dipendenze, impedendo al tempo stesso di verificare la completezza delle estensioni necessarie
  • ha un significato logico da solo - i Docker servono a separare i servizi per renderli più facili da gestire; Il compositore è IMVHO non un servizio, ma parte della stessa pipeline di costruzione.

Mi manca qualcosa?

BTW, questa domanda è non su scenari come link (cioè semplicemente aggiungendo il binario Composer da un'immagine) o link (dove la build multistadio potrebbe essere probabilmente utile per gestire Webpack, Node, JS, CSS ecc.); alcune persone che effettivamente propongono la soluzione con un'immagine separata del Composer ( link ) non forniscono alcun reale razionale sul possibile vantaggio rispetto alla soluzione alternativa, ovvero rimuovere il Composer dopo aver installato le dipendenze.

    
posta vaxquis 23.10.2018 - 14:46
fonte

1 risposta

0

Questa è chiamata build a più stadi . È usato per mantenere al minimo sia la dimensione finale dell'immagine che i numeri di livelli . Ciò si traduce in un minor traffico di rete e un tempo di rotazione più veloce su macchine in cui l'immagine non è ancora stata scaricata.

    
risposta data 24.10.2018 - 00:33
fonte

Leggi altre domande sui tag