O advento do Docker como principal tecnologia para uso de containers vem revolucionando as áreas de desenvolvimento de software e DevOps nestes últimos anos. Inicialmente focando em Linux e, mais recentemente estendendo o suporte para ambientes Windows, o Docker está presente hoje em projetos construídos nas mais diferentes plataformas.

ASP.NET Core, Node, Java, Python, Ruby e PHP constituem bons exemplos de tecnologias nas quais a utilização do Docker cresce a cada dia.

E quais os motivos de tanta agitação em torno do Docker? Bom, além do fato de ser uma plataforma open source em contínua evolução e que conta com uma comunidade bastante engajada, o Docker traz ainda grandes vantagens em termos de deployment de aplicações.

Um container Docker oferece um ambiente isolado, no qual estarão uma aplicação e todas as suas dependências. No caso de um típico projeto Web, isso pode envolver binários, bibliotecas das quais ele depende e arquivos estáticos (HTML, CSS, entre outros).

O isolamento de aplicações em um mesmo host impede que a atualização de uma delas afete as demais, o que se traduz em deployments mais seguros.

Outro ponto que pesa a favor da adoção do Docker está na menor dependência em relação às configurações dos ambientes nos quais acontecerá o deployment de uma aplicação. Se um projeto é capaz de executar normalmente em um container gerado a partir de uma imagem criada numa máquina de desenvolvimento, o mesmo valerá para publicações em outros ambientes que suportem Docker.

A questão do isolamento possibilita ainda um melhor aproveitamento de recursos, evitando assim a criação de múltiplas máquinas virtuais que na maioria das vezes seriam subutilizadas. Embora empreguem técnicas de virtualização, containers Docker localizados em um mesmo host compartilham recursos deste último e contribuem para uma utilização mais racional de recursos computacionais.

Grandes players do mercado enxergaram todo o potencial oferecido pelo Docker e têm realizado vultosos investimentos na disponibilização de serviços baseados nessa tecnologia. Microsoft, IBM, Amazon, Google e Red Hat se destacam dentro dessa iniciativa, oferecendo alternativas na nuvem para os mais variados tipos de demanda envolvendo aplicações Web.

Todo um ecossistema foi também desenvolvido em torno do Docker, com soluções estendendo as capacidades de recursos baseados nessa tecnologia. Exemplos disso são Kubernetes e Docker Swarm, alternativas open source voltadas para a orquestração e o gerenciamento de containers Docker.

Orquestradores de containers são opções extremamente interessantes em projetos Web com alta demanda de utilização:

• Dispondo de mecanismos que permitem escalar rapidamente uma aplicação, tecnologias como Kubernetes e Docker Swarm conseguem criar dezenas, centenas ou até mesmo milhares de containers em poucos segundos.
• As rotinas de gerenciamento de produtos como esses são capazes de detectar instâncias/containers com problemas e rapidamente gerar novas estruturas desse tipo, em substituição aos elementos com defeito. Tudo isso contribui para garantir uma alta disponibilidade do projeto em questão.

Soluções de integração contínua, como Jenkins e Visual Studio Team Services (VSTS), também suportam Docker. Tal compatibilidade acaba por viabilizar o build e o deployment automatizado de aplicações que dependam de containers.

Características como isolamento, escalabilidade facilitada, alta disponibilidade e deployment automatizado correspondem a aspectos perseguidos dentro de uma arquitetura de microsserviços. Essas razões acabam por favorecer a adoção do Docker em projetos que se guiam por esse novo paradigma de desenvolvimento.

Mas além de projetos Web, como sites e APIs REST, podemos utilizar Docker com outros tipos de soluções?

A resposta para essa pergunta felizmente é SIM. Além da containerização de soluções Web, o Docker pode ser empregado em cenários como a montagem de instâncias de servidores de bancos de dados, instalação de serviços de mensageria e, até mesmo, como meio para o deployment de rotinas de processamento contínuo/periódico (neste último caso, em um formato similar ao de implementações como Windows Services).

E quais seriam então as vantagens de se utilizar o Docker fora do desenvolvimento Web, levando em consideração esses outros cenários mencionados?

• A instalação de instâncias de servidores de bancos de dados como SQL Server e Oracle costuma ser um processo moroso, variando de minutos a até algumas horas. Ao se baixar uma imagem desses SGBDs, é possível subir uma nova instância via geração de um container em questão de segundos.
• Outro tipo de processo em que muitas vezes há demora e eventuais problemas é a desinstalação de um software. Com o Docker, temos a possibilidade de interromper a execução e proceder com a remoção de um container em poucos segundos. Eventuais resquícios deixados após uma desinstalação deixam de constituir um problema, já que um container Docker encapsula tudo do que uma aplicação depende para funcionar (e ao ser eliminado não produzirá vestígio algum).
• Diferentes versões de um mesmo software podem conviver sem dificuldades em uma mesma máquina, bastando para isso que se definam diferentes portas para a execução de cada release. Tomando como exemplo o SQL Server, isso abre a possibilidade de execução de instâncias das versões 2016 e 2017 a partir de um mesmo host.
• Todos esses benefícios contribuem para que o Docker represente uma excelente alternativa para a montagem de ambientes de desenvolvimento e testes, dada a velocidade de criação/remoção de containers baseados nessa tecnologia.

Podemos exemplificar tudo o que foi discutido até aqui com a criação de um container baseado no RabbitMQ, message broker open source e multiplataforma que conta com grande adesão entre desenvolveres das mais variadas plataformas.

O comando a seguir criará um novo container do RabbitMQ, baixando ainda a imagem necessária caso ela não exista no host (o que é indicado na imagem que aparece na sequência):

docker run -d --hostname rabbit-local --name testes-rabbitmq -p 6672:5672 -p 15672:15672 -e RABBITMQ_DEFAULT_USER=testes -e RABBITMQ_DEFAULT_PASS=Testes2018! rabbitmq:3-management

Nessa instrução constam:

• O atributo -d, que fará com que o container em questão seja executado como um serviço em background.
• O atributo –hostname, com o nome de identificação do message broker.
• No atributo –name, está o nome do container a ser gerado (testes-rabbitmq).
• O atributo -p permite configurar a porta (6672) em que acontecerá a comunicação com o RabbitMQ, a qual será mapeada para a porta default (5672) desse message broker dentro do container.
• O atributo -e duas vezes, utilizado em conjunto com os parâmetros RABBITMQ_DEFAULT_USER e RABBITMQ_DEFAULT_PASS na definição das credenciais de acesso ao message broker.
• Um segundo atributo -p indica a porta (15672) para acesso ao plugin de monitoramento do RabbitMQ.
• A imagem utilizada como base para a geração do container (rabbitmq:3-management).

O comando docker images rabbitmq:3-management mostrará que a imagem foi baixada corretamente:

Já a instrução docker ps confirmará que o container criado se encontra em execução:

O plugin de gerenciamento do RabbitMQ pode ser acessado a partir do endereço http://localhost:15672:

Além do SQL Server, do Oracle e do RabbitMQ, é importante mencionar ainda a viabilidade de se instalar por meio de containers serviços populares como o PostgreSQL, o MySQL, o Redis e o MongoDB. Inúmeras são as possibilidades de uso do Docker, desde projetos de grande porte à montagem rápida e sem dificuldade de ambientes de desenvolvimento/testes.

***

Artigo publicado na revista iMasters, edição #27: https://issuu.com/imasters/docs/imasters_27_issuu