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:
Qualquer registro do Docker compatível com a autenticação básica
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:
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
.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.
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 valorimagePullSecrets
à definiçãospec.template.spec
. Ao usar o WebSphere tradicional, o arquivo YAML de implantação é chamadotwas_deployment_spec.yaml
,liberty_deployment_spec.yaml
ouopenliberty_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.
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 é chamadoliberty-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
- Saiba como criar e implantar cargas de trabalho baseadas no Linux.
- Saiba como personalizar artefatos de migração para cargas de trabalho baseadas no Windows.
- Saiba como criar e implantar cargas de trabalho baseadas no Windows.
- Saiba como analisar arquivos gerados para implantar um contêiner do sistema Linux.