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:
Ao usar o Compute Engine como origem de migração:
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.
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.
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.
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.
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
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.
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.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çõespath
e quaisquersharedLibraries
para que apenas um aplicativo seja especificado. Essa edição garante que cada aplicativo tenha a própria imagem de contêiner.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"
O app_name precisa ser exclusivo para cada app.
O campo
deployment
especifica o nome do app usado no arquivodeployment_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
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"
Defina outras propriedades que você quer personalizar.
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 usandogcloud builds
.deployment_spec.yaml
: o arquivo YAML usado para implantar a carga de trabalho criada porbuild.sh
. Usekubectl 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,
edeployment_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:
Abra o navegador do Cloud Storage no Console do Google Cloud:
Selecione o bucket usado na migração.
Para o aplicativo migrado, você verá os arquivos .ear e .py.
Também é possível ver os arquivos
Dockerfile
,build.sh
edeployment_spec.yaml
junto com todos os outros artefatos.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 deWAS_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.