Antes de começar a nossa série de posts relacionados a containers, gostaria de perguntar: você ouviu o podcast produzido especialmente sobre este assunto? Não?
Ok, te desculpo e está aqui o link, ouve lá porque está muito bacana.
A analogia
Nos últimos séculos, o que possibilitou o ser humano realizar grandes quantidades de trocas e fazer comércio em larga escala foi o transporte marítimo e, por incrível que pareça, é utilizando essa forma de “tecnologia” que conseguimos explicar melhor o conceito de containers. Acredito que você já deve ter visto, pelo menos em imagens, algo parecido com isto, certo?
Pois bem, este é um navio cargueiro, que transporta minérios brasileiros para os quatro cantos do mundo. Ele foi desenhado, projetado e construído para atender uma única demanda: Levar minério mundo afora. Agora você imagina a dificuldade que se teria caso quiséssemos transportar soja em vez de minério, quantas adaptações teriam que ser realizadas, etc. Agora imaginem se quiséssemos transportar tanto soja quanto minério no mesmo cargueiro. Vai dizer, coisa para louco não?
Pois então, imagine que este navio cargueiro ai é o nosso famigerado host (seja físico ou virtual), onde temos que instalar nossa stack toda, servidor web, framework A, linguagem B, banco de dados C e por aí vai. A cada novo update em alguma ferramenta instalada neste host, é uma tarefa de tirar o sono de toda a equipe de ops.
Levanta a mão aí quem já passou a noite fazendo aquele update maroto que quebrou tudo.
Ambos os processos de atualização, do cargueiro e do host, são atividades que até bem pouco tempo atrás eram comuns, pois havia essa necessidade, e até então aplicava-se a melhor solução possível, ou a menos dolorida obviamente.
OK, sabemos que isso não escala ou, pior, escala de forma difícil e descontrolada. Então, como resolvemos?
Compare a imagem do cargueiro acima, com essa agora:
Bonitão esse navio né?
Pois então, este também é um navio cargueiro, mas neste caso, cargueiro de qualquer coisa, pode-se transportar minérios, soja, roupas, eletrônicos, etc., sem a preocupação deste transporte atender ou não a demanda. Acho que você já deve ter entendido onde quero chegar, não?
Da mesma forma que os containers possibilitam que este cargueiro transporte qualquer coisa, os containers do Linux permitem que você encapsule a sua aplicação e a execute em qualquer lugar. E o mais legal é que você não precisa se preocupar com a compatibilidade no seu host, pois tudo que você precisa para atender o seu serviço ou aplicação estará dentro do container, igualzinho aos containers desse navio, que foram construídos cada um para atender a demanda daquele container apenas.
Isso, obviamente, resolve o problema que tínhamos no exemplo anterior, em que um update poderia quebrar a aplicação.
Agora a única forma de quebrar sua aplicação é você construir o seu container de forma errada, veja que agora o poder não está mais na mão dos Ops,
pois quem define dependências e o que precisa ser instalado são os próprios Devs.
A única coisa que o até então Ops precisa fazer, é garantir que o host tenha alguma tecnologia que permita a execução de containers, da mesma forma que os engenheiros que projetaram este navio tiveram que pensar em como deveria ser o navio para transportar containers e não mais um único produto.
A história
Sim, atualmente falamos muito sobre containers, Docker, RKT, LXC, LXD e etc., mas o que não levamos em consideração é que o linux container (ou pelo menos os recursos que permitiram que ele fosse possível) existem há muitos anos. . Alguns deles são tão antigos, que muitas pessoas que estão lendo este post nem era nascidas em seu lançamento. Loucura né? Mas é a mais pura verdade! Em ordem cronológica podemos colocar assim.
Containers a partir de então
Assim como Warden fez, o Docker também usou o LXC em seus estágios iniciais e depois substituiu esse gerenciador de container por sua própria biblioteca, a libcontainer, depois também foi substituída pelo RunC. Mas há dúvidas de que Docker tem se tornado, cada vez mais, muito mais que um simples gerenciador de container. Ele vem, então, oferecendo todo um ecossistema para o gerenciamento de containers e, obviamente, facilitando a adoção desse tipo de tecnologia.
Com o Docker, os desenvolvedores podem criar e executar seus ambientes/aplicações muito mais rapidamente pois como mencionei, ele provê toda uma plataforma, como por exemplo o Docker Hub, de onde os desenvolvedores podem baixar suas imagens e executar containers e, obviamente enviar suas próprias imagens.
Claro, Docker não está sozinho. Em fevereiro de 2016 o CoreOS lançou o RKT com a intenção de se tornar uma alternativa confiável ao Docker, dentre outras soluções que têm o mesmo objetivo.
É VM?
É uma pergunta muito frequente e, de certa forma, difícil de responder. Se for feita uma análise por funcionalidade apenas, ambas as soluções são parecidas. O que muda – e muito – são as tecnologias empregadas em cada uma.
Enquanto na virtualização tradicional nós temos todo o ambiente “emulado” (isso inclui memória, processamento, disco, rede, etc.) e nele temos todo um sistema operacional instalado, com containers nós não temos todo esse overhead, pois o isolamento e controle de recursos de um container é realizado diretamente por chamadas de sistemas, e não por uma camada de virtualização.
SIM você verá agora a imagem mais vista nos últimos anos, mas que é essencial para entender realmente a diferença entre as tecnologias, veja:
Uma das grandes vantagens da tecnologia de containers é o compartilhamento das bibliotecas de sistema entre host e containers. Isso é possível graças a um conceito chamado copy-on-write, que abordaremos mais profundamente em posts futuros. Isso permite que cada container possa ter acesso direto a recursos do host sem a necessidade de emulação de todo um sistema operacional.
Eu sei que você deve estar se fazendo a seguinte pergunta:
Então eu formato todos os meus hosts físicos e abandono máquina virtual?
Não precisa ser tão extremo assim, é incentivado que você utilize containers dentro de máquinas virtuais, principalmente pela facilidade de provisionamento de ambiente.
Ok, legal. Mas o que ganho com isso?
Eita ponto importante!
O mais curioso disso é que a resposta está presente no seu dia-a-dia e tende a ser mais filosófica do que técnica realmente. Por exemplo, o que você ganha tendo o ambiente que tem da forma que é hoje?
Se a resposta for apenas “Me manter ganhando dinheiro”, repense, pois algum ponto você precisará trabalhar. Atualmente, apenas se manter não é mais algo racional. Ou você melhora dia após dia, ou daqui a pouco alguém fará muito melhor o que você faz. E daí? O que acontecerá?
O que a tecnologia de container te proporciona é a melhoria contínua em sua entrega de software ou ambiente, pois torna muito mais simples para você validar uma ideia ou melhorar a aplicação. Outro ponto muito importante é a autonomia e controle dos times no momento do desenvolvimento, pois tudo que o desenvolvedor precisa é criar uma imagem da forma que ele precisar e executar quantas vezes for preciso. Este benefício, no entanto, não se limita apenas ao desenvolvimento.
Imagine você, como o cara de Ops, o quão fácil é para você fazer suas manutenções sem se preocupar se algo vai quebrar a aplicação, ou ainda por cima, ter versionado seu ambiente, podendo fazer rollback de alguma configuração com apenas dois ou três comandos, bacana né?
Isso tudo sem falar nas mais variadas formas de integração, podendo automatizar desde o provisionamento do ambiente, monitoramento, deploy, etc.
Atualmente na Umbler utilizamos containers por dois grandes motivos:
- Entregar soluções para os clientes de forma mais ágil;
- Otimizar recursos, possibilitando um melhor aproveitamento do ambiente.
Isso quer dizer que trabalhamos com containers porque entendemos que esse tipo de tecnologia nos permite entregar mais facilidades para os desenvolvedores de forma mais rápida conseguindo, assim, atender tanto às demandas de nossos clientes finais, quanto otimizar o que temos hoje de infraestrutura, tendo um custo benefício para ambos os lados muito positivo.
Isso quer dizer que paramos por aqui?
Claro que não, nossa primeira iniciativa – que foi o lançamento da plataforma NodeJS + MongoDB – nos permitiu que validássemos nossa ideia e, ainda por cima, agregou muito conhecimento para todos, incluindo nossos usuários. Acredito que a troca foi bacana e proveitosa para todos. Baseado nisso, temos em nosso road map a expansão dessa plataforma para atender outras necessidades, outras linguagens, outras soluções e, claro, agregar mais facilidades para nossos usuários.
O que gostaria de trazer neste post era essa breve introdução, um pouco mais conceitual, mas que se faz necessária para os próximos posts que estão sendo produzidos e que tem uma pegada mais técnica. 😉