Docker: onde estamos?
O Docker, em apenas 2 anos de existência, conquistou rapidamente a adoção da comunidade e de gigantes do mercado. Este sucesso fez emergir uma série de ferramentas auxiliares em torno da tecnologia. Temos hoje um variado ecossistema de soluções baseadas em Docker que vão de automatização de testes a soluções de big data. Apesar do sucesso, muitos times enfrentaram problemas no uso em produção já que diversas destas ferramentas facilitadoras ainda estão em versão Beta e com pouca documentação.
O objetivo deste artigo é mostrar um panorama de onde estamos e indicar as ferramentas oficiais do ecossistema Docker estão com um bom grau de maturidade.
Docker no ambiente de desenvolvimento Mac OS e Windows
Um dos maiores problemas em utilizar Docker em ambientes de desenvolvimento Mac OS ou Windows era a necessidade de utilizar o script Boot2Docker e o aplicativo VirtualBox. Isso criava várias camadas de complexidade na configuração de rede entre a máquina host a vm e a distro linux além de problemas de performance.
Em julho deste ano, foram lançadas as versões estáveis das aplicações nativas para Mac e Windows que eliminam o VirtualBox e utilizam as respectivas tecnologias de virtualização xhyve e Hyper-V. Isso facilita as muito tarefas que acabavam se tornando impeditivas para equipes que trabalham em projetos com ambientes de rede mais restritos. Agora é possível, por exemplo, usar as configurações de proxy e VPN da máquina de desenvolvimento.
Trabalhando com multiplos containers em produção
O Swarm é a solução oficial do Docker para gerenciamento e scheduler de containers chegou a versão estável com bom grau de maturidade em na versão 1.12.
Basicamente o que o Swarm faz é transformar um pool de Docker Engines em uma grande engine virtual. Sua arquitetura básica consiste em um host executando Swarm Manager, um host rodando o serviço de service discovery (pode ser o consul ou zookeeper) e os demais hosts executando o Docker Engine em swarm mode.
Uma das principais vantagens do Swarm em relação a outras soluções é a possibilidade de utilizar outros recursos nativos do ecossistema docker como o Docker Compose e o Docker CLI.
A arquitetura do Swarm foi feita de forma bastante flexível permitindo, por exemplo, definir diversas estratégias de alocação nos hosts de acordo com critérios como CPU e memória. Também posso criar políticas de rescheduling para quando os dos containers falha ou finaliza sua tarefa.
O Compose surgiu a partir do projeto fig e foi incorporado à suite de ferramentas em 2015.
Ele permite, de forma declarativa, descrever meu ambiente de containers em um arquivo yaml e ele se encarrega de realizar todas as configurações necessárias de rede, volumes, portas etc
Por exemplo: para subir uma instância do wordpress vou precisar de um container MySQL e outro com o PHP. No modo manual, eu teria que iniciar um container PHP expondo as portas necessárias e em seguida iniciar o container do MySQL configurando um link entre os dois. Com o Compose eu posso simplesmente descrever estar configuração em um arquivo yml da seguinte forma:
Docker na AWS
No último AWS Reinvent a Amazon ampliou o suporte ao Docker com o anúncio de novos produtos: EC2 Container Registry que é o equivalente a um Docker HUB privado e o EC2 Container service CLI. Dada a quantidade de formas de utilização de containers, montamos 3 cenários de possibilidades de acordo com o tamanho da sua aplicação.
O ECS é um serviço de gerenciamento de containers lançado pela amazon em 2015. Os containers rodam em instâncias EC2 em uma VPC e é possivel escalar a quantidade de containers baseado em critérios como CPU e memória. O serviço integra com outros recursos da AWS que você possa estar acostumado como S3, SQS, RDS. O usuário não paga pelo uso do ECSe sim pelos recursos AWS (ec2, ebs) que utilizar.
Apesar dos esforços da AWS, o ECS tem algumas desvantagens como não possuir um service discovery. Você precisa utilizar o ELB obrigatoriamente e dependendo da sua arquitetura pode não te atender. Não suportar um service discovery como o consul por exemplo significa que a única forma de trocar informações com containers é via variaveis de ambiente. Outra desvantagem é que a CLI não possui muitos recursos quando comparada com outras soluções de mercado.
O Beanstalk é um serviço da AWS que gerencia para você o deploy, versionamento e monitoramento de aplicações em diversas plataformas. Desde 2014 além de plataformas como java, ruby, go e node, o Beanstalk passou a suportar containers Docker. Basta especificar um Dockerfile ou uma imagem com uma arquivo json com detalhes do deploy e o beanstalk se encarrega do resto. Se por um lado o serviço facilita bastante o deploy por outro acaba tirando um pouco de flexibilidade nas configurações sendo recomendado para serviços que utilizam um ou poucos containers sem grande flexibilidade.
Este é um panorama geral das ferramentas oficiais do Docker. No próximo artigo vou falar exclusivamente do kubernetes. Uma solução robusta para gerenciamento de containers criado pelo Google.