Tecnologia de Container: conheça essa nova tendência para a virtualização

em Tendências.

Tendência entre os desenvolvedores, a tecnologia de container é uma nova forma de virtualização que isola serviços em ambientes fechados, os chamados containers.

Esse modelo de abstração de infraestrutura está conquistando espaço no mercado com sua praticidade e economia de recursos, especialmente em times que utilizam uma arquitetura de microsserviços em seus projetos.

Apesar de guardar algumas semelhanças com os servidores virtuais, os containers definitivamente não são a mesma coisa.

O Linux Container surgiu em 2008 como uma alternativa mais robusta e segura ao comando chroot, porém com uma economia de recursos imensa quando comparado ao sistema tradicional de virtualização de servidores.

Com a chegada do Docker em 2013, ele ganhou as massas e começou a se popularizar entre os desenvolvedores, se provando uma solução muito eficiente — ainda que não seja totalmente capaz de substituir a forma tradicional de virtualização de máquinas.

Neste artigo, vamos falar um pouco mais sobre o que é container e quais as vantagens em utilizá-lo.

1. O que é Container?

Cada vez mais populares no meio DevOps, os containers são uma nova forma de abstração de infraestrutura, semelhante à virtualização de máquinas, mas com algumas diferenças cruciais.

Os containers são uma maneira de empacotar aplicações separadamente, com todos os conteúdos necessários para sua execução, em ambientes Linux isolados. Dentro deles, é fácil realizar alterações dos limites de recursos nas instâncias em execução, sem precisar reinicializar nada.

Os containers são especialmente interessante do ponto de vista da arquitetura de microsserviços, um estilo de desenvolvimento em que uma única aplicação é fatorizada em diversos serviços e funções que rodam isoladamente em ambientes virtuais.

A vantagem dessa abordagem está na facilidade de tratar cada funcionalidade separadamente. Em aplicações monolíticas, quando é necessário fazer ajustes ou escalar o serviço, é preciso criar e fazer o deploy de uma nova versão do aplicativo no servidor.

Em uma arquitetura de microsserviços, cada parcela do aplicativo é independente e possui um limite de módulo firme, o que permite que ele seja gerenciado por times distintos e até escrito em linguagens diferentes.

Essa modularidade dos microsserviços se encaixa muito bem com o conceito de containers, que também são chamados de LXC, ou Linux Containers. Como eles isolam os serviços em ambientes específicos, é possível desenvolver cada um separadamente, sem interferências de ou para outras partes da aplicação.

Atualmente, a plataforma mais usada para implantação de containers é o Docker, que possibilita o encapsulamento e a mobilidade de ambientes inteiros entre hosts diferentes. A maior parte das soluções que envolvem LXC utiliza o Docker.

Além dele, outro nome muito ouvido quando se fala em containers é o Kubernetes: criado pelo Google em 2014, o Kubernetes é uma plataforma Open Source para automatização de deploys, escalamento e operação de containers em máquinas físicas e virtuais.

O Kubernetes pode funcionar sobre o Docker, mas permite que desenvolvedores não fiquem presos às limitações da plataforma e da API.

Bem versátil, o Kubernetes possibilita que os desenvolvedores não apenas gerenciem containers em clusters de máquinas virtuais e físicas, como também pode viabilizar a transformação de uma infraestrutura centrada em hosts para outra centrada em containers.

E, apesar de parecer, o Kubernetes definitivamente não é uma PaaS (sigla para Platform as a Service, ou plataforma como serviço); por outro lado, existem algumas PaaSs que rodam no Kubernetes: as mais notáveis são a OpenShift, a Deis e a Eldarion.

2. Como essa tecnologia surgiu?

Foi em 2008 que o projeto Linux Container apareceu pela primeira vez em um site oficial com a mensagem: “LXC, um ambiente ‘chrootado’ com esteroides”.

Logo de cara, os seus criadores demonstraram que os containers eram uma espécie de alternativa ao comando chroot, que nasceu no Unix V7 em 1979 com o objetivo de limitar o acesso do usuário à estrutura raiz.

Mais tarde, foi criado o comando jail, no FreeBSD 4, que já distribuía de forma limitada o uso de rede e processadores aos usuários. Ou seja, o conceito de abstração e virtualização que antecede o container é relativamente antigo.

Com o tempo, a baixa segurança do chroot fez com que o comando se tornasse inadequado para algumas funcionalidades; os servidores virtuais, por outro lado, supriam essa demanda na maior parte das vezes.

Mas, em alguns casos, a virtualização tradicional pode ser desnecessariamente dispendiosa, em especial quando o objetivo é encapsular pequenas aplicações em uma arquitetura de microsserviços.

Os containers surgiram então para preencher esse vácuo entre a virtualização tradicional e o bom e velho chroot.

3. Quais as principais vantagens do Container?

A função primordial de um container é possibilitar que processos rodem isoladamente dentro de um host com um mesmo sistema operacional. Essa abordagem reduz a complexidade da virtualização e gera uma economia considerável de recursos.

3.1 Como pode ser tão econômico?

Para entender como um container consegue ser tão mais econômico, é necessário discutir a diferença entre containers e imagens. Em poucas linhas, podemos dizer que um container é uma imagem em execução: enquanto a imagem é uma camada extra de dados em formato ‘somente leitura’, no container esses processos estão em execução, teoricamente consumindo processamento, recursos de rede e memória.

Mas, ao criar uma imagem que dependa de outra, é elaborada uma pilha de imagens, que pode formar a base de um ou vários containers. Ou seja, todos eles terão como referência um mesmo conteúdo.

Se fossem rodar como aplicações totalmente independentes, os containers precisariam se basear em várias pilhas de imagens diferentes, o que essencialmente faria deles máquinas individuais. Mas como a estrutura de containers utiliza ambientes montados sob uma única base e sistema operacional, apenas arquivos temporários e logs de cada um serão efetivamente acrescentados como uma camada extra de dados, exigindo recursos mínimos.

3.2 Maior portabilidade com containers

Produtos com alto grau de complexidade, como CRMs, ERPs ou CMSs, podem rapidamente se tornar um monstro de código monolítico, ficando cada vez mais complexos à medida que evoluem. Isso acaba dificultando a vida dos desenvolvedores que trabalham sobre esses projetos.

O uso de uma abordagem de microsserviços pode minimizar um pouco essa ineficiência, desconstruindo esse programa gigantesco em serviços menores e modulares, com um código pequeno e fácil de ser trabalhado.

Mas existem alguns desafios nessa abordagem referentes à portabilidade das aplicações: geralmente, no começo do desenvolvimento, elas rodam em ambientes de teste dentro dos PCs dos desenvolvedores. Mover esses serviços pode ser uma tarefa dispendiosa, pois é necessário alterar referências e configurar tudo novamente.

Mas não com a tecnologia de container: ela possibilita rodar aplicações com consistência entre um computador e outro, seja em ambientes físicos ou virtuais.

3.3 Provisionamento instantâneo

É fato que, se comparado com o tempo de provisionamento de um servidor físico, os minutos necessários para uma máquina virtual operar são imensamente menores. Mas, algumas vezes, a criação de uma VM (Virtual Machine) ainda pode ser lenta demais em comparação com o LXC.

Um container pode subir quase instantaneamente na maior parte dos casos. Isso faz com que pequenas soluções e serviços sejam implementados em tempo recorde.

Outra vantagem dessa praticidade é a inevitável redução da criação de múltiplas VM nos servidores: o provisionamento desenfreado de VMs para banalidades pode prejudicar de forma aguda o gerenciamento da RAM. Com os containers, isso não é um problema tão grande, já que os microsserviços utilizam a memória de forma inteligente.

3.4 Menor desperdício de RAM

Já explicamos sobre como os containers são bem mais econômicos que máquinas virtuais, mas, além de consumir menos, eles também possibilitam um uso mais otimizado e menor desperdício do RAM.

Com as VMs, ficou fácil dividir os recursos de forma isolada e gerenciar a RAM em múltiplas aplicações. Mas, ao mesmo tempo, como o hypervisor requer seu próprio sistema operacional completo, é necessário reservar a cada VM uma quantidade específica de RAM: são raros os hypervisors capazes de redimensionar a disponibilidade do RAM de uma VM de acordo com a demanda.

O resultado é que a maior parte dos desenvolvedores reservam um ‘extra’ significativo de RAM em suas VMs, tanto para o escalonamento posterior quanto para picos de utilização. O resultado disso é que muito RAM pode ficar reservado e sem uso: enquanto algumas aplicações podem engasgar por falta de memória, outras teriam sobrando.

Como no LXC os serviços rodam em um mesmo sistema operacional, cada um deles utiliza apenas a memória necessária no momento: não há desperdício de RAM, o que não está sendo usado está sempre disponível.

Ou seja, além de usualmente consumir menos RAM, os containers nunca desperdiçam esse recurso.

3.4 Facilidade de usar e flexibilidade

Como todo gerenciamento de infraestrutura já é feito pelo hostnet, o LXC permite que o desenvolvedor foque sua atenção quase totalmente na aplicação. Uma vez configurado, o ambiente do container pode ser instantaneamente replicado pelo Docker, o que permite testes muito mais rápidos e facilidade na criação de templates.

Essa usabilidade simples fica ainda melhor quando levamos em conta a natureza Open Source do LXC: existe uma comunidade imensa dando suporte à solução, disponibilizando novos projetos e ferramentas.

4. Gerenciadores de Containers: o que é Docker, Kubernetes e OpenShift?

Antes de 2013, a configuração de um container não era para qualquer um. Apesar de teoricamente simples, o LXC exige um conhecimento técnico em virtualização e um volume de trabalho que afastava muitas iniciativas na tecnologia.

Isso mudou com a chegada de plataformas como o Docker, o Kubernetes e o OpenShift, que simplificam o gerenciamento dos containers.

Apesar de existirem outras soluções no mercado para o mesmo problema, conhecer esses três nomes é essencial para quem quer entender melhor os containers.

4.1 O que é o Docker?

A plataforma de containers mais popular hoje é o Docker. O Docker é uma aplicação Open Source que foi lançada em 2013 e se consolidou como a ferramenta que levou o desenvolvimento em containers para as massas. Escrito em Go, ele usa o LXC como backend para criar um ambiente de virtualização em recursos isolados que utilizam as mesmas bibliotecas kernel, mas sem a necessidade de um sistema operacional completo.

O Docker permite empacotar uma aplicação ou ambiente inteiro dentro de um container, além de replicá-lo para qualquer outro host com o Docker instalado. Essa praticidade faz com que o tempo de deploy seja dramaticamente reduzido, já que não será necessário realizar ajustes para corrigir o funcionamento de um serviço.

A facilidade em configurar apenas uma vez e multiplicar à vontade é dos fatores que fez do Docker a plataforma padrão de containers em desenvolvimento. O Docker também permite que desenvolvedores compartilhem ambientes prontos, abreviando ainda mais o serviço de configuração.

Com o Docker, é possível gerenciar a infraestrutura de uma aplicação sem grandes problemas, o que agiliza o processo de criação e manutenção de um serviço. E como o Docker roda em uma camada abaixo do sistema operacional, ele pode ser usado sem a necessidade de acesso privilegiado à rede.

Como um exemplo do modelo de container, o Docker permite que desenvolvedores empacotem seus aplicativos em uma imagem Docker: se ela funcionar no notebook pessoal do criador, funcionará da mesma forma em um servidor ou mainframe — uma portabilidade surpreendente.

Com a utilização do Docker, o desenvolvedor é capaz de viabilizar ambientes prontos para uso e configurados em segundos, o que é surpreendentemente rápido e muito útil para quem trabalha em uma arquitetura de microsserviços.

4.2 O que é o Kubernetes?

Criado em código aberto pela Google e posteriormente doado para um projeto da Fundação Linux, o Kubernetes é uma plataforma para automatização de deploy, escalonamento e operação de containers.

O Kubernetes é programado em Go e foi inspirado pela experiência de funcionários da Google em escalabilidade de produção, com a contribuição de ideias e práticas de outros membros da comunidade desenvolvedora em código aberto.

Pode-se dizer que o Kubernetes é o sistema que proporciona infraestrutura para containers em máquinas reais e virtuais, de forma versátil e completa. Além disso, ele pode ser usado por desenvolvedores que queiram fazer a transição de uma infraestrutura centrada em hosts para outra centrada em containers.

A importância principal do Kubernetes é que ele é mais que um sistema para orquestrar containers: ele pode literalmente eliminar a necessidade de orquestração, pelo menos da forma que o termo é tradicionalmente aceito.

Normalmente, a orquestração de um sistema está relacionada à execução de um fluxo de trabalho linear com base em um controle centralizado: no Kubernetes, os processos são independentes e não seguem uma ordem rígida de execução, mas cumprem seus propósitos da mesma forma.

O Kubernetes não é um tipo de Plataforma como Serviço (PaaS), apesar de parecer,  mas algumas PaaS, como o OpenShift, o Eldarion e o Deis, rodam no Kubernetes.

4.3 O que é o OpenShift?

OpenShift é uma PaaS desenvolvida pela Red Hat em 2011 e, a partir de 2013, construída sobre o Kubernetes e o Docker. Como uma Plataforma como Serviço, o OpenShift permite que qualquer usuário desenvolvedor faça deploy de aplicativos na nuvem sem custos (na versão free).

Facílimo de usar e extremamente eficiente, o OpenShift é muito provavelmente a forma com que a maior parte dos desenvolvedores lida com containers, ainda que muitos não saibam da existência deles na ferramenta.

Com o OpenShift, os usuários não precisam se preocupar com o backend (ainda que tenham a opção de realizar ajustes, caso desejem). A plataforma permite o provisionamento e a configuração de ambientes em poucos cliques.

O monitoramento e a gestão dos containers também podem ser realizados de forma simples pela própria plataforma, que tem uma usabilidade intuitiva o bastante para ser manejada por quem não tem conhecimentos profundos na área.

Outra grande vantagem é a possibilidade de escalar a aplicação hospedada no OpenShift em minutos, sem ter que se preocupar com deploys e configurações de instalação em ambientes diferentes, justamente como deveria ser com o uso de containers.

Finalmente, o OpenShift permite a administração de todos os ambientes de desenvolvimento em uma única interface visual simples, prática e de usabilidade excelente.

O OpenShift está disponível para usuários em três versões: o OpenShift Origin é mantido pela comunidade e pode ser usado livremente em servidores próprios; o OpenShift Online é oferecido pela Red Hat e inclui um plano gratuito simples para um projeto e até quatro pods.

Se não for o bastante, sua empresa pode adotar o OpenShift Enterprise, que é pago, voltado para negócios e proporciona suporte especializado. A solução é hoje adotada por algumas gigantes, como a Cisco.

5. Qual a diferença entre um Container e uma Máquina Virtual?

Um olhar superficial sobre o modelo de container pode levar à conclusão precipitada de que eles são a mesma coisa que uma máquina virtual, as chamadas VMs. Mas isso é um engano comum. Apesar de servirem a propósitos similares, existem diferenças cruciais entre eles. De forma grosseira, podemos dizer que o LXC é um meio-termo entre a virtualização tradicional e o chroot.

Como já foi citado, os containers nasceram como uma alternativa ao chroot, que por sua vez consegue encapsular sistemas inteiros em uma estrutura única de diretórios. Isso é útil para executar processos e microsserviços sem comprometer o processamento de uma máquina virtual inteira.

A grande novidade dos containers em relação ao chroot é o nível de segurança que pode ser atingido. Aqui, os ambientes virtuais são totalmente blindados, como em uma máquina virtual completa; ou seja, é possível realizar muita coisa com o LXC que antes demandaria todos os recursos de uma máquina virtual completa.

Em relação às máquinas virtuais, a principal diferença está na forma que a abstração é realizada. Enquanto o hardware é virtualizado pela figura do Hypervisor em uma máquina virtual, nos containers o isolamento acontece no nível do sistema operacional.

Com isso, todos ambientes partilham um mesmo kernel e recursos de hardware, mas como o produto não é entregue como uma máquina completa, apenas um processo de execução isolado, a economia de memória e processamento é bem significativa. Além disso, a portabilidade desse modelo de virtualização é bem alta, o que é interessante do ponto de vista da arquitetura de microsserviços.

6. Containers podem se tornar o novo padrão de virtualização?

A tecnologia de container tem realmente muitas vantagens e, justamente por isso, ganha cada vez mais espaço entre os desenvolvedores, especialmente na comunidade DevOps. Muitas vezes, equipes que usavam de forma precária o chroot como alternativa para encapsular aplicações estão muito mais bem servidas com os containers.

Ao mesmo tempo, o container substitui o uso de máquinas virtuais na hora de disponibilizar alguns serviços, fazendo o trabalho com muito mais economia de recursos. Mas, apesar disso, é importante entender que o LXC não é uma máquina virtual mais leve: em situações que envolvem complexidade nas configurações de rede, optar pela tradicional máquina virtual pode ser mais seguro.

A tecnologia de container é ideal para encapsular processos simples ou pequenos elementos de uma arquitetura de microsserviços. Logo, não são exatamente uma concorrência direta às VMs, ainda que seja inevitável que boa parte dos serviços hospedados nelas funcionem melhor se adaptados para os containers.

Talvez, no futuro, os containers possam se tornar o padrão de mercado para a virtualização, mas isso exigiria mudanças em sistemas operacionais que teriam que ser repensados para rodar nativamente em LXC, por exemplo.

Além disso, a própria mentalidade de alguns desenvolvedores precisaria evoluir em direção à chamada arquitetura de microsserviços. Atualmente, aplicativos monolíticos ainda são comuns, mesmo que as desvantagens e frustrações desse tipo de abordagem sejam claras.

Portanto, apesar de completar quase uma década de vida, o LXC ainda passa por evoluções e pela aprovação de desenvolvedores. Mas a própria virtualização de servidores, que hoje é um padrão, encontrou resistência do mercado no passado. Por isso, é cedo para afirmar qual será a aceitação dos containers no futuro; no presente, já são uma tendência com muitas possibilidades de aplicações práticas.

Quer saber mais sobre as soluções da Locaweb Corp? Acesse nosso site!.