Antes de começar

Antes de iniciar uma migração, é necessário executar as tarefas a seguir.

Instalar o Migrate to Containers

É preciso instalar o Migrate to Containers no cluster de processamento. Um cluster de processamento é um cluster do Google Kubernetes Engine (GKE) ou Anthos com os componentes do Migrate to Containers instalados e usados para migrar VMs. Consulte Visão geral da instalação para ver todas as instruções de instalação.

Como opção, instale o Migrate for Compute Engine

Se você quiser usar o Migrate to Containers para migrar VMs do Linux para o Google Cloud da VMware, da AWS e do Azure, instale o Migrate for Compute Engine que gerencia o transporte. Para mais informações, consulte Configurar o Migrate for Compute Engine.

Confirme o nome do bucket do Cloud Storage

O Migrate to Containers usa um bucket do Google Cloud Storage como o repositório de artefatos. Você precisa saber o nome do bucket para fazer uma migração.

O nome do bucket do Cloud Storage depende da plataforma usada para hospedar o cluster de processamento:

  • Para clusters de processamento hospedados no Google Cloud, o instalador do Migrate to Containers cria automaticamente um bucket padrão chamado:

    GCP_PROJECT-migration-artifacts
  • Quando você instala o Migrate to Containers em clusters do Anthos no VMware ou em clusters do Anthos na AWS, nenhum bucket padrão é criado. É preciso criar um por conta própria como parte da configuração dos repositórios usados pelo cluster. Consulte Como definir repositórios de dados para mais informações.

Para visualizar a lista de buckets do Cloud Storage:

  1. Abra o navegador do Cloud Storage no Console do Google Cloud.

    Abrir o navegador do Cloud Storage

  2. Veja a lista de buckets para determinar seu nome.

Faça upload do binaryAppScanner.jar

O Migrate to Containers automatiza o uso de binaryAppScanner.jar, disponível como parte do IBM WebSphere Application Server Migration Toolkit para binários de aplicativo (em inglês), para extrair informações de configuração e arquivos para aplicativos WAS na VM de origem.

Antes de fazer uma migração, você precisa:

Para fazer upload de binaryAppScanner.jar para o Cloud Storage:

  1. Faça o download do arquivo do instalador, binaryAppScannerInstaller.jar, de aqui. Você precisa aceitar o contrato de licença como parte do download.

  2. Execute o seguinte comando para extrair o arquivo binaryAppScanner.jar e aceitar o Contrato de Licença:

    java -jar binaryAppScannerInstaller.jar --acceptLicense --verbose
  3. Especifique o diretório de destino para a extração. Por exemplo, /tmp O instalador cria um diretório chamado /wamt abaixo do diretório de destino.

  4. Navegue até o diretório /wamt. Exemplo:

    cd /tmp/wamt
  5. Faça o upload do arquivo binaryAppScanner.jar para a raiz de um bucket do Cloud Storage:

    gsutil cp binaryAppScanner.jar gs://BUCKET_NAME

Revisar problemas abertos

Esta versão tem os seguintes problemas em aberto:

  • 182208300: ao criar uma imagem do Docker para o contêiner, examine os registros. Às vezes, uma etapa interna pode falhar, mesmo quando o comando de compilação mostra que a compilação foi bem-sucedida.

  • 187683152: o Migrate to Containers não reconhece bibliotecas compartilhadas fora de /opt. Portanto, os aplicativos que dependem de bibliotecas compartilhadas fora de /opt não funcionarão no contêiner de destino.

    A solução alternativa é adicioná-los manualmente ao YAML WebSphereGenerateArtifactsFlow antes de iniciar a etapa de geração de artefatos.

  • 183383198: a variável de ambiente WAS_HOME especifica onde o WAS tradicional está instalado. Se o Migrate to Containers não puder determinar o valor de WAS_HOME ou se a VM não tiver o WAS tradicional instalado, o comando migctl migration status não mostrará que o status da migração é ERROR/RETRYING, isso indica que o status é RUNNING. Para ver o erro, use a forma detalhada do comando:

    migctl migration status -v

    Para mais informações, consulte Como processar um erro com a variável de ambiente WAS_HOME.

  • 183600316: uma migração pode falhar para aplicativos que foram implantados como um arquivo WAR, em vez de ser implantado como um arquivo EAR.

Próximas etapas