Prepare um cluster do Windows para implementação

Esta página descreve como preparar o cluster do Windows para a implementação.

Antes de começar

Escolha e configure o seu registo do Docker

Como parte da implementação, cria e carrega a imagem Docker do seu contentor para um registo Docker.

Para o registo do Docker, pode optar por usar:

  • Artifact Registry

  • Qualquer registo do Docker que suporte a autenticação básica

A solução recomendada é usar o Artifact Registry no mesmo projeto do cluster de implementação. O GKE pode aceder ao registo por predefinição. Para mais informações, consulte os requisitos de integração com o GKE.

Se quiser usar um registo Docker privado, saiba como configurar o registo.

Configure cargas de trabalho migradas para usar gMSA

As cargas de trabalho da aplicação IIS do Windows são frequentemente associadas ao Active Directory (AD) e funcionam com identidades de domínio. Quando migra estas VMs para contentores, os próprios contentores não são associados a um domínio, mas sim os respetivos nós do cluster do Kubernetes anfitrião podem ser associados a um domínio.

Quando implementa os contentores migrados num cluster, pode usar uma conta de serviço gerida por um grupo (gMSA). Use a gMSA para executar o contentor numa identidade de conta de serviço específica. Anexa um gMSA no cluster do Kubernetes como parte da configuração do pod, em vez de como uma configuração de identidade estática na imagem do contentor.

A migração para contentores ajuda no processo de transformação das suas cargas de trabalho. A migração para contentores descobre automaticamente a configuração dos conjuntos de aplicações do IIS e adiciona recomendações ao plano de migração gerado. Em seguida, pode avaliar estas recomendações e modificá-las para o seu ambiente e requisitos específicos.

Se o Migrate to Containers determinar que a configuração de um conjunto de aplicações não requer uma gMSA, mantém a configuração original do conjunto de aplicações. Por exemplo, quando usa um tipo de conta incorporado, como ApplicationPoolIdentity, NetworkService, LocalSystem ou LocalService.

Para suportar o gMSA num contentor Windows migrado, tem de:

  1. Edite o plano de migração para definir as propriedades necessárias para configurar o contentor migrado de modo a usar uma gMSA.

  2. Configure o cluster de destino que aloja o contentor implementado.

Configure um cluster de destino para suportar o gMSA

Anexa uma gMSA no cluster do Kubernetes como parte da configuração do pod, em vez de como uma configuração de identidade estática na imagem do contentor.

Para configurar um cluster que aloja o contentor do Windows migrado para suportar o gMSA, tem de ter:

  1. Configurou o Active Directory para que as VMs se juntem automaticamente a um domínio.

  2. Configurou o gMSA para contentores e pods do Windows.

Para mais informações, consulte o seguinte:

Implemente um contentor quando armazena certificados SSL como segredos do Kubernetes

Recomendamos que use o Cloud Load Balancing, Ingress, ou o Cloud Service Mesh como um frontend HTTPS para proteger o acesso externo ao seu contentor implementado. Esta opção permite-lhe proteger a comunicação externa sem incluir certificados no cluster. Para mais informações, consulte o artigo Personalizar um plano de migração.

Também pode armazenar certificados Secure Sockets Layer (SSL) como segredos do Kubernetes e montá-los no tempo de execução no contentor.

Para usar segredos do Kubernetes:

  1. Crie um ficheiro PFX com o certificado e a palavra-passe.

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

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

    Onde:

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

    • sslport especifica a porta a ouvir para ligações SSL (normalmente, 443).

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

    • password especifica a palavra-passe do ficheiro PFX.

    • thumbprint especifica a impressão digital SHA-1 do ficheiro PFX que pode ser obtida através do comando do PowerShell:

      Get-PfxCertificate -FilePath "path to pfx"

      Em alternativa, veja-o no Gestor 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 do volume na implementaçã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

    Onde:

    • mountPath é o mesmo caminho especificado por pfxpath no ficheiro de configuração que criou no passo 2.
    • M4A_CERT_YAML é uma variável de ambiente definida para o caminho completo do ficheiro YAML de configuração que criou no passo 2.
    • secret-name é o nome do segredo que criou no passo 3.

Configure o SSL

Recomendamos que não armazene chaves privadas de certificados SSL numa imagem de contentor, uma vez que são acessíveis a qualquer pessoa que leia a imagem. A migração para contentores oferece várias formas de processar o SSL para o Windows.

Use um certificado autogerado autoassinado

Por predefinição, a um contentor Windows com uma associação HTTPS é atribuído um certificado autossinado gerado automaticamente na inicialização do contentor Docker. Esta configuração permite-lhe testar a carga de trabalho migrada, mas não pode ser usada num ambiente de produção. O certificado é autoassinado e regenerado sempre que o contentor é executado.

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

Pode personalizar as associações no plano de migração para usar HTTP. Em seguida, use o Cloud Load Balancing, Ingress> ou o Cloud Service Mesh como um front-end HTTPS para proteger o acesso externo. Esta opção permite-lhe proteger a comunicação externa sem incluir certificados no cluster.

  • Para personalizar a associação, edite a definição 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

Em seguida, pode encaminhar pedidos do front-end HTTPS para o caminho e a porta HTTP da carga de trabalho do Windows.

Armazene certificados SSL como segredos do Kubernetes

Recomendamos que use o Cloud Load Balancing, Ingress, ou Cloud Service Mesh como um front-end HTTPS para proteger o acesso externo. No entanto, também pode armazenar certificados SSL como segredos do Kubernetes e montá-los em tempo de execução no contentor.

Para usar certificados SSL armazenados como segredos do Kubernetes, tem de editar a imagem de implementação do contentor. Para mais informações, consulte o artigo Implemente um contentor quando armazena certificados SSL como segredos do Kubernetes.

Configure o registo no Cloud Logging

A ferramenta Migrate to Containers usa a ferramenta LogMonitor para extrair registos de um contentor do Windows e encaminhá-los para o seu cluster do GKE. Em seguida, estes registos são encaminhados automaticamente para o Cloud Logging, que oferece um conjunto de ferramentas para monitorizar os seus contentores.

Por predefinição, a ferramenta Migrate to Containers ativa o registo do IIS para monitorizar os registos do IIS e também encaminha os registos de eventos de aplicações ou do sistema para o Cloud Logging.

Configure o registo

A expansão do ficheiro artifacts.zip gerado cria vários diretórios, incluindo o diretório m4a. O diretório contém uma pasta para cada imagem. O diretório m4a inclui o ficheiro LogMonitorConfig.json que pode editar para controlar o registo.

Para mais informações sobre a edição de LogMonitorConfig.json, consulte o artigo Criar um ficheiro de configuração.

Defina LCAs

Algumas aplicações IIS requerem que defina autorizações específicas de listas de controlo de acesso (ACL) em ficheiros e pastas para que as aplicações funcionem corretamente. A migração para contentores analisa automaticamente todas as aplicações IIS migradas e adiciona todas as autorizações específicas definidas na VM de origem que se aplicam às contas IIS (a conta IUSR e o grupo IIS_IUSRS) e aplica-as aos ficheiros e diretórios copiados na imagem do contentor gerada.

Uma vez que as imagens de contentores do Windows não suportam a definição de ACLs como parte do comando COPY do Docker, as ACLs são definidas num script denominado set_acls.bat. A migração para contentores cria automaticamente set_acls.bat no diretório da imagem gerada para a sua aplicação Windows específica. Migre para contentores e, em seguida, chame set_acls.bat quando executar o comando docker build.

Edite set_acls.bat para adicionar ou remover autorizações personalizadas, ou edite autorizações que não estejam relacionadas com utilizadores específicos do IIS e, por isso, não foram detetadas pela ferramenta Migrate to Containers.

O script usa a ferramenta icacls incorporada do Windows para definir autorizações.

Acerca da cache de assemblagens global do .NET

A migração para contentores analisa a cache de assemblagens global (GAC) do .NET da imagem de origem à procura de recursos do .NET instalados na máquina de origem e não disponíveis como parte das imagens oficiais. Qualquer DLL detetada é copiada para o contexto do Docker e instalada como parte da criação da imagem de destino por um script de utilidade install_gac.ps1.

Todas as assemblagens .NET são copiadas para o contexto do Docker no diretório m4a\gac. Para remover montagens da imagem, elimine-as do diretório m4a\gac.

Registo de DLL de objeto COM

As DLLs que expõem objetos COM são analisadas e registadas automaticamente. Durante a fase de extração, os ficheiros copiados são analisados para encontrar DLLs registadas como objetos COM, que são depois registados no contentor.

Este processo ocorre sem a intervenção do utilizador. No entanto, pode influenciar este processo adicionando mais DLLs a copiar. Se necessário, estas DLLs são verificadas por sua vez e registadas.

O que se segue?