Preparar um cluster do Windows para implantação

Nesta página, discutimos alguns cenários que podem exigir a personalização dos artefatos de migração.

Antes de começar

Neste documento, consideramos que você concluiu a migração.

Verificar se o cluster de destino tem acesso de leitura ao registro do Docker

Como parte da migração, o Migrate to Containers faz upload de imagens do Docker que representam uma VM migrada para um registro do Docker. Essas imagens do Docker representam os arquivos e diretórios da VM de migração.

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

Para mais informações, consulte Como definir repositórios de dados.

Implantar uma carga de trabalho em um projeto do Google Cloud diferente daquele usado para migração

Normalmente, você tem vários projetos do Google Cloud no seu ambiente. Se você realizar uma migração em um projeto do Google Cloud, mas quiser implantar a carga de trabalho migrada em um cluster em um projeto diferente, verifique se tem as permissões configuradas corretamente.

Por exemplo, você executa a migração no projeto A. Nesse caso, a carga de trabalho migrada é copiada para um bucket do Container Registry no projeto A. Por exemplo:

gcr.io/project-a/image_name:image_tag

Em seguida, implante a carga de trabalho em um cluster no projeto B. Se você não configurar as permissões corretamente, o pod da carga de trabalho não será executado porque o cluster no projeto B não tem acesso de envio de imagem ao projeto A. Em seguida, você verá um evento no pod contendo uma mensagem no formulário:

Failed to pull image "gcr.io/project-a/image_name:image_tag...
pull access denied...
repository does not exist or may acquire 'docker login'...

Todos os projetos que ativaram a API Compute Engine têm uma conta de serviço padrão do sistema do Compute Engine com o e-mail a seguir: 

PROJECT_NUMBER-compute@developer.gserviceaccount.com

Em que PROJECT_NUMBER é o número do projeto B.

Para solucionar esse problema, verifique se a conta de serviço padrão do Compute Engine para o projeto B tem as permissões necessárias para acessar o bucket do Container Registry. Por exemplo, é possível usar o seguinte comando gcloud storage para ativar o acesso:

gcloud storage buckets add-iam-policy-binding gs://artifacts.project-a.appspot.com --member=serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com --role=roles/storage.objectViewer

Implantar em um cluster de destino usando o Container Registry como o registro do Docker

Para que um cluster de destino tenha acesso ao Container Registry, crie um secret do Kubernetes que contenha as credenciais necessárias para acessar o Container Registry:

  1. Crie uma conta de serviço para implantar uma migração, conforme descrito em Como criar uma conta de serviço para acessar o Container Registry e o Cloud Storage.

    Esse processo faz o download de um arquivo de chave JSON chamado m4a-install.json.

  2. Crie um secret do Kubernetes que contenha as credenciais necessárias para acessar o Container Registry:

    kubectl create secret docker-registry gcr-json-key \
 --docker-server=gcr.io --docker-username=_json_key --docker-password="$(cat ~/m4a-install.json.json)" \
 --docker-email=account@project.iam.gserviceaccount.com

    em que:

    • docker-registry especifica o nome do secret do Kubernetes. Neste exemplo, gcr-json-key;
    • docker-server=gcr.io especifica o Container Registry como o servidor.
    • docker-username=_json_key especifica que o nome de usuário está no arquivo de chave JSON;
    • docker-password especifica o uso da senha no arquivo de chave JSON.
    • docker-email especifica o endereço de e-mail da conta de serviço.

  3. Configure o secret do Kubernetes de uma das seguintes maneiras:

    • Alterando o valor padrão de imagePullSecrets:

      kubectl patch serviceaccount default -p '{"imagePullSecrets": [{"name": "gcr-json-key"}]}'

    • Editar o arquivo deployment_spec.yaml para adicionar o valor imagePullSecrets à definição spec.template.spec. Ao usar o WebSphere tradicional, o arquivo YAML de implantação é chamado twas_deployment_spec.yaml, liberty_deployment_spec.yaml ou openliberty_deployment_spec.yaml, dependendo do destino.

      spec:
  containers:
  - image: gcr.io/PROJECT_ID/mycontainer-instance:v1.0.0
    name: mycontainer-instance
    ...
  volumes:
  - hostPath:
      path: /sys/fs/cgroup
      type: Directory
    name: cgroups
  imagePullSecrets:
  - name: gcr-json-key

      Substitua PROJECT_ID pela ID do seu projeto.

  4. Implante o secret da carga de trabalho, se houver secrets.yaml. Haverá um arquivo de segredos para cargas de trabalho baseadas no Tomcat e cargas de trabalho baseadas no WebSphere tradicional com o Liberty. O arquivo do Liberty é chamado liberty-secrets.yaml.

    kubectl apply -f secrets.yaml

Implantar em um cluster de destino usando um registro do Docker com autenticação básica

Se você usa um registro do Docker para armazenar imagens de migração, o registro precisa ser compatível com a autenticação básica com um nome de usuário e uma senha. Como há muitas maneiras de configurar uma conexão somente leitura a um registro do Docker, use o método apropriado para sua plataforma de cluster e o registro do Docker.

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.