Docker è adatto al mio caso d'uso?

La mia azienda ha un sistema che vendiamo che consiste essenzialmente in un "Smartbox" mini-computer che esegue Ubuntu 12.04. Questa casella esegue un'applicazione Django più una serie di diversi processi di avvio correlati ad essa. Non molto altro. Abbiamo migliaia di queste scatole sul campo. Gestiamo le dipendenze dei pacchetti, la registrazione dei processi, ecc. Attraverso un pacchetto deb con vari gradi di successo.

Abbiamo bisogno di un modo per inviare in modo efficiente e affidabile aggiornamenti ai nostri utenti sul campo. Abbiamo anche bisogno di qualcosa che, quando si aggiorna il sistema operativo (siamo in ritardo per un aggiornamento di Ubuntu, come si può dire), possiamo sentirci relativamente sicuri sui nostri pacchetti "semplicemente funzionanti".

Non so molto di Docker, ma quando ho sentito parlare per la prima volta del nostro problema (sono un nuovo assunto), Docker è stato il mio primo pensiero. Ma più ci pensavo e forse mi sembrava che non lo fosse, dato che queste scatole sono nostre, controlliamo il sistema operativo su di esso, che è una grande parte della proposta di valore di Docker, o almeno così capisco. Quindi, se SAPPIAMO che le nostre scatole saranno sempre Ubuntu e fondamentalmente abbiamo solo un'app Django più alcuni processi da eseguire, Docker è meglio di un pacchetto deb?

TL; DR: pacchetti Docker vs deb per un'appliance distribuita che eseguirà sempre Ubuntu, quindi l'indipendenza della piattaforma non è così importante.

Non sono sicuro al 100% di aver capito dalla domanda, ma sembra che la soluzione Docker sarebbe quella di passare da un'appliance (fisica?) Con un sistema operativo e la tua app installata su di esso, ad avere un'appliance con un sistema operativo e Docker su di esso, eseguendo un singolo contenitore con l'app in esso. Ciò non elimina la necessità di aggiornare il sistema operativo nell'host e aggiunge un livello di complessità (e più aggiornamenti da affrontare, poiché ora dovrete mantenere Docker e il sistema operativo patchati) senza alcun vantaggio evidente per quanto riguarda le aree specifiche menzionate nell'interrogazione.

Tuttavia, se stai parlando di passare da un'appliance virtuale a un contenitore Docker, ciò potrebbe potenzialmente appianare le cose per te, ma aggiunge anche Docker come dipendenza per il tuo prodotto; stai escludendo chiunque non stia utilizzando Docker e non desideri aggiungerlo al proprio stack solo per utilizzare il tuo prodotto. Potresti continuare a supportare quelli che non usano / non useranno Docker continuando a spedire l'appliance virtuale (ora "legacy") come prima, ma ora hai appena raddoppiato il tuo carico di lavoro perché hai due distribuzioni da supportare invece di uno.

Ho lavorato a lungo con Docker. L'indipendenza della piattaforma è buona, ma non è ciò che ritengo più utile su Docker.

Innanzitutto, si ottiene la ripetibilità. È possibile creare un Dockerfile, eseguire il debug in un contenitore sul computer dello sviluppatore, eseguire test su un server di integrazione continua e quindi nel prodotto finale e si sa che si comporterà lo stesso in tutti quegli ambienti. Senza dimenticare una dipendenza che uno sviluppatore aveva installato sul proprio computer. Inoltre, i tuoi sviluppatori non devono usare Ubuntu alla loro scrivania. Importante per farci felici gli utenti di Arch Linux :-)

In secondo luogo, per il tuo scenario di aggiornamento, puoi avere più versioni trasferite contemporaneamente su una macchina. Se fai un docker pull myapp:2.0po 1.0'di tempo in esecuzione, puoi passare a 2.0estremamente rapidamente. Molto più veloce di un normale aggiornamento del sistema operativo normalmente richiederebbe. Se si utilizza un orchestrator con più istanze di microservizi, è anche possibile eseguire aggiornamenti continui che non interrompono affatto il servizio.

Se si utilizza un modello di microservizi, Docker fornisce anche sandbox che possono limitare la quantità di danno che gli aggressori possono fare in caso di exploit. Invece di ottenere il controllo su un'intera macchina, stanno acquisendo il controllo su un solo contenitore.

L'aspetto negativo è che è necessario il sistema operativo host e una sorta di orchestrazione. Ci sono molte scelte per questo, ma non sottovalutare la quantità di lavoro necessaria per valutarne una, metterla in atto e mantenerla.

In generale, la finestra mobile offre numerosi vantaggi sia per gli sviluppatori che per il personale operativo. Uso la finestra mobile per alcune delle mie applicazioni e trovo che sia un approccio molto affidabile e robusto.

Il mio problema con l'adozione della finestra mobile è che non ti sento fare le domande giuste e potresti potenzialmente rendere la tua vita più complicata senza affrontare i requisiti più importanti.

La prima domanda che dovresti porre (hai detto che eri nuovo) è come vengono gestiti ora gli aggiornamenti del sistema operativo e dell'applicazione? L'attuale metodologia funziona per te (la tua azienda)? Cosa funziona bene? Cosa potrebbe essere migliorato? È possibile eseguire un controllo di configurazione fisica sui computer di destinazione sul campo per verificare che abbiano le patch del sistema operativo corrette, l'applicazione e siano state apportate modifiche non autorizzate.

Adoro la docker, ma non vorrei saltare sul carro della docker senza prima valutare dove ti trovi in ​​questo momento, incluso ciò che funziona bene e ciò che deve essere migliorato.

Mentre c'è una piccola regione sovrapposta Docker e i sistemi di packaging Debian risolvono essenzialmente due problemi molto diversi :

• Il sistema di packaging Debian è costruito per installare software su un host e aggiornarlo il più facilmente possibile. È in grado di gestire complessi schemi di dipendenza e vincoli tra i componenti software, come "il software X versione A richiede il software Y con la versione B o installata più recente" o "il software X non dovrebbe mai essere installato con il software Z versione C".

• Il sistema Docker è concepito per descrivere e distribuire facilmente servizi, in particolare micro-servizi, possibilmente su più host, ad esempio uno sciame Docker o un cluster Kubernetes.

Questi due problemi sono essenzialmente ortogonali, il che significa che, dato il problema di distribuzione da risolvere, è possibile utilizzarne uno, entrambi, o forse nessuno di essi, come parte della soluzione. Quando si usano entrambi, il pacchetto Debian viene usato nella produzione dell'immagine Docker e il Dockerfile (le ricette usate per preparare l'immagine Docker che descrive il "sistema virtualizzato" eseguito in un contenitore) registrerebbe essenzialmente il proprio repository Debian nel fonti del sistema di packaging Debian e installa il tuo pacchetto.

Con questo in mente, mi sembra che quello che stai davvero cercando sia implementare il modello di server immutabile. Il recente sviluppo delle tecnologie cloud ha reso possibile l'aggiornamento del software non utilizzando il classico sistema di aggiornamento software da un sistema di pacchetti software (come il sistema di packaging Debian) ma piuttosto semplicemente sostituendo l'intero server contemporaneamente. (Alcune persone hanno fatto questo prima di questo sviluppo avendo tre OS su un server, due usati in alternanza per eseguire l'appliance e un mini-OS dedicato all'esecuzione della sostituzione dell'appliance. Sebbene non eccessivamente complesso, questo sembra essere sempre rimasto un di nicchia.) Questa tecnica può essere di interesse per te perché se sei abituato ad aggiornare il software sul tuo server usando il gestore pacchetti, lo stato finale del server dipende dalla "cronologia degli aggiornamenti" del server - specialmente se si verificano errori nel processo di aggiornamento. Questa eterogeneità è cattiva,

Abbiamo migliaia di queste scatole sul campo. Gestiamo le dipendenze dei pacchetti, la registrazione dei processi, ecc. Attraverso un pacchetto deb con vari gradi di successo.

potrebbe riguardare questo. Il modello di server immutabile cancella questa fonte di errori essenzialmente distruggendo il concetto di "cronologia degli aggiornamenti" dal problema.

Ora ci sono varie opzioni per implementare il modello di server immutabile, due scelte popolari sono usare immagini Docker, immagini o usare "immagini di istanza master" dal tuo provider cloud (queste sono chiamate AMI in AWS e solo Immagini personalizzate in Google Compute Engine) . Il tuo caso d'uso proibisce l'uso di tecniche basate su cloud, pertanto assumerò le immagini Docker come l'unica scelta ammissibile. (Per motivi di completamento, è certamente possibile utilizzare altri approcci, ad esempio utilizzando Virtual Box o una soluzione di virtualizzazione simile, in alternativa a Docker.)

Quando si utilizza la tecnica del modello di server immutabile, si introduce un nuovo artefatto (l'immagine Docker) che rappresenta il proprio server e questo artefatto può anche essere testato ed è molto facile ottenere un'installazione che replica in modo veritiero le impostazioni di produzione - a parte il carico di servizio.

Ora per considerare il problema concreto che hai descritto, supponiamo che l'implementazione del modello di server immutabile con Docker sia effettivamente ciò che desideri. Dato che il sistema Docker e il sistema di packaging Debian sono complementari anziché reciprocamente esclusivi (cfr. Introduzione), dobbiamo ancora rispondere alla domanda se dovreste preparare un pacchetto Debian per il vostro software.

La pertinenza dell'uso di un pacchetto Debian per installare il software (nell'immagine Docker o su un host) risiede nella complessità del problema di versioning che devi risolvere. Se si eseguono contemporaneamente più versioni del software, a volte è necessario eseguire il downgrade e si hanno requisiti di versione complessi che è necessario documentare attentamente, avere un pacchetto Debian è un must. Altrimenti, questo passaggio può essere ignorato, ma poiché hai già fatto uno sforzo per produrre e distribuire questi pacchetti, non c'è alcun valore reale nel lasciare il tuo lavoro. Vorrei quindi suggerire di continuare a produrre i pacchetti Debian.

Penso che potrebbe essere una buona opzione (sono necessari ulteriori test)

È possibile fornire un URL con tutti i tag / versioni del contenitore creato e i client leggeranno tale URL per vedere se esiste una nuova versione del contenitore.

Puoi archiviare file / impostazioni personali su locale e non perderai mai tali informazioni negli aggiornamenti e ti assicurerai che ciò che hai creato e testato funzionerà per tutti allo stesso modo.

Anche tu potresti dare agli utenti la possibilità di scegliere quale versione tra quelle disponibili vogliono usare (se vuoi dare quella possibilità).

Sarà come "" aggiorna solo un pacchetto "", parlando solo di recuperare una nuova versione del contenitore, molto meglio che gestire i pacchetti debian;)

Docker mi sembra ragionevole, dal momento che è possibile apportare e testare le modifiche al contenitore in casa, quindi, a seconda del processo di rilascio, riavviare i contenitori sempre tirando: ultimo o qualcosa di simile che fornirebbe un aggiornamento testato.

Considerazioni di cui dovresti occuparti includono l'archiviazione dei dati poiché i contenitori non mantengono le modifiche al riavvio, quindi vorrai un volume di dati. Probabilmente ci sono molte più considerazioni che dovresti avere anche una volta scavato. Il sistema con cui sto attualmente lavorando (tutto basato su docker) è in sviluppo da oltre un anno e stiamo ancora trovando aree in cui è necessario apportare modifiche al contenitore, alle configurazioni, ecc.