Usando contêineres do Windows para "contentorizar" aplicativos existentes

Aplica-se a: Windows Server 2025, Windows Server 2022, Windows Server 2019, Windows Server 2016

Os contêineres do Windows fornecem um ótimo mecanismo para modernizar aplicativos tradicionais ou herdados. Embora seja possível ouvir esta abordagem ser chamada de "elevar e mudar para contentores", a metáfora de "elevar e mudar" origina-se do processo de transferir cargas de trabalho de máquinas físicas para máquinas virtuais e é usada quando se fala em mover cargas de trabalho para a nuvem. Hoje, esse termo é aplicado de forma mais apropriada à migração de máquinas virtuais (VMs). Mas os contêineres não são VMs, e pensar neles como VMs pode levar a confusão sobre como um aplicativo é conteinerizado, ou se ele pode, ou deve, ser conteinerizado.

Este tópico fornece orientações práticas sobre como mover aplicativos tradicionais para contêineres do Windows. O objetivo é ajudá-lo a priorizar quais aplicativos devem ser conteinerizados, explicando considerações especiais antecipadamente.

Introdução

O que são e o que não são contêineres do Windows

O termo genérico container refere-se a uma tecnologia que virtualiza o sistema operacional (SO). Essa virtualização fornece um nível de isolamento do sistema operacional do próprio servidor/host, o que, por sua vez, permite mais agilidade para desenvolvedores de aplicativos e equipes de operações.

Os contêineres do Windows são uma implementação específica da tecnologia de contêiner. Eles fornecem instâncias de sistemas operacionais virtualizados que são isolados do sistema operacional Windows. Mas a interdependência total entre contêiner e host é impossível: um contêiner do Windows deve coordenar sua demanda por recursos e funções com o sistema operacional Windows. Por que isso é importante? Porque um contêiner do Windows não é um servidor virtualizado inteiro e algumas das coisas que você pode querer fazer com um aplicativo não podem ser feitas apenas com um sistema operacional virtualizado.

Você pode ler mais sobre este tópico em Containers vs. virtual machines. Mas alguns pontos positivos que ajudam você a lembrar a distinção entre contêiner e VM são:

• Os contêineres não são uma solução equivalente à virtualização de aplicativos de desktop. Eles suportam apenas aplicativos do lado do servidor que não exigem uma sessão interativa. Como são executados em imagens de contêiner especializadas, eles suportam apenas os aplicativos que não precisam de um front-end gráfico.
• Os contentores são efémeros por natureza. Isso significa que, por padrão, não há nenhum mecanismo para salvar o estado de uma instância de contêiner. Se uma instância falhar, outra instância tomará seu lugar.

A tecnologia de contêiner começou no Linux, com o Docker surgindo como padrão. A Microsoft trabalhou em estreita colaboração com o Docker para garantir que a funcionalidade do contêiner seja a mesma no Windows quanto for razoavelmente possível. As diferenças inerentes entre Linux e Windows podem surgir de maneiras que parecem ser limitações de contêineres do Windows quando, na verdade, são apenas as diferenças entre Linux e Windows. Por outro lado, os contêineres do Windows fornecem algumas implementações exclusivas, como isolamento Hyper-V, que serão abordadas posteriormente. Este tópico ajuda você a entender essas diferenças e como acomodá-las.

Benefícios da utilização de contentores

Assim como executar várias VMs em um único host físico, você pode executar vários contêineres em um único host físico ou virtual. Mas, ao contrário das VMs, você não precisa gerenciar o sistema operacional para um contêiner, o que lhe dá a flexibilidade de se concentrar no desenvolvimento de aplicativos e na infraestrutura subjacente. Isso também significa que você pode isolar um aplicativo para que ele não seja afetado por quaisquer outros processos suportados pelo sistema operacional.

Os contêineres fornecem um método leve de criar e interromper dinamicamente os recursos necessários para um aplicativo funcional. Embora seja possível criar e implantar VMs à medida que a demanda de aplicativos aumenta, é mais rápido usar contêineres para dimensionamento. Com contêineres, você também pode reiniciar rapidamente em caso de falha ou interrupção de hardware. Os contêineres permitem que você leve qualquer aplicativo do desenvolvimento à produção com pouca ou nenhuma alteração de código, pois eles "contêm" dependências de aplicativos para que funcionem em todos os ambientes. A capacidade de colocar em contêineres um aplicativo existente com alterações mínimas de código, devido à integração do Docker nas ferramentas de desenvolvedor da Microsoft, também é um fator poderoso no desenvolvimento e manutenção de aplicativos.

Finalmente, um dos benefícios mais importantes do uso de contêineres é a agilidade que você ganha para o desenvolvimento de aplicativos, já que você pode ter diferentes versões de um aplicativo em execução no mesmo host sem conflito de recursos.

Você pode encontrar uma lista mais completa dos benefícios do uso de contêineres para aplicativos existentes na página de documentação do Microsoft .NET.

Conceito importante de nível de isolamento

Os contêineres do Windows fornecem isolamento do sistema operacional Windows, isolamento que é vantajoso quando você está criando, testando e promovendo um aplicativo para produção. Mas a maneira como o isolamento é alcançado é importante para entender quando você está pensando em contentorizar um aplicativo.

Os contêineres do Windows oferecem dois modos distintos de isolamento de tempo de execução: de processo e Hyper-V. Os contêineres em ambos os modos são criados e gerenciados de forma idêntica e funcionam de forma idêntica. Então, quais são as diferenças e por que você deve se importar?

No isolamento de processos em , vários contentores são executados simultaneamente num único host, com o isolamento fornecido através de "namespace", controlo de recursos e outras funcionalidades. Os contêineres no modo de isolamento de processo compartilham o mesmo kernel com o host e uns com os outros. Isso é mais ou menos o mesmo que a maneira como os contêineres Linux são executados.

Em Hyper-Vde isolamento, vários contêineres também são executados simultaneamente em um único host, mas os contêineres são executados dentro de máquinas virtuais altamente otimizadas, com cada um efetivamente obtendo seu próprio kernel. A presença dessa máquina virtual – efetivamente uma VM "utilitária" – fornece isolamento no nível de hardware entre cada contêiner e o host do contêiner.

De certo modo, o modo de isolamento Hyper-V é quase como um híbrido de VM e contentor, fornecendo uma camada extra de segurança que é particularmente útil se a sua aplicação precisar de multitenancy. Mas as possíveis compensações ao usar o modo de isolamento Hyper-V incluem:

• Maior tempo de inicialização para o contêiner e um provável impacto no desempenho geral do aplicativo.
• Nem todas as ferramentas funcionam nativamente com isolamento Hyper-V.
• Nem o Serviço Kubernetes do Azure (AKS) nem o AKS no Azure Stack HCI suportam isolamento Hyper-V neste momento.

Você pode ler mais sobre como os dois modos de isolamento são implementados no tópico Modos de isolamento. Ao colocar um aplicativo em contêineres pela primeira vez, você precisará escolher entre os dois modos. Felizmente, é muito fácil mudar de um modo para outro mais tarde, pois não requer nenhuma alteração no aplicativo ou no contêiner. Mas esteja ciente de que, quando você contentoriza um aplicativo, escolher entre os dois modos é uma das primeiras coisas que você terá que fazer.

Orquestração de contêineres

A capacidade de executar vários contêineres em um único ou vários hosts sem se preocupar com o gerenciamento do sistema operacional oferece grande flexibilidade, ajudando você a avançar para uma arquitetura baseada em microsserviços. Uma contrapartida para essa flexibilidade, no entanto, é que um ambiente baseado em contêineres e microsserviços pode rapidamente se transformar em muitas partes móveis – muitas para acompanhar. Felizmente, gerenciar o balanceamento de carga, a alta disponibilidade, o agendamento de contêineres, o gerenciamento de recursos e muito mais é o papel de um orquestrador de contêineres.

Os orquestradores talvez estejam mal nomeados; são mais como os maestros de uma orquestra, na medida em que coordenam a atividade de vários contentores para manter a música a tocar. Em certo sentido, eles lidam com o agendamento e a alocação de recursos para contêineres de forma semelhante ao funcionamento de um sistema operacional. Assim, à medida que você se move para contentorizar seus aplicativos, você precisará escolher entre os orquestradores que suportam contêineres do Windows. Alguns dos mais comuns são Kubernetes e Docker Swarm.

O que não pode ser movido para contêineres do Windows

Quando você considera se um aplicativo pode ser conteinerizado ou não, provavelmente é mais fácil começar com a lista de fatores que descartam completamente os contêineres do Windows como uma opção.

A tabela a seguir resume os tipos de aplicativos que não podem ser movidos para contêineres do Windows e por que não. As razões são explicadas mais detalhadamente nas subsecções após o quadro. Entender os motivos dessas limitações pode dar uma ideia mais clara do que os contêineres realmente são, incluindo como eles diferem das VMs. Isso, por sua vez, ajudará você a avaliar melhor os recursos dos contêineres do Windows que você pode aproveitar com os aplicativos existentes que você pode colocar em contêineres.

Nota: A lista abaixo não é uma lista completa. Em vez disso, é uma compilação de aplicativos que a Microsoft viu os clientes tentarem colocar em contêineres.

Aplicações/funcionalidades não suportadas	Porque não é suportado?	Você pode contornar isso?
Aplicações que requerem um ambiente de trabalho	Os contêineres não suportam GUI (Graphic User Interface, interface gráfica do usuário)	Se o aplicativo requer apenas uma GUI para instalar, alterá-lo para uma instalação silenciosa pode ser uma solução
Aplicações que utilizam o protocolo RDP (Remote Desktop Protocol)	O PDR destina-se a sessões interativas, pelo que o princípio acima também se aplica aqui	Talvez você possa usar o Windows Admin Center (WAC) ou o PowerShell Remoto como uma alternativa para gerenciamento remoto
Aplicações com estado	Os contentores são efémeros	Sim, alguns aplicativos podem exigir alterações mínimas, portanto, não armazenam dados ou estado dentro do contêiner
Aplicações de bases de dados	Os contentores são efémeros	Sim, alguns aplicativos podem exigir alterações mínimas, portanto, não armazenam dados ou estado dentro do contêiner
Diretório Ativo	O design e a finalidade do Ative Directory impedem a execução em um contêiner	Não. No entanto, os aplicativos dependentes do Ative Directory podem usar Contas de Serviço Gerenciado de Grupo (gMSA). Mais informações sobre gMSA são fornecidas abaixo
Versões mais antigas do Windows Server	Apenas o Windows Server 2016 ou posterior é suportado	Não. No entanto, a compatibilidade de aplicativos pode ser uma opção – a maioria dos aplicativos do Windows Server 2008/R2 e mais antigos são executados em versões mais recentes do Windows Server
Aplicativos que usam o .NET Framework versão 2.0 ou anterior	Imagens de contêiner específicas são necessárias para dar suporte ao .NET Framework e apenas versões mais recentes são suportadas	As versões anteriores à 2.0 não são suportadas, mas veja abaixo as imagens de contêiner necessárias para versões posteriores
Aplicativos que usam outras estruturas de terceiros	A Microsoft não certifica ou oferece suporte específico ao uso de estruturas que não sejam da Microsoft em contêineres do Windows	Verifique com o fornecedor da estrutura ou aplicativo específico a política de suporte para contêineres do Windows. Veja abaixo mais informações

Vamos considerar cada uma dessas limitações por vez.

Aplicações que requerem um ambiente de trabalho

Os contêineres são ideais para funções efêmeras que são invocadas de outros aplicativos, incluindo aqueles com interações do usuário. Mas você não pode usá-los para aplicativos que têm GUIs próprios. Isso é verdade mesmo se o aplicativo em si não tiver uma GUI, mas tiver um instalador que depende de uma GUI. Em geral, o Windows Installer pode ser invocado usando o PowerShell, mas se seu aplicativo exigir instalação por meio de uma GUI, esse requisito o eliminará como um candidato para conteinerização.

Isso não é um problema com a forma como os contêineres do Windows foram implementados, mas sim um conceito fundamental de como os contêineres funcionam.

É uma questão diferente se um aplicativo precisa de APIs GUI. As APIs são suportadas mesmo que a GUI servida por essas APIs não seja. Isso é explicado mais detalhadamente no tópico Nano Server x Server Core x Server - Qual imagem base é a certa para você?

Aplicações que utilizam RDP

Como todo o objetivo do RDP (Remote Desktop Protocol) é estabelecer uma sessão visual interativa, a limitação de GUI descrita também se aplica. Um aplicativo que usa RDP não pode ser conteinerizado as-is.

No entanto, uma boa alternativa é uma ferramenta de gerenciamento remoto, como o Windows Admin Center. Você pode usar o Windows Admin Center para gerir os hosts de contêineres do Windows e os próprios contêineres, sem a necessidade de aceder via RDP. Você também pode abrir uma sessão remota do PowerShell para o host e/ou contêineres para gerenciá-los.

Aplicações com estado

Os aplicativos que precisam preservar dados de estado podem ser conteinerizados somente se você isolar os dados necessários de uma sessão para a próxima e armazená-los em armazenamento persistente. Isso pode exigir alguma "rearquitetura", que pode ou não ser trivial, mas prosseguir com isso eliminará essa barreira à conteinerização.

Um exemplo de estado é uma aplicação Web que armazena imagens ou ficheiros de música numa pasta local. Em um ambiente Windows tradicional, um arquivo é salvo no disco no momento em que a operação de gravação é concluída, portanto, se a instância (uma VM, neste caso) falhar, basta trazê-lo de volta e o arquivo ainda estará lá. Por outro lado, se uma instância de contêiner que executa uma operação de gravação falhar, a nova instância de contêiner não incluirá esse arquivo. Por esse motivo, você deve considerar o uso de armazenamento persistente para que todas as instâncias de contêiner possam armazenar dados ou arquivos de estado em um local centralizado e durável. Esse tipo de rearquitetura não exige que você altere o código do aplicativo, apenas o tipo de armazenamento usado pela instância do Windows. Para obter mais informações, consulte a documentação do container Windows sobre armazenamento.

No entanto, isso traz outro tópico relacionado...

Aplicações de bases de dados

Como regra geral, os aplicativos de banco de dados não são ótimos candidatos para a conteinerização. Embora você possa executar um banco de dados dentro de um contêiner, a conteinerização de um banco de dados existente geralmente não é ideal, por dois motivos.

Primeiro, o desempenho necessário para um banco de dados pode exigir todos os recursos de hardware disponíveis para o host – o que desvaloriza o benefício da consolidação. Em segundo lugar, várias instâncias de uma única camada de banco de dados precisam de coordenação para suas operações de gravação. A orquestração de contêineres pode resolver isso, mas para bancos de dados existentes, a orquestração pode se tornar uma sobrecarga. A maioria dos bancos de dados, como o Microsoft SQL Server, tem um balanceamento de carga interno e um mecanismo de alta disponibilidade.

Funções de infraestrutura no Windows Server

As funções de infraestrutura do Windows Server lidam principalmente com funções mais próximas do sistema operacional (por exemplo, AD, DHCP e Servidor de Arquivos). Como tal, eles não estão disponíveis para contêineres em execução. Portanto, os aplicativos que precisam dessas funções sempre serão difíceis de conteinerizar.

Existem algumas áreas cinzentas. Por exemplo, alguns recursos, como o DNS, podem funcionar em contêineres do Windows, mesmo que não se destinem a ser usados em contêineres. Outras funções de infraestrutura são simplesmente removidas da imagem de contêiner base e não podem ser instaladas, como Ative Directory, DHCP e outras.

Ative Directory (AD)

O Ative Directory foi lançado há mais de vinte anos junto com o Windows 2000 Server. Ele usa um mecanismo no qual cada dispositivo ou usuário é representado por um objeto armazenado em seu banco de dados. Essa relação é fortemente acoplada e os objetos são mantidos no banco de dados, mesmo que o usuário ou dispositivo real não esteja mais em jogo. Essa abordagem para o Ative Directory contradiz diretamente a natureza efêmera dos contêineres, que devem ser de curta duração ou excluídos quando desativados. Manter essa relação um-para-um com o Ative Directory não é ideal para esses cenários.

Por esse motivo, os contêineres do Windows não podem ser associados ao domínio. Como efeito disso, não é possível executar os Serviços de Domínio Ative Directory como uma função de infraestrutura em contêineres do Windows. Você pode executar o módulo PowerShell para gerenciar controladores de domínio remotamente dentro de um contêiner do Windows.

Para aplicativos executados em contêineres do Windows dependentes do Ative Directory, use Contas de Serviço Gerenciado de Grupo (gMSA), que serão explicadas mais detalhadamente.

Aplicativos que usam o .NET Framework versão 2.0 ou anterior

Se seu aplicativo requer o .NET, sua capacidade de conteinerizar depende inteiramente da versão do .NET Framework que ele usa. Qualquer versão anterior ao .NET Framework 2.0 não é suportada; versões superiores requerem o uso de imagens específicas, conforme descrito mais adiante.

Aplicativos que usam estruturas de terceiros (não Microsoft)

De um modo geral, a Microsoft não consegue certificar estruturas ou aplicativos de terceiros ou oferecer suporte à execução em contêineres do Windows – ou máquinas físicas e virtuais. No entanto, a Microsoft realiza seus próprios testes internos de usabilidade de várias estruturas e ferramentas de terceiros, incluindo Apache, Cassandra, Chocolatey, Datadog, Django, Flask, Git, Golang, JBoss, Jenkins, Rust, Nodejs, Pearl, Python, Ruby, Tomcat e muitos outros.

Para qualquer estrutura ou software de terceiros, valide sua capacidade de suporte em contêineres do Windows com o fornecedor que o fornece.

Candidatos ideais para contentorização

Agora que consideramos as limitações rígidas de aplicativos em contêineres, é mais fácil ver quais tipos de aplicativos se prestam mais facilmente aos contêineres do Windows. Os candidatos ideais para contêineres do Windows, e quaisquer considerações especiais para conteinerizá-los, estão na tabela a seguir.

Tipo de aplicação	Porque é que estes são bons candidatos	Considerações especiais
Aplicações de consola	Sem limitações de GUI, os aplicativos de console são candidatos ideais para contêineres.	Use a imagem de contêiner base apropriada dependendo das necessidades do aplicativo.
Serviços do Windows	Porque estes são processos em segundo plano que não requerem qualquer interação direta do usuário	Use a imagem de contêiner base apropriada dependendo das necessidades do aplicativo. Você precisa criar um processo em primeiro plano para manter qualquer processo em segundo plano conteinerizado em execução. Consulte a secção sobre Serviços de fundo abaixo.
Serviços do Windows Communication Foundation (WCF)	Porque são aplicações orientadas para serviços que também são executadas em segundo plano	Use a imagem de contêiner base apropriada dependendo das necessidades do aplicativo. Talvez seja necessário criar um processo em primeiro plano para manter qualquer processo em segundo plano conteinerizado em execução. Consulte a secção sobre Serviços de fundo abaixo.
Aplicações Web	Os aplicativos Web são, em essência, serviços em segundo plano escutando em uma porta específica e, portanto, são ótimos candidatos para a conteinerização, pois aproveitam a escalabilidade oferecida pelos contêineres	Use a imagem de contêiner base apropriada dependendo das necessidades do aplicativo.

Observação: mesmo esses candidatos ideais para a conteinerização podem depender dos principais recursos e componentes do Windows que precisarão ser manipulados de forma diferente nos contêineres do Windows. A próxima seção, que entra em mais detalhes sobre essas considerações práticas, irá prepará-lo melhor para aproveitar a funcionalidade dos contêineres do Windows.

Considerações práticas para aplicações que podem ser conteinerizadas

Os projetos de renovação de aplicativos geralmente levam em conta se um aplicativo específico pode ser conteinerizado através da perspetiva da função de negócios do aplicativo. Mas a funcionalidade do negócio não é o fator que determina se é tecnicamente possível. O que é importante é a arquitetura do aplicativo, ou seja, em quais componentes técnicos ele depende. Portanto, não há uma resposta fácil para uma pergunta como "Posso contentorizar meu aplicativo de RH?" porque não é o que o aplicativo está fazendo, é como (e quais componentes/serviços do Windows ele usa) que faz a diferença.

Essa é uma distinção importante, porque se seu aplicativo não for criado com uma arquitetura de microsserviços para começar, é provável que seja mais difícil de conteinerizar. À medida que você procede à conteinerização, certos recursos podem precisar de manuseio especial. Alguns podem ser devido ao uso pelo aplicativo de componentes e estruturas principais do Windows que não são suportados em contêineres do Windows. Outros, como o registo de eventos e a monitorização, devem-se a diferenças inerentes entre Linux e Windows que se tornam aparentes apenas quando você contentoriza a aplicação. Outros ainda, como tarefas agendadas e serviços em segundo plano, devem ser entendidos da perspetiva de que um contêiner não é uma VM, mas é efêmero e, portanto, precisa de tratamento especial.

A tabela a seguir apresenta um resumo rápido dos componentes/recursos de aplicativos que precisam de consideração especial quando você está pensando em conteinerização. As subseções a seguir fornecem mais detalhes, incluindo exemplos que ilustram técnicas para lidar com cada cenário. Embora a lista abaixo abranja cenários suportados em contêineres do Windows, esses cenários ainda precisam respeitar as orientações do capítulo anterior. Por exemplo, enquanto os serviços em segundo plano são suportados, a execução de um serviço em segundo plano no .NET Framework 1.1 não é suportada.

Funcionalidade/componente do Windows que requer um manuseamento especial	Justificação
Fila de mensagens da Microsoft (MSMQ)	O MSMQ se originou muito antes dos contêineres e nem todos os seus modelos de implantação para filas de mensagens são compatíveis com a arquitetura de contêineres.
Coordenador de Transações Distribuídas da Microsoft (MSDTC)	A resolução de nomes entre MSDTC e o contêiner requer consideração especial.
IIS	O IIS é o mesmo que em uma VM, mas há considerações importantes ao executá-lo em um ambiente de contêiner, como gerenciamento de certificados, cadeias de conexão de banco de dados e muito mais.
Tarefas agendadas	Os contêineres do Windows podem executar tarefas agendadas, assim como qualquer instância do Windows. No entanto, talvez seja necessário executar uma tarefa em primeiro plano para manter a instância do contêiner em execução. Dependendo do aplicativo, convém considerar uma abordagem orientada a eventos.
Serviços em segundo plano	Como os contêineres são executados como processos efêmeros, você precisará de manipulação adicional para manter o contêiner em execução.g
.NET Framework e .NET (anteriormente .Net Core)	Certifique-se de usar a imagem certa para garantir a compatibilidade, conforme explicado na subseção abaixo.

Outros componentes de suporte

Componente que requer manuseamento especial	Justificação	Abordagem alternativa
Registo/monitorização de eventos	Porque a maneira como o Windows grava eventos e logs é inerentemente diferente do Linux stdout	Use a nova ferramenta Log Monitor para normalizar os dados e combinar a partir do Linux e do Windows.
Segurança de contêineres do Windows	Embora muitas práticas de segurança permaneçam as mesmas, os contêineres exigem medidas de segurança adicionais.	Utilize uma ferramenta de registo e digitalização de imagens criada especificamente para o efeito – mais detalhes mais tarde.
Cópia de segurança de contentores do Windows	Os contêineres não devem ter dados ou estados	Faça backup de qualquer armazenamento persistente usado por contêineres, bem como imagens de contêiner.

Componentes/recursos do Windows

Agora vamos mergulhar nos detalhes de aplicativos e componentes que podem ser conteinerizados, mas exigem manuseio adicional.

MSMQ

Se seu aplicativo depende do MSMQ, se você pode conteinerizá-lo depende de seu cenário de implantação do MSMQ. O MSMQ inclui várias opções de implantação. Os fatores de filas privadas versus públicas, transacionais ou não, e o tipo de autenticação formam uma matriz de cenários que o MSMQ foi originalmente projetado para suportar. Nem todos eles podem ser facilmente movidos para contêineres do Windows. A tabela a seguir lista os cenários suportados:

Âmbito de aplicação	Transacional?	Localização da fila	Tipo de autenticação	Enviar e receber?
Privado	Sim	Mesmo recipiente (recipiente único)	Anônimo	Sim
Privado	Sim	Volume persistente	Anônimo	Sim
Privado	Sim	Controlador de Domínio	Anônimo	Sim
Privado	Sim	Anfitrião único (dois contentores)	Anônimo	Sim
Público	Não	Dois anfitriões	Anônimo	Sim
Público	Sim	Dois anfitriões	Anônimo	Sim

Algumas notas sobre esses cenários suportados, que foram validados pelas equipes de desenvolvimento internas da Microsoft:

• Modo de isolamento: o modo de processo e o modo de Hyper-V para isolamento funcionam com os cenários listados acima.
• SO mínimo e imagem de contêiner: A versão mínima do sistema operacional recomendada para uso com o MSMQ é o Windows Server 2019.
• Volumes persistentes: os cenários acima foram validados executando o MSMQ no Serviço Kubernetes do Azure (AKS) usando arquivos do Azure para armazenamento persistente.

Ao juntar essas considerações com a tabela acima, você pode ver que o único cenário sem suporte é para filas que exigem autenticação com o Ative Directory. A integração de gMSAs (Contas de Serviço Gerenciado de Grupo) com o MSMQ não é suportada no momento, pois o MSMQ tem dependências no Ative Directory que ainda não estão em vigor.

Como alternativa, use o Barramento de Serviço do Azure em vez do MSMQ. O Barramento de Serviço do Azure é um agente de mensagens empresarial totalmente gerenciado com filas de mensagens e tópicos de publicação-assinatura (em um namespace). Mudar do MSMQ para o Barramento de Serviço do Azure requer alterações de código e rearquitetura de aplicativos, mas lhe dará a agilidade necessária para migrar para uma plataforma moderna.

MSDTC

O Microsoft Distributed Transaction Coordinator (MSDTC) é muito usado em aplicativos herdados do Windows entre grandes empresas. O MSDTC pode ser instalado em Contêineres do Windows, mas há determinados cenários que não funcionam e não podem ser reproduzidos em Contêineres do Windows.

• Ao criar o contêiner, certifique-se de passar o parâmetro --name para o comando docker run. Esse parâmetro name é o que permite que os contêineres se comuniquem pela rede docker. Se estiver usando gMSA, o nome deve corresponder ao nome do host, que deve corresponder ao nome da conta gMSA.
  • Aqui está um exemplo do comando run com gMSA:

docker run -d --security-opt "credentialspec=file://contoso_webapp01.json" --hostname webapp01 -- name webapp01 mcr.microsoft.com/windows/servercore:ltsc2022

• Os contêineres devem ser capazes de resolver uns aos outros usando o nome NETBIOS. Se houver alguma dificuldade com isso, a melhor maneira de resolver é adicionar o nome e o ip dos contêineres aos arquivos host uns dos outros.
• O uuid para msdtc em ambos os contêineres deve ser exclusivo. O uuid pode ser encontrado executando "Get-Dtc" no PowerShell nos contêineres. Se eles não forem exclusivos, uma maneira de resolver é desinstalando e reinstalando o msdtc em um dos contêineres. Estes comandos PowerShell podem ser usados – "uninstall-dtc", "install-dtc".
• Atualmente, o MSDTC não tem suporte nos Serviços Kubernetes do Azure. Se tiver uma necessidade específica de executar o MSDTC no AKS, informe a equipa de containers do Windows ao abrir uma issue no repositório de containers do Windows no GitHub.

Como o IIS funciona em um contêiner versus uma VM

O IIS funciona da mesma forma em um contêiner do Windows como em uma VM. No entanto, há alguns aspetos da execução de uma instância do IIS que devem ser considerados ao executar em um ambiente de contêiner:

• Armazenamento persistente para dados locais: as pastas nas quais o aplicativo grava/lê arquivos de/para são um ótimo exemplo de algo que você manteria em uma VM para uma instância do IIS. Com contêineres, você não quer que nenhum dado seja gravado diretamente no contêiner. Os contêineres usam um "espaço de rascunho" para armazenamento local e, quando um novo contêiner surge para a mesma aplicação, ele não tem acesso a essa área a partir de um contêiner anterior. Por esse motivo, use o armazenamento persistente para dados que precisam estar acessíveis ao aplicativo Web, para que qualquer instância de contêiner possa ter acesso a esse armazenamento.
• Certificados: Embora você possa ter certificados locais em instâncias de contêiner, evite fazer isso, porque se um certificado precisar ser atualizado, será necessário reconstruir sua imagem de contêiner. Como alternativa, você pode usar um orquestrador de contêiner com controle Ingress. Os controladores de entrada podem aplicar políticas de rede e também lidar com o gerenciamento de certificados para o site que está sendo hospedado por trás dele. A vantagem é que você dissocia o gerenciamento do ciclo de vida do certificado do gerenciamento do site.
• Cadeias de conexão de banco de dados: para a implantação tradicional do IIS, você pode passar a cadeia de conexão de banco de dados como parte da implantação do aplicativo. Embora os contêineres do Windows permitam que você siga esse modelo, convém considerar o desacoplamento da cadeia de conexão de banco de dados do contêiner para uma configuração centralizada fornecida pelo orquestrador de contêiner, a partir do qual o aplicativo pode ler. Isso permite que você gerencie e atualize a cadeia de conexão de banco de dados independentemente do aplicativo. Se o banco de dados mudar (para casos de Lift e Shift para a nuvem, por exemplo), você poderá alterar facilmente a cadeia de conexão sem reconstruir a imagem do contêiner. Essa abordagem também permite que você mantenha segredos (como nome de usuário e senha para se conectar ao banco de dados) em um armazenamento secreto.
• Escalonamento automático horizontal: Quando a carga aumenta, os sistemas de computação tendem a diminuir o desempenho observado devido à tentativa de processar as solicitações simultâneas. Geralmente, há duas maneiras de evitar o impacto no desempenho: escala vertical ou horizontal. A escala vertical aumenta os recursos disponíveis para as instâncias de computação existentes (mais CPU, memória, etc.). A escala horizontal aumenta o número de instâncias que dão suporte às solicitações (mais hosts físicos, VMs ou contêineres). Para camadas da Web, como o IIS, a escala horizontal tende a ser mais eficiente do que a vertical, mas os ambientes locais podem encontrar limitações de recursos e problemas de balanceamento de carga. Com ambientes de nuvem, a escala horizontal é muito mais fácil, pois os recursos estão prontamente disponíveis (por um custo adicional) e o provedor de nuvem normalmente projeta seu mecanismo de balanceamento de carga com a escala horizontal em mente. Os contêineres do Windows podem aproveitar a escala horizontal para o IIS, mas o aspeto efêmero dos contêineres desempenha um papel importante. É imperativo que seus contêineres tenham a mesma configuração e que nenhum estado ou dados sejam armazenados para permitir aumentar ou diminuir o número de instâncias que suportam seu aplicativo Web.

Tarefas agendadas

As tarefas agendadas são usadas para chamar um programa, serviço ou script a qualquer momento em um ambiente Windows. Tradicionalmente, você tem uma instância do Windows em execução o tempo todo e, quando um gatilho é atendido, a tarefa é executada. Isso é possível com contêineres do Windows e, além do fato de que você precisa configurar e gerenciar tarefas agendadas por meio do Azure PowerShell, eles funcionam exatamente da mesma forma.

Com uma abordagem de microsserviços, no entanto, você tem algumas opções para evitar manter um contêiner em execução para aguardar um gatilho:

• Use um PaaS (Plataforma como Serviço) controlado por eventos, como o Azure Function, para armazenar seu código e definir um gatilho para esse aplicativo. O Azure Functions até dá suporte a imagens de contêiner do Windows para serem executadas quando um gatilho é atendido.
• Use contêineres do Windows em conjunto com um orquestrador de contêineres. O contêiner pode ser executado somente quando o gatilho é atendido e chamado de outras partes do aplicativo. Nesse caso, o orquestrador de contêiner manipulará o agendamento e o gatilho para o aplicativo.
• Finalmente, mantenha um contêiner do Windows em execução para executar uma tarefa agendada. Você precisará de um serviço de primeiro plano (como o Monitor de Serviço) para manter o contêiner em execução.

Serviços em segundo plano

Embora os contêineres sejam geralmente para processos efêmeros, você pode colocar em contêineres um aplicativo em segundo plano e de longa execução, desde que crie um processo em primeiro plano para iniciá-lo e mantê-lo em execução.

Um ótimo exemplo disso é o ServiceMonitor, que é um executável do Windows projetado para ser usado como um processo de ponto de entrada ao executar o IIS em contêineres. Embora tenha sido criada para o IIS, a ferramenta ServiceMonitor oferece um modelo que também pode ser usado para monitorar outros serviços, com algumas limitações.

Para obter mais informações sobre o ServiceMonitor, consulte a documentação do no Github.

.NET Framework e .NET

Os contêineres do Windows oferecem suporte ao .NET Framework e ao .NET (anteriormente, .NET Core). A equipe do .NET cria suas próprias imagens oficiais para ambas as estruturas sobre as imagens de contêiner base do Windows. Escolher a imagem apropriada é fundamental para garantir a compatibilidade. A equipa do .NET fornece imagens do .NET Framework baseadas na imagem do contêiner do Server Core e imagens do .NET baseadas nas imagens do contêiner do Server Core e do Nano Server. O Server Core tem um conjunto de APIs maior do que o Nano Server, o que permite maior compatibilidade, mas também um tamanho de imagem maior. O Nano Server tem uma superfície de API severamente reduzida, mas um tamanho de imagem muito menor.

Em alguns casos, talvez seja necessário criar sua própria imagem do .NET Framework ou .NET sobre as imagens de contêiner base do Windows ou do Server. Isso pode ser necessário se seu aplicativo tiver não apenas uma dependência de estrutura, mas uma dependência de sistema operacional. Você poderá detetar tais dependências testando seu aplicativo com uma imagem de contêiner de base específica.

Por exemplo, as imagens de contêiner base Server Core e Nano Server têm apenas uma fonte disponível, para reduzir o tamanho da imagem. Se o seu aplicativo exigir uma fonte diferente, você terá que instalar essa fonte ou usar as imagens do Servidor ou do Windows, que têm uma API maior definida e incluem todas as fontes padrão do Windows. Do ponto de vista da compatibilidade, isso permite que praticamente qualquer aplicativo (desde que respeite a natureza dos contêineres, como no-GUI) seja conteinerizado. No lado negativo, eles serão muito maiores em tamanho, o que pode afetar o desempenho.

Ao validar se o aplicativo a ser conteinerizado funciona em contêineres do Windows, a Microsoft recomenda o seguinte:

Para este quadro	Teste primeiro com esta imagem de contêiner	Usar esta imagem de contêiner se a primeira não funcionar	Imagem base
.NET Framework versões 2.X e 3.X	.NET Framework 4.x	.NET Framework 3.5	Núcleo do Windows Server
Versões do .NET Framework 4.x	.NET Framework 4.x	Crie sua imagem de contêiner do .NET Framework com imagens do Servidor ou do Windows	Núcleo do Windows Server
.NET 6 ou 7	.NET 6 ou 7, respectivamente	Crie sua imagem de contêiner .NET com imagens base do Windows ou do Server	Windows Nano Server ou Server Core

Outros componentes de suporte

Os componentes e tópicos abaixo fornecem orientações adicionais para itens que acompanham ou que proporcionam melhor clareza em contentores do Windows.

Registo de eventos

Windows e Linux usam métodos diferentes para armazenar e apresentar logs e eventos para seus usuários. Tradicionalmente, o Windows utiliza o formato EVT, que pode ser visualizado de forma estruturada no Visualizador de Eventos. O Linux, por outro lado, forneceu uma abordagem simplificada com Standard Output (stdout) na qual outras ferramentas, como o Docker, confiam.

O Docker sempre teve um mecanismo para extrair logs de contêineres Linux. Usando o comando "docker logs" com uma configuração stdout padrão, o Docker traz os logs do aplicativo para fora do contêiner sem abri-lo interativamente. Até o lançamento da ferramenta Log Monitor, no entanto, a mesma técnica não funcionava no Windows.

A ferramenta Log Monitor apresenta os logs do Windows no formato stdout para que outras ferramentas, como o Docker, possam reunir as informações necessárias para exibi-los. Os benefícios adicionais de usar o Log Monitor incluem:

• Ser capaz de filtrar quais tipos de eventos/logs você deseja expor no stdout. Por exemplo, você pode filtrar o log do aplicativo para mensagens de "erro" e "aviso" somente se não estiver interessado em eventos de "informação".
• A capacidade de escolher entre Logs de Eventos, Ficheiros de Log Personalizados ou Rastreamento de Eventos no Windows (ETW). Isso é particularmente útil se seu aplicativo estiver gravando em uma fonte de log diferente. Um exemplo disso são os logs do IIS localizados na pasta "C:\inetpub".
• O facto de o Log Monitor fazer com que os contentores do Windows se comportem muito como contentores Linux e, portanto, ferramentas que procuram pela saída padrão e interagem com a função de tempo de execução do contentor funcionem conforme o esperado. Por exemplo, se mudar do Docker para o ContainerD como runtime do contêiner, os logs devem continuar visíveis a partir do host do contêiner através, por exemplo, de "crictl logs".

Você pode ler mais sobre a ferramenta Log Monitor em esta postagem de blog.

Segurança de contêineres do Windows

Os contêineres do Windows são criados na mesma base que as instâncias do Windows executadas em máquinas físicas ou virtuais. Compreender as especificidades de como os contêineres são implementados, especialmente sua natureza de kernel compartilhado, ajuda a proteger um aplicativo conteinerizado:

• Componentes compartilhados. Os contêineres do Windows compartilham alguns dos componentes do host para fins de segurança. Isso inclui o Firewall do Windows, o Windows Defender (Antivírus) e outras limitações de acesso a recursos. Não é necessário configurar esses componentes diretamente no contêiner porque o host do contêiner faz os ajustes necessários com base na carga de trabalho do contêiner. Por exemplo, se o contêiner fizer uma solicitação da Web, o host do contêiner encaminhará o tráfego necessário através de seu firewall para que o contêiner possa acessar a Web.
• Modo de isolamento. Conforme discutido, os contentores do Windows podem ser implantados no modo de isolamento de processo ou no modo Hyper-V, com Hyper-V fornecendo o isolamento mais seguro. No isolamento do processo, o contêiner compartilha seu kernel, sistema de arquivos e registro com o host, o que permite que um processo elevado (admin) interaja com os processos e serviços do contêiner. Escolher o modo de isolamento correto para seu aplicativo é importante para garantir o modelo de segurança apropriado.
• Atualizações do Windows. Como a pilha de serviços não está presente nos contêineres do Windows, os contêineres do Windows não recebem atualizações como instâncias gerais do Windows. Em vez disso, você precisa reconstruir contêineres do Windows usando a imagem de contêiner base mais recente disponível. Os clientes podem aproveitar os pipelines de DevOps para essa finalidade. A Microsoft atualiza as imagens de contentor base para todas as suas imagens oficiais todos os meses, seguindo a cadência do Patch Tuesday.
• Conta de usuário do contêiner. Por padrão, os aplicativos dentro de contêineres do Windows são executados com privilégios elevados na conta de usuário ContainerAdmin. Isso é útil para instalar e configurar os componentes necessários dentro da imagem do contêiner. No entanto, você deve considerar alterar a conta de usuário para ContainerUser ao executar um aplicativo que não requer os privilégios elevados. Para cenários específicos, você também pode criar uma nova conta com os privilégios apropriados.
• Digitalização de imagens e execução em tempo real. Os contêineres exigem que as imagens em repositórios e instâncias de contêineres sejam seguras. A Microsoft recomenda que você use o Microsoft Defender for Containers para verificação de imagens e verificação de tempo de execução. O Defender for Containers oferece suporte a contêineres do Windows para avaliação de vulnerabilidades com verificação de registro e proteção de tempo de execução com deteção de ameaças.

Mais informações sobre os tópicos acima podem ser encontradas na página de documentação de contentores do Windows.

Cópia de segurança de contentores do Windows

Você precisa pensar em backups de forma diferente ao usar contêineres. Como discutido anteriormente, um contêiner não deve ser usado para armazenar estado ou dados, dada sua natureza efêmera. Se separar o estado e os dados da instância do contêiner, as suas preocupações com backup estarão fora do tempo de vida da instância do contêiner, que pode ser substituída por uma nova instância para a qual todo o armazenamento persistente necessário continuará disponível.

No entanto, ainda há componentes que você é responsável por fazer backup; incluindo o aplicativo, a imagem do contêiner e o dockerfile que cria a imagem do contêiner. A maioria dessas operações é tratada pela plataforma na qual você executa suas cargas de trabalho de produção e desenvolvimento. Ao adotar uma abordagem de DevOps, considere os casos mais comuns:

• Aplicativo: Seu aplicativo provavelmente reside em um repositório de origem, como o GitHub ou o Azure DevOps. Esses repositórios fornecem controle de versão, que permite reverter para uma versão específica do aplicativo. Se você possui o repositório de origem, siga as recomendações de backup e gerenciamento.
• Imagem de contêiner: para ambientes de produção, sua imagem de contêiner deve viver em um repositório de imagens centralizado, como o Azure Container Registry (ACR). Você pode enviar as suas imagens de contentor para o ACR para que sejam disponibilizadas, de modo que outros hosts as possam obter. O ACR lida com a disponibilidade das imagens de contêiner e serve como uma opção de backup – no entanto, lembre-se de que, embora o ACR lide com a disponibilidade da imagem, ele não impede que uma imagem seja excluída ou substituída. Para qualquer outro repositório de imagens local ou no local, siga a recomendação do fornecedor para fazer backup de registos existentes.
• Dockerfile: Os Dockerfiles criam novas imagens de contêiner e geralmente são armazenados junto com a fonte do aplicativo. Como o dockerfile pode não ter sido criado com o aplicativo, especialmente se for um aplicativo existente que está sendo conteinerizado, você é responsável por garantir que o dockerfile seja armazenado em um local seguro e com backup. Você também deve garantir que todos os outros ativos necessários para que seu aplicativo funcione em um contêiner sejam submetidos a backup; por exemplo: os arquivos YAML e JSON para modelos Kubernetes, Docker Swarm e Azure ARM seguem as mesmas diretrizes acima.

Planear o processo de elevação e mudança

Depois de avaliar a prontidão do seu aplicativo para a conteinerização, use as seguintes orientações gerais para planejar o processo:

1. Determine a imagem base do sistema operacional Windows de que você precisa: Windows Server Core, Nano Server, Windowsou Server imagens.
2. Determine o tipo de modo de isolamento para o contentor: escolha entre os modos de isolamento de processo ou Hyper-V. Nota: Atualmente, o AKS e o AKS no Azure Stack HCI suportam apenas contentores isolados por processos. Em uma versão futura, o AKS e o AKS no Azure Stack HCI também darão suporte a contêineres isolados do Hyper-V. Para obter mais informações, consulte Modos de Isolamento.
3. Escolha a versão correta do Windows Server para seu aplicativo para fins de compatibilidade de aplicativos. A versão mínima do Windows Server para contêineres é o Windows Server 2016, mas o Windows Server 2019 e o Windows Server 2022 são os únicos sistemas operacionais de host de contêiner com suporte no AKS e AKS no Azure Stack HCI.
4. Certifique-se de que as políticas de segurança da sua empresa estão em vigor para o ambiente de contêineres. Isso inclui a adaptação aos requisitos específicos do contêiner, como verificação de registro e deteção de ameaças.
5. Considere as necessidades de balanceamento de carga. Os contentores em si não se movem; Em vez disso, você pode usar um Orchestrator para iniciar ou parar automaticamente contêineres em nós de cluster ou para gerenciar alterações na carga e disponibilidade com escala horizontal automática.
6. Considere as necessidades de orquestração. Uma vez conteinerizado, seu aplicativo provavelmente precisa de gerenciamento automatizado disponível com ferramentas como Kubernetes, AKS ou AKS no Azure Stack HCI. Consulte a secção Visão Geral da Orquestração de Contentores do Windows para uma discussão completa e um guia para escolher entre as ferramentas.
7. Containerizar a aplicação.
8. Envie o aplicativo para um repositório de imagens. Isso permitirá que os hosts de contêiner baixem a imagem em qualquer ambiente, incluindo desenvolvimento, teste e produção.

O Azure Migrate pode fornecer um processo guiado para descobrir, avaliar e migrar seu aplicativo existente do Windows para o Serviço Kubernetes do Azure. Para obter mais informações, consulte a página de documentação do Azure Migrate.