Devo usar o Vagrant ou o Docker para criar um ambiente isolado? [fechadas]

Eu uso o Ubuntu para desenvolvimento e implantação e tenho a necessidade de criar um ambiente isolado.

Estou considerando o Vagrant ou o Docker para esse fim. Quais são os prós e os contras, ou como essas soluções se comparam?

Se seu objetivo é o isolamento, acho que Docker é o que você deseja.

O Vagrant é um gerenciador de máquinas virtuais. Ele permite que você script a configuração da máquina virtual, bem como o provisionamento. No entanto, ainda é uma máquina virtual, dependendo do VirtualBox (ou de outros) com uma enorme sobrecarga. Ele exige que você tenha um arquivo do disco rígido que pode ser enorme, que requer muita memória RAM e que o desempenho pode não ser muito bom.

O Docker, por outro lado, usa o kernel cgroup e o namespacing via LXC . Isso significa que você está usando o mesmo kernel que o host e o mesmo sistema de arquivos. Você pode usar o Dockerfile com o docker buildcomando para lidar com o provisionamento e a configuração do seu contêiner. Você tem um exemplo em docs.docker.com sobre como criar seu arquivo Docker; é muito intuitivo.

A única razão pela qual você pode querer usar o Vagrant é se você precisa desenvolver BSD, Windows ou outro desenvolvimento não Linux na sua caixa do Ubuntu. Caso contrário, vá para o Docker.

Disclaimer: Eu escrevi Vagrant! Mas como eu escrevi o Vagrant, passo a maior parte do tempo vivendo no mundo do DevOps, que inclui software como o Docker. Eu trabalho com muitas empresas usando o Vagrant e muitas usam o Docker e vejo como as duas interagem.

Antes de falar demais, uma resposta direta: em seu cenário específico (você trabalhando sozinho, trabalhando no Linux, usando o Docker em produção), você pode ficar com o Docker sozinho e simplificar as coisas. Em muitos outros cenários (discuto mais adiante), não é tão fácil.

Não é correto comparar diretamente o Vagrant ao Docker. Em alguns cenários, eles se sobrepõem e, na grande maioria, não. Na verdade, a comparação mais adequada seria o Vagrant versus algo como o Boot2Docker (SO mínimo que pode executar o Docker). Vagrant é um nível acima do Docker em termos de abstrações, portanto, não é uma comparação justa na maioria dos casos.

O Vagrant lança coisas para executar aplicativos / serviços com o objetivo de desenvolvimento. Isso pode ser no VirtualBox, VMware. Pode ser remoto como AWS, OpenStack. Nessas, se você usar contêineres, o Vagrant não se importa e aceita isso: ele pode instalar, puxar, construir e executar automaticamente contêineres do Docker, por exemplo. Com o Vagrant 1.6, o Vagrant possui ambientes de desenvolvimento baseados no docker e suporta o uso do Docker com o mesmo fluxo de trabalho do Vagrant no Linux, Mac e Windows. O Vagrant não tenta substituir o Docker aqui, abrange as práticas do Docker.

O Docker executa especificamente contêineres do Docker. Se você estiver comparando diretamente com o Vagrant: é especificamente uma solução mais específica (só pode executar contêineres do Docker), menos flexível (requer host Linux ou Linux em algum lugar). Obviamente, se você está falando sobre produção ou IC, não há comparação com o Vagrant! O Vagrant não vive nesses ambientes e, portanto, o Docker deve ser usado.

Se sua organização executar apenas contêineres do Docker para todos os seus projetos e tiver apenas desenvolvedores em execução no Linux, tudo bem, o Docker definitivamente funcionará para você!

Caso contrário, não vejo benefício em tentar usar o Docker sozinho, pois você perde muito do que o Vagrant tem a oferecer, o que traz benefícios reais de negócios / produtividade:

• O Vagrant pode iniciar máquinas VirtualBox, VMware, AWS, OpenStack, etc. Não importa o que você precisa, o Vagrant pode iniciá-lo. Se você estiver usando o Docker, o Vagrant poderá instalar o Docker em qualquer um deles, para que você possa usá-los para esse fim.

• O Vagrant é um fluxo de trabalho único para todos os seus projetos. Ou, dito de outra maneira, é apenas uma coisa que as pessoas precisam aprender a executar um projeto, esteja ele em um contêiner do Docker ou não. Se, por exemplo, no futuro, um concorrente surgir para competir diretamente com o Docker, o Vagrant também poderá executá-lo.

• O Vagrant funciona no Windows (volta ao XP), Mac (volta à 10.5) e Linux (volta ao kernel 2.6). Nos três casos, o fluxo de trabalho é o mesmo. Se você usa o Docker, o Vagrant pode iniciar uma máquina (VM ou remota) que possa executar o Docker nos três sistemas.

• O Vagrant sabe como configurar algumas coisas avançadas ou não triviais, como rede e sincronização de pastas. Por exemplo: O Vagrant sabe como conectar um IP estático a uma máquina ou portas de encaminhamento, e a configuração é a mesma, independentemente do sistema que você usa (VirtualBox, VMware, etc.). Para pastas sincronizadas, o Vagrant fornece vários mecanismos para obter seu local arquivos para a máquina remota (pastas compartilhadas do VirtualBox, NFS, rsync, Samba [plugin], etc.). Se você estiver usando o Docker, mesmo o Docker com uma VM sem o Vagrant, você precisará fazer isso manualmente ou eles terão que reinventar o Vagrant nesse caso.

• O Vagrant 1.6 possui suporte de primeira classe para ambientes de desenvolvimento baseados em docker . Isso não iniciará uma máquina virtual no Linux e iniciará automaticamente uma máquina virtual no Mac e Windows. O resultado final é que o trabalho com o Docker é uniforme em todas as plataformas, enquanto o Vagrant ainda lida com os detalhes tediosos de coisas como redes, pastas sincronizadas etc.

Para abordar contra-argumentos específicos que ouvi a favor do uso do Docker em vez do Vagrant:

• "São menos partes móveis" - Sim, pode ser, se você usar o Docker exclusivamente para cada projeto. Mesmo assim, está sacrificando a flexibilidade do aprisionamento no Docker. Se você decidir não usar o Docker para qualquer projeto, passado, presente ou futuro, terá mais peças móveis. Se você já usou o Vagrant, tem uma parte móvel que suporta o resto.

• "É mais rápido!" - Depois de ter o host que pode executar contêineres Linux, o Docker é definitivamente mais rápido em executar um contêiner do que qualquer máquina virtual seria lançada. Mas iniciar uma máquina virtual (ou máquina remota) é um custo único. Ao longo do dia, a maioria dos usuários do Vagrant nunca destrói sua VM. É uma otimização estranha para ambientes de desenvolvimento. Na produção, onde o Docker realmente brilha, entendo a necessidade de girar rapidamente os contêineres para cima / baixo.

Espero que agora fique claro que é muito difícil, e acredito que não correto, comparar o Docker ao Vagrant. Para ambientes de desenvolvimento, o Vagrant é mais abstrato, mais geral. O Docker (e as várias maneiras pelas quais você pode fazê-lo se comportar como o Vagrant) é um caso de uso específico do Vagrant, ignorando tudo o que o Vagrant tem a oferecer.

Concluindo: em casos de uso altamente específicos, o Docker é certamente um possível substituto para o Vagrant. Na maioria dos casos de uso, não é. O Vagrant não atrapalha o uso do Docker; na verdade, faz o que pode para tornar essa experiência mais suave. Se você acha que isso não é verdade, fico feliz em receber sugestões para melhorar as coisas, pois o objetivo do Vagrant é trabalhar igualmente bem com qualquer sistema.

Espero que isso esclareça as coisas!

Eu sou o autor de Docker.

A resposta curta é que, se você deseja gerenciar máquinas, deve usar o Vagrant. E se você deseja criar e executar ambientes de aplicativos, use o Docker.

O Vagrant é uma ferramenta para gerenciar máquinas virtuais. O Docker é uma ferramenta para criar e implantar aplicativos, empacotando-os em contêineres leves. Um contêiner pode conter praticamente qualquer componente de software junto com suas dependências (executáveis, bibliotecas, arquivos de configuração etc.) e executá-lo em um ambiente de tempo de execução garantido e repetível. Isso facilita muito a criação do seu aplicativo uma vez e a implantação em qualquer lugar - no laptop para teste e em servidores diferentes para implantação ao vivo etc.

É um equívoco comum que você só pode usar o Docker no Linux. Isso está incorreto; você também pode instalar o Docker no Mac e Windows. Quando instalado no Mac, o Docker empacota uma pequena VM do Linux (25 MB no disco!), Que atua como um invólucro para o seu contêiner. Uma vez instalado, isso é completamente transparente; você pode usar a linha de comando do Docker exatamente da mesma maneira. Isso oferece o melhor dos dois mundos: você pode testar e desenvolver seu aplicativo usando contêineres, que são muito leves, fáceis de testar e fáceis de mover (veja, por exemplo, https://hub.docker.com para compartilhar contêineres reutilizáveis ​​com comunidade Docker) e você não precisa se preocupar com os detalhes básicos do gerenciamento de máquinas virtuais, que são apenas um meio para atingir um fim.

Em teoria, é possível usar o Vagrant como uma camada de abstração para o Docker. Eu recomendo isso por dois motivos:

• Primeiro, o Vagrant não é uma boa abstração para o Docker. O Vagrant foi projetado para gerenciar máquinas virtuais. O Docker foi projetado para gerenciar um tempo de execução do aplicativo. Isso significa que o Docker, por design, pode interagir com um aplicativo de maneiras mais sofisticadas e ter mais informações sobre o tempo de execução do aplicativo. As primitivas no Docker são processos, fluxos de logs, variáveis ​​de ambiente e links de rede entre componentes. As primitivas no Vagrant são máquinas, dispositivos de bloco e chaves ssh. O Vagrant simplesmente fica mais baixo na pilha, e a única maneira de interagir com um contêiner é fingir que é apenas mais um tipo de máquina: você pode "inicializar" e "entrar". Então, com certeza, você pode digitar "vagrant up" com um plug-in do Docker e algo bonito acontecerá. É um substituto para toda a amplitude do que o Docker pode fazer? Experimente o Docker nativo por alguns dias e veja você mesmo :)

• Segundo, o argumento de bloqueio. "Se você usar o Vagrant como uma abstração, não será bloqueado no Docker!". Do ponto de vista do Vagrant, projetado para gerenciar máquinas, isso faz todo o sentido: os contêineres não são apenas outro tipo de máquina? Assim como o Amazon EC2 e o VMware, devemos ter cuidado para não vincular nossas ferramentas de provisionamento a nenhum fornecedor em particular! Isso criaria lock-in - melhor abstrair tudo isso com o Vagrant. Exceto que isso erra totalmente o objetivo do Docker. O Docker não provisiona máquinas; envolve seu aplicativo em um tempo de execução portátil leve, que pode ser descartado em qualquer lugar.

O tempo de execução que você escolhe para o seu aplicativo não tem nada a ver com o modo como você provisiona suas máquinas! Por exemplo, é bastante frequente implantar aplicativos em máquinas provisionadas por outra pessoa (por exemplo, uma instância do EC2 implantada pelo administrador do sistema, talvez usando o Vagrant) ou em máquinas bare metal que o Vagrant não pode provisionar. Por outro lado, você pode usar o Vagrant para provisionar máquinas que nada têm a ver com o desenvolvimento de seu aplicativo - por exemplo, uma caixa do Windows IIS pronta para usar ou algo assim. Ou você pode usar o Vagrant para provisionar máquinas para projetos que não usam o Docker - talvez eles usem uma combinação de rubygems e rvm para gerenciamento de dependências e sandbox, por exemplo.

Em resumo: o Vagrant é para gerenciar máquinas e o Docker é para criar e executar ambientes de aplicativos.

Prefácio minha resposta admitindo que não tenho experiência com o Docker, a não ser como um observador ávido do que parece ser uma solução realmente interessante que está ganhando muita força.

Eu tenho uma quantidade razoável de experiência com o Vagrant e posso recomendá-lo. Certamente, é uma solução mais pesada em termos de VM, em vez de LXC. No entanto, descobri que um laptop decente (8 GB de RAM, CPU i5 / i7) não tem problemas ao executar uma VM usando o Vagrant / VirtualBox junto com as ferramentas de desenvolvimento.

Uma das melhores coisas do Vagrant é a integração com os scripts Puppet / Chef / shell para automatizar a configuração. Se você estiver usando uma dessas opções para configurar seu ambiente de produção, poderá criar um ambiente de desenvolvimento o mais próximo possível do idêntico, e é exatamente isso que você deseja.

A outra grande coisa do Vagrant é que você pode fazer a versão do seu arquivo Vagrant junto com o código do aplicativo. Isso significa que todos os outros membros da sua equipe podem compartilhar esse arquivo e você garante que todos estão trabalhando com a mesma configuração de ambiente.

Curiosamente, Vagrant e Docker podem realmente ser complementares. O Vagrant pode ser estendido para oferecer suporte a diferentes provedores de virtualização, e pode ser possível que o Docker seja um desses provedores que obtenha suporte em um futuro próximo. Consulte https://github.com/dotcloud/docker/issues/404 para obter uma discussão recente sobre o tópico.

Eles são muito complementares.

Eu tenho usado uma combinação de VirtualBox, Vagrant e Docker para todos os meus projetos há vários meses e senti os seguintes benefícios.

No Vagrant, você pode eliminar completamente qualquer provisionamento individual do Chef e tudo o que você precisa para fazer o seu arquivo vagrant é preparar uma máquina que executa um único script de shell pequeno que instala o docker. Isso significa que meus arquivos Vagrant para cada projeto são quase idênticos e muito simples.

Aqui está um arquivo Vagrant típico

# -*- 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

O arquivo Bootstrap que instala a janela de encaixe fica assim

#!/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

Agora, para obter todos os serviços necessários, eu tenho um script docker_start que se parece com isso

#!/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"

Neste exemplo, eu estou executando MongoDB, Elastisearch, RabbitMQ e Memcached

Uma configuração individual do Chef sem docker seria consideravelmente mais complicada.

Uma grande vantagem final é obtida quando você está entrando em produção, traduzindo o ambiente de desenvolvimento para uma infraestrutura de hosts que são todos iguais, pois eles só têm configuração suficiente para executar o docker, o que significa muito pouco trabalho.

Se você estiver interessado, tenho um artigo mais detalhado sobre o ambiente de desenvolvimento no meu próprio site em

Implementando um ambiente de desenvolvimento Vagrant / Docker

O Vagrant-lxc é um plugin para o Vagrant que permite usar o LXC para provisionar o Vagrant. Ele não possui todos os recursos da VM vagrant padrão (VirtualBox), mas deve permitir mais flexibilidade do que os contêineres do docker. Há um vídeo no link mostrando seus recursos que vale a pena assistir.

Com o Vagrant agora você pode ter o Docker como provedor. http://docs.vagrantup.com/v2/docker/ . O provedor Docker pode ser usado em vez do VirtualBox ou VMware.

Observe que você também pode usar o Docker para provisionar com o Vagrant. Isso é muito diferente do que usar o Docker como provedor. http://docs.vagrantup.com/v2/provisioning/docker.html

Isso significa que você pode substituir o Chef ou o Puppet pelo Docker. Você pode usar combinações como Docker como provedor (VM) com o Chef como provisionador. Ou você pode usar o VirtualBox como provedor e o Docker como provisionador.

O uso de ambos é uma parte importante do teste de entrega de aplicativos. Estou apenas começando a me envolver com o Docker e pensando muito sobre uma equipe de aplicativos que tem uma complexidade terrível na criação e entrega de seu software. Pense em uma situação clássica do Projeto Phoenix / Entrega Contínua.

O pensamento é mais ou menos assim:

• Pegue um componente de aplicativo Java / Go e construa-o como um contêiner (observe, não tenho certeza se o aplicativo deve ser construído no contêiner ou construído e instalado no contêiner)
• Entregue o contêiner em uma VM Vagrant.
• Repita isso para todos os componentes do aplicativo.
• Iterar nos componentes contra os quais codificar.
• Teste continuamente o mecanismo de entrega nas VMs gerenciadas pelo Vagrant
• Durma bem sabendo que é hora de implantar o contêiner, que os testes de integração estavam ocorrendo de maneira muito mais contínua do que antes do Docker.

Esta parece ser a extensão lógica da afirmação de Mitchell de que o Vagrant é para desenvolvimento combinado com o pensamento de Farley / Humbles em Entrega Contínua. Se eu, como desenvolvedor, conseguir diminuir o ciclo de feedback nos testes de integração e na entrega de aplicativos, seguiremos uma melhor qualidade e melhores ambientes de trabalho.

O fato de que, como desenvolvedor, estou constantemente e consistentemente entregando contêineres à VM e testando o aplicativo de forma mais holística, significa que as liberações de produção serão ainda mais simplificadas.

Então, vejo o Vagrant evoluindo como uma maneira de aproveitar algumas das impressionantes consequências que o Docker terá na implantação de aplicativos.

Definitivamente Docker pela vitória!

Como você deve saber, o Vagrant é para gerenciamento de máquinas virtuais, enquanto o Docker é para gerenciamento de contêineres de software. Se você não estiver ciente da diferença, aqui está: Um contêiner de software pode compartilhar a mesma máquina e kernel com outros contêineres de software. Ao usar contêineres, você economiza dinheiro porque não desperdiça recursos em vários sistemas operacionais (kernels), você pode empacotar mais software por servidor, mantendo um bom grau de isolamento.

É claro que é uma nova disciplina para cuidar de seus próprios pitfals e desafios.

Escolha o Docker Swarm se seus requisitos ultrapassarem o limite de recursos de uma única máquina.

Há um artigo realmente informativo na revista Oracle Java real sobre o uso do Docker em combinação com o Vagrant (e o Puppet):

Conclusão

Os contêineres leves do Docker são mais rápidos em comparação com as VMs clássicas e se tornaram populares entre os desenvolvedores e como parte das iniciativas de CD e DevOps. Se seu objetivo é o isolamento, o Docker é uma excelente opção. O Vagrant é um gerenciador de VM que permite criar configurações de script de VMs individuais, bem como fazer o provisionamento. No entanto, ainda é uma VM dependente do VirtualBox (ou outro gerenciador de VM) com sobrecarga relativamente grande. Ele exige que você tenha um disco rígido ocioso que pode ser enorme, é preciso muita RAM e o desempenho pode ser abaixo do ideal. O Docker usa cgroups de kernel e isolamento de namespace via LXC. Isso significa que você está usando o mesmo kernel que o host e o mesmo sistema de arquivos. Vagrant é um nível acima do Docker em termos de abstração, portanto eles não são realmente comparáveis. Ferramentas de gerenciamento de configuração, como o Puppet, são amplamente usadas para provisionar ambientes de destino. Reutilizar soluções existentes baseadas em Puppet é fácil com o Docker. Você também pode dividir sua solução, para que a infraestrutura seja provisionada com o Puppet; o middleware, o próprio aplicativo de negócios ou ambos são fornecidos com o Docker; e o Docker é envolvido pelo Vagrant. Com essa gama de ferramentas, você pode fazer o melhor para o seu cenário.

Como criar, usar e orquestrar contêineres do Docker no DevOps http://www.javamagazine.mozaicreader.com/JulyAug2015#&pageSet=34&page=0