Preparar um cluster do Windows para implantação

Nesta página, descrevemos como preparar o cluster do Windows para implantação.

Antes de começar

Escolher e configurar o registro do Docker

Como parte da implantação, você cria e faz upload da imagem do Docker do seu contêiner para um registro do Docker.

No registro do Docker, você pode optar por usar:

  • Artifact Registry

  • Qualquer registro do Docker compatível com a autenticação básica

A solução recomendada é usar o Artifact Registry no mesmo projeto do cluster de implantação. O GKE pode acessar o registro por padrão. Para mais informações, consulte os requisitos para integração com o GKE.

Se você quiser usar um registro particular do Docker, aprenda como configurar o registro.

Configurar cargas de trabalho migradas para usar o gMSA

As cargas de trabalho de aplicativos IIS do Windows geralmente são mescladas pelo Active Directory (AD) e operam usando identidades de domínio. Ao migrar essas VMs para contêineres, os próprios contêineres não são mesclados com o domínio, mas os nós de cluster host do Kubernetes podem ser mesclados com o domínio.

Ao implantar os contêineres migrados em um cluster, é possível usar uma conta de serviço gerenciado de grupo (gMSA). Use a gMSA para executar o contêiner em uma identidade de conta de serviço específica. Anexe uma gMSA no cluster do Kubernetes como parte da configuração do pod, e não como uma configuração de identidade estática dentro da imagem do contêiner.

O Migrate to Containers ajuda você a transformar suas cargas de trabalho. O Migrate to Containers descobre automaticamente a configuração dos pools de aplicativos IIS e adiciona recomendações ao plano de migração gerado. Em seguida, é possível avaliar essas recomendações e modificá-las para seu ambiente e requisitos específicos.

Se o Migrate to Containers determinar que a configuração de um pool de aplicativos não requer uma gMSA, ele manterá a configuração do pool de aplicativos original. Por exemplo, quando ela usa um tipo de conta integrado, como ApplicationPoolIdentity, NetworkService, LocalSystem ou LocalService.

Para oferecer compatibilidade com o gMSA em um contêiner do Windows migrado, você precisa fazer o seguinte:

  1. Edite o plano de migração para definir as propriedades necessárias para configurar o contêiner migrado para usar um gMSA.

  2. Configure o cluster de destino que hospeda o contêiner implantado.

Configurar um cluster de destino para aceitar o gMSA

Anexe um gMSA no cluster do Kubernetes como parte da configuração do pod, e não como uma configuração de identidade estática dentro da imagem do contêiner.

Para configurar um cluster que hospeda o contêiner do Windows migrado para aceitar o gMSA, você precisa:

  1. Configurar o Active Directory para VMs para ingressar automaticamente em um domínio.

  2. Configurar o gMSA para pods e contêineres do Windows.

Para ver mais informações, consulte os seguintes tópicos:

Implantar um contêiner ao armazenar certificados SSL como secrets do Kubernetes

Recomendamos que você use o Cloud Load Balancing, o Ingress ou o Cloud Service Mesh como um front-end HTTPS para proteger o acesso externo ao contêiner implantado. Essa opção permite proteger a comunicação externa sem incluir qualquer certificado dentro do cluster. Para mais informações, consulte Personalizar um plano de migração.

Também é possível armazenar certificados Secure Sockets Layer (SSL) como secrets do Kubernetes e montá-los no ambiente de execução no contêiner.

Para usar o secrets do Kubernetes:

  1. Crie um arquivo PFX com o certificado e a senha.

  2. Crie um arquivo YAML de configuração que defina o acesso ao site:

    sites:
 - sitename: "sitename"
   sslport: 443
   pfxpath: c:\sslconfig\pfx
   password: "password"
   thumbprint: "3e858d0551fc0536f52d411dad92b680a4fad4da"

    Em que:

    • sitename especifica o nome do site configurado para usar SSL. A propriedade sites pode conter várias entradas sitename.

    • sslport especifica a porta a ser detectada para conexões SSL (normalmente 443).

    • pfxpath especifica o caminho para o arquivo PFX. Configure-o como parte do volumeMounts da implantação do pod.

    • password especifica a senha do arquivo PFX.

    • thumbprint especifica a impressão digital SHA1 do arquivo PFX, que pode ser recuperada usando o comando do PowerShell:

      Get-PfxCertificate -FilePath "path to pfx"

      Ou visualize no Gerenciador de certificados do Windows.

  3. Crie o secret do Kubernetes:

    kubectl create secret generic secret-name --from-file=pfx=path-to-pfx --from-file=config=path-to-config

  4. Crie o volume e a montagem de volume na implantação da imagem:

    apiVersion: v1
kind: Pod
metadata:
 name: iis-pod
 labels:
   app: iis-server-simple
 spec:
   nodeSelector:
     kubernetes.io/os: windows
   containers:
   - name: iis-server
     image: your-image-url
     volumeMounts:
     - name: ssl-secret
       mountPath: c:\sslconfig
     env:
     - name: M4A_CERT_YAML
       value: c:\sslconfig\config
   volumes:
   - name: ssl-secret
     secret:
       secretName: secret-name

    Em que:

    • mountPath é o mesmo caminho especificado por pfxpath no arquivo de configuração criado na Etapa 2.
    • M4A_CERT_YAML é uma variável de ambiente definida para o caminho completo para o arquivo YAML de configuração criado na Etapa 2.
    • secret-name é o nome do secret que você criou na Etapa 3.

Configurar SSL

É recomendável não armazenar chaves privadas de certificados SSL em uma imagem de contêiner, porque elas podem ser acessadas por qualquer pessoa que leia a imagem. O Migrate to Containers oferece várias maneiras de lidar com o SSL para Windows.

Usar um certificado autoassinado gerado automaticamente

Por padrão, um contêiner do Windows com uma vinculação HTTPS recebe um certificado autoassinado gerado automaticamente na inicialização do contêiner do Docker. Essa configuração permite testar a carga de trabalho migrada, mas não pode ser usada em um ambiente de produção. O certificado é autoassinado e gerado novamente sempre que o contêiner é executado.

Recomendado: use o Cloud Load Balancing, o Ingress ou o Cloud Service Mesh

É possível personalizar as vinculações no plano de migração para usar HTTP. Em seguida, use o Cloud Load Balancing, o Ingress ou o Cloud Service Mesh como front-end HTTPS para proteger o acesso externo. Essa opção permite proteger a comunicação externa sem incluir qualquer certificado dentro do cluster.

  • Para personalizar a vinculação, edite a definição de site no plano de migração que representa a migração para definir protocol como http:

    sites:
  site:
  - applications:
    - path: /
      virtualdirectories:
        - path: /
          physicalpath: '%SystemDrive%\inetpub\wwwroot'
          bindings:
          - port: 8080
            protocol: http
          name: Default Web Site

É possível encaminhar solicitações do front-end HTTPS para o caminho HTTP e a porta da carga de trabalho do Windows.

Armazenar certificados SSL como secrets do Kubernetes

Recomendamos o uso do Cloud Load Balancing, Ingress ou Cloud Service Mesh como front-end HTTPS para proteger o acesso externo. No entanto, também é possível armazenar certificados SSL como secrets do Kubernetes e montá-los no ambiente de execução no contêiner.

Para usar certificados SSL armazenados como secrets do Kubernetes, edite a imagem de implantação do contêiner. Para mais informações, consulte Implantar um contêiner ao armazenar certificados SSL como secrets do Kubernetes.

Configurar a geração de registros no Cloud Logging

O Migrate to Containers usa a ferramenta LogMonitor para extrair registros de um contêiner do Windows e encaminhá-los para o cluster do GKE. Esses registros são encaminhados automaticamente para o Cloud Logging, que oferece um conjunto de ferramentas para monitorar seus contêineres.

Por padrão, o Migrate to Containers permite que a geração de registros IIS monitore os registros do IIS e também encaminhe os registros de eventos do aplicativo/sistema para o Cloud Logging.

Configurar a geração de registros

A expansão do arquivo artifacts.zip gerado cria vários diretórios, incluindo o diretório m4a. O diretório contém uma pasta para cada imagem. Incluído no diretório m4a está o arquivo LogMonitorConfig.json, que pode ser editado para controlar a geração de registros.

Para mais informações sobre como editar LogMonitorConfig.json, consulte Como autorizar um arquivo de configuração.

Definir ACLs

Alguns aplicativos do IIS exigem a definição de permissões específicas das listas de controle de acesso (ACL) em arquivos e pastas para que eles sejam executados corretamente. O Migrate to Containers verifica automaticamente todos os aplicativos IIS migrados e adiciona todas as permissões específicas definidas na VM de origem que se aplicam às contas de IIS (a conta IUSR e o grupo IIS_IUSRS), aplicando-as aos arquivos e diretórios copiados na imagem do contêiner gerada.

Como as imagens de contêiner do Windows não aceitam a configuração de ACLs como parte do comando COPY do Docker, as ACLs são definidas em um script chamado set_acls.bat. O Migrate to Containers cria automaticamente set_acls.bat no diretório da imagem gerada para seu aplicativo do Windows específico. Em seguida, o Migrate to Containers chama set_acls.bat ao executar o comando docker build.

Edite set_acls.bat para adicionar ou remover permissões personalizadas ou permissões não relacionadas a usuários IIS específicos e que, portanto, não foram detectadas pelo Migrate to Containers.

O script usa a ferramenta integrada icacls do Windows para definir permissões.

Sobre o cache de conjunto global do .NET

O Migrate to Containers verifica o arquivo cache de conjunto global (GAC, na sigla em inglês) do .NET para recursos .NET instalados na máquina de origem e que não estão disponíveis como parte das imagens oficiais. Qualquer DLL descoberta é copiada para o contexto do Docker e instalada como parte da criação da imagem de destino por um script de utilitário install_gac.ps1.

Todos os conjuntos do .NET são copiados para o contexto do Docker no diretório m4a\gac. Para remover os conjuntos da imagem, exclua-os do diretório m4a\gac.

Registro de DLL do objeto COM

As DLLs que expõem objetos COM são verificadas e registradas automaticamente. Durante a fase de extração, os arquivos copiados são verificados quanto a DLLs registradas como objetos COM, que são então registrados no contêiner.

Esse processo ocorre sem a entrada do usuário. No entanto, é possível influenciar esse processo adicionando mais DLLs que serão copiadas. Se necessário, essas DLLs são verificadas por sua vez e registradas.

A seguir

  • Saiba como criar e implantar cargas de trabalho baseadas no Windows.