Desenvolvimento

22 mar, 2018

Bem-vindo ao mundo dos Containers – Do Docker ao Kubernetes

Publicidade

No últimos anos, um dos assuntos que eu mais ouvi falar — em conversas, artigos, podcasts, vídeos, etc — foi Docker. Admito que como desenvolvedor, este assunto sempre ficava em segundo plano no meu pipeline de estudos, talvez por eu achar que era algo mais da parte de infraestrutura, ou simplesmente por ter outro foco em mente.

Enfim, antes tarde do que nunca, eu resolvi começar a estudar e me aprofundar no assunto. Mas veja bem, já se passaram 4 anos desde o lançamento do Docker e realmente o assunto cresceu muito. São muitos conceitos por trás. E quando um leigo no assunto — que é o meu caso — vai procurar sobre, recebe uma enxurrada de diferentes tecnologias, ferramentas e conceitos novos. Com isso, fica a dúvida: Por onde eu começo?

A ideia deste artigo é situar aqueles que, assim como eu, estão iniciando neste assunto e querem um norte ou pelo menos um caminho no estudos.

O passado

“Se queres prever o futuro, estuda o passado.” – Confúcio.

O futuro são os Containers, é o que estão dizendo. Então para entendê-los melhor, vamos seguir o sábio pensamento do Confúcio e dar uma olhada no passado.

Nos anos 2000, a maioria das aplicações rodavam em um servidor físico — sim, este mesmo! Aquele que o estagiário desconectava o cabo sem querer. Mas, além do problema de “chutar o cabo”, quais outros problemas esta abordagem possuía?

Para responder esta pergunta, vamos imaginar a seguinte situação:

Em meados de 2000, a empresa Acme Corp estava com uma ideia de produto novo e desejava desenvolver uma aplicação nova. O pedido chegou ao departamento de TI da empresa. Numa sala de reunião qualquer, estava reunido o pessoal de desenvolvimento de software e o pessoal de infraestrutura. E nesta sala, surgiu a seguinte conversa:

*musiquinha de suspense*

O cara da Infra perguntou: “Então, quão grande este software tem que ser? Quão rápido?”

O programador respondeu: “Hãã, pois é, não sabemos muito bem ainda.”

E realmente, podemos culpar a equipe de desenvolvedores? Os negócios evoluem. É – de fato – difícil prever este tipo de coisa. E neste caso, o pessoal de infraestrutura acabava fazendo a coisa mais sensata: investiam em servidores poderosíssimos. Afinal, a última coisa que eles queriam é que um sistema importante ficasse lento e consequentemente afastasse clientes, né?

Mas no final das contas, na prática, sabe o que acontecia? Os servidores rodavam no seu máximo de 10%, 20% da capacidade total. Gerando um vergonhoso desperdício de dinheiro e recursos da empresa.

Arquitetura com máquinas virtuais

Então, veio o Hypervisor (e as máquinas virtuais) ilustrado na Figura 1. Esta foi uma tecnologia disruptiva com certeza. Com a chegada dela, de uma hora pra outra era possível utilizar aquele mesmo servidor físico — que era subutilizado — e aproveitar muito mais da capacidade dele, tornando possível virtualizar múltiplos servidores em um único servidor físico. Isso significava ter a capacidade de aproveitar aqueles 80% de hardware que antes ficavam sobrando.

Porém, como nem tudo são rosas, a abordagem das máquinas virtuais continuava tendo alguns contratempos. Olhando a Figura 1, é possível visualizar como ficam distribuídas as máquinas virtuais em um servidor físico. Note que cada máquina virtual necessita de um SO para rodar a aplicação, isso significa que continuamos tendo que pagar as licenças para servidores Windows ou versões empresariais de Linux.

Outro ponto importante, é que cada um destes sistemas operacionais utiliza CPU, memória RAM e espaço em disco. Recursos estes que poderiam ser utilizados por nossas aplicações. E tem mais, todas estas VMs necessitam de pessoas responsáveis pela manutenção contínua, por exemplo, atualização do sistemas operacional, aplicação de patches de seguranças, atualização de antivírus, etc.

Então, por mais que o Hypervisor tenha sido disruptivo, existiam os problemas acima citados, e para superá-los surgiram:

Os Containers

Os Containers e as máquinas virtuais possuem benefícios semelhantes quando falamos de isolamento e alocação de recursos, porém, diferente das máquinas virtuais que virtualizam o hardware, os Containers virtualizam a camada da aplicação, o sistema operacional.

Arquitetura com containers

A Figura 2 ilustra um servidor com o conceito de Containers implantado. Para fins comparativos, vamos supor que é o mesmo servidor ilustrado na Figura 1. Alguns pontos importantes de notar:

  1. Percebemos que agora é necessário somente um sistema operacional (logo, só uma licença e menos mão de obra para manutenção).
  2. Junto ao sistema operacional é instalado o software para os Containers.
  3. Utilizando Containers, o servidor suporta mais aplicações. Isso ocorre pois não existe mais o fardo de virtualizar o hardware inteiro. Logo, aqueles recursos que os SOs consumiam, sobram e podem ser direcionados para novas aplicações.

Até o momento evitei falar de Docker, para deixar claro que o conceito de Containers é independente. O Docker é a solução de Containers mais famosa atualmente, porém é importante citar que existem outras opções, como por exemplo o Apache Mesos e Core OS’ rkt.

O Ecossistema

Bom, acho que já conseguimos ter uma ideia de como tudo começou e o que são os Containers. Agora finalmente vamos falar do famoso Docker. A ideia aqui é situar e introduzir algumas das palavras chaves que achamos quando googlamos sobre Docker.

Docker

É uma tecnologia provedora de Containers desenvolvida em Go. Ele funciona provendo uma camada adicional para abstração e automação da virtualização do sistema operacional (Windows, Linux e MacOS). O Docker utiliza algumas funcionalidades do Kernel do SO hospedeiro, como por exemplo o isolamento de recursos e o sistema de arquivos. Tudo isso torna possível aos Containers rodarem independentes em instâncias, evitando a sobrecarga de inicializar e manter uma máquina virtual.

Docker Compose

O Compose é uma ferramenta client side que serve para configurar e rodar múltiplos containers Dockers. Nele a composição dos serviços é configurada em um arquivo YAML. Assim, com um único comando, é possível criar e rodar todos os serviços configurados.

Resumidamente falando, vamos precisar do Docker Compose quando possuirmos uma stack de aplicação com múltiplos componentes dependentes.

Caso de uso 1: Você precisa inicializar a stack da sua aplicação que possui a camada web, a camada de aplicação e a camada de banco de dados.

Docker Swarm

O Docker Swarm é a ferramenta nativa para clusterização e orquestração do Docker. Ele agrupa vários hosts do Docker e expõe como um único host virtual. Ele é compatível com a API padrão do Docker. Logo, qualquer ferramenta que já funciona com o Docker pode utilizar o Swarm. E ao utilizar, ganha a capacidade de expandir de forma transparente para múltiplos hosts.

É interessante citar que o Swarm foi lançado após o Compose, e o “Caso de uso 1” – do Docker Compose – pode ser solucionado também com a funcionalidade de orquestração do Swarm.

Caso de uso 2: Você possui 10 máquinas (virtuais ou físicas). Você precisa utilizar todo este hardware delas para hospedar e iniciar vários Containers.

Kubernetes

O Kubernetes é uma plataforma open-source para automação de deployment, scaling e operações entre cluster de hosts. O Kubernetes possui como bagagem 15 anos de experiências rodando nos servidores de produção do Google.

É interessante notar que atualmente existem outros orquestradores de Containers. Aqui neste artigo falamos dos dois mais famosos atualmente: o Docker Swarm e o Kubernetes. Embora ambos os orquestradores ofereçam grande parte das mesmas funcionalidade um do outro, existem diferenças fundamentais entre o modo que os dois operam. Caso queira entender melhor as diferenças, no final do artigo tem uma lista de links úteis.

Docker Hub

O Docker Hub é um serviço de registro que permite que você crie e teste suas Docker images (vincule a repositórios de código).

Uma Docker image é um template (binários e bibliotecas exigidos) de determinada aplicação. Um Docker Container é a instância de um Docker Image.

As principais funcionalidades do Docker hub, são:

  • Repositório de Docker image: Ache e consuma as images da comunidade e de bibliotecas oficiais.
  • Build automático: A imagem é automaticamente atualizada quando o repositório vinculado sofre mudanças.
  • Organizações: Crie grupos para gerenciar o acesso aos repositórios de imagens privados. Possui integração com GitHub e BitBucket.

Partiu estudar

É isso, pessoal! A ideia é somente um big picture dessa tecnologia que está em constante evolução e é difícil de acompanhar pelo horizonte. O artigo acabou ficando maior que o esperado, mas acredito que vai ajudar a nortear um pouco por onde começar a estudar.