Como usar contêineres do Windows para "conteinerizar" aplicativos

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

Os contêineres do Windows fornecem um ótimo mecanismo para modernizar aplicativos tradicionais ou herdados. Embora você possa ouvir essa abordagem ser chamada de "lift and shift para contêineres", a metáfora lift-and-shift se origina da mudança de cargas de trabalho de máquinas físicas para virtuais e tem sido usada ultimamente ao se referir à movimentação de cargas de trabalho no estado em que se encontram para a nuvem (seja privada ou pública). Hoje esse termo é aplicado mais adequadamente às VMs (máquinas virtuais) de migração. Porém, os contêineres não são VMs e pensar neles como VMs podem causar confusão sobre como um aplicativo pode ser conteinerizado ou se ele pode, ou deve, ser conteinerizado.

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

Introdução

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

O termo genérico contêiner se refere a uma tecnologia que virtualiza o SO (sistema operacional). 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 isolados do sistema operacional Windows. Contudo, a interdependência total entre o contêiner e o 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? Isso acontece porque um contêiner do Windows não é um servidor virtualizado inteiro e algumas das coisas que talvez você queira fazer com um aplicativo não podem ser feitas apenas com um sistema operacional virtualizado.

Você pode ler mais sobre este tópico em Contêineres versus máquinas virtuais. Alguns pontos relevantes que ajudam você a se lembrar da distinção contêiner versus VM são:

• Os contêineres não são uma solução equivalente à virtualização de aplicativos da área de trabalho. Eles dão suporte apenas a aplicativos do lado do servidor que não exigem uma sessão interativa. Como são executados em imagens de contêiner especializadas, eles dão suporte apenas a aplicativos que não precisam de um front-end gráfico.
• Os contêineres são efêmeros por natureza. Isso significa que, por padrão, não há 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 emergindo como o padrão. A Microsoft trabalhou em forte colaboração com o Docker para garantir que a funcionalidade do contêiner seja o mais parecida possível com a do Windows. Diferenças inerentes entre o Linux e o Windows podem surgir de maneiras que parecem ser limitações dos contêineres do Windows quando, na verdade, são apenas as diferenças entre o Linux e o Windows. Por outro lado, os contêineres do Windows fornecem algumas implementações exclusivas, como o isolamento do Hyper-V, que será abordado posteriormente. Este tópico ajudará você a entender essas diferenças e como acomodá-las.

Benefícios do uso de contêineres

Assim como a execução de várias VMs em um só host físico, você pode executar vários contêineres em apenas um host físico ou virtual. Porém, ao contrário das VMs, você não precisa gerenciar o SO de um contêiner, o que lhe dá flexibilidade para 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 outros processos com suporte no SO.

Os contêineres fornecem um método leve de criação e interrupção dinâmica dos recursos necessários para um aplicativo funcional. Embora seja possível criar e implantar VMs à medida que a demanda do aplicativo aumenta, é mais rápido usar contêineres para expansão. 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 para a produção com pouca ou nenhuma alteração de código, pois eles "contêm" dependências de aplicativo para que eles funcionem em vários ambientes. A capacidade de conteinerizar um aplicativo existente com alterações mínimas de código, devido à integração do Docker entre as ferramentas para desenvolvedores Microsoft, também é um fator poderoso para o desenvolvimento e a manutenção de aplicativos.

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

Você pode encontrar uma lista muito mais completa de benefícios de usar 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 permitem isolamento do SO Windows, o que é vantajoso ao criar, testar e promover um aplicativo para produção. No entanto, é importante entender o modo como o isolamento é alcançado quando você está pensando em colocar um aplicativo em contêiner.

Os contêineres do Windows oferecem dois modos distintos de isolamento de runtime: processo e Hyper-V. Os contêineres em ambos os modos são criados e gerenciados do mesmo modo e funcionam de maneira idêntica. Quais são as diferenças e por que você deve se importar? No isolamento do processo, vários contêineres são executados simultaneamente em um só host com o isolamento fornecido por meio do namespace, controle de recursos e outros recursos. Contêineres no modo de isolamento de processo compartilham o mesmo kernel com o host, bem como entre si. Isso é aproximadamente igual ao modo como os contêineres do Linux são executados.

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

De certa forma, o modo de isolamento do Hyper-V é quase como um híbrido de uma VM e um contêiner, fornecendo uma camada extra de segurança que é particularmente útil se seu aplicativo precisa de multilocação. Os possíveis contras de usar o modo de isolamento do Hyper-V incluem:

• Tempo de inicialização mais longo para o contêiner e um impacto provável no desempenho geral do aplicativo.
• Nem todas as ferramentas funcionam nativamente com o isolamento do Hyper-V.
• Nem o AKS (Serviço de Kubernetes do Azure) nem o AKS no Azure Stack HCI dão suporte ao isolamento do 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 conteinerizar um aplicativo pela primeira vez, você precisará escolher entre os dois modos. Felizmente, é muito fácil mudar de um modo para outro mais tarde, pois isso não requer nenhuma alteração no aplicativo ou no contêiner. Porém, lembre que, ao colocar um aplicativo em contêiner, 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 ou em vários hosts sem preocupação com o gerenciamento do sistema operacional proporciona uma grande flexibilidade, ajudando você a migrar para uma arquitetura baseada em microsserviço. Um contra dessa flexibilidade é que um ambiente baseado em contêineres e microsserviços pode rapidamente gerar muitas partes móveis, partes demais para acompanhar. Felizmente, gerenciar o balanceamento de carga, a alta disponibilidade, o agendamento de contêiner, o gerenciamento de recursos e muito mais é a função de um orquestrador de contêineres.

Os orquestradores talvez sejam nomes errados; eles são mais como os maestros de uma orquestra em que coordenam a atividade de vários contêineres para manter a música tocando. De certa forma, eles lidam com o agendamento e a alocação de recurso para contêineres de modo semelhante ao funcionamento de um sistema operacional. Portanto, à medida que você passa a conteinerizar seus aplicativos, precisa escolher entre os orquestradores que dão suporte a 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. Os motivos são explicados em mais detalhes nas subseções após a tabela. 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 que podem ser conteinerizados.

Observação: a lista abaixo não é uma exaustiva. Em vez disso, é uma compilação de aplicativos que a Microsoft viu os clientes tentarem conteinerizar.

Aplicativos/recursos sem suporte	Por que não há suporte	Você pode contornar isso?
Aplicativos que exigem uma área de trabalho	Os contêineres não dão suporte à GUI (Interface Gráfica do Usuário)	Se o aplicativo exigir apenas uma GUI para instalar, alterá-lo para uma instalação silenciosa poderá ser uma solução
Aplicativos que usam o protocolo RDP	O RDP é para sessões interativas, portanto, o princípio acima também se aplica aqui	Você pode usar o WAC (Windows Admin Center) ou o PowerShell Remoto como alternativa para o gerenciamento remoto
Aplicativos com estado	Contêineres são efêmeros	Sim, alguns aplicativos podem exigir alteração mínima, de modo que não armazenam dados ou estado dentro do contêiner
Aplicativos de banco de dados	Contêineres são efêmeros	Sim, alguns aplicativos podem exigir alteração mínima, de modo que não armazenam dados ou estado dentro do contêiner
Active Directory	O design e a finalidade do Active Directory impedem a execução em um contêiner	Não. No entanto, os aplicativos dependentes do Active Directory podem usar gMSA (contas de serviço gerenciado de grupo). Mais informações sobre gMSA são fornecidas abaixo
Versões mais antigas do Windows Server	Há suporte apenas ao Windows Server 2016 ou superior	Não. Contudo, a compatibilidade do aplicativo pode ser uma opção – a maioria dos aplicativos Windows Server 2008/R2 e mais antigos são executados em versões mais recentes do Windows Server
Aplicativos que usam .NET Framework versão 2.0 ou mais antiga	Imagens de contêiner específicas são necessárias para dar suporte ao .NET Framework e apenas versões mais recentes têm suporte	Não há suporte para versões anteriores à 2.0, 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 nem dá suporte especificamente ao uso de estruturas não 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 a seguir para obter mais informações

Vamos considerar cada uma dessas limitações.

Aplicativos que exigem uma área de trabalho

Os contêineres são ideais para funções efêmeras 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 em si. Isso é verdade mesmo que o aplicativo em si não tenha uma GUI, mas tenha um instalador que depende de uma GUI. Em geral, o Windows Installer pode ser invocado usando o PowerShell, mas se seu aplicativo exigir a instalação por meio de uma GUI, esse requisito o eliminará como um candidato para contêineres.

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

É uma questão diferente se um aplicativo precisa de APIs de GUI. As APIs têm suporte, embora a GUI atendida por essas APIs não tenha. Isso é explicado de modo mais completo no tópico Nano Server x Server Core x Server – Qual é a imagem base certa para você?

Aplicativos que usam RDP

Como a finalidade do protocolo RDP é 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 no estado em que se encontra.

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

Aplicativos com estado

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

Um exemplo de estado é um aplicativo Web que armazena imagens ou arquivos de música em uma pasta local. Em um ambiente tradicional do Windows, um arquivo é salvo em disco no momento em que a operação de gravação é concluída, portanto, se a instância (uma VM nesse caso) falhar, você simplesmente o trará de volta e o arquivo ainda estará lá. Por outro lado, se uma instância de contêiner executando 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 usar armazenamento persistente para que todas as instâncias de contêiner possam armazenar dados de estado ou arquivos 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, confira a documentação sobre armazenamento do contêiner do Windows.

No entanto, isso traz outro tópico relacionado…

Aplicativos de banco de dados

Como regra geral, os aplicativos de banco de dados não são ótimos candidatos à conteinerização. Embora você possa executar um banco de dados dentro de um contêiner, o contêiner de um banco de dados 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 diminui o benefício da consolidação. Em segundo lugar, várias instâncias de um só nível de banco de dados precisam de coordenação para suas operações de gravação. A orquestração de contêiner pode resolver isso, mas, para bancos de dados, 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). Assim, não estão disponíveis para a execução de contêineres. Portanto, aplicativos que precisam dessas funções sempre serão difíceis de conteinerizar.

Há algumas áreas imprecisas. Por exemplo, alguns recursos, como o DNS, podem funcionar em contêineres do Windows mesmo que não tenham a intenção de serem 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 Active Directory, DHCP e outras.

AD (Active Directory)

O Active Directory foi lançado há mais de vinte anos no 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 é bem acoplada e os objetos são mantidos no banco de dados mesmo que o usuário ou o dispositivo real não esteja mais em jogo. Essa abordagem para o Active 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 de um-para-um com o Active Directory não é ideal para esses cenários.

Por esse motivo, os contêineres do Windows não podem ser conectados ao domínio. Como efeito disso, você não pode executar o Active Directory Domain Services como uma função de infraestrutura em contêineres do Windows. Você pode executar o módulo do PowerShell para gerenciar controladores de domínio remotamente dentro de um contêiner do Windows.

Para aplicativos em execução em contêineres do Windows dependentes do Active Directory, você pode usar gMSA (Contas de Serviço Gerenciado por Grupo), o que será explicado mais adiante.

Aplicativos que usam .NET Framework versão 2.0 ou mais antiga

Se o aplicativo exigir .NET, sua capacidade de contêiner dependerá inteiramente da versão do .NET Framework que ele usa. Não há suporte para nenhuma versão anterior a .NET Framework 2.0; versões superiores exigem o uso de imagens específicas, conforme descrito posteriormente.

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

De modo geral, a Microsoft não pode certificar estruturas ou aplicativos de terceiros nem dar suporte à execução em contêineres do Windows ou máquinas físicas e virtuais. No entanto, a Microsoft realiza 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 respectivo fornecedor.

Candidatos ideais para conteinerização

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

Tipo de aplicativo	Por que estes são bons candidatos	Considerações especiais
Aplicativos de console	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 Windows	Porque eles são processos em segundo plano que não exigem nenhuma 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 em contêiner em execução. Confira a seção sobre Serviços em segundo plano abaixo.
Serviços WCF (Windows Communication Foundation)	Porque eles são aplicativos orientados a serviço que também podem ser executados 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 em contêiner em execução. Confira a seção sobre Serviços em segundo plano abaixo.
Aplicativos Web	Os aplicativos Web são, em essência, serviços em segundo plano escutando em uma porta específica, portanto, são ótimos candidatos à conteinerização, pois podem aproveitar a escalabilidade oferecida por 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 tratados de maneira diferente em contêineres do Windows. A próxima seção, que entra em mais detalhes sobre essas considerações práticas, preparará você melhor para aproveitar a funcionalidade dos contêineres do Windows.

Considerações práticas para aplicativos que podem ser conteinerizados

Projetos de renovação de aplicativo normalmente levam em conta se um aplicativo específico pode ser conteinerizado pela perspectiva da função de negócios do aplicativo. Mas a funcionalidade de negócios não é o fator que determina a viabilidade técnica. O importante é a arquitetura do aplicativo, ou seja, de quais componentes técnicos ele depende. Portanto, não há uma resposta fácil a uma pergunta como "Posso conteinerizar 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, pois se o aplicativo não for criado com uma arquitetura de microsserviços para começar, provavelmente será mais difícil de conteinerizá-lo. À medida que você avança para conteinerizá-lo, determinados recursos podem precisar de tratamento especial. Alguns podem ser devido ao uso do aplicativo de componentes e estruturas principais do Windows que não têm suporte em contêineres do Windows. Outros, como registro em log e monitoramento de eventos, são devido a diferenças inerentes entre o Linux e o Windows que se tornam aparentes somente quando você conteineriza o aplicativo. Outros ainda, como tarefas agendadas e serviços em segundo plano, devem ser compreendidos na perspectiva de que um contêiner não é uma VM, mas é efêmero, 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 ao pensar em contêineres. As subseções a seguir dão mais detalhes, incluindo exemplos que ilustram técnicas para lidar com cada cenário. Embora a lista a seguir abranja cenários com suporte em contêineres do Windows, esses cenários ainda precisam respeitar as diretrizes do capítulo anterior. Por exemplo, embora haja suporte para serviços em segundo plano, não há suporte para executar um serviço em segundo plano no .NET Framework 1.1.

Recurso/componente do Windows que exige tratamento especial	Motivo
MSMQ (Microsoft Messaging Queueing)	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êiner.
Coordenador de Transações Distribuídas da Microsoft (MSDTC)	A resolução de nomes entre o MSTDC e o contêiner exige uma 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 de contêiner em execução. Dependendo do aplicativo, talvez você queira 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 tratamento adicional para manter o contêiner em execução
.NET Framework e .NET (anteriormente .Net Core)	Use a imagem certa para garantir a compatibilidade, conforme explicado na subseção abaixo

Outros componentes de suporte

Componente que exige tratamento especial	Motivo	Abordagem alternativa
Registro em log/monitoramento de eventos	Porque a maneira como o Windows grava eventos e logs é inerentemente diferente do Linux stdout	Use a nova ferramenta do Log Monitor para normalizar os dados e combiná-los tanto do Linux quanto do Windows
Segurança de contêineres do Windows	Embora muitas práticas de segurança permaneçam iguais, os contêineres exigem medidas de segurança adicionais	Empregar um registro criado com finalidade e uma ferramenta de verificação de imagens – mais detalhes posteriormente
Backup de contêineres do Windows	Os contêineres não devem ter dados nem estado	Fazer backup de qualquer armazenamento persistente usado por contêineres, bem como imagens de contêiner

Componentes/recursos do Windows

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

MSMQ

Se seu aplicativo depende do MSMQ, você poder conteinerizá-lo ou não depende do 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 tipo de autenticação formam uma matriz de cenários para os quais o MSMQ foi originalmente projetado para dar suporte. Nem todos eles podem ser facilmente movidos para contêineres do Windows. A seguinte tabela lista os cenários compatíveis:

Escopo	Transacional?	Local da fila	Tipo de autenticação	Enviar e receber?
Privado	Yes	Mesmo contêiner (contêiner único)	Anônima	Yes
Privado	Yes	Volume persistente	Anônima	Yes
Privado	Yes	Controlador de domínio	Anônima	Yes
Privado	Yes	Host único (dois contêineres)	Anônima	Sim
Público	No	Dois hosts	Anônima	Sim
Público	Yes	Dois hosts	Anônima	Yes

Algumas anotações sobre esses cenários com suporte foram validadas pelas equipes de desenvolvimento internas da Microsoft:

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

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

Como alternativa, use Barramento de Serviço do Azure em vez de 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 Barramento de Serviço do Azure requer alterações de código e arquitetura de aplicativo, mas dá a agilidade para migrar para uma plataforma moderna.

MSDTC

O MSDTC (Coordenador de Transações Distribuídas da Microsoft) é muito usado em aplicativos herdados do Windows em grandes empresas. O MSDTC pode ser instalado em contêineres do Windows, mas há certos cenários que não funcionam e não podem ser reproduzidos em contêineres do Windows.

• Ao criar o contêiner, lembre-se de passar o parâmetro --name ao comando docker run. Esse parâmetro de nome é o que permite que os contêineres se comuniquem pela rede do Docker. Se estiver usando o gMSA, o nome precisará corresponder ao nome da conta do gMSA.
  • Veja 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 um ao outro usando o nome NETBIOS. Em caso de dificuldade com isso, a melhor maneira de resolver é adicionar o nome e o IP dos contêineres aos arquivos de host uns dos outros.
• O UUID do MSDTC nos dois contêineres precisa ser exclusivo. O UUID pode ser encontrado executando "Get-Dtc" no PowerShell nos contêineres. Se eles não forem exclusivos, uma forma de resolver será desinstalar e reinstalar o MSDTC em um dos contêineres. Estes comandos do PowerShelll podem ser usados: “uninstall-dtc”, “install-dtc”.
• No momento, o MSDTC não é compatível com os Serviços de Kubernetes do Azure. Se houver uma necessidade específica de executar o MSDTC no AKS, informe a equipe de contêineres do Windows abrindo o problema no repositório de contêineres 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 e em uma VM. No entanto, alguns aspectos da execução de uma instância do IIS devem ser considerados ao executar em um ambiente de contêiner:

• Armazenamento persistente para dados locais: 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 deseja que nenhum dado seja gravado diretamente no contêiner. Os contêineres usam um "espaço de risco" para o armazenamento local e, quando um novo contêiner aparece para o mesmo aplicativo, ele não tem acesso a essa área de um contêiner anterior. Por isso, você deve usar 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, pois, se um certificado precisar ser atualizado, você precisará recompilar sua imagem de contêiner. Como alternativa, você pode usar um orquestrador de contêineres com controle de entrada. Os controladores de entrada podem aplicar políticas de rede e manipular o gerenciamento de certificados para o site hospedado por trás dele. O lado positivo é que você separa o gerenciamento do ciclo de vida do certificado do gerenciamento de sites.
• Cadeias de conexão de banco de dados: para implantação tradicional do IIS, você pode passar a cadeia de conexão do BD como parte da implantação do aplicativo. Embora os contêineres do Windows permitam que você siga esse modelo, convém considerar a desacoplamento da cadeia de conexão de BD do contêiner para uma configuração centralizada fornecida pelo orquestrador de contêineres, da qual o aplicativo pode ler. Isso permite gerenciar e atualizar a cadeia de conexão do BD independentemente do aplicativo. Se o BD mudar (para casos de lift-and-shift para a nuvem, por exemplo), você poderá alterar facilmente a cadeia de conexão sem recompilar a imagem de contêiner. Essa abordagem também permite que você mantenha segredos (como nome de usuário e senha para se conectar ao BD) em um repositório secreto.
• Dimensionamento automático horizontal: quando a carga aumenta, os sistemas de computação tendem a diminuir o desempenho percebido ao tentarem 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 em 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 pensando na escala horizontal. Os contêineres do Windows podem aproveitar a escala horizontal do IIS, mas o aspecto efêmero dos contêineres desempenha uma função importante. É fundamental que os contêineres tenham a mesma configuração e que nenhum estado ou dados seja armazenado para permitir o dimensionamento ou redução do número de instâncias que dão suporte ao aplicativo Web.

Tarefas Agendadas

As tarefas agendadas são usadas para chamar um programa, serviço ou script a qualquer momento em um ambiente do 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, exceto pelo fato de que você precisa configurar e gerenciar tarefas agendadas por meio de Azure PowerShell, elas 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 uma PaaS (Plataforma como serviço) controlada por eventos, como o Azure Function, para armazenar seu código e definir um gatilho para esse aplicativo. O Azure Functions dá suporte inclusive a imagens de contêiner do Windows a serem executadas quando um gatilho é atendido.
• Use contêineres do Windows em conjunto com um orquestrador de contêineres. O contêiner só pode ser executado quando o gatilho é atendido e chamado de outras partes do aplicativo. Nesse caso, o orquestrador de contêineres manipulará o agendamento e o gatilho para o aplicativo.
• Por fim, mantenha um contêiner do Windows em execução para executar uma tarefa agendada. Você precisará de um serviço em primeiro plano (como o Service Monitor) para manter o contêiner em execução.

Serviços em segundo plano

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

Um grande 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, confira a documentação no Github.

.NET Framework e .NET

Os contêineres do Windows dão suporte a .NET Framework e a .NET (anteriormente, .NET Core). A equipe do .NET cria as próprias imagens oficiais para ambas as estruturas, além das imagens de contêiner base do Windows. Escolher a imagem apropriada é essencial para garantir a compatibilidade. A equipe do .NET fornece imagens do .Net Framework sobre a imagem de contêiner base do Server Core e imagens do .NET sobre as imagens de contêiner base do Server Core e do Nano Server. O Server Core tem um conjunto de API maior do que o Nano Server, o que possibilita mais 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 uma imagem própria do .NET Framework ou do .NET sobre as imagens de contêiner base do Windows ou do Servidor. Isso poderá ser necessário se o aplicativo não tiver apenas uma dependência de estrutura, mas uma dependência do sistema operacional. Você poderá detectar essas dependências testando seu aplicativo com uma imagem de contêiner base específica.

Por exemplo, para reduzir o tamanho da imagem, as imagens de contêiner base do Server Core e do Nano Server têm apenas uma fonte disponível. Se o aplicativo exigir uma fonte diferente, você precisará instalar essa fonte ou usar as imagens do Servidor ou do Windows, que têm um conjunto de API maior 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 a não GUI) seja conteinerizado. O lado negativo é que eles serão muito maiores, 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 essa estrutura	Testar com essa imagem de contêiner primeiro	Fazer fallback para essa imagem de contêiner se primeiro não funcionar	Base image
.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	Criar sua imagem de contêiner .NET Framework com imagens do Servidor ou do Windows	Núcleo do Windows Server
.NET 6 ou 7	.NET 6 ou 7, respectivamente	Criar sua imagem de contêiner do .NET com imagens base do Windows ou do Servidor	Windows Nano Server ou Server Core

Outros componentes de suporte

Os componentes e tópicos abaixo apresentam diretrizes adicionais para itens que acompanham ou que dão mais clareza sobre os contêineres do Windows.

Log de eventos

O Windows e o Linux usam métodos diferentes para armazenar e apresentar logs e eventos aos usuários. Tradicionalmente, o Windows usa o formato EVT, que pode ser exibido de maneira estruturada em Visualizador de Eventos. O Linux, por outro lado, forneceu uma abordagem simplificada com a Saída Padrão (stdout) de que outras ferramentas, como o Docker, dependem.

O Docker sempre teve um mecanismo para extrair logs de contêineres do Linux. Usando o comando "docker logs" com uma configuração stdout padrão, o Docker extrai os logs do aplicativo do contêiner sem abrir o contêiner interativamente. No entanto, até o início da ferramenta do Log Monitor, 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 coletar as informações necessárias para exibi-los. Os benefícios adicionais de usar o Log Monitor incluem:

• Poder 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 você não está interessado em eventos de "informações".
• A capacidade de escolher entre logs de eventos, arquivos de log personalizados ou ETW (Rastreamento de Eventos para Windows). Isso é particularmente útil se o aplicativo estiver gravando em uma fonte de log diferente. Um exemplo disso são os logs do IIS localizados na pasta "C:\inetpub".
• O fato de que o Log Monitor faz com que os contêineres do Windows se comportem de modo muito parecido com contêineres do Linux e, portanto, ferramentas que procuram stdout e interagem com a função de runtime do contêiner conforme o esperado. Por exemplo, se você mover do Docker para o ContainerD como o runtime do contêiner, os logs ainda deverão estar visíveis do host do contêiner por meio (por exemplo) de "logs crictl".

Leia mais sobre a ferramenta Log Monitor nesta postagem no blog.

Segurança de contêineres do Windows

Os contêineres do Windows são criados com a mesma base que as instâncias do Windows em execução em máquinas físicas ou virtuais. Entender as especificidades de como os contêineres são implementados, especialmente sua natureza de kernel compartilhado, ajuda você 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. Você não precisa configurar esses componentes diretamente em seu contêiner porque o host de 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 de contêiner encaminhará o tráfego necessário por meio do firewall para que o contêiner possa acessar a Web.
• Modos de isolamento. Conforme discutido, os contêineres do Windows podem ser implantados no processo ou no modo de isolamento do Hyper-V, com o 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 (administrador) interaja com os processos e serviços de 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 manutenção não está presente em 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 recompilar contêineres do Windows usando a imagem de contêiner base disponível mais recente. Os clientes podem aproveitar pipelines de DevOps para essa finalidade. A Microsoft atualiza as imagens de contêiner base para todas as suas imagens oficiais todos os meses após a cadência de 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 de contêiner. No entanto, você deve considerar a alteração da conta de usuário para ContainerUser ao executar um aplicativo que não exija os privilégios elevados. Para cenários específicos, você também pode criar uma nova conta com os privilégios apropriados.
• Verificação de imagem e runtime. 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 para Contêineres para verificação de imagens e de runtime. O Defender para Contêineres dá suporte a contêineres do Windows para avaliação de vulnerabilidade com verificação de registro e proteção de runtime com detecção de ameaças.

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

Backup de contêineres do Windows

Você precisa pensar em backups de modo diferente ao usar contêineres. Conforme já discutido, dada a sua natureza efêmera, um contêiner não deve ser usado para armazenar o estado ou dados. Se você separar o estado e os dados da instância de contêiner, suas preocupações de backup estarão fora do runtime da instância de contêiner, que pode ser substituído por um novo ao qual todo o armazenamento persistente necessário ainda estará disponível.

No entanto, ainda há componentes responsáveis pelo backup; incluindo o aplicativo, a imagem de contêiner e o dockerfile que compila a imagem de 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, o que permite reverter para uma versão específica do aplicativo. Se você é o proprietário do repositório de origem, siga suas recomendações de backup e gerenciamento.
• Imagem de contêiner: para ambientes de produção, sua imagem de contêiner deve estar em um repositório de imagem centralizado, como o ACR (Registro de Contêiner do Azure). Você pode enviar suas imagens de contêiner por push para o ACR para que ele as disponibilize para outros hosts capturarem-nas. O ACR manipula a disponibilidade das imagens de contêiner e serve como uma opção de backup. No entanto, saiba 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 local, siga a recomendação do fornecedor para fazer backup de registros existentes.
• Dockerfile: os dockerfiles criam imagens de contêiner e geralmente são armazenados junto com a origem do aplicativo. Como o dockerfile pode não ter sido criado com o aplicativo, especialmente se for um aplicativo que está sendo conteinerizado, você é responsável por garantir que o dockerfile seja armazenado em um local seguro e que passe por backup. Você também deve garantir que todos os outros ativos necessários para que seu aplicativo funcione em um contêiner sejam apoiados; por exemplo: arquivos YAML e JSON para modelos do Kubernetes, Docker Swarm e ARM do Azure seguem as mesmas diretrizes acima.

Como planejar o processo lift-and-shift

Depois de avaliar a preparação do aplicativo para o contêiner, use as seguintes diretrizes gerais para planejar o processo:

1. Determine a imagem base do sistema operacional Windows de que você precisa: imagens do Windows Server Core, do Nano Server, do Windows ou do Server.
2. Determine o tipo de modo de isolamento para o contêiner: escolha entre os modos de isolamento de processo ou Hyper-V. Observação: atualmente, o AKS e o AKS no Azure Stack HCI dão suporte apenas a contêineres isolados por processo. 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, confira Modos de Isolamento.
3. Escolha a versão certa do Windows Server para seu aplicativo para fins de compatibilidade do aplicativo. 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 host de contêiner com suporte no AKS e no AKS no Azure Stack HCI.
4. Verifique se as políticas de segurança da sua empresa estão em vigor para o ambiente de contêiner. Isso inclui a adaptação aos requisitos específicos do contêiner, como verificação de registro e detecção de ameaças.
5. Considere as necessidades de balanceamento de carga. Os contêineres em si não se movem; em vez disso, você pode usar um orquestrador para iniciar ou parar contêineres automaticamente em nós de cluster ou gerenciar alterações de carga e disponibilidade com escala horizontal automática.
6. Considere as necessidades de orquestração. Depois de conteinerizado, seu aplicativo provavelmente precisa de gerenciamento automatizado disponível com ferramentas como Kubernetes, AKS ou AKS no Azure Stack HCI. Confira a Visão geral de orquestração de contêiner do Windows para uma discussão completa e um guia para escolher entre as ferramentas.
7. Colocar o aplicativo em contêineres.
8. Envie o aplicativo por push 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.

As Migrações para Azure podem fornecer um processo guiado para descobrir, avaliar e migrar seu aplicativo Windows existente para o Serviço de Kubernetes do Azure. Para obter mais informações, confira a página de documentação das Migrações para Azure.