Dovrei usare Vagrant o Docker per creare un ambiente isolato? [chiuso]

Uso Ubuntu per lo sviluppo e la distribuzione e ho bisogno di creare un ambiente isolato.

Sto prendendo in considerazione Vagrant o Docker per questo scopo. Quali sono i vantaggi e gli svantaggi o come si confrontano queste soluzioni?

Se il tuo scopo è l'isolamento, penso che Docker sia ciò che desideri.

Vagrant è un gestore di macchine virtuali. Consente di eseguire lo script della configurazione della macchina virtuale e del provisioning. Tuttavia, è ancora una macchina virtuale a seconda di VirtualBox (o di altri) con un enorme sovraccarico. È necessario disporre di un file del disco rigido che può essere enorme, richiede un sacco di RAM e le prestazioni potrebbero non essere molto buone.

Docker invece usa il cgroup del kernel e lo spazio dei nomi tramite LXC . Significa che stai usando lo stesso kernel dell'host e lo stesso file system. È possibile utilizzare Dockerfile con il docker buildcomando per gestire il provisioning e la configurazione del proprio contenitore. Hai un esempio su docs.docker.com su come creare il tuo Dockerfile; è molto intuitivo.

L'unico motivo per cui potresti voler usare Vagrant è se devi fare lo sviluppo di BSD, Windows o altri sistemi non Linux sulla tua casella Ubuntu. Altrimenti, scegli Docker.

Disclaimer: ho scritto Vagrant! Ma poiché ho scritto Vagrant, passo la maggior parte del mio tempo vivendo nel mondo DevOps che include software come Docker. Lavoro con molte aziende che usano Vagrant e molti usano Docker, e vedo come i due interagiscono.

Prima di parlare troppo, una risposta diretta: nel tuo scenario specifico (lavorando da solo, lavorando su Linux, usando Docker in produzione), puoi rimanere con Docker da solo e semplificare le cose. In molti altri scenari (discuterò ulteriormente), non è così facile.

Non è corretto confrontare direttamente Vagrant con Docker. In alcuni scenari, si sovrappongono e nella stragrande maggioranza no. In realtà, il confronto più appropriato sarebbe Vagrant rispetto a qualcosa come Boot2Docker (sistema operativo minimo che può eseguire Docker). Vagrant è un livello superiore a Docker in termini di astrazioni, quindi nella maggior parte dei casi non è un confronto equo.

Vagrant lancia cose per eseguire app / servizi a scopo di sviluppo. Questo può essere su VirtualBox, VMware. Può essere remoto come AWS, OpenStack. All'interno di questi, se usi i container, a Vagrant non importa, e lo abbraccia: può ad esempio installare, abbattere, costruire ed eseguire automaticamente container Docker. Con Vagrant 1.6, Vagrant ha ambienti di sviluppo basati su docker e supporta l'utilizzo di Docker con lo stesso flusso di lavoro di Vagrant su Linux, Mac e Windows. Vagrant non cerca di sostituire Docker qui, abbraccia le pratiche Docker.

Docker esegue specificamente i contenitori Docker. Se stai confrontando direttamente con Vagrant: è specificamente una soluzione più specifica (può eseguire solo contenitori Docker), meno flessibile (richiede host Linux o Linux da qualche parte). Naturalmente se stai parlando di produzione o CI, non c'è paragone con Vagrant! Vagrant non vive in questi ambienti, quindi dovrebbe essere usato Docker.

Se la tua organizzazione esegue solo container Docker per tutti i loro progetti e ha solo sviluppatori in esecuzione su Linux, allora okay, Docker potrebbe sicuramente funzionare per te!

Altrimenti, non vedo alcun vantaggio nel tentare di utilizzare Docker da solo, poiché perdi molto di ciò che Vagrant ha da offrire, che offre vantaggi reali in termini di business / produttività:

• Vagrant può avviare macchine VirtualBox, VMware, AWS, OpenStack, ecc. Non importa di cosa hai bisogno, Vagrant può avviarlo. Se stai usando Docker, Vagrant può installare Docker su uno di questi in modo da poterli utilizzare a tale scopo.

• Vagrant è un flusso di lavoro unico per tutti i tuoi progetti. O, per dirla in altro modo, è solo una cosa che le persone devono imparare a eseguire un progetto, che si tratti di un contenitore Docker o meno. Se, ad esempio, in futuro, un concorrente dovesse competere direttamente con Docker, anche Vagrant sarà in grado di gestirlo.

• Vagrant funziona su Windows (indietro su XP), Mac (indietro su 10.5) e Linux (indietro su kernel 2.6). In tutti e tre i casi, il flusso di lavoro è lo stesso. Se si utilizza Docker, Vagrant può avviare una macchina (VM o remota) in grado di eseguire Docker su tutti e tre questi sistemi.

• Vagrant sa come configurare alcune cose avanzate o non banali come il networking e la sincronizzazione delle cartelle. Ad esempio: Vagrant sa come collegare un IP statico a una macchina o a porte dirette e la configurazione è la stessa indipendentemente dal sistema in uso (VirtualBox, VMware, ecc.) Per le cartelle sincronizzate, Vagrant fornisce diversi meccanismi per ottenere il tuo locale file sul computer remoto (cartelle condivise VirtualBox, NFS, rsync, Samba [plugin], ecc.). Se stai usando Docker, anche Docker con una VM senza Vagrant, dovresti farlo manualmente o dovrebbero reinventare Vagrant in questo caso.

• Vagrant 1.6 ha un supporto di prima classe per ambienti di sviluppo basati su docker . Ciò non avvierà una macchina virtuale su Linux e avvierà automaticamente una macchina virtuale su Mac e Windows. Il risultato finale è che lavorare con Docker è uniforme su tutte le piattaforme, mentre Vagrant gestisce ancora i noiosi dettagli di cose come rete, cartelle sincronizzate, ecc.

Per affrontare argomenti contrari specifici che ho sentito a favore dell'utilizzo di Docker invece di Vagrant:

• "Sono meno parti in movimento" - Sì, può essere, se si utilizza Docker esclusivamente per ogni progetto. Anche allora, sta sacrificando la flessibilità per il blocco Docker. Se decidi di non utilizzare Docker per progetti, passati, presenti o futuri, avrai più parti mobili. Se avessi usato Vagrant, hai quella parte mobile che supporta il resto.

• "È più veloce!" - Una volta che hai l'host che può eseguire container Linux, Docker è decisamente più veloce nell'esecuzione di un container di quanto qualsiasi macchina virtuale sarebbe in grado di lanciare. Ma l'avvio di una macchina virtuale (o macchina remota) è un costo una tantum. Nel corso della giornata, la maggior parte degli utenti di Vagrant non distrugge mai la propria VM. È una strana ottimizzazione per ambienti di sviluppo. In produzione, dove Docker brilla davvero, capisco la necessità di girare rapidamente su / giù i container.

Spero ora sia chiaro che è molto difficile, e credo non corretto, confrontare Docker con Vagrant. Per gli ambienti di sviluppo, Vagrant è più astratto, più generale. Docker (e i vari modi in cui puoi farlo comportare come Vagrant) è un caso d'uso specifico di Vagrant, ignorando tutto ciò che Vagrant ha da offrire.

In conclusione: in casi d'uso altamente specifici, Docker è sicuramente un possibile sostituto di Vagrant. Nella maggior parte dei casi, non lo è. Vagrant non ostacola l'utilizzo di Docker; fa davvero il possibile per rendere quell'esperienza più fluida. Se ritieni che ciò non sia vero, sono felice di dare suggerimenti per migliorare le cose, dal momento che un obiettivo di Vagrant è lavorare ugualmente bene con qualsiasi sistema.

Mi auguro questo chiarisca tutto!

Sono l'autore di Docker.

La risposta breve è che se si desidera gestire le macchine, è necessario utilizzare Vagrant. E se vuoi creare ed eseguire ambienti applicativi, dovresti usare Docker.

Vagrant è uno strumento per la gestione di macchine virtuali. Docker è uno strumento per la creazione e la distribuzione di applicazioni confezionandole in contenitori leggeri. Un contenitore può contenere praticamente qualsiasi componente software insieme alle sue dipendenze (eseguibili, librerie, file di configurazione, ecc.) Ed eseguirlo in un ambiente di runtime garantito e ripetibile. Ciò semplifica la creazione dell'app una volta e la distribuisce ovunque: sul laptop per i test, quindi su server diversi per la distribuzione live, ecc.

È un'idea sbagliata comune che è possibile utilizzare Docker solo su Linux. Non è corretto; puoi anche installare Docker su Mac e Windows. Se installato su Mac, Docker raggruppa una piccola VM Linux (25 MB su disco!) Che funge da wrapper per il tuo contenitore. Una volta installato questo è completamente trasparente; puoi usare la riga di comando Docker esattamente nello stesso modo. Questo ti offre il meglio di entrambi i mondi: puoi testare e sviluppare la tua applicazione utilizzando contenitori molto leggeri, facili da testare e facili da spostare (vedi ad esempio https://hub.docker.com per condividere contenitori riutilizzabili con la comunità Docker), e non devi preoccuparti dei dettagli chiacchieroni della gestione delle macchine virtuali, che sono comunque solo un mezzo per raggiungere un fine.

In teoria è possibile usare Vagrant come strato di astrazione per Docker. Lo sconsiglio per due motivi:

• Innanzitutto, Vagrant non è una buona astrazione per Docker. Vagrant è stato progettato per gestire macchine virtuali. Docker è stato progettato per gestire un runtime dell'applicazione. Ciò significa che Docker, in base alla progettazione, può interagire con un'applicazione in modi più ricchi e dispone di maggiori informazioni sul runtime dell'applicazione. Le primitive in Docker sono processi, flussi di log, variabili di ambiente e collegamenti di rete tra i componenti. Le primitive in Vagrant sono macchine, dispositivi a blocchi e chiavi ssh. Vagrant è semplicemente più basso nello stack e l'unico modo in cui può interagire con un container è fingendo che sia solo un altro tipo di macchina, che puoi "avviare" e "accedere". Quindi, certo, puoi digitare "vagrant up" con un plugin Docker e accadrà qualcosa di carino. È un sostituto per l'ampiezza di ciò che Docker può fare? Prova Docker nativo per un paio di giorni e vedi di persona :)

• In secondo luogo, l'argomento lock-in. "Se usi Vagrant come astrazione, non sarai bloccato in Docker!". Dal punto di vista di Vagrant, progettato per gestire le macchine, questo ha perfettamente senso: i contenitori non sono solo un altro tipo di macchina? Proprio come Amazon EC2 e VMware, dobbiamo stare attenti a non legare i nostri strumenti di provisioning a un particolare fornitore! Ciò creerebbe un lock-in - meglio per astrarre tutto con Vagrant. Tranne questo, manca completamente il punto di Docker. Docker non fornisce macchine; avvolge la tua applicazione in un runtime portatile leggero che può essere lasciato cadere ovunque.

Quale runtime scegli per la tua applicazione non ha nulla a che fare con il modo in cui esegui il provisioning dei tuoi computer! Ad esempio, è abbastanza frequente distribuire applicazioni su macchine fornite da qualcun altro (ad esempio un'istanza EC2 distribuita dall'amministratore di sistema, magari usando Vagrant), oppure su macchine bare metal che Vagrant non può affatto eseguire il provisioning. Al contrario, è possibile utilizzare Vagrant per eseguire il provisioning di macchine che non hanno nulla a che fare con lo sviluppo dell'applicazione, ad esempio una scatola IIS di Windows pronta per l'uso o qualcosa del genere. Oppure puoi usare Vagrant per eseguire il provisioning di macchine per progetti che non usano Docker - forse usano una combinazione di rubygems e rvm per la gestione delle dipendenze e il sandboxing, ad esempio.

In sintesi: Vagrant è per la gestione di macchine e Docker per la creazione e l'esecuzione di ambienti applicativi.

Prefazione la mia risposta ammettendo che non ho esperienza con Docker, se non come un avido osservatore di quella che sembra essere una soluzione davvero accurata che sta guadagnando molta trazione.

Ho una discreta esperienza con Vagrant e lo consiglio vivamente. È certamente una soluzione più pesante in quanto basata su VM anziché su LXC. Tuttavia, ho trovato un laptop decente (8 GB di RAM, CPU i5 / i7) non ha problemi a far funzionare una VM usando Vagrant / VirtualBox insieme agli strumenti di sviluppo.

Una delle cose veramente fantastiche di Vagrant è l'integrazione con gli script Puppet / Chef / shell per automatizzare la configurazione. Se stai utilizzando una di queste opzioni per configurare il tuo ambiente di produzione, puoi creare un ambiente di sviluppo il più vicino identico a quello che otterrai e questo è esattamente ciò che desideri.

L'altra cosa grandiosa con Vagrant è che puoi eseguire la versione del tuo Vagrantfile insieme al codice dell'applicazione. Ciò significa che tutti gli altri membri del tuo team possono condividere questo file e hai la certezza che tutti stiano lavorando con la stessa configurazione di ambiente.

È interessante notare che Vagrant e Docker potrebbero effettivamente essere gratuiti. Vagrant può essere esteso per supportare diversi provider di virtualizzazione e potrebbe essere possibile che Docker sia uno di questi provider che riceverà supporto nel prossimo futuro. Vedi https://github.com/dotcloud/docker/issues/404 per una recente discussione sull'argomento.

Sono molto complementari.

Sto usando una combinazione di VirtualBox, Vagrant e Docker per tutti i miei progetti da diversi mesi e ho sentito fortemente i seguenti vantaggi.

In Vagrant puoi eliminare completamente qualsiasi provisioning da solo di Chef e tutto ciò di cui hai bisogno per fare il tuo file vagrant è preparare una macchina che esegua un singolo script shell che installa docker. Ciò significa che i miei file Vagrant per ogni progetto sono quasi identici e molto semplici.

Ecco un tipico Vagrantfile

# -*- mode: ruby -*-
# vi: set ft=ruby :
VAGRANTFILE_API_VERSION = "2"
Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  config.vm.box = "mark2"
  config.vm.box_url = "http://cloud-images.ubuntu.com/vagrant/trusty/current/trusty-server-cloudimg-amd64-vagrant-disk1.box"
  [3000, 5000, 2345, 15672, 5672, 15674, 27017, 28017, 9200, 9300, 11211, 55674, 61614, 55672, 5671, 61613].each do |p|
    config.vm.network :forwarded_port, guest: p, host: p
  end
  config.vm.network :private_network, ip: "192.168.56.20"
  config.vm.synced_folder ".", "/vagrant", :type => "nfs"
  config.vm.provider :virtualbox do |vb|
    vb.customize ["modifyvm", :id, "--memory", "2048"]
    vb.customize ["modifyvm", :id, "--cpus", "2"]
  end
  # Bootstrap to Docker
  config.vm.provision :shell, path: "script/vagrant/bootstrap", :privileged => true
  # Build docker containers
  config.vm.provision :shell, path: "script/vagrant/docker_build", :privileged => true
  # Start containers
  # config.vm.provision :shell, path: "script/vagrant/docker_start", :privileged => true
end

Il file Bootstrap che installa la finestra mobile si presenta così

#!/usr/bin/env bash
echo 'vagrant  ALL= (ALL:ALL) NOPASSWD: ALL' >> /etc/sudoers
apt-get update -y
apt-get install htop -y
apt-get install linux-image-extra-`uname -r` -y
apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 36A1D7869245C8950F966E92D8576A8BA88D21E9
echo deb http://get.docker.io/ubuntu docker main > /etc/apt/sources.list.d/docker.list
apt-get update -y
apt-get install lxc-docker -y
apt-get install curl -y

Ora per ottenere tutti i servizi di cui ho bisogno ho uno script docker_start che assomiglia a questo

#!/bin/bash
cd /vagrant
echo Starting required service containers
export HOST_NAME=192.168.56.20
# Start MongoDB
docker run --name=mongodb --detach=true --publish=27017:27017 --publish=28017:28017 dockerfile/mongodb
read -t5 -n1 -r -p "Waiting for mongodb to start..." key
# Start rabbitmq
docker run --name=rabbitmq --detach=true --publish=5671:5671 --publish=5672:5672 --publish=55672:55672 --publish=15672:15672 --publish=15674:15674 --publish=61613:61613 --env RABBITMQ_USER=guest --env RABBITMQ_PASS=guest rabbitmq
read -t5 -n1 -r -p "Waiting for rabbitmq to start..." key
# Start cache
docker run --name=memcached --detach=true --publish=11211:11211  ehazlett/memcached
read -t5 -n1 -r -p "Waiting for cache to start..." key
# Start elasticsearch
docker run --name=elasticsearch --detach=true --publish=9200:9200 --publish=9300:9300 dockerfile/elasticsearch
read -t5 -n1 -r -p "Waiting for elasticsearch to start..." key
echo "All services started"

In questo esempio sto eseguendo MongoDB, Elastisearch, RabbitMQ e Memcached

Una configurazione da solo Chef non docker sarebbe notevolmente più complicata.

Un grande vantaggio finale si ottiene quando ci si sposta nella produzione, traducendo l'ambiente di sviluppo in un'infrastruttura di host che sono tutti uguali in quanto hanno solo una configurazione sufficiente per eseguire docker significa davvero molto poco lavoro.

Se sei interessato, ho un articolo più dettagliato sull'ambiente di sviluppo sul mio sito web all'indirizzo

Implementazione di un ambiente di sviluppo Vagrant / Docker

Vagrant-lxc è un plugin per Vagrant che ti consente di utilizzare LXC per eseguire il provisioning di Vagrant. Non ha tutte le funzionalità della VM virtuale (VirtualBox) predefinita, ma dovrebbe consentire una maggiore flessibilità rispetto ai container docker. C'è un video nel link che mostra le sue capacità che vale la pena guardare.

Con Vagrant ora puoi avere Docker come fornitore. http://docs.vagrantup.com/v2/docker/ . Il provider Docker può essere utilizzato al posto di VirtualBox o VMware.

Nota che puoi anche utilizzare Docker per il provisioning con Vagrant. Questo è molto diverso dall'uso di Docker come provider. http://docs.vagrantup.com/v2/provisioning/docker.html

Ciò significa che puoi sostituire Chef o Puppet con Docker. Puoi utilizzare combinazioni come Docker come provider (VM) con Chef come provisioner. Oppure puoi usare VirtualBox come provider e Docker come provisioner.

L'uso di entrambi è una parte importante del test di consegna delle applicazioni. Sto solo cominciando a mettermi in gioco con Docker e pensando molto a un team di applicazioni che ha una terribile complessità nella costruzione e nella consegna del suo software. Pensa a un classico progetto Phoenix / consegna continua.

Il pensiero va in questo modo:

• Prendi un componente dell'applicazione Java / Go e crealo come contenitore (nota, non sei sicuro che l'app debba essere compilata nel contenitore o compilata e installata nel contenitore)
• Consegnare il contenitore a una macchina virtuale Vagrant.
• Ripetere l'operazione per tutti i componenti dell'applicazione.
• Scorrere sui componenti su cui codificare.
• Testare continuamente il meccanismo di consegna alle VM gestite da Vagrant
• Dormi bene sapendo quando è il momento di distribuire il container, che i test di integrazione si stavano verificando su una base molto più continua rispetto a prima di Docker.

Questa sembra essere l'estensione logica dell'affermazione di Mitchell secondo cui Vagrant è per lo sviluppo combinato con il pensiero di Farley / Humbles in Continuous Delivery. Se io, come sviluppatore, posso ridurre il ciclo di feedback sui test di integrazione e sulla consegna delle applicazioni, seguiranno ambienti di lavoro di qualità superiore e migliori.

Il fatto che come sviluppatore consegni costantemente e costantemente container alla VM e collauda l'applicazione in modo più olistico significa che le versioni di produzione saranno ulteriormente semplificate.

Quindi vedo Vagrant evolversi come un modo per sfruttare alcune delle fantastiche conseguenze che Docker avrà per la distribuzione delle app.

Sicuramente Docker per la vittoria!

Come forse saprai, Vagrant è per la gestione delle macchine virtuali, mentre Docker è per la gestione dei contenitori di software. Se non si è consapevoli della differenza, ecco: Un contenitore software può condividere la stessa macchina e lo stesso kernel con altri contenitori software. Usando i contenitori risparmi denaro perché non sprechi risorse su più sistemi operativi (kernel), puoi impacchettare più software per server mantenendo un buon grado di isolamento.

Naturalmente è una nuova disciplina prendersi cura dei propri problemi e sfide.

Scegli Docker Swarm se le tue esigenze superano il limite delle risorse della singola macchina.

C'è un articolo davvero informativo sull'attuale rivista Oracle Java sull'uso di Docker in combinazione con Vagrant (e Puppet):

Conclusione

I container leggeri Docker sono più veloci rispetto alle macchine virtuali classiche e sono diventati popolari tra gli sviluppatori e nell'ambito delle iniziative su CD e DevOps. Se il tuo scopo è l'isolamento, Docker è una scelta eccellente. Vagrant è un gestore di macchine virtuali che consente di creare script delle configurazioni delle singole macchine virtuali e di eseguire il provisioning. Tuttavia, si tratta di una VM che dipende da VirtualBox (o da un altro gestore VM) con un sovraccarico relativamente elevato. È necessario disporre di un disco rigido inattivo che può essere enorme, richiede molta RAM e le prestazioni possono essere non ottimali. Docker utilizza i cgroup del kernel e l'isolamento dello spazio dei nomi tramite LXC. Questo significa che stai usando lo stesso kernel dell'host e lo stesso sistema ile. Vagrant è un livello superiore a Docker in termini di astrazione, quindi non sono realmente comparabili. Gli strumenti di gestione della configurazione come Puppet sono ampiamente utilizzati per il provisioning degli ambienti di destinazione. Riutilizzare le soluzioni esistenti basate su Puppet è facile con Docker. Puoi anche suddividere la tua soluzione, in modo che l'infrastruttura sia fornita con Puppet; il middleware, l'applicazione aziendale stessa o entrambi sono forniti con Docker; e Docker è avvolto da Vagrant. Con questa gamma di strumenti, puoi fare ciò che è meglio per il tuo scenario.

Come costruire, utilizzare e orchestrare i contenitori Docker in DevOps http://www.javamagazine.mozaicreader.com/JulyAug2015#&pageSet=34&page=0