Usando contêineres do Windows para "conteinerizar" 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 você possa ouvir essa abordagem conhecida como "lift and shift to containers", a metáfora lift-and-shift se origina da mudança de cargas de trabalho de computadores físicos para virtuais e é usada ao se referir à movimentação de cargas de trabalho para a nuvem. Hoje, esse termo é aplicado mais adequadamente às VMs (máquinas virtuais) de migração. Mas os contêineres não são VMs e pensar neles como VMs pode causar confusão sobre como um aplicativo é conteinerizado ou se ele pode, ou deve, ser conteinerizado.

Este tópico fornece diretrizes práticas sobre como mover aplicativos tradicionais para contêineres do Windows. Ele visa 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 "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 isolados do sistema operacional Windows. Mas 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? Como 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. Mas alguns pontos bons que ajudam você a se lembrar da distinção contêiner versus VM são:

• 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 elas são executadas em imagens de contêiner especializadas, elas dão suporte apenas aos 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 padrão. A Microsoft tem trabalhado em estreita colaboração com o Docker para garantir que a funcionalidade do contêiner seja a mesma no Windows que for razoavelmente possível. 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 do Linux versus do Windows. Por outro lado, os contêineres do Windows fornecem algumas implementações exclusivas, como Hyper-V isolamento, que serão abordadas posteriormente. Este tópico ajuda você a entender essas diferenças e como acomodá-las.

Benefícios do uso de contêineres

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 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 compatíveis com o sistema operacional.

Os contêineres fornecem um método leve de criação e interrupção dinâmica dos recursos necessários para um aplicativo em funcionamento. Embora seja possível criar e implantar VMs à medida que a demanda do aplicativo aumenta, é mais rápido usar contêineres para escalar horizontalmente. 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 entre ambientes. A capacidade de colocar em contêiner um aplicativo existente com alterações mínimas de código, devido à integração do Docker entre as ferramentas de desenvolvedor da Microsoft, também é um fator poderoso no desenvolvimento e manutenção de aplicativos.

Por fim, um dos benefícios mais importantes do uso de contêineres é a agilidade que você obtém 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 mais completa de benefícios para usar contêineres para aplicativos existentes na página de documentação do .NET do Microsoft .

Conceito importante de nível de isolamento

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

Os contêineres do Windows oferecem dois modos distintos de isolamento de tempo de execução: 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?

Em isolamento de processo, vários contêineres são executados simultaneamente em um único host, com isolamento fornecido por meio de namespaces, controle 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 é aproximadamente o mesmo que a maneira como os contêineres do Linux são executados.

Em 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, tendo cada uma efetivamente um kernel próprio. A presença dessa máquina virtual – efetivamente uma VM de utilidade – fornece isolamento em nível de hardware entre cada contêiner e o host do contêiner.

De certa forma, o modo de isolamento Hyper-V é quase como uma fusão entre uma VM e um contêiner, fornecendo uma camada extra de segurança que é particularmente útil se seu aplicativo precisar 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 isolamento Hyper-V.
• Nem o AKS (Serviço de Kubernetes do Azure) nem o AKS no Azure Stack HCI oferecem suporte ao 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êiner 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 lembre-se de 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 único ou vários hosts sem preocupação com o gerenciamento do sistema operacional oferece grande flexibilidade, ajudando você a se mover em direção a uma arquitetura baseada em microsserviço. Uma compensação 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 controlar. 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 recursos para contêineres de maneira semelhante ao funcionamento de um sistema operacional. Portanto, à medida que você se move para colocar em contêiner seus aplicativos, precisará 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 mais explicados nas subseções após a tabela. Entender os motivos dessas limitações pode fornecer 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êiner.

Observação: 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êiner.

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

Aplicativos que exigem uma área 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 em si. Isso é verdadeiro mesmo se o aplicativo em si não tiver uma GUI, mas tiver um instalador que dependa de uma GUI. Em geral, o Windows Installer pode ser invocado usando o PowerShell, mas se o 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 maneira 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 de GUI. As APIs têm suporte, embora a GUI atendida por essas APIs não tenha. Isso é mais explicado no tópico Nano Server x Server Core x Server – Qual imagem base é a certa para você?

Aplicativos usando RDP

Como toda a finalidade do RDP (Protocolo de Área de Trabalho Remota) é 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 gerenciar hosts de contêineres do Windows e os próprios contêineres, sem a necessidade de 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 "rearquitecagem", que pode ou não ser trivial, mas continuar com ela eliminará essa barreira à contêinerizaçã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 colocará 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 o uso do 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 rearquitecagem 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 à contêinerização. Embora você possa executar um banco de dados dentro de um contêiner, containerizar 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ê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). Dessa forma, eles não estão disponíveis para a execução de contêineres. Portanto, os aplicativos que precisam dessas funções sempre serão difíceis de colocar em contêiner.

Há algumas áreas cinzas. Por exemplo, alguns recursos, como o DNS, podem funcionar em contêineres do Windows, mesmo que eles não sejam realmente destinados a 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 outros.

Active Directory (AD)

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 é firmemente acoplada e os objetos são mantidos no banco de dados mesmo que o usuário ou dispositivo real não esteja mais em execução. 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 um-para-um com o Active Directory não é ideal para esses cenários.

Por esse motivo, contêineres do Windows não podem ser adicionados a um 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, use contas de serviço gerenciado de grupo (gMSA), o que será explicado mais adiante.

Aplicativos usando o .NET Framework versão 2.0 ou anterior

Se o aplicativo exigir .NET, sua capacidade de contêiner depende inteiramente da versão do .NET Framework que ele usa. Não há suporte para qualquer versão antes do .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 um modo geral, a Microsoft não consegue certificar estruturas ou aplicativos de terceiros ou dar suporte a eles em execução em contêineres do Windows ou máquinas físicas e virtuais. No entanto, a Microsoft realiza seus próprios testes internos para 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 contêinerização

Agora que consideramos as limitações difíceis na contêinerização de aplicativos, é mais fácil ver quais tipos de aplicativos se prestam mais facilmente a 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.

Observação: mesmo esses candidatos ideais para a contêinerização podem depender dos principais recursos e componentes do Windows que precisarão ser tratados de forma diferente em contêineres do Windows. A próxima seção, que entra em mais detalhes sobre essas considerações práticas, preparará melhor você 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 determinado aplicativo pode ser conteinerizado por meio da perspectiva da função de negócios do aplicativo. Mas a funcionalidade de negócios não é o fator que determina se é tecnicamente possível. O importante é a arquitetura do aplicativo, ou seja, quais componentes técnicos ele depende. Portanto, não há uma resposta fácil para uma pergunta como "Posso colocar meu aplicativo de RH em contêiner?" 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 colocar em contêiner. À 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ê contêineriza o aplicativo. Outros, como tarefas agendadas e serviços em segundo plano, devem ser entendidos da perspectiva 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 ao pensar em contêineres. As subseções a seguir fornecem mais detalhes, incluindo exemplos que ilustram técnicas para lidar com cada cenário. Embora a lista a seguir abrange cenários com suporte em contêineres do Windows, esses cenários ainda precisam respeitar as diretrizes do capítulo anterior. Por exemplo, enquanto os serviços em segundo plano têm suporte, não há suporte para a execução de um serviço em segundo plano no .NET Framework 1.1.

Outros componentes de suporte

Componentes/recursos do Windows

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

MSMQ

Se o aplicativo depende do MSMQ, se você pode conteinerizá-lo 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 que o MSMQ foi originalmente projetado para dar suporte. Nem todos eles podem ser facilmente movidos para contêineres do Windows. A tabela a seguir lista os cenários com suporte:

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

• Modo de isolamento: tanto o modo de processo quanto o modo Hyper-V trabalham 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 uso 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.

Quando você coloca essas considerações junto com a tabela acima, você pode ver que o único cenário que não tem suporte é para 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) ao MSMQ, pois o MSMQ tem dependências do Active Directory que ainda não estão em vigor.

Como alternativa, use o Azure Service Bus em vez do MSMQ. O Azure Service Bus é um corretor de mensagens empresarial totalmente gerenciado com filas de mensagens e tópicos de publicação e assinatura (em um namespace). Mudar do MSMQ para o Barramento de Serviço do Azure requer alterações de código e arquitetura de aplicativo, mas lhe dará 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 entre grandes empresas. O MSDTC pode ser instalado em contêineres do Windows, mas há alguns 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 de execução do docker. Esse parâmetro de nome é o que permite que os contêineres se comuniquem pela rede do Docker. Se estiver usando gMSA, o nome deverá corresponder ao nome do host que deve corresponder ao nome da conta gMSA.
  • Aqui está um exemplo do comando executar 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. Se houver alguma 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 para o msdtc em cada um dos contêineres deve ser exclusivo. O uuid pode ser encontrado executando "Get-Dtc" nos contêineres no PowerShell. Se eles não forem exclusivos, uma maneira de resolver é desinstalando e reinstalando o msdtc em um dos contêineres. Estes comandos do PowerShelll podem ser usados: “uninstall-dtc”, “install-dtc”.
• Atualmente, o MSDTC não tem suporte nos Serviços de Kubernetes do Azure. Se você tiver uma necessidade específica de executar o MSDTC no AKS, por favor informe a equipe de contêineres do Windows abrindo um problema no repositório de contêineres do Windows no GitHub, na seção .

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

O IIS funciona da mesma forma em um contêiner do Windows que em uma VM. No entanto, há alguns aspectos 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: 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 esse motivo, use o armazenamento persistente para dados que precisam ser 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êiner com controle de Ingress. 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 dos certificados do gerenciamento dos 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 seguir esse modelo, pode ser interessante considerar a desassociação da cadeia de conexão do banco de dados do contêiner para uma configuração centralizada fornecida pelo orquestrador de contêineres, da qual o aplicativo pode obter as informações necessárias. Isso permite que você gerencie e atualize 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 banco de dados) em um repositório secreto.
• Escala automática horizontal: quando a carga aumenta, os sistemas de computação tendem a diminuir o desempenho percebido ao tentar 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 vertical, mas 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 escala horizontal em mente. Os contêineres do Windows podem aproveitar a escala horizontal para o IIS, mas o aspecto 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 seja armazenado para permitir o dimensionamento ou redução do número de instâncias que dão suporte ao aplicativo Web.

Tarefas agendadas

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 funcionamento 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, 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 esperar por um gatilho:

• Use um PaaS controlado por eventos (Plataforma como serviço), 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 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 colocar um aplicativo em segundo plano e de execução longa, desde que você crie um processo de 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, confira a documentação do no Github.

.NET Framework e .NET

Os contêineres do Windows dão suporte ao .NET Framework e ao .NET (anteriormente, .NET Core). A equipe do .NET cria suas próprias imagens oficiais para ambos os frameworks com base nas imagens de contêiner base do Windows. Escolher a imagem apropriada é fundamental 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 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, pode ser necessário criar sua própria imagem do .NET Framework ou do .NET em cima das imagens de contêiner base do Windows ou do Servidor. Isso pode 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, as imagens de contêiner base do Server Core e do Nano Server têm apenas uma fonte disponível, para reduzir o tamanho da imagem. 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 eles respeitem a natureza dos contêineres, como não 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:

Outros componentes de suporte

Os componentes e tópicos abaixo fornecem diretrizes adicionais para itens que acompanham ou que fornecem melhor clareza sobre contêineres do Windows.

Log de eventos

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

O Docker sempre teve um mecanismo para extrair logs de contêineres do Linux. Usando o comando "logs do docker" com uma configuração stdout padrão, o Docker tira 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 Monitor de Log 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 para usar o Log Monitor incluem estes:

• 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çõ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 na mesma base que as instâncias do Windows em execução em máquinas físicas ou virtuais. Entender os detalhes de como os contêineres são implementados, especialmente sua natureza de kernel compartilhado, ajuda você a proteger um aplicativo em contêineres:

• 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 em seu contêiner diretamente 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 do contêiner encaminhará o tráfego necessário por meio de seu firewall para que o contêiner possa acessar a Web.
• Modo de isolamento. Conforme discutido, os contêineres do Windows podem ser implantados no modo de isolamento de processo ou no modo de isolamento 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 (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 recriar contêineres do Windows usando a imagem de contêiner base disponível mais recente. Os clientes podem aproveitar os pipelines do 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 alterar a 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 imagem e verificação 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 dos contêineres do Windows .

Backup de contêineres do Windows

Você precisa pensar em backups de forma diferente ao usar contêineres. Conforme discutido anteriormente, um contêiner não deve ser usado para armazenar o estado ou os dados devido à sua natureza efêmera. 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ída por uma nova para a qual todo o armazenamento persistente necessário ainda estará 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 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ê possui o 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 residir em um repositório de imagens 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 lida com a disponibilidade das imagens de contêiner e serve como uma opção de backup– no entanto, tenha em mente que, enquanto o ACR manipula 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 no servidor, siga a recomendação do fornecedor para fazer backup de registros existentes.
• Dockerfile: Os Dockerfiles criam novas 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 existente que está sendo conteinerizado, você será responsável por garantir que o dockerfile seja armazenado em um local seguro e de backup. Você também deve garantir que todos os outros ativos necessários para que seu aplicativo funcione em um contêiner sejam armazenados em backup; por exemplo: arquivos YAML e JSON para modelos 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 de 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 compatíveis com AKS e 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 a 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 próprios contêineres não se movem; em vez disso, você pode usar um orquestrador para iniciar ou parar automaticamente contêineres em nós de cluster ou gerenciar alterações na carga e disponibilidade com escala horizontal automática.
6. Considere as necessidades de orquestração. Depois de conteinerizado, o 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 um contêiner.
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.

Azure Migrate pode 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 do Azure Migrate.