Ci sono degli svantaggi nell'uso di un pacchetto deb come se fosse un contenitore per distribuire un'applicazione?

Il mio team sta attualmente cercando di decidere se distribuire la nostra app Nodejs come pacchetto deb invece di provare a eseguirla in un contenitore come Docker.

Ho avuto questa idea leggendo questo blog qui che fornisce alcuni buoni argomenti per l'utilizzo di un pacchetto deb per un'applicazione python preesistente. Il punto principale di questo blog che ci attira è il problema del mantenimento dell'ecosistema Docker (condivisione delle porte, autorizzazioni, hosting di immagini Docker, ecc.)

Sembra che "dep-package come i contenitori originali" abbia molto senso per i piccoli servizi in cui non vi è alcun problema di conflitti portuali e dove tutte le dipendenze sono mantenute all'interno di un ambiente virtuale.

Il mio istinto però mi sta dicendo che se i pacchetti deb fossero adatti, sarebbe più comune e la finestra mobile verrebbe pubblicizzata come una soluzione più specifica per la lingua. Ci sono degli svantaggi nell'usare qualcosa come pacchetti deb per distribuire i nostri servizi, invece di usare un sistema completo come docker?

Innanzitutto, mentre Docker viene talvolta visto e utilizzato come sistema di packaging ad hoc , risolve in realtà un problema completamente diverso: Docker riguarda l' esecuzione di programmi. Il sistema Docker consente di descrivere servizi che possono essere ridimensionati a piacimento e di controllare sciami di container. I pacchetti Debian sono per l'installazione di programmi e sono in grado di gestire le dipendenze tra le versioni del software. docker certamente non si qualificano come un sistema di packaging di discesa: ogni “pacchetto” può avere solo una dipendenza, il sistema non ha un'opzione “build ricorsiva” e non supporta vincoli di versione complessi!

Una possibile risposta sarebbe che, se si è disposti a scrivere un pacchetto Debian per la propria applicazione, è anche possibile utilizzare Docker per distribuire l'applicazione. Questo può essere ottenuto con uno script di configurazione apt_setup.shche dovrebbe apparire

apt-key add - <<EOF
-----BEGIN PGP PUBLIC KEY BLOCK-----
<YOUR RELEASE OFFICER PGP KEY GOES HERE>
EOF

cat >> /etc/apt/sources.list <<EOF
deb https://my.organisation.org/repo debian-jessie main
apt-get update -y
apt-get upgrade -y
EOF

e a Dockerfilelungo le linee di

ADD apt_setup.sh /root
RUN sh -ex /root/apt_setup.sh && rm /root/apt_setup.sh
RUN apt-get install -y my-node-js-package

(Nella tua situazione specifica, apt_setup.shsarebbe più complicato, aggiungendo i repository di nodesource e alcuni pacchetti di supporto come apt-transport-https .)

È quindi davvero possibile usare i pacchetti Debian e Docker contemporaneamente, tuttavia ...

Il mio istinto […] mi sta dicendo che se i pacchetti deb fossero adatti, sarebbe più comune

Questo è un intoppo corretto che ci porta a chiederci perché Docker si è rivelato popolare come sistema di confezionamento ad hoc , mentre non è destinato a esserlo. (Vedi sopra.)

Il sistema di packaging "ufficiale" di una determinata distribuzione è solo una possibilità tra molti altri di installare software in un ambiente informatico. Ci sono molte altre fonti disponibili, come i gestori di pacchetti specifici della comunità come npm o opam, alberi port come pkgsrc e distribuzione semplice del codice sorgente. Da questo punto di vista, è facile comprendere il successo di Docker come sistema di packaging ad hoc :

• Le specifiche Docker sono molto simili a uno script della shell e qualunque sia la fonte da cui provengono, installiamo il software usando la shell.

• Docker ha un servizio "incorporato" (a pagamento) per l'hosting di manufatti che produce, l' hub Docker .

Ora quali sono i punti di forza dei pacchetti Debian sulle immagini Docker come sistema di pacchetti? Lo stretto controllo sulle dipendenze durante l'installazione. (Esiste anche la possibilità di eseguire l'upgrade e il downgrade ma non ha alcuna importanza pratica se stiamo implementando il modello di server immutabili .) Questo porta al

Conclusione

Se si dispone di un solo prodotto distribuito in un'unica versione (che è tipica di SaaS), le esigenze di gestione della versione sono molto semplici e l'utilizzo di Docker come gestore di pacchetti ad hoc non dovrebbe presentare gravi inconvenienti. Non appena lavori con diverse versioni di un singolo prodotto o più prodotti, la complessità del problema dei vincoli di versione che devi risolvere aumenta e hai bisogno di uno strumento appropriato per questo, che potrebbe essere pacchetti Debian o qualche sistema di gestione della configurazione se lo sei miscelazione di software di origini diverse.

Sì, ci sono degli svantaggi.

Con un pacchetto .deb non sarai in grado di avere due versioni della stessa applicazione sullo stesso host. Dovrai fare affidamento sui pacchetti di distribuzione disponibili, ad esempio se la tua app si basa su nodejs, rimarrai bloccato con la versione di distribuzione o dovrai installarne uno tuo.

Ora, quando vuoi ospitare applicazioni multiple sullo stesso host, colpirai un muro molto rapidamente quando dipendono dalla stessa cosa (teniamo qui i nodejs) in due versioni diverse.

L'obiettivo principale della finestra mobile è isolare ogni applicazione dal sistema di hosting e altre applicazioni sullo stesso host. ci sono due motivi per fare questo isolamento: 1. per evitare la compromissione dell'app per essere in grado di assumere l'host o influire su un'altra applicazione 2. per dare all'applicazione le sue esatte dipendenze e impedire che venga influenzato da un aggiornamento del sistema o da un'altra applicazione dipendenza.

Un pacchetto Debian (o RedHat) per installare applicazioni è stata una buona pratica se eseguita correttamente. I pacchetti vengono utilizzati allo scopo di distribuire applicazioni che vengono modificate di rado. I pacchetti Debian comportano alcuni overhead, come la gestione delle versioni, la gestione delle dipendenze, gli script pre e post installazione, ecc ...

In molti casi l'aggiornamento da una versione precedente a una nuova versione richiede l'attenta scrittura di script, l'attenzione ai dettagli nella versione, ecc. Perché la modifica dello stato esistente è difficile. Sarebbe molto più semplice sostituire lo stato attuale del tutto con un nuovo stato, senza mutare nulla.

Una volta deciso di sostituire completamente la configurazione o le dipendenze o l'applicazione su ogni distribuzione perché è più facile e meno soggetto a errori. La maggior parte delle organizzazioni (era solita) passare a una nuova VM o istanza cloud. Ciò significa che l'installazione del pacchetto verrebbe eseguita su un server "pulito" e che la modifica dei file e della configurazione sul server non sarà più un problema.

Gli sviluppatori che hanno creato pacchetti e non hanno capito l'errore e la complessità delle mutazioni hanno avuto molte difficoltà.

La sostituzione di macchine virtuali non è ottimale quando tutto ciò che serve è sostituire un'applicazione, motivo per cui sono stati introdotti contenitori leggeri come risposta. Utilizzando Docker (o altri LWC) è possibile sostituire la base utenti, comprese tutte le dipendenze, senza sostituire il server stesso. È inoltre possibile ospitare più versioni della stessa applicazione, con dipendenze diverse, sullo stesso server e passare all'aggiornamento solo il traffico di rete in entrata. Oltre a riportare il traffico di rete al rollback (blu-verde), qualcosa di estremamente difficile nel caso della gestione delle distribuzioni tramite pacchetti.

I contenitori introducono un modo per raggruppare tutto il codice dell'applicazione, le dipendenze e la configurazione in un'immagine. Questa immagine ha più proprietà che la rendono molto migliore rispetto ai tradizionali pacchetti del sistema operativo. Ad esempio, ha tag che consentono il controllo delle versioni, ma ha anche livelli che consentono di risparmiare spazio. Permette un modo semplice per spedire queste immagini ai server e agli ambienti di sviluppo, usando un registro. E queste immagini possono essere eseguite come contenitori in qualsiasi ambiente e server, quasi in modo identico. Ciò include il laptop dello sviluppatore e l'ambiente di produzione. Ancora una volta, qualcosa che era molto più difficile da fare con le macchine virtuali e / o con le versioni del software basate su pacchetti. Avere la stessa immagine testata sul laptop dello sviluppatore e rimanere gli stessi bit e byte in produzione rimuove molto "

Parlando in particolare del pezzo di imballaggio delle immagini di Docker, non del tempo di esecuzione del contenitore, ci sono alcuni bit minori. Il più grande è che un'immagine Docker è più simile a un chroot, il che significa che ti viene impedito di dipendere accidentalmente dallo stato del sistema condiviso poiché ogni file in uso deve essere esplicitamente incluso nell'immagine mentre un pacchetto di sistema potrebbe raccogliere collegamenti dinamici che non hai aspettarsi o altrimenti intrecciarsi con altri pacchetti. Questo può dare origine a dipendenze C complesse che vengono caricate a tua insaputa, ad esempio OpenSSL. Inoltre, l'utilizzo dei pacchetti deb non de-duplica i bit condivisi, ad esempio il sistema di archiviazione di Docker. Per alcuni potrebbe essere una buona cosa, migliori prestazioni di I / O e meno pezzi in movimento, ma per altri potrebbe essere un problema.