Personalizar o plano de migração de servidores JBoss

Importante: a interface do Migrate to Containers no console do Google Cloud, migctl, e os CRDs que usam clusters de processamento para migrar cargas de trabalho para o Google Cloud foram descontinuados. Eles podem ser usados pelos usuários até maio de 2024. Depois dessa data, eles não estarão mais disponíveis. Se você não conhece o Migrate to Containers, use a CLI do Migrate to Containers para realizar migrações na máquina local. Para mais informações, consulte Arquitetura da CLI do Migrate to Containers.

Revise o arquivo do plano de migração gerado ao criar a migração. Personalize o arquivo antes de realizar a migração. Os detalhes do plano de migração são usados para extrair os artefatos de contêiner da carga de trabalho da origem.

Nesta seção, você verá uma descrição do conteúdo da migração e dos tipos de personalização disponíveis antes de executar a migração e gerar artefatos de implantação.

Antes de começar

Para seguir este tópico, é necessário criar uma migração e ter o arquivo do plano de migração.

Editar o plano de migração

Para editar o plano de migração, use a ferramenta migctl ou o console do Google Cloud.

migctl

É necessário fazer o download do plano de migração antes de editá-lo:

1. Faça o download do plano de migração.

   migctl migration get my-migration
   

2. Edite o plano de migração transferido por download, my-migration.yaml, em um editor de texto.

3. Quando tiver terminado as edições, salve e faça upload do plano de migração revisado:

   migctl migration update my-migration --main-config my-migration.yaml
   

4. Repita essas etapas se mais alterações forem necessárias.

Console

Edite o plano de migração no console do Google Cloud usando o editor YAML.

1. Abra a página "Migrate to Containers" no Console do Google Cloud.

   Acesse a página do Migrate to Containers.

2. Clique na guia Migrações para exibir uma tabela com as migrações disponíveis.

3. Na linha da migração desejada, selecione o Nome da migração para abrir a guia Detalhes.

4. Selecione a guia YAML.

   Observação: também é possível selecionar Fazer o download do plano de migração para fazer o download de uma cópia local.

5. Edite o plano de migração conforme necessário.

6. Quando terminar de editar, será possível:

   1. salvar o plano de migração. Em seguida, execute manualmente a migração para gerar os artefatos de migração. Use o procedimento mostrado em Como executar uma migração.

   2. salvar e gerar os artefatos. Execute a migração usando as edições feitas para gerar os artefatos de migração. O processo é o mesmo descrito em Como executar uma migração. Depois, monitore a migração conforme descrito em Como monitorar uma migração.

CRD

É necessário fazer o download do plano de migração, editá-lo e aplicá-lo. O plano de migração é armazenado dentro do campo appXGenerateArtifactsConfig do CRD AppXGenerateArtifactsFlowSpec.

1. Consiga o nome do AppXGenerateArtifactsFlow:

   kubectl get migrations.anthos-migrate.cloud.google.com -n v2k-system -o jsonpath={.status.migrationPlanRef.name} my-migration

   O padrão de nomenclatura é retornado na forma de appx-generateartifactsflow-id.

2. Para encontrar o plano de migração por nome e gravar em um arquivo chamado my-plan.yaml:

   kubectl -n v2k-system get appxgenerateartifactsflows.anthos-migrate.cloud.google.com -o jsonpath={.spec.appXGenerateArtifactsConfig} appx-generateartifactsflow-id > my-plan.yaml

3. Edite o plano de migração conforme necessário.

4. Aplique o arquivo:

   kubectl patch appxgenerateartifactsflows.anthos-migrate.cloud.google.com --type merge -n v2k-system --patch '{"spec": {"appXGenerateArtifactsConfig": '"$(jq -n --rawfile plan my-plan.yaml '$plan')"'}}' appx-generateartifactsflow-id

Estrutura do plano de migração

O plano de migração de uma carga de trabalho do JBoss tem a estrutura a seguir, que pode ser personalizada conforme descrito nas próximas seções.

# Server name. Edit this to change the artifacts naming.
serverName: jboss-server
# JBoss home directory.
home: /opt/jboss/wildfly
# Parent Wildfly image for the generated container image.
fromImage: docker.io/jboss/wildfly:10.1.0.Final
# JBoss home directory in the target image.
targetImageHome: /opt/wildfly
# Configuration file path from source VM.
configurationFile: /opt/jboss/wildfly/standalone/configuration/standalone.xml
# Ports list to expose on the generated container image.
ports:
- name: management-http
  port: 9990
- name: management-https
  port: 9993
- name: ajp
  port: 8009
- name: http
  port: 8080
- name: https
  port: 8433
- name: txn-recovery-environment
  port: 4712
- name: txn-status-manager
  port: 4713
# List of deployments files to copy.
deployments:
  directory: /opt/jboss/wildfly/standalone/deployments
  applications:
  - test.war
# List of modules to copy in rsync filter format.
# Note: files under '/system/layers/base/' are JBoss/Wildfly binaries and should be copied only if they have been modified.
modules:
- '- system/layers/base'
# External paths required for running the JBoss server or apps.
additionalFiles: []
# Sensitive data which is filtered out of the container image.
# If includeSensitiveData is set to true the sensitive data is mounted on the container.
sensitiveData:
  includeSensitiveData: false
  sensitiveDataPaths:
  - /opt/jboss/wildfly/standalone/configuration/application-roles.properties
  - /opt/jboss/wildfly/standalone/configuration/application-users.properties
  - /opt/jboss/wildfly/standalone/configuration/application.keystore
  - /opt/jboss/wildfly/standalone/configuration/mgmt-groups.properties
  - /opt/jboss/wildfly/standalone/configuration/mgmt-users.properties

Para adicionar informações conforme necessário, analise os detalhes do plano de migração e os comentários de orientação.

Mais especificamente, considere editar as seguintes seções:

Especificar a imagem do Docker

No plano de migração, geramos uma tag de imagem da comunidade do Docker com base na versão do JBoss. A versão do JBoss é detectada e convertida em uma versão principal (versões secundárias não são compatíveis). Se não detectarmos uma versão do JBoss, o fromImage conterá uma string vazia.

No plano de migração, o campo fromImage representa a tag de imagem do Docker usada como base da imagem do contêiner.

As versões originais do JBoss detectadas na VM de origem estão contidas em discovery-report.yaml, que é gerado pela descoberta inicial.

Se você quiser alterar a imagem da comunidade do Docker ou fornecer sua própria imagem do Docker, modifique a tag fromImage no plano de migração usando o seguinte formato:

# Parent Wildfly image for the generated container image.
 fromImage: docker.io/jboss/wildfly:10.1.0.Final

O campo targetImageHome especifica o caminho do diretório inicial do JBoss na imagem de destino e é derivado do campo fromImage. Não é necessário alterar o valor desse campo, a menos que você use uma imagem JBoss com um valor inicial diferente.

Especificar aplicativos

Para excluí-los da imagem do contêiner, remova-os da lista.

Especificar módulos

A lista module contém os módulos JBoss atuais marcados com um sinal de adição ou subtração. Somente os módulos marcados com um sinal de adição serão adicionados à imagem de contêiner gerada. Os módulos marcados com um sinal de subtração, por exemplo, (/system/layers/base), já estão presentes na imagem da comunidade e não serão substituídos, a menos que você os marque novamente com um sinal de adição.

Configurar a migração de dados confidenciais

Para fazer upload de dados confidenciais no repositório, defina o campo includeSensitiveData no plano de migração como true. Os secrets são enviados em secrets.yaml

O campo sensitiveDataPaths especifica as listas de arquivos a serem filtrados do plano de migração. Esses arquivos podem conter informações confidenciais, como certificados, armazenamento de secrets, usuários e senhas usados pelo JBoss. Se você remover um caminho de arquivo do campo sensitiveDataPaths, o arquivo será enviado para a imagem.

A seguir

• Saiba como executar a migração.