Na era da conteinerização… Afinal, alguém sabe o que é container?

A transformação digital tem quebrado paradigmas e exigido um exercício diário dentro das organizações. A cada dia, novas tecnologias surgem com o intuito de tornar processos mais ágeis e menos dispendiosos. Mas com tantos conceitos inovadores flutuando pelo mercado, até os mais gabaritados profissionais de TI acabam misturando temas vez ou outra. Containers, Kubernetes, Docker, Coreos, Atomic, LXC, DevOps, DevSecOps, só para citar alguns, acabam se misturando. E, em muitos casos, tudo acaba rotulado como container, quando a verdade não é bem assim.

O que são containers?

De forma sucinta, a tecnologia de container é uma metodologia utilizada para empacotar aplicações para que possam ser executadas/disponibilizadas com o seu subset de dependências de maneira isolada e eficiente no intuito de segregar e facilitar a portabilidade dessas aplicações.

Mas, de fato, o questionamento sobre a definição dos containers depende muito da perspectiva de quem responde a essa pergunta. Como a aplicabilidade dos containers tem como principal ponto servir de base para o modelo DevOps, há duas visões distintas por área. Em Operações, por exemplo, os containers se traduzem em processos de aplicações rodando em um kernel compartilhado, de maneira mais simples e leve que em máquinas virtuais e com portabilidade entre diferentes ambientes. Já para o time de Desenvolvimento, os containers empacotam aplicações com todas as suas dependências, são instaláveis em qualquer ambiente em segundos, acessíveis e compartilháveis.

Há alguns anos, a infraestrutura de TI era criada com aplicações desenvolvidas diretamente sobre máquinas virtuais. Ou, em alguns casos, em máquinas físicas (conhecidas como bare metal), dependendo de quão legada era a aplicação. À medida que a infraestrutura/workload evoluiu, as máquinas virtuais (VMs) passaram a permitir níveis mais altos de gerência e centralização do ambiente.

As VMs por si só não atendem completamente às necessidades de uma abordagem ágil de desenvolvimento, principalmente quando se trata de portabilidade. Nesse caso, os containers ganham espaço, já que fornecem um modo de virtualizar o sistema operacional para executar várias cargas de trabalho em uma única instância do sistema. Apesar de ambos serem técnicas de virtualização, em muitos cenários possuem um espaço próprio e podem coexistir no mesmo ecossistema.

O velho/novo container

Compreendido o conceito de container, precisamos entender que, ao contrário do que muita gente pensa, essa tecnologia não é assim tão nova. Sua primeira aparição no mercado de TI data da década de 1970. Durante o desenvolvimento do Unix V7, foi introduzido o systemcall conhecido como chroot, alterando o diretório raiz de um processo e seus filhos para um novo local no sistema de arquivos, recurso muito utilizado até hoje para eventuais manutenções. Esse avanço deu início ao isolamento do processo, segregando o acesso a arquivos para cada processo.

Já nos anos 2000, a tecnologia de containers ganha forma com a aparição do FreeBSD Jails que permite aos sysadmins dividir um sistema operacional FreeBSD em vários sistemas menores e independentes conhecido como jails, inclusive com a capacidade de atribuir IP e hostname para cada sistema e configuração.

No período, houve ainda o lançamento do Linux VServer “old-school”; foi disponibilizada a primeira versão beta e pública do Solaris Containers; apresentado ao mercado o projeto OpenVZ (Open Virtuozzo) e o “Process Containers”, lançado pelo Google. Por fim, em 2008, o projeto LXC (Linux Containers) foi a primeira e mais completa implementação do gerenciador de containers do Linux. Devido à confiabilidade e estabilidade do LXC, muitas outras tecnologias foram criadas usando-o como base, incluindo Warden, em 2011, e o Docker, em 2013, que levou a tecnologia de containers a um novo patamar.

Mais adeptos, novas preocupações

Com a ampla adoção de aplicações baseadas em containers, os sistemas se tornaram mais complexos e aumentaram os riscos. Em 2016, revelada a importância da segurança dos containers, houve uma mudança no longo do ciclo de vida de desenvolvimento do software, também conhecido como DevSecOps. A ideia é desenvolver a mentalidade de que todos são responsáveis pela segurança, com ações que devem garantir a velocidade e escala dos containers. O objetivo é construir containers seguros desde sua concepção, sem impactar o tempo de lançamento no mercado.

Com o Docker tornando-se um padrão no empacotamento e utilização dos containers, em 2015 a comunidade decidiu definir um padrão aberto para evitar futuros problemas de lock-in da tecnologia em volta dos formatos e runtimes dos containers. Docker e o CoreOS, iniciaram o Open Container Initiative (OCI) para tentar padronizar o tempo de execução (runtime) do container e as especificações de formato aberto de imagem. Os esforços do OCI amadureceram bastante e hoje a especificação do formato de imagem OCI é suportada pela maioria, senão todos, repositórios de imagem convencionais (como Docker Hub, ECR da Amazon etc.). A especificação de tempo de execução da OCI possui uma implementação de referência no runC, e a maioria dos tempos de execução de containers existentes já é compatível com OCI ou possui conformidade com ele.

O container runtime é o software que executa os containers propriamente ditos e gerencia as imagens do mesmo em um determinado node. Hoje, o tempo de execução do container mais conhecido é o Docker.

Em suma, os containers alteraram fundamentalmente o desenvolvimento de software devido à proposta de portabilidade das aplicações e escalabilidade. Uma vez bem estruturada a ideia de containers e de como estão presentes no dia a dia, chega o próximo passo: como escalar e orquestrar a tecnologia entre múltiplos datacenters, provedores de cloud.

O cenário do ecossistema de containers mudou de uma maneira significativa. O Docker desfrutou do status de padrão de execução e formato de imagem até 2017. Seu formato e runtime de imagem eram constantes em uma guerra aquecida no espaço de orquestração de containers.

Importante destacar a nova geração de ferramentas para o provisionamento de containers como o Buildah (construção), Podman (lançar) e o Skopeo (copiar). Essas ferramentas de código aberto são mantidas pela organização de containers no Github. Há alguma sobreposição de funcionalidade entre Buildah e Podman, mas a separação das responsabilidades principais é clara. Nenhuma dessas ferramentas requer um daemon em execução e, na maioria das vezes, também não precisam de acesso root. O foco é construir containers mais seguros desde sua concepção, sem impactar o tempo de lançamento no mercado.

Desde então, o Kubernetes está na frente do tema orquestradores e se tornou o padrão aberto para tal. Desenvolvido pelo Google, o Kubernetes é um sistema de código aberto para gerenciamento de aplicações que oferece uma plataforma para automatização de deploy, balanceamento de carga, escalonamento e operação de containers. Programado em Go, trata-se de um sistema cujo objetivo é facilitar a implantação de aplicativos a partir da perspectiva dos microsserviços.

Funcionando como um jogo de montar, onde cada peça é fundamental para o desenvolvimento do projeto final, o universo do TI é fascinante. E quem souber navegar, dominando peculiaridades desse oceano, vai sair na frente.

*Raul Leite é sênior Cloud Architect na Red Hat Brasil