Como migrar apps de uma VM tradicional da IBM WAS

As seções a seguir descrevem as etapas usadas para migrar aplicativos de uma VM tradicional do IBM WAS.

Sobre o migctl

O Migrate to Containers inclui a ferramenta de linha de comando migctl que você usa para executar todas as partes de uma migração, conforme descrito abaixo. A maneira como você executa migctl depende do tipo de desordem de processamento que usa para realizar a migração:

Ao usar um cluster de processamento do Google Kubernetes Engine (GKE) ou Anthos no Google Cloud, execute migctl no Cloud Shell.
Ao usar um cluster de processamento local do GKE, você instala e executa o migctl na estação de trabalho de administrador, conforme descrito nas instruções de instalação.

Como adicionar uma origem de migração

Antes de começar a migração, crie uma origem que represente a plataforma de onde a migração será feita. Ela será adicionada ao plano de migração. É possível usar origens de migração que foram configuradas anteriormente no Migrate to Containers para migrar outras VMs do Linux ou do Windows.

Defina a origem de migração da qual você está migrando usando o comando migclt source create:

Para um cluster de processamento implantado no Google Cloud, crie a origem:
1. Ao usar o Compute Engine como origem de migração:
  1. Crie uma conta de serviço para usar o Compute Engine como origem de migração e faça o download do arquivo de chave JSON, conforme descrito em Como configurar uma conta de serviço.
    
    Observação: as instruções a seguir pressupõem que o nome do arquivo de chave JSON é m4a-ce-src.json.
  2. Crie a origem usando a conta de serviço:
```
migctl source create ce my-was-src --project my-project --json-key m4a-ce-src.json
```
    Em que m4a-ce-src.json especifica a conta de serviço.
2. Ao usar AWS como origem de migração:
```
migctl source create aws my-was-src --manager-address 1.2.3.4 --cloud-details cloud-details --cloud-extension cloud-extension
```
  Especifique o nome da extensão do Migrate for Compute Engine e o nome dos detalhes da nuvem, conforme configurado no Migrate for Compute Engine. Para mais detalhes sobre a nuvem, consulte configurar o Migrate for Compute Engine.
  
  A senha do servidor de gerenciamento do Migrate for Compute Engine será solicitada.
3. Ao usar o Azure como origem da migração:
```
migctl source create azure my-was-src --manager-address 1.2.3.4 --cloud-details cloud-details --cloud-extension cloud-extension
```
  Especifique o nome da extensão do Migrate for Compute Engine e o nome dos detalhes da nuvem, conforme configurado no Migrate for Compute Engine. Para mais detalhes sobre a nuvem, consulte configurar o Migrate for Compute Engine.
  
  A senha do servidor de gerenciamento do Migrate for Compute Engine será solicitada.
4. Ao usar VMware como origem da migração:
```
migctl source create vmware my-was-src --manager-address 1.2.3.4 --cloud-extension cloud-extension
```
  Especifique o nome da extensão do Migrate for Compute Engine, conforme configurado no Migrate for Compute Engine.
  
  A senha do servidor de gerenciamento do Migrate for Compute Engine será solicitada.
Para um cluster de processamento do Anthos no local no VMware, crie a origem:
```
migctl source create local-vmware my-was-src --vc '1.2.3.4' --username 'admin'
```
Em que:

--vc especifica o nome DNS do vCenter ou o endereço IP do vCenter.

--username especifica o nome de usuário de um usuário que tem permissão para acessar o vCenter. Você receberá uma solicitação para digitar a senha do usuário.
Para um cluster de processamento do Anthos no AWS, crie a origem:
```
migctl source create local-aws local-aws-src --region my-region --access-key-id my-access-key-id
```
ou:
```
migctl source create local-aws local-aws-src --region my-region --credentials-file-path=credentials.csv
```
Em que:

--region especifica a região do Google Cloud do seu cluster.

--access-key-id especifica o ID da chave de acesso da AWS para um usuário que tem permissão para acessar a AWS. Você receberá uma solicitação para inserir a chave secreta para o código da chave de acesso. Consulte Como gerenciar chaves de acesso para usuários do IAM para saber mais.

--credentials-file-path especifica o caminho para um arquivo CSV, que você faz o download pelo console da AWS, contendo as credenciais. Consulte Como configurar grupos e papéis da instância do AWS IAM para mais informações sobre como criar o arquivo CSV.

Como criar uma migração

Comece a migrar aplicativos criando uma migração, o que resulta na criação de um objeto de plano de migração. É preciso realizar outras análises e personalizar o plano gerado antes de executar a migração, conforme descrito abaixo, em Como personalizar um plano de migração.

Um objeto de migração, implementado como uma Definição de recursos personalizados (CRD, na sigla em inglês) do Kubernetes, é usado para configurar e monitorar o processo de migração. Para mais informações, consulte a referência de CRD.

Ao criar uma migração, você especifica a sinalização intent com base na natureza da carga de trabalho. A IBM recomenda que aplicativos WAS não contenham informações de estado, mas precisam depender de repositórios de dados externos para armazenar essas informações. Um valor de Image significa que você está migrando binários e configurações de app sem estado e é o único intent compatível com apps tradicionais WAS. Consulte Como configurar o intent de migração para saber mais em intent.

Para criar uma migração:

Quando usar o Compute Engine como origem da migração, interrompa a VM de origem antes de criar uma migração. Depois que o objeto de migração for criado, reinicie a VM.
Crie a migração:
```
migctl migration create my-migration --source my-was-src --vm-id my-id --intent Image --os-type Linux --app-type websphere-traditional
```
Em que my-was-src especifica a origem da migração que você criou acima, e --vm-id especifica o nome da VM tradicional WAS.
Para ver o status da migração:
```
migctl migration status my-migration -v
```
Observação: se ver uma mensagem de erro com a mensagem "WAS_HOME not found", consulte Como processar um erro com a variável de ambiente WAS_HOME.

Quando o status mostrar que a operação foi concluída, avance para a próxima etapa.

Observação: esse processo pode levar vários minutos para ser concluído.

Como personalizar um plano de migração

Revise o arquivo do plano de migração gerado ao criar a migração e personalize-o antes de continuar com o processo de execução dela. Para saber mais, consulte Como personalizar um plano de migração.

Também é possível analisar o relatório de migração de aplicativos gerado pelo Toolkit de migração do IBM WebSphere Application Server para binários de aplicativo. O toolkit gera um relatório HTML para cada app na VM de origem. Veja o arquivo HTML para avaliar a migração do app.

Para analisar o relatório de migração do aplicativo:

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

Abrir o navegador do Cloud Storage
Navegue até a pasta /discovery no bucket de artefatos de migração no Google Cloud Storage.
Para cada aplicativo descoberto na VM, você verá um arquivo HTML chamado:

app-name.ear_MigrationReport.html
Selecione o arquivo HTML para visualizá-lo ou faça o download localmente para avaliar a migração.

Para personalizar o plano de migração:

Para personalizar o plano de migração, faça o download dele, edite-o e atualize-o usando migctl. O plano de migração é representado pelo CRD WebSphereGenerateArtifactsFlow:

Faça o download do plano de migração. O plano de migração é representado por um objeto WebSphereGenerateArtifactsFlow:
```
migctl migration get my-migration
```
Como você editará este arquivo, primeiro faça uma cópia para que possa recuperá-lo:
```
cp my-migration.yaml my-migration-original.yaml
```
Edite o plano de migração transferido por download, my-migration.yaml, em um editor de texto.
1. Verifique se há apenas uma propriedade path.
  
  O objeto WebSphereGenerateArtifactsFlow contém uma propriedade path para cada app que o Migrate to Containers descobriu na VM tradicional do WAS. Exclua todas as definições path e quaisquer sharedLibraries para que apenas um aplicativo seja especificado. Essa edição garante que cada aplicativo tenha a própria imagem de contêiner.
  
  Observação: primeiro salve uma cópia do objeto original WebSphereGenerateArtifactsFlow para poder migrar posteriormente outros apps em a VM.
  
  O objeto WebSphereGenerateArtifactsFlow lista todos os apps no formato:
```
spec:
appBinariesMigrationToolkit:
  applications:
  -  path: "PATH_TO_APP1"
    sharedLibraries:
    - sharedLibrary1
      sharedLibrary2
  -  path: "PATH_TO_APP2"
    sharedLibraries:
    - sharedLibrary1
  -  path: "PATH_TO_APP3" 
```
2. O app_name precisa ser exclusivo para cada app.
  
  O campo deployment especifica o nome do app usado no arquivo deployment_spec.yaml. Defina este campo como um valor exclusivo para cada app no CRD. Você precisa implantar cada contêiner de app com o próprio nome.
```
deployment:
 appName: app-name
```
3. Defina o nome da tag da imagem.
  
  O valor do campo image define o nome e o local das imagens criadas a partir de uma VM migrada. Por padrão, uma tag correspondente ao carimbo de data/hora da migração é aplicada automaticamente ao valor "image_name". Essa tag está neste formato:
  
  MM-DD-YYYY--hh:mm:ss
  
  É possível usar o carimbo de data/hora para diferenciar migrações. Também é possível aplicar sua própria tag. Por exemplo, edite o CRD e adicione a tag rev1, conforme mostrado abaixo:
  
  name: "image_name:rev1"
  
  Observação: como a tag é usada para armazenar os valores em cache, confirme que ela seja exclusiva para todos os CRDs.
4. Defina outras propriedades que você quer personalizar.
5. Salve o arquivo.
Quando tiver terminado as edições, faça upload do plano de migração editado:
```
migctl migration update my-migration --file my-migration.yaml
```

Agora você pode migrar o app. Depois de concluir a migração de um aplicativo, edite o objeto WebSphereGenerateArtifactsFlow para cada aplicativo adicional na VM que você quer migrar.

Como gerar e analisar artefatos de migração

Comece a migrar as VMs com um comando que gera os artefatos de migração usando o cluster de processamento criado em Como instalar o Migrate to Containers.

Para executar uma migração e gerar os artefatos de migração:

Execute a migração:

migctl migration generate-artifacts my-migration

Para ver o status da migração:
```
migctl migration status my-migration
```

Quando o status mostrar que a operação foi concluída, revise os artefatos gerados.

A migração de um aplicativo de uma VM de origem cria um conjunto de arquivos, chamados de artefatos de migração, que você usa para implantar sua carga de trabalho migrada. Após concluir a migração de uma carga de trabalho, revise os artefatos usados para implantação.

Os artefatos de migração estão localizados em um bucket do Cloud Storage. Incluídos no bucket estão estes arquivos:

Dockerfile: o Dockerfile usado para criar a imagem da VM migrada.
build.sh: o script para criar sua carga de trabalho de implantação usando gcloud builds.
deployment_spec.yaml: o arquivo YAML usado para implantar a carga de trabalho criada por build.sh. Use kubectl apply com esse arquivo para implantar a carga de trabalho em um cluster, como um cluster de produção ou de teste. Esse arquivo também inclui todos os mapeamentos de portas exigidos pelo aplicativo.
Para cada aplicativo na VM:
- Um arquivo .ear contendo o binário do aplicativo.
- Um script Python .py usado para criar o contêiner do app.

Para visualizar o artefato gerado:

Use o seguinte comando para fazer o download dos arquivos de artefato gerados:
```
migctl migration get-artifacts my-migration
```
Esse comando faz o download dos seguintes arquivos usados para implantar o aplicativo migrado: Dockerfile, build.sh, e deployment_spec.yaml.

Na próxima seção, Como criar uma imagem de contêiner de aplicativo, descrevemos como criar o contêiner do aplicativo.
Também é possível ver e fazer o download desses arquivos no Console do Google Cloud:
1. Abra o navegador do Cloud Storage no Console do Google Cloud:
  
  Abrir o navegador do Cloud Storage
2. Selecione o bucket usado na migração.
3. Para o aplicativo migrado, você verá os arquivos .ear e .py.
4. Também é possível ver os arquivos Dockerfile, build.sh e deployment_spec.yaml junto com todos os outros artefatos.
5. Selecione um arquivo para ver o conteúdo dele ou fazer o download dele.

Como criar uma imagem de contêiner do aplicativo

Usando os artefatos de migração, crie uma imagem de contêiner para o aplicativo migrado que você possa implantar no seu cluster de destino. Use build.sh para criar o contêiner criado como parte dos artefatos de migração:

Crie o contêiner do app usando o script de compilação:
```
chmod +x ./build.sh
./build.sh`
```
Se quiser, defina o tipo de serviço em deployment_spec.yaml.

Por padrão, o Migrate to Containers define o tipo de serviço como ClusterIP, o que torna o serviço disponível apenas para os pods no cluster de implantação.

Se você quiser acessar o serviço externamente, defina o tipo de serviço como LoadBalancer ou qualquer outro tipo exigido pela implantação. Exemplo:
```
apiVersion: v1
kind: Service
…
spec:
  …
  type: LoadBalancer
```

Agora é possível implantar o contêiner do aplicativo.

Como implantar um contêiner de aplicativo em um cluster de destino

Depois de criar a imagem do contêiner do aplicativo, implante a imagem no cluster de destino.

Certifique-se de que o cluster de destino atenda aos pré-requisitos descritos nos requisitos do sistema de migração.
Implante a imagem do contêiner usando o arquivo deployment_spec.yaml:
```
kubectl apply -f deployment_spec.yaml
```
Se você editou o arquivo deployment_spec.yaml para permitir que o serviço seja acessado externamente, conforme descrito acima, determine o endereço IP público e a porta do serviço:
```
kubectl get service
```
As colunas IP externo mostram o endereço IP e a porta.
Abra o endereço IP externo e a porta do serviço em um navegador:

http://IP:PORT

Como monitorar cargas de trabalho migradas

Por padrão, as informações de registro dos aplicativos implantados são gravadas em stdout pelos processos iniciados por init.

Você também pode examinar o conteúdo de /var/log/syslog para informações de registro.

Como processar um erro com a variável de ambiente WAS_HOME

A variável de ambiente WAS_HOME especifica onde o WAS tradicional está instalado, como /opt/IBM/WebSphere/AppServer/. O Migrate to Containers usa esse valor quando você cria uma migração para executar scripts que buscam informações sobre um app e determina o caminho de um perfil de app.

O Migrate to Containers tenta localizar a pasta de instalação do WebSphere automaticamente pesquisando caminhos comuns em que os binários do Linux estão instalados. Se o Migrate to Containers não localizar a pasta de instalação ou substituir a pasta determinada pela pesquisa automática, defina o valor de WAS_HOME.

Se o Migrate to Containers usa um valor incorreto de WAS_HOME ao criar uma migração, o Migrate to Containers registrará um erro. É possível ver esse erro ao verificar o status da migração:

migctl migration status MIGRATION_NAME -v

O erro aparece neste formato:

Warning  PodFailure 2m55s (x49 over 123m) WebSphereDiscoveryTask MIGRATION_NAME
Pod reached error state. Retrying by recreating pod. Details: Container `lister` terminated: (no termination message provided).
Container `aggregator` terminated: (no termination message provided).
Container `websphere-discoverer` terminated:
{"code": "DIS-11", "reason": "WAS_HOME not found", "description": "WAS_HOME installation directory was not found"}.

Para definir explicitamente o valor de WAS_HOME:

Se você estiver usando migctl para criar a migração, transmita o valor de WAS_HOME ao criar a migração:

migctl  migration create  MIGRATION_NAME \
 --source SOURCE_NAME --vm-id VM_ID --app-type websphere-traditional \
 --parameters WAS_HOME_paths=/FOLDER_PATH/

Se você estiver usando arquivos CRD para realizar a migração, edite o arquivo yaml de migração para definir o caminho:

apiVersion: anthos-migrate.cloud.google.com/v1beta2
kind: Migration
metadata:
name: my-migration
namespace: v2k-system
annotations:
  anthos-migrate.cloud.google.com/initial-intent: Image
spec:
osType: Linux
parameters:
- name: WAS_HOME_paths
  value: /FOLDER_PATH/
sourceSnapshot:
sourceProvider: my-ce-src
sourceId: my-id

Em seguida, execute novamente a operação de criação de migração.