Preparar um cluster do Linux para implantação

Nesta página, descrevemos como preparar o cluster de destino para a implantação.

Antes de começar

Neste documento, consideramos que você já concluiu a migração e tem os artefatos gerados resultantes.

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. 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 gsutil para ativar o acesso:

gsutil iam ch serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com:objectViewer gs://artifacts.project-a.appspot.com

Implantar cargas de trabalho no cluster de processamento

É possível implantar a carga de trabalho migrada no mesmo cluster que você usou para realizar a migração, chamado de cluster de processamento do Migrate to Containers. Na maioria das situações, não é necessário realizar outras configurações no cluster de processamento porque ele já requer acesso de leitura ou gravação ao registro do Docker para realizar uma migração.

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

    onde:

    • 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.

A seguir