Preparar um cluster do Windows para implantação

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

Antes de começar

Escolher e configurar seu registro do Docker

Como parte da implantação, você cria e faz upload da imagem 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 com suporte à 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, saiba como configurar o registro.

Configurar cargas de trabalho migradas para usar a 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 nós de cluster do Kubernetes host podem ser associados ao domínio, não os próprios contêineres.

Ao implantar os contêineres migrados em um cluster, é possível usar uma conta de serviço gerenciada de grupo (gMSA). Use a gMSA para executar o contêiner em uma identidade de conta de serviço específica. Anexe uma gMSA ao 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. É possível avaliar essas recomendações e modificá-las para o 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 ele usa um tipo de conta integrado, como ApplicationPoolIdentity, NetworkService, LocalSystem ou LocalService.

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

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

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

Configurar um cluster de destino para oferecer suporte à gMSA

Anexe uma gMSA ao 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 oferecer suporte à gMSA, você precisa:

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

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

Para conferir 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 do contêiner implantado. Essa opção permite proteger a comunicação externa sem incluir qualquer certificado no cluster. Para mais informações, consulte Como 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 os 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 SHA-1 do arquivo PFX, que pode ser recuperada usando o comando do PowerShell:

      Get-PfxCertificate -FilePath "path to pfx"

      Ou visualize no Certificate Manager 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 criado 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 no cluster.

  • Para personalizar a vinculação, edite a definição de site no plano de migração que a representa 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 pacote 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 IIS e encaminhe os logs 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 criar um arquivo de configuração.

Definir ACLs

Alguns aplicativos IIS exigem a definição de permissões específicas de listas de controle de acesso (ACL) em arquivos e pastas para serem 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 o aplicativo do Windows específico. Em seguida, o Migrate to Containers chama set_acls.bat ao executar o comando docker build.

Altere set_acls.bat para adicionar ou remover permissões personalizadas ou editar 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 assembly global do .NET

O Migrate to Containers verifica o cache de assembly global (GAC, na sigla em inglês) do .NET de 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 assemblies do .NET são copiados para o contexto do Docker no diretório m4a\gac. Para remover os assemblies 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 para identificar DLLs registradas como objetos COM, que são registrados no contêiner em seguida.

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

A seguir