La configurazione iniziale del docker non sconfigge uno degli argomenti chiave della finestra mobile?

Question

La configurazione iniziale del docker non sconfigge uno degli argomenti chiave della finestra mobile?

#1 da (2 voti)
#2 da (2 voti)
#3 da (1 voti)

6

Sono molto entusiasta della finestra mobile , se sei uno sviluppatore di un grande progetto hai sofferto troppo per macchine mani di ambienti e multipiattaforma.

Uno dei punti chiave di vendita di Docker è che tramite lo snapshot / commit dello stato dell'immagine si evita il rischio di creare un ambiente con una versione diversa, eventualmente incompatibile, di una data dipendenza. Lo capisco, fantastico!

Eseguendo le esercitazioni su dockerfile , non è esattamente lo stesso concetto dell'esecuzione di npm , chef o bower . Ovviamente le librerie unix sarebbero più stabili di quelle che si trovano in questi negozi di librerie che ho appena menzionato, ma non è lo stesso flusso di lavoro che la finestra mobile sta combattendo?

L'obiettivo non è quello di adattare un contenitore alle tue esigenze e quindi impegnarlo per moltiplicare a piacimento?

Mi manca qualcosa di banale, o questo è il caso? La finestra mobile ti offre ancora la possibilità di creare immagini dai file di script e con la quale si sposta sulle dita dei piedi?

docker virtualization paas

posta bitoiu 17.11.2013 - 22:40

fonte

3 risposte

Leggi altre domande sui tag docker virtualization paas

design per operazioni interrompibili Implementazioni comuni di Lisp: threading e multipiattaforma?

score 2 · Answer 1

Docker says it's bad to run package managers at different points in time

...

however it goes against that when in their tutorial they build a machine from a set of "apt-gets"

La finestra mobile dice:

... è fantastico avere gestori di pacchetti (come apt / yum / npm / bower)
... sono perfetti per "installa ora le versioni più recenti delle dipendenze"
... la maggior parte di questi gestori di pacchetti non capiscono correttamente "installa lo stesso sul prod ciò che è stato installato su una iterazione di prova 11 giorni fa"
... lo rendono difficile da replicare a prod:
- esattamente gli stessi pacchetti, niente di meno, niente di più
- con esattamente le stesse versioni
- contenente gli stessi byte non elaborati
- insieme a tutti i file a cui l'applicazione ha avuto accesso, ma non gestiti da questo gestore di pacchetti (ma uno diverso o del tutto assente)
- che specifica chiaramente cosa fa cambia tra test e prod
... mentre Docker lo rende facile .

La risposta è per la domanda chiarita dai commenti dell'OP.

score 2 · Answer 2

I contenitori / docker sono molto più semplici per gli sviluppatori che vogliono girare la testa per lo sviluppo locale, ed elimina il requisito dell'intero team di comprendere come utilizzare il sistema di gestione della configurazione di scelta, incollato insieme a Vagrant. I contenitori Docker sono simili alle macchine virtuali, ma ci sono differenze chiave.

Tutte le dipendenze dell'applicazione sono fornite in bundle con il contenitore, il che significa che non è necessario creare immediatamente su tutti i server durante la distribuzione. Ciò si traduce in implementazioni e rollback molto più rapidi. Con gli strumenti di gestione della configurazione, dovrai ripetere gli stessi passaggi per ogni distribuzione. Ciò significa che è più difficile tenere traccia delle versioni e delle dipendenze del software.

Un'altra differenza è che Dockerfile non ti dà lo stesso livello di controllo sulla configurazione come le transizioni delle applicazioni tra ambienti, come dev, staging e produzione. È possibile entrare in una situazione in cui il Dockerfile deve chiamare uno script esterno che modifichi al volo i file di configurazione nell'immagine della finestra mobile. Se desideri maggiori informazioni dai un'occhiata a questo wiki del contenitore.

score 1 · Answer 3

Ho avuto una discussione in una conferenza questa settimana circa la stessa cosa, avendo più o meno la stessa domanda.

Poiché sembra esserci qualche sovrapposizione, una buona pratica, basata sulla mia comprensione, è che con un Dockerfile si otterrà il contenitore in uno stato iniziale da cui sarà quindi possibile utilizzare un framework DevOps (o npm o bower).

Dockerfile potrebbe anche velocizzare le cose, poiché le slice potrebbero ereditare da uno stato iniziale migliore, nel caso in cui ciò sia richiesto. Esempio se hai installato "g ++" all'interno del Dockerfile, ogni istanza che hai generato, non avrà bisogno di scaricarlo, come nel caso di Chef, che gira su una macchina "bare metal".

Infine, penso che dobbiamo considerare dove non c'è sovrapposizione, per cose che possono essere fatte solo all'interno del Dockerfile, come le porte da mappare, ecc. Quindi è necessario almeno per questo. Ad esempio:

FROM ubuntu

Suppongo che non si possa dire a uno strumento DevOps: "rendere questo nodo un'istanza ubuntu".

Sono un po 'nuovo in questo territorio e anche questo territorio è nuovo, quindi la validità di questa risposta potrebbe fluttuare nel tempo.