Evolua Dockerfiles manuais e modelados com automação

A portabilidade do Docker torna mais simples para as organizações migrar aplicativos para a nuvem ou adotar estratégias de nuvem híbrida. Os aplicativos podem ser desenvolvidos localmente em contêineres e depois implantados na nuvem sem alterações significativas. Esta flexibilidade é crucial para organizações que procuram aproveitar a nuvem pela sua escalabilidade e rentabilidade, mantendo ao mesmo tempo alguns recursos no local.

Ao padronizar o ambiente no qual os aplicativos são executados, o Docker reduz a sobrecarga associada à configuração e manutenção de diferentes ambientes para desenvolvimento, teste e produção. Esta eficiência acelera o ciclo de desenvolvimento e simplifica o processo de implantação, permitindo que as equipes se concentrem mais no desenvolvimento e menos nas questões de infraestrutura.

O problema é que criar e manter Dockerfiles manualmente apresenta desafios significativos para os desenvolvedores. Esses desafios incluem a natureza demorada de escrever e manter a configuração e também a dificuldade em otimizar Dockerfiles para compilações eficientes em uma variedade de tipos e tamanhos de projetos.

Ao decidir se deseja criar Dockerfiles manualmente ou usar uma ferramenta de abstração para gerá-los automaticamente, a escolha certa depende de vários fatores, incluindo a complexidade do seu projeto, a familiaridade da sua equipe com o Docker e os requisitos específicos dos seus ambientes de implantação.

O dilema do Dockerfile

Para projetos simples, a sobrecarga de aprendizagem de uma ferramenta de abstração pode não ser justificada. Para um aplicativo de nó básico, um Dockerfile simples poderia se parecer com o trecho a seguir.

Embora esse Dockerfile seja simples para um único aplicativo, gerenciar arquivos semelhantes em vários microsserviços ou atualizá-los para refletir novas dependências torna-se cada vez mais complexo e sujeito a erros.

Vamos dar uma olhada em um exemplo de Dockerfile fora de controle para um aplicativo Node.js. Este é um exemplo exagerado projetado para ilustrar armadilhas comuns que tornam difícil mantê-lo à medida que o projeto cresce.

Armadilhas comuns do Docker

Embora você possa não encontrar todas essas armadilhas de uma só vez, é provável que algumas delas surjam com o tempo. Vejamos cada problema neste Dockerfile:

• Camadas ineficientes – Este Dockerfile cria camadas desnecessárias, pois existem vários RUN instruções que podem ser combinadas. Além disso, ele lida de forma ineficiente com a cópia de arquivos e a instalação de dependências.
• Codificação rígida – Este Dockerfile usa uma versão específica da imagem Node.js (node:14) sem uma maneira fácil de atualizá-la. É mais escalonável usar argumentos de construção (ARG) para especificar versões, permitindo atualizações fáceis sem modificar o Dockerfile diretamente.
• Instalação do pacote NPM global – A instalação de pacotes globais (TypeScript, ts-node, nodemon) aumenta a imagem e vincula a construção a versões específicas dessas ferramentas. É melhor incluí-las como dependências de desenvolvimento em package.json e usá-las localmente, garantindo consistência entre ambientes.
• Operações desnecessárias – O Dockerfile inclui etapas que aumentam o tempo de construção e o tamanho da imagem, como copiar todos os arquivos de origem duas vezes e instalar pacotes desnecessários após copiar os arquivos de origem. Além disso, o uso de npm prune --production depois de instalar todas as dependências indica uma abordagem ineficiente para gerenciar dependências de produção e desenvolvimento.

O caso da geração automática de imagens Docker

Com o advento de ferramentas e estruturas sofisticadas que automatizam a criação e o gerenciamento de contêineres Docker, há um forte argumento para usar essas tecnologias para economizar tempo e reduzir o potencial de erro humano.

Usar mecanismos de modelo como Jinja2, Moustache ou EJS pode ajudar a gerar Dockerfiles a partir de modelos. Esses modelos podem definir a estrutura do seu Dockerfile, com espaços reservados para opções configuráveis ​​como imagens base, variáveis ​​de ambiente e dependências. Um script simples pode preencher esses modelos com valores reais com base nos requisitos do seu aplicativo ou nas configurações específicas do ambiente.

Podemos dar um passo adiante?

Frameworks como o Nitric trazem automação inteligente para o desenvolvimento de aplicativos em nuvem, incluindo a geração de Dockerfiles, abstraindo as complexidades das configurações e implantações de serviços em nuvem.

Como automatizar a geração do Dockerfile

Os aplicativos em nuvem geralmente têm vários pontos de entrada em uma API, como get, put, patch e delete métodos. Esses aplicativos também possuem manipuladores que ativam gatilhos, como ouvir um tópico de evento ou executar uma tarefa agendada. Cada ponto de entrada em um aplicativo pode ser integrado em seu próprio contêiner usando o Docker e, em seguida, implantado em um tempo de execução de contêiner em nuvem, como AWS Lambda, Google CloudRun ou Azure Container Apps.

Podemos então decidir como construir esses contêineres com base nas propriedades do projeto — por exemplo, a linguagem de programação usada no projeto ou a necessidade de telemetria. No nível superficial, pode parecer que a conveniência disso está na perda de controle, mas contanto que a estrutura também inclua “escotilhas de escape” integradas para manter o controle, você ainda será capaz de substituir o comportamento padrão implementando modelos Dockerfile personalizados para serem usados ​​por alguns ou todos os serviços em seu aplicativo.

Aqui está um exemplo de modelo Docker retirado da estrutura Nitric que pode ser facilmente substituído.

As vantagens da abordagem automatizada

Para implantações baseadas em contêineres, as estruturas de automação podem gerar Dockerfiles com base na configuração do aplicativo e nos serviços que ele usa. Isso inclui configurar os ambientes de tempo de execução apropriados, lidar com dependências e configurar as etapas de construção necessárias para que o aplicativo seja executado em um ambiente em contêiner.

Também ganhamos dois power-ups úteis:

1. Portabilidade — Além da geração do Dockerfile, a estrutura de automação pode agilizar o processo de implantação para oferecer suporte a vários provedores de nuvem. Isso significa que os aplicativos podem ser implantados em AWS, Microsoft Azure, Google Cloud, etc., sem exigir alterações na configuração de implantação, tornando-os extremamente escalonáveis ​​e flexíveis.

2. Desenvolvimento local — As estruturas de automação podem permitir o desenvolvimento e o teste off-line de aplicativos nativos da nuvem, emulando ambientes de nuvem. Isso significa que os desenvolvedores podem testar seus aplicativos em um ambiente gratuito que imita de perto o ambiente de implantação de destino, reduzindo o “Funciona na minha máquina!” síndrome.

Experimente para o seu projeto

Embora a modelagem de Dockerfiles possa oferecer um nível de automação e padronização para a criação de imagens Docker, estruturas como a Nitric se baseiam nesse conceito, fornecendo uma abordagem mais holística para implantação e gerenciamento de aplicativos. Eles oferecem uma interface simplificada e de alto nível para tarefas comuns com a capacidade de substituir ou estender os Dockerfiles gerados automaticamente e as configurações de implantação.

Os desenvolvedores podem especificar instruções personalizadas do Dockerfile, integrar ferramentas ou serviços adicionais e até mesmo ajustar manualmente as configurações geradas antes da implantação. Isso garante que as equipes possam alcançar as otimizações de desempenho ou integrações de recursos exatas de que necessitam, sem serem limitadas pela automação da estrutura.

Crie uma prova de conceito com Nitric para ver como você pode agilizar o desenvolvimento de seu aplicativo e gerar automaticamente o padrão necessário para executar seu aplicativo na nuvem.

A postagem Evoluir Dockerfiles manuais e modelados com automação apareceu pela primeira vez em The New Stack.