Contentorização de aplicações monolíticas
Gorjeta
Este conteúdo é um trecho do eBook, .NET Microservices Architecture for Containerized .NET Applications, disponível no .NET Docs ou como um PDF para download gratuito que pode ser lido offline.
Talvez você queira criar um único aplicativo ou serviço Web implantado monoliticamente e implantá-lo como um contêiner. O aplicativo em si pode não ser internamente monolítico, mas estruturado como várias bibliotecas, componentes ou até mesmo camadas (camada de aplicativo, camada de domínio, camada de acesso a dados, etc.). Externamente, no entanto, é um único contêiner — um único processo, um único aplicativo Web ou um único serviço.
Para gerenciar esse modelo, implante um único contêiner para representar o aplicativo. Para aumentar a capacidade, basta expandir para fora, ou seja, basta adicionar mais cópias com um balanceador de carga na frente. A simplicidade vem do gerenciamento de uma única implantação em um único contêiner ou VM.
Figura 4-1. Exemplo da arquitetura de um aplicativo monolítico conteinerizado
Você pode incluir vários componentes, bibliotecas ou camadas internas em cada contêiner, conforme ilustrado na Figura 4-1. Um aplicativo monolítico em contêineres tem a maior parte de sua funcionalidade em um único contêiner, com camadas ou bibliotecas internas, e é dimensionado clonando o contêiner em vários servidores/VMs. No entanto, esse padrão monolítico pode entrar em conflito com o princípio do contêiner "um contêiner faz uma coisa e faz isso em um processo", mas pode ser ok para alguns casos.
A desvantagem dessa abordagem torna-se evidente se o aplicativo crescer, exigindo que ele seja dimensionado. Se todo o aplicativo puder ser dimensionado, isso não será realmente um problema. No entanto, na maioria dos casos, apenas algumas partes da aplicação são os pontos de estrangulamento que exigem escala, enquanto outros componentes são usados menos.
Por exemplo, em um aplicativo de comércio eletrônico típico, você provavelmente precisa dimensionar o subsistema de informações do produto, porque muito mais clientes pesquisam produtos do que os compram. Mais clientes usam sua cesta do que usam o pipeline de pagamento. Menos clientes adicionam comentários ou visualizam seu histórico de compras. E você pode ter apenas um punhado de funcionários que precisam gerenciar o conteúdo e as campanhas de marketing. Se você dimensionar o design monolítico, todo o código para essas tarefas diferentes será implantado várias vezes e dimensionado no mesmo grau.
Há várias maneiras de dimensionar uma duplicação horizontal de aplicativo, dividindo diferentes áreas do aplicativo e particionando conceitos de negócios ou dados semelhantes. Mas, além do problema de dimensionamento de todos os componentes, as alterações em um único componente exigem um novo teste completo de todo o aplicativo e uma reimplantação completa de todas as instâncias.
No entanto, a abordagem monolítica é comum, porque o desenvolvimento do aplicativo é inicialmente mais fácil do que para abordagens de microsserviços. Assim, muitas organizações se desenvolvem usando essa abordagem arquitetônica. Enquanto algumas organizações tiveram resultados bons o suficiente, outras estão atingindo limites. Muitas organizações projetaram seus aplicativos usando esse modelo porque as ferramentas e a infraestrutura dificultaram demais a criação de arquiteturas orientadas a serviços (SOA) anos atrás, e não viram a necessidade até que o aplicativo crescesse.
Do ponto de vista da infraestrutura, cada servidor pode executar vários aplicativos dentro do mesmo host e ter uma proporção aceitável de eficiência no uso de recursos, como mostra a Figura 4-2.
Figura 4-2. Abordagem monolítica: host executando vários aplicativos, cada aplicativo sendo executado como um contêiner
Os aplicativos monolíticos no Microsoft Azure podem ser implantados usando VMs dedicadas para cada instância. Além disso, usando conjuntos de dimensionamento de máquina virtual do Azure, você pode dimensionar facilmente as VMs. O Serviço de Aplicativo do Azure também pode executar aplicativos monolíticos e dimensionar instâncias facilmente sem exigir que você gerencie as VMs. Desde 2016, os Serviços de Aplicativo do Azure também podem executar instâncias únicas de contêineres do Docker, simplificando a implantação.
Como um ambiente de QA ou um ambiente de produção limitado, você pode implantar várias VMs de host do Docker e equilibrá-las usando o balanceador do Azure, como mostra a Figura 4-3. Isso permite que você gerencie o dimensionamento com uma abordagem de grão grosso, porque todo o aplicativo vive dentro de um único contêiner.
Figura 4-3. Exemplo de vários hosts dimensionando um único aplicativo de contêiner
A implantação nos vários hosts pode ser gerenciada com técnicas tradicionais de implantação. Os hosts do Docker podem ser gerenciados com comandos como docker run ou docker-compose executados manualmente, ou por meio de automação, como pipelines de entrega contínua (CD).
Implantando um aplicativo monolítico como um contêiner
Há benefícios em usar contêineres para gerenciar implantações de aplicativos monolíticos. O dimensionamento de instâncias de contêiner é muito mais rápido e fácil do que a implantação de VMs adicionais. Mesmo se você usar conjuntos de dimensionamento de máquina virtual, as VMs levam tempo para iniciar. Quando implantado como instâncias de aplicativo tradicionais em vez de contêineres, a configuração do aplicativo é gerenciada como parte da VM, o que não é ideal.
A implantação de atualizações como imagens do Docker é muito mais rápida e eficiente na rede. As imagens do Docker normalmente começam em segundos, o que acelera as distribuições. Derrubar uma instância de imagem do Docker é tão fácil quanto emitir um docker stop comando e normalmente é concluído em menos de um segundo.
Como os contêineres são imutáveis por design, você nunca precisa se preocupar com VMs corrompidas. Por outro lado, os scripts de atualização para uma VM podem esquecer de levar em conta alguma configuração ou arquivo específico deixado no disco.
Embora os aplicativos monolíticos possam se beneficiar do Docker, estamos tocando apenas nos benefícios. Os benefícios adicionais do gerenciamento de contêineres vêm da implantação com orquestradores de contêineres, que gerenciam as várias instâncias e o ciclo de vida de cada instância de contêiner. Dividir o aplicativo monolítico em subsistemas que podem ser dimensionados, desenvolvidos e implantados individualmente é o seu ponto de entrada no domínio dos microsserviços.
Publicando um aplicativo baseado em contêiner único no Serviço de Aplicativo do Azure
Se você deseja obter a validação de um contêiner implantado no Azure ou quando um aplicativo é simplesmente um aplicativo de contêiner único, o Serviço de Aplicativo do Azure fornece uma ótima maneira de fornecer serviços escalonáveis baseados em contêiner único. Usar o Serviço de Aplicativo do Azure é simples. Ele fornece uma ótima integração com o Git para facilitar a captura do seu código, a criação dele no Visual Studio e a implantação diretamente no Azure.
Figura 4-4. Publicando um aplicativo de contêiner único no Serviço de Aplicativo do Azure a partir do Visual Studio 2022
Sem o Docker, se você precisasse de outros recursos, estruturas ou dependências sem suporte no Serviço de Aplicativo do Azure, teria que esperar até que a equipe do Azure atualizasse essas dependências no Serviço de Aplicativo. Ou você teve que mudar para outros serviços, como Serviços de Nuvem do Azure ou VMs, onde você tinha mais controle e podia instalar um componente ou estrutura necessária para seu aplicativo.
O suporte a contêineres no Visual Studio 2017 e posterior oferece a capacidade de incluir o que quiser em seu ambiente de aplicativo, como mostra a Figura 4-4. Como você está executando-o em um contêiner, se você adicionar uma dependência ao seu aplicativo, poderá incluir a dependência em sua imagem do Dockerfile ou do Docker.
Como também mostrado na Figura 4-4, o fluxo de publicação envia uma imagem por meio de um registro de contêiner. Pode ser o Registro de Contêiner do Azure (um registro próximo às suas implantações no Azure e protegido por grupos e contas do Azure Ative Directory) ou qualquer outro registro do Docker, como o Docker Hub ou um registro local.
