Como conteinerizar um aplicativo legado

A conteinerização transformou a forma como novos aplicativos são desenvolvidos e implantados. No entanto, muitas organizações mantêm um catálogo anterior de sistemas mais antigos que precisam de uma abordagem diferente. Essa desconexão entre o novo e o antigo não precisa ser perpetuada: você também pode empacotar sistemas mais antigos como contêineres, facilitando sua evolução com métodos de desenvolvimento mais modernos.

Neste artigo, veremos um processo que você pode usar para iniciar a conteinerização de instrument “herdado”. Embora não haja dois produtos iguais e o termo “legado” seja subjetivo, vamos nos concentrar em etapas amplamente aplicáveis ​​para empacotar sistemas fortemente acoplados atualmente vinculados a ambientes individuais.

1. Identificar Sistemas Candidatos

Vale a pena primeiro preparar um inventário de sistemas que permita identificar bons candidatos para a conteinerização. Em alguns casos, você pode concluir que um aplicativo específico simplesmente não pode ser conteinerizado. Isso geralmente ocorre quando há requisitos de {hardware} profundamente arraigados ou depende de recursos obsoletos do kernel e linguagens de programação.

Os melhores candidatos são sistemas usados ​​com frequência que se beneficiarão imediatamente de um desenvolvimento futuro acelerado. Procure aplicativos que já sejam bastante autocontidos se você for completamente novo na conteinerização. A seleção de um sistema que seja bem usado, mas não de missão crítica, lhe dará margem de manobra se as coisas derem errado, permitindo que você reconheça os benefícios de uma migração bem-sucedida.

2. Componente o Sistema

Você poderia conteinerize seu sistema candidato escrevendo um Dockerfile, incluindo todas as dependências do aplicativo, e chamando-o de um dia. Embora essa seja uma maneira válida de colocar rapidamente um sistema em um contêiner, não deve ser o objetivo ultimate de seus esforços. Um contêiner monolítico resultará em compilações longas, tamanhos de imagem enormes e escalabilidade ruim.

Em vez disso, você deve procurar oportunidades para dividir cada um de seus sistemas em componentes individuais. Esses componentes devem terminar em seus próprios recipientes, evitando que qualquer peça única fique muito grande. Você poderá dimensionar os componentes individualmente criando réplicas extras de contêineres com recursos limitados.

Essa etapa também é importante para estabelecer a modularidade geral e incentivar a adoção de contêineres adicionais. À medida que você separa mais sistemas em seus componentes, você começará a encontrar sobreposições que permitem reutilizar imagens de contêiner que você já criou. Você notará que se torna gradualmente mais fácil continuar com a conteinerização.

Decidir onde dividir os componentes não deve ser muito cansativo. Comece identificando onde o sistema depende de serviços que já são externos ao seu código-fonte. Conexões de banco de dados, filas de mensagens, servidores de email, proxies e gateways devem ser independentes do componente que aumentam. Você os separará em seus próprios contêineres que ficam ao lado da instância que executa seu código.

Também vale a pena procurar oportunidades para refatorar o que sobrou. Seu serviço tem muitas responsabilidades que podem ser divididas em unidades funcionais separadas? Você pode ter uma API de perfil de usuário que aceita uploads de fotos; o serviço que redimensiona essas fotos pode ser um bom candidato para ser executado de forma autônoma em seu próprio contêiner.

3. Get ready seus componentes

Depois de separar os componentes, você precisa prepará-los para operar em um ambiente em contêiner. Os contêineres têm várias diferenças importantes em comparação com as VMs tradicionais. Armazenamento persistente, configuração e hyperlinks entre componentes são os três mais importantes a serem considerados antecipadamente.

Armazenamento persistente

Os contêineres são ambientes efêmeros. As modificações do sistema de arquivos são perdidas quando seus contêineres param. Você é responsável por gerenciar os dados persistentes de seu aplicativo usando os mecanismos fornecidos pelo pace de execução do contêiner.

No caso do Docker, os volumes são usados ​​para manter os dados fora de suas instâncias de contêiner. Os volumes são montados em caminhos específicos dentro de contêineres. Para evitar ter que montar dezenas de volumes, é melhor concentrar os dados do seu aplicativo em alguns diretórios de nível awesome. A montagem de volumes nesses locais garantirá a persistência dos arquivos que seu aplicativo armazena.

É importante auditar as interações do sistema de arquivos do seu aplicativo para entender de quais volumes você precisa e quaisquer problemas que encontrará. Não prestar atenção a esta etapa pode ser caro se os dados que você supõe serem persistentes forem perdidos sempre que um contêiner for reiniciado.

Gerenciando a configuração

Muitos aplicativos legados são configurados usando arquivos de configuração estáticos. Eles podem estar em um formato dedicado, como XML, JSON ou INI, ou codificados usando a linguagem de programação do sistema.

Os contêineres são normalmente configurados por variáveis ​​de ambiente externas. As variáveis ​​são definidas quando os bins são criados, usando mecanismos como o do Docker -e bandeira com docker run. Eles são injetados no ambiente do contêiner em execução.

O uso desse sistema garante que você possa confiar em sua cadeia de ferramentas de contêiner para definir e alterar os parâmetros de configuração. Talvez você actual refatorar seu aplicativo primeiro para dar suporte às configurações de leitura de variáveis ​​de ambiente. Uma maneira comum de facilitar a transição é colocar um pequeno script dentro do ponto de entrada do contêiner. Isso pode enumerar variáveis ​​de ambiente na criação do contêiner e gravá-las em um arquivo de configuração para seu aplicativo.

Hyperlinks entre serviços

A conteinerização também faz você pensar em redes entre serviços. Os serviços geralmente não são expostos uns aos outros, exceto por configuração explícita. Você pode configurar a vinculação automática no Docker juntando vários contêineres à mesma rede do Docker. Isso oferece uma função de descoberta de serviço que permite que os contêineres entrem em contato pelo nome.

Outras tecnologias de conteinerização usam diferentes abordagens para redes e descoberta de serviços. Tendo separado seus sistemas em componentes individuais, você precisa juntá-los novamente usando os recursos oferecidos pelo seu pace de execução. A natureza das implantações em contêiner significa que geralmente há mais complexidade do que a rede entre VMs ou hosts físicos. O tráfego precisa ser roteado e balanceado entre todas as suas réplicas de contêiner e suas dependências, portanto, você deve reconhecer esses requisitos desde o início.

4. Escreva seus Dockerfiles

Depois de planejar sua arquitetura, você pode iniciar o trabalho físico associado à conteinerização. A primeira etapa é escrever Dockerfiles para os componentes do seu aplicativo. Eles definem a sequência de comandos e ações que criam um sistema de arquivos contendo tudo o que o componente precisa para ser executado.

Os Dockerfiles começam com uma imagem base apropriada referenciada por um FROM declaração. Geralmente é um sistema operacional (ubuntu:20.04, alpine:3) ou um ambiente de linguagem de programação pré-construído (php:8, node:16). Você pode escolher a imagem que melhor corresponde ao ambiente existente do seu aplicativo. Começar a partir de um sistema de arquivos vazio é possível, mas geralmente não é necessário, a menos que você actual de um controle extremamente granular.

O conteúdo adicional é colocado em camadas na imagem base por instruções como COPY e RUN. Eles permitem que você copie arquivos do seu host e execute comandos no sistema de arquivos temporário da compilação. Depois de escrever seu Dockerfile, você pode construí-lo com o docker construct -t my-image:newest . comando.

5. Configure a orquestração

Supondo que você tenha dividido seu sistema em componentes, você terminará com uma imagem de contêiner para cada peça. Agora você precisa de uma maneira de abrir todos os contêineres simultaneamente para poder iniciar convenientemente uma instância de aplicativo em funcionamento.

Instalações de produção maiores geralmente usam o Kubernetes para essa finalidade. É um sistema de orquestração dedicado que adiciona seus próprios conceitos de nível awesome para criar implantações em contêiner replicadas. Sistemas menores e ambientes de desenvolvimento geralmente são bem servidos pelo Docker Compose, uma ferramenta que se baseia em arquivos YAML mais simples para iniciar uma “pilha” de vários contêineres:

model: "3"

app:
  picture: my-web-app:newest
  ports:
    - 80:80
database:
  picture: mysql:8.0
  ports:
    - 3306:3306

UMA docker-compose.yml arquivo permite iniciar todos os seus serviços usando o docker-compose binário:

docker-compose up -d

A configuração de alguma forma de orquestração torna sua frota de contêineres mais gerenciável e facilita o dimensionamento por meio da replicação. Tanto o Kubernetes quanto o Docker Compose são capazes de iniciar várias instâncias de seus serviços, um recurso que não pode ser alcançado com aplicativos herdados formados por componentes fortemente acoplados.

6. Após a mudança: monitorando e expandindo sua frota de contêineres

A conteinerização não termina com o início de uma instância do seu aplicativo. Para obter o máximo da tecnologia, você precisa monitorar adequadamente seus contêineres para se manter informado sobre erros e utilização de recursos.

Sistemas maiores são melhor atendidos por uma plataforma de observabilidade dedicada que pode agregar logs e métricas de toda a sua frota. Você já pode estar usando uma solução semelhante com suas implantações de aplicativos herdados, mas é ainda mais importante para os contêineres. Uma boa observabilidade permitirá que você rastreie os problemas até a instância de contêiner de onde eles se originaram, trazendo à tona os insights que importam quando você tem centenas ou milhares de réplicas.

Para continuar expandindo sua frota, dobre a documentação e a padronização. Já vimos como a divisão de sistemas em componentes ajuda a reutilização futura. No entanto, isso só funciona efetivamente se você documentou o que tem e como cada peça se encaixa. Reserve um pace para escrever sobre seu sistema e o processo pelo qual você passou agilizará o trabalho futuro. Também ajudará os novos membros da equipe a entender as decisões que você tomou.

Vale a pena?

A conteinerização vale a pena quando você sente que o desenvolvimento de um sistema está sendo retido por seus processos atuais. Ser capaz de implantá-lo como um conjunto de contêineres simplifica a experiência de desenvolvimento e oferece mais versatilidade na implantação. Agora você pode iniciar o serviço em qualquer lugar em que um pace de execução de contêiner esteja disponível, seja uma instância em seu computer ou 1.000 em um provedor de nuvem pública.

A integração overall em contêineres facilita o aproveitamento do poder da nuvem, consolida suas implantações e reduz os custos de infraestrutura native. No entanto, essas vitórias aparentes podem ser contrabalançadas pela necessidade de retreinar engenheiros, contratar novos talentos especializados e manter seus contêineres ao longo do pace.

A decisão de conteinerizar um sistema legado precisa considerar o valor desse sistema para o seu negócio, o pace atual gasto em sua manutenção e a provável redução como resultado do uso de contêineres. Pode ser que os serviços de baixa prioridade sejam deixados sozinhos se os processos associados a eles não estiverem causando problemas imediatos.

Deve-se reconhecer que nem todos os aplicativos herdados precisarão ou serão capazes de usar todos os benefícios da conteinerização. A adoção é um espectro, desde a execução do sistema em um único contêiner monolítico até a componentização, orquestração e integração completas com suítes de observabilidade. O último modelo é o alvo very best para aplicações críticas de negócios que os engenheiros evoluem todos os dias; por outro lado, o primeiro pode ser adequado para serviços raramente tocados, onde o foremost obstáculo é o pace gasto provisionando novos ambientes de desenvolvimento baseados em VM.

Conclusão

A migração de aplicativos legados para fluxos de trabalho em contêiner pode parecer um desafio superficialmente. Dividir o processo em etapas distintas geralmente ajuda a definir onde você está e onde deseja estar. Neste artigo, analisamos seis estágios granulares que você pode usar para abordar a conteinerização de sistemas existentes. Também discutimos algumas das considerações que você precisa fazer ao decidir se deve continuar.

Do ponto de vista conceitual, contentorizar um aplicativo legado é um pouco diferente de trabalhar com um novo. Você está aplicando os mesmos princípios de componentização, serviços vinculados e configuração injetados do ambiente externo. A maioria dos sistemas é relativamente simples de conteinerizar quando vista dessa perspectiva. Concentrar-se nesses aspectos ajudará você a desacoplar seus aplicativos, criar componentes escaláveis ​​e criar uma metodologia de conteinerização eficaz.