Carregue seus ambientes no bolso com Vagrant e Docker

Neste último sábado, fiz uma apresentação dobre Vagrant e Docker na trilha de DevOps do TDC Porto Alegre.

Na real, minha parte favorita foi o bate-papo depois da palestra (seja ainda durante as perguntas “oficiais”, ou as posteriores, quando o pessoal se solta pra entrar no detalhe).

Vou tentar listar todas elas aqui, mas se alguém lembrar de alguma, ou só quiser adicionar, é só prender o grito.

1. Legal, mas o quão estável está o Docker?

TL;DR:

O Docker, bastante. O que ainda está em franca expansão é o ecossistema em torno dele.

Detalhes:

• Docker está na versão 1.2, considerada estável;
• Por outro lado, o suporte à ferramenta ainda está em seu estágio inicial:
  • O MesoSphere parece uma das soluções mais evoluídas — baseada em Apache Mesos, com suporte (via API inclusive) a Docker, via integração com Kubernetes;
  • Falando em Mesosphere, tem como brincar com a ferramenta via Vagrant;
  • Falando em Kubernetes, tem grandes chances de se tornar o grande player nesse espaço: — desenvolvido pela Google, com apoio de empresas como IBM, Red Hat e Microsoft (!), o projeto ainda está em beta, mas é algo para se acompanhar…
  • Ainda falando em Kubernetes, ele também tem Vagrant files para se experimentar…
  • Dokku, já estável, é muito legal mas bastante limitado — mas dá para aproveitar a ideia de combinar buidpacks com docker;
  • Flynn, seu sucessor, ainda está em Beta e ainda não gerou nenhuma grande comoção;
  • Deis, também interessante, está na mesma do Flynn;
  • OpenShift agora tem suporte a Docker. Resta ver se como cidadão de primeira ou segunda categoria;
  • OpenStack tem suporte a Docker. Alguém aí tem um case para aplicar o OpenStack?
  • O Hadoop também está entrando na jogada e os planos são de permitir a execução de containers Docker (via Kubernetes) sobre Yarn;
• Uma série de serviços de nuvem vem aparecendo com suporte a Docker:
  • Um dos primeiros adopters, o Orchard (criadores do Fig) foi comprado pela Docker, mas pelo visto para uma hiring acquisition, já que o serviço deve ser descontinuado;
  • A AWS, obviamente, também suporta containers Docker. Se alguém quiser testar e compartilhar a experiência, ótimo 🙂
  • Para quem quer brincar, o Tutum, que está de graça durante seu beta, é uma bela pedida;

2. E eu pago um overhead de performance por usar containers?

TL;DR:

Sim, mas é um overhead menor do que a criação de uma VM.

Detalhes:

Para os que curtem benchmarks, existe uma série deles por aí. Para mim, os mais relevantes são o da própria VMWare (notem que mesmo num post da VMWare containers docker nativos aparecem rodando mais rapidamente) e, principalmente, o da IBM.

Por que a comparação é relevante?

• Por que isso está abrindo caminho para virtualização sobre bare metal, o que pode reduzir custos (menor overhead => mais capacidade disponível => menor preço);
• Também é possível adotar uma solução container-based sobre VMs. A VMWare jura de pé junto que o overhead dos containers sobre VMs é negligenciável (ver benchmark). E trazer containers para a jogada ajuda bastante em DevOps, conforme discutimos;
• E ainda na solução de containers sobre VMs, existe a possibilidade de rodar múltiplos containers sobre a mesma VM, gerando uma maior densidade;

3. Como limito o uso de CPU/Memória?

TL;DR

O docker tem switches para isso.

Detalhes:

Essa é uma novidade que passou batido por mim. Até o início do ano era necessário conversar diretamente com o LXC. Hoje em dia, é só passar um -m ou -c ao executar um docker run.

O Docker em si não controla o uso de memória e CPU e deixa isso a encargo da ferramenta de containerização rodando por baixo dele. Isso quer dizer que para uma introdução completa de containers Windows sob Docker, a MS também precisará implementar esses controles na sua plataforma.

4. Ok, já rodo minha infra numa nuvem pública. Por que olhar o Docker agora?

TL;DR:

Provavelmente não é hora para adotar. Mas vale ficar de olho e aprender.

Detalhes:

• Ainda pode fazer sentido do ponto de vista de deploy e em breve pode ser economicamente interessante;
• Talvez você use um provedor que já oferece suporte a docker. Neste caso, uma rápida investigação de custo é interessante — vai que já esteja de barbada…

Adendo: mas qual é a diferença de provisionar uma VM a partir de uma imagem?

1. Tempo
   • Containers são menores para baixar/transferir
   • Containers bootam mais rápido
   • A estratificação de camadas dos containers aumenta em muito a chance de aproveitamento de cache ao provisionar um container
2. Dinheiro
   • Um container consome menos recursos computacionais que uma VM
   • Isso se reverte em din-din

E no final das contas: é possível e mesmo provável que daqui a alguns anos os containers se tornem o padrão de uso da indústria, com VMs ainda sendo

5. Como o uso de containers impacta no meu uso de rede?

TL;DR:

Em geral, o efeito é negligenciável.

Detalhes:

1. O uso da bridge interna do Docker pode introduzir overhead significativo (ver o exemplo com Redis neste benchmark, algo solucionável com o uso do networking do host (mais uma coisa a ser feita com cautela);
2. O Fernando Ike mencionou que, existe, sim, um lag (rápido) no host com a introdução de um novo container;

6. Containers são realmente isolados? Não posso, por exemplo, gerar efeitos colaterais no file system?

TL;DR:

Por default, containers rodam em “espelhos” isolados do file system, garantindo a não interferência.

Detalhes:

Para mais detalhes sobre esse comportamento esta página da SUSE tem material interessante.

Tendo dito isso:

1. É possível configurar um container para acessar o file system do seu host. Obviamente, algo a ser feito com muito cuidado e só quando estritamente necessário;
2. O isolamento também vale para processos, rede e afins, mas…
3. Como o container lida diretamente com o kernel do host é possível que um container quebre seu sistema hospedeiro, levando todos os outros containers junto com ele;
4. Existe uma série de recomendações da própria Docker para evitar esse risco;

7. Perdi a palestra e ainda não sei qual a diferença entre Docker e Vagrant. Pode me explicar?

TL;DR:

Vagrant é uma ferramenta a ser usada durante o desenvolvimento. Docker, um mecanismo para empacotar aplicações e facilitar sua distribuição e escalada. Uma discussão “Vagrant vs Docker” não faz muito sentido, no final das contas.

Detalhes:

Simplificação grosseira aí em cima (ex: é possível deployar para uma nuvem a partir do Vagrant. A pergunta é “por que eu faria isso?”), mas o use case tradicional do Vagrant é automatizar a criação de VMs com um setup prod-like, rodando na máquina dos desenvolvedores. O resto do ciclo de CI/CD roda da maneira tradicional. É uma ferramenta bastante útil, que pode ser deployada com um mínimo de esforço numa empresa (vocês já automatizam o setup dos servers, né?).

Docker é outra parada, com impactos muito mais profundos. Ele é uma ferramenta de gestão de containers (hoje em dia rodando sobre Linux LXC, mas em breve em um Windows Server perto de você) que “empacota” a aplicação em si, com todo seu runtime. Esses containers rodam diretamente sobre um host, que pode hospedar inúmeros deles sem interferência entre si. Ver respostas acima para entender algumas das ramificações disso.

8. Perdi a palestra e estou tendo muitas dificuldades com Docker. Por onde começo?

TL;DR:

GU Cloud FTW!

Detalhes:

Sério, entra lá. Estamos discutindo a ideia de um meetup/hangout/whatever na semana que vem…

9. Assisti a palestra, fiquei curioso com tua menção a NoOps e acabei não perguntando. Que papo é esse?

TL;DR

Perdeu, preiboi 🙂

Detalhes:

Como a pergunta nunca foi feita, não vou responder ela aqui. Se surgir o interesse, tocamos no assunto, ok?

Advertisement