Modernize cargas de trabalho tradicionais

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.

Neste tópico, descrevemos como modernizar cargas de trabalho baseadas em VM em contêineres executados no Google Kubernetes Engine (GKE), no cluster do GKE Enterprise ou na plataforma Cloud Run. É possível migrar as cargas de trabalho de VMs em execução no VMware ou no Compute Engine, oferecendo flexibilidade para conteinerizar as cargas de trabalho existentes.

Para executar a modernização, também conhecida como migração, você usa um cluster de processamento que você criou com as etapas em Como instalar o Migrate to Containers.

O fluxo básico para migrar uma carga de trabalho é semelhante nos tipos de cargas de trabalho compatíveis. Há algumas diferenças entre os tipos de carga de trabalho. Portanto, você precisa identificar o tipo de carga de trabalho nas seções abaixo para ter uma descrição do procedimento e informações detalhadas por etapa.

Cargas de trabalho compatíveis

• VM do Linux
• Aplicativo IIS do Windows
• Aplicativo Tomcat
• Aplicativos do WebSphere tradicional
• JBoss
• Apache
• Sites do WordPress

Migrar uma VM do Linux

Procedimento de migração

O diagrama a seguir ilustra as etapas de migração de uma carga de trabalho do Linux:

.

Observação: para ver tutoriais passo a passo sobre o processo de migração, consulte:

• O tutorial para mover o exemplo de serviço e banco de dados Bank of GKE Enterprise de uma VM para um ambiente do GKE, sem alterações no código.

• Os laboratórios práticos:

  • Migre e implante uma VM do Linux

1. Adicione uma origem de migração.

   Você inicia uma migração configurando uma origem que representa a plataforma de origem da qual você migrará. Se você já tiver uma origem de uma migração anterior e as VMs que estiver migrando forem da mesma origem, será possível reutilizá-la.

2. Crie uma migração.

   Crie um objeto de migração com um plano de migração inicial.

3. Migrar dados do Linux.

   Escolha se você quer migrar os dados.

4. Personalize o plano de migração.

   Edite o plano de migração de acordo com os seus requisitos específicos antes de executar a migração.

5. Execute a migração.

   Execute a migração para extrair os artefatos do contêiner, incluindo a imagem e o Dockerfile. Use esses artefatos para implantar o contêiner no ambiente de teste ou na produção.

6. Monitorar uma migração.

   Monitore o progresso de uma migração e inspecione os registros de atividade da migração.

7. Excluir uma migração.

   Exclua a migração para liberar os recursos usados por ela.

Migrar um aplicativo IIS do Windows

Procedimento de migração

O diagrama a seguir ilustra as etapas de migração de uma carga de trabalho do Windows:

Observação: para ver tutoriais passo a passo sobre o processo, consulte os laboratórios práticos do Migrate to Containers: Windows.

As etapas da migração com o Migrate to Containers são as seguintes:

1. Adicione uma origem de migração.

   Inicie uma migração configurando uma origem que represente a plataforma de origem da qual você está migrando. Se você já tiver uma origem de uma migração anterior e as VMs que estiver migrando forem da mesma origem, será possível reutilizá-la.

   Observação: a migração do Windows é compatível apenas com o Compute Engine como origem. Porém, é possível usar o Migrate to Virtual Machines para migrar ou clonar uma VM do Windows de outras fontes para o Compute Engine e, depois, migrar a VM resultante. A VM do Windows migrada não precisa ser configurada para ser executada no Compute Engine.

2. Crie um plano de migração.

   Crie um objeto de migração com um plano de migração inicial.

3. Personalize o plano de migração.

   Edite o plano de migração de acordo com os seus requisitos específicos antes de executar a migração.

4. Execute a migração.

   Execute a migração para extrair os artefatos do contêiner, que incluem o Dockerfile e outros arquivos necessários para criar uma imagem de contêiner.

5. Monitore a migração.

   Monitore o progresso de uma migração e inspecione os registros de atividade da migração.

6. Criar uma imagem de contêiner do Windows

   Use os artefatos gerados para criar um contêiner do Windows que pode ser implantado em um cluster.

7. Excluir uma migração.

   Exclua a migração para liberar os recursos usados por ela.

Recursos compatíveis

Migrate to Containers: o Windows é compatível com a migração de sites de framework .Net do IIS. É possível dividir os sites em imagens de finalidade única ou agrupá-los como quiser.

Para ter uma melhor indicação de quais sites podem ser migrados em uma VM de origem, tente executar a avaliação off-line da CLI do cliente de descoberta da Central de migração.

Migrar um servidor do Tomcat

O diagrama a seguir ilustra as etapas de migração de uma carga de trabalho do Tomcat:

Ao usar o Migrate to Containers para migrar as cargas de trabalho do Tomcat, é possível aproveitar os recursos e a arquitetura do Tomcat para:

• separar automaticamente os subconjuntos de aplicativos em contêineres individuais;
• reter os keystores, truststores e certificados existentes do aplicativo Tomcat da VM de origem;
• determinar dinamicamente a alocação de memória ideal para aplicativos JVM;
• copiar volumes de dados específicos e declarações de volumes de dados das VMs de origem.

Pré-requisitos

• Um servidor de aplicativos Apache Tomcat baseado em VM do Linux v8.5 e mais recente.
• Determine a adequação da carga de trabalho para migração executando uma avaliação off-line.
• Configure um cluster do Cloud para migrar VMs do Linux.

Importante: não especifique a opção --readonly na CLI mcdc. A opção --readonly impede que a CLI mcdc armazene dados coletados sobre o Tomcat na VM e impede que o Migrate to Containers acesse esses dados.

Importante: não use o comando ./mcdc discover. É necessário executar o script de coleta de convidados em uma VM para recuperar as informações exigidas para a conteinerização usando as imagens da comunidade do Tomcat OSS.

Procedimento de migração

As etapas da migração com o Migrate to Containers são as seguintes:

1. Adicione uma origem de migração.

   Inicie uma migração configurando uma origem que represente a plataforma de origem da qual você está migrando. Se você já tiver uma origem de uma migração anterior e as VMs que estiver migrando forem da mesma origem, será possível reutilizá-la.

2. Crie uma migração.

   Crie um objeto de migração com um plano de migração inicial.

3. Migrar dados do Tomcat.

   Escolha se você quer migrar os dados.

4. Personalize o plano de migração.

   Edite o plano de migração de acordo com os seus requisitos específicos antes de executar a migração.

5. Execute a migração.

   Execute a migração para extrair os artefatos do contêiner, que incluem o Dockerfile e outros arquivos necessários para criar uma imagem de contêiner.

6. Monitore a migração.

   Monitore o progresso de uma migração e inspecione os registros de atividade da migração.

7. Criar uma imagem de contêiner do Tomcat

   Use os artefatos gerados para criar um contêiner que pode ser implantado em um cluster.

8. Excluir uma migração.

   Exclua a migração para liberar os recursos usados por ela.

Recursos não suportados

Não há suporte para os seguintes recursos do Tomcat:

• Clustering/replicação de sessão.

• Suporte do Windows para migrações do Tomcat usando cargas de trabalho do Windows.

Migrar aplicativos do WebSphere tradicional

Importante: o uso do plug-in websphere-traditional foi descontinuado. Para clientes atuais, esse plug-in ainda será compatível até dezembro de 2023. Após esse período, ele não estará mais disponível. Se a modernização de cargas de trabalho do WebSphere não for novidade, use o plug-in websphere-container com a CLI do Migrate to Containers.

Visão geral da migração

O IBM WebSphere Application Server (WAS) tradicional é um framework de software que hospeda cargas de trabalho baseadas em Java. O Migrate to Containers permite modernizar as cargas de trabalho do app em execução no WAS tradicional convertendo-as em contêineres de aplicativos. Em seguida, é possível implantar os contêineres de apps no cluster do GKE ou do GKE Enterprise no Google Cloud.

Sobre a migração de aplicativos tradicionais do servidor WebSphere

Uma VM tradicional WAS pode conter vários aplicativos. O Migrate to Containers ajuda a automatizar a modernização de aplicativos WAS para contêineres descobrindo apps implantados na VM de origem e sugerindo automaticamente a configuração da modernização.

O Google requer que cada aplicativo seja migrado para a própria imagem de contêiner (ibmcom/websphere-traditional, ibmcom/websphere-liberty ou openliberty/open-liberty). Depois disso, será possível testar e implantar os aplicativos migrados individualmente, em vez de testar e implantar vários aplicativos juntos.

A origem da migração pode ser a base WAS ND ou WAS. O destino será um contêiner de base WAS tradicional ou do Liberty, e os respectivos recursos de cluster ND serão delegados ao Kubernetes.

Requisitos

Confirme se os ambientes de migração e implantação são compatíveis com o Migrate to Containers analisando os requisitos do sistema a seguir.

Requisitos para migrar apps tradicionais para WA

Antes de iniciar a migração, verifique se os clusters de processamento de migração e ambiente tradicional do WAS da IBM atendem aos requisitos descritos abaixo.

Requisitos tradicionais de sistema do WA

O Migrate to Containers é compatível com a migração de apps hospedados nas seguintes versões do WAS da IBM:

• Servidor de aplicativo WebSphere tradicional 8.5.5.x
• Servidor de aplicativos WebSphere tradicional: 9.0.5.x

Para que o Migrate to Containers processe uma VM contendo um app tradicional do WAS, o Migrate to Containers extrai dois tipos de configuração da VM:

• A configuração de cada aplicativo.

• A configuração do perfil de destino. O perfil define o ambiente de execução de um WAS, incluindo portas, configurações do JVM e muito mais.

O software Migrate to Containers automatiza o uso do kit de ferramentas de migração do servidor da Web do IBM WebSphere para binários de aplicativo no cluster do GKE Enterprise ou do GKE, para descobrir, avaliar e gerar relatórios de migração e scripts de configuração. Você é o único responsável por adquirir, licenciar e usar o kit de ferramentas.

Antes de iniciar uma migração, é preciso fazer o upload do toolkit para um bucket do Google Cloud Storage na sua conta. Consulte Configurar o binaryAppScanner.jar para conhecer o procedimento.

Sistemas operacionais de VM compatíveis

O Migrate to Containers é compatível com migrações de aplicativos tradicionais WAW de VMs instaladas com os sistemas operacionais Linux de 64 bits listados em Sistemas operacionais de VM compatíveis.

Requisitos do cluster de processamento

Use um cluster do Google Kubernetes Engine (GKE) ou GKE Enterprise para executar os componentes do Migrate to Containerss que executam as transformações necessárias para migrar um aplicativo de uma origem VM para um contêiner de destino. Para aplicativos em uma VM de WAS:

• O cluster de processamento pode ser implantado da seguinte maneira:

  • Google Kubernetes Engine (GKE) no Google Cloud
  • Clusters do GKE Enterprise no Google Cloud
  • Google Cloud Distributed Cloud Virtual para Bare Metal

O cluster de processamento precisa usar um sistema operacional Linux listado em Sistemas operacionais de cluster de processamento compatível.

Consulte Escolher o tipo de cluster de processamento para informações sobre como criar cada tipo de cluster de processamento.

Requisitos para implantar aplicativos migrados

Depois de migrar os aplicativos, verifique se o ambiente do aplicativo e o cluster de destino atendem aos requisitos descritos abaixo.

Requisitos do cluster de destino

Use um cluster do Google Kubernetes Engine (GKE), do GKE Enterprise no Google Cloud ou do Google Distributed Cloud Virtual para Bare Metal. O cluster de destino precisa usar um sistema operacional Linux listado em Sistemas operacionais de cluster de carga de trabalho compatíveis.

Como parte da execução de uma migração, o Migrate to Containers cria uma imagem do Docker que representa um app WAS migrado e o envia para um registro do Docker. Você precisa garantir que o cluster de destino tenha acesso de leitura ao registro do Docker, conforme descrito neste link.

Contêineres de destino compatíveis

• WebSphere Application Server tradicional
• WebSphere Application Server Liberty
• Open Liberty

Antes de começar

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

Instalar o Migrate to Containers

Instalar o Migrate to Containers no cluster de processamento. Um cluster de processamento é um cluster do Google Kubernetes Engine (GKE) ou GKE Enterprise 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.

Observação :use o Migrate to Containers versão 1.11.0 ou mais recente.

Como opção, configure o Migrate to Virtual Machines

Para usar o Migrate to Containers para migrar cargas de trabalho do Websphere para o Google Cloud da VMware, configure o Migrate to Virtual Machines, que gerencia o transporte.

Para saber mais, consulte Configurar o Migrate to Virtual Machines.

Configurar o binaryAppScanner.jar

Observação:

Faça o download da versão mais recente do binaryAppScanner.jar. Se você já fez o download da ferramenta, verifique a data de modificação na página de download para conferir se você tem a versão mais recente.

Você também pode usar o seguinte comando para determinar a versão atual:

java -jar binaryAppScanner.jar --version

Em seguida, compare a versão atual com a versão exibida na licença da IBM que aparece quando você clica em Kit de ferramentas de migração para binários de aplicativos para fazer o download do arquivo.

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:

• Aceite o contrato de licença e faça o download do Kit de ferramentas de migração de servidores do aplicativo do IBM WebSphere para binários do aplicativo. Depois, extraia o arquivo binaryAppScanner.jar.

• Crie um Dockerfile e prepare o plug-in agrupado com o verificador binário.

Para configurar binaryAppScanner.jar:

1. Faça o download do arquivo instalador, binaryAppScannerInstaller.jar, pelo Suporte da IBM. 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. Por exemplo:

   cd /tmp/wamt
   

5. Crie dois Dockerfiles com os seguintes comandos:

   FROM us-docker.pkg.dev/migrate-modernize-public/modernize-plugins-prod/websphere-traditional-container-discover:1.3.1
   ADD binaryAppScanner.jar /
   

   FROM us-docker.pkg.dev/migrate-modernize-public/modernize-plugins-prod/websphere-traditional-container-extract:1.3.1
   ADD binaryAppScanner.jar /
   

6. Crie e envie as imagens Docker:

   gcloud builds submit --timeout 1h -t gcr.io/PROJECT_ID/websphere-traditional-container-discover-with-scanner:1.3.1 --project PROJECT_ID
   gcloud builds submit --timeout 1h -t gcr.io/PROJECT_ID/websphere-traditional-container-extract-with-scanner:1.3.1 --project PROJECT_ID
   

7. Edite o CRD do plug-in para agrupá-lo com o verificador binário da seguinte maneira:

   $ kubectl edit appxplugins.anthos-migrate.cloud.google.com -n v2k-system websphere-traditional-container
   
   # Set the value of spec.discoveryImage and spec.generateArtifactsImage:
   
   apiVersion: anthos-migrate.cloud.google.com/v1beta2
   kind: AppXPlugin
   metadata:
     namespace: v2k-system
     name: websphere-traditional-container
     labels:
       anthos-migrate.cloud.google.com/preview-type: public
     annotations:
       anthos-migrate.cloud.google.com/display-name: WebSphere traditional container
   spec:
     discoverImage: gcr.io/PROJECT_ID/websphere-traditional-container-discover-with-scanner:1.3.1
     discoverCommand:
     - /ko-app/websphere-traditional
     - discover
     generateArtifactsImage: gcr.io/PROJECT_ID/websphere-traditional-container-extract-with-scanner:1.3.1
     generateArtifactsCommand:
     - /ko-app/websphere-traditional
     - extract
     parameterDefs:
     - name: was-home
       usage: Path of the WebSphere WAS_HOME on the original instance.
       envVar: APPX_WAS_HOME
   

8. Salve o CRD.

Procedimento de migração

O diagrama a seguir ilustra as etapas de migração de uma carga de trabalho do WebSphere:

As etapas da migração com o Migrate to Containers são as seguintes:

1. Adicione uma origem de migração.

   Adicione a origem da migração que representa a plataforma de origem.

2. Crie uma migração.

   Crie um objeto de migração com um plano de migração inicial.

3. Migrar dados do WebSphere.

   Escolha se você quer migrar os dados.

4. Personalizar o plano de migração.

   Edite o plano de migração de acordo com os seus requisitos específicos antes de executar a migração. Você migra um app WAS por migração.

5. Execute a migração.

   Execute a migração para extrair os artefatos do contêiner, que incluem o Dockerfile e outros arquivos necessários para criar uma imagem de contêiner.

6. Gere e analise os artefatos de migração.

   Faça a migração para gerar o contêiner do app. Você pode monitorar o processo de migração e, quando terminar, revisar os artefatos como preparação para a criação da imagem implantável do app.

7. Monitore a migração.

   Monitore o progresso de uma migração e inspecione os registros de atividade da migração.

8. Crie uma imagem de contêiner do app.

   Use os artefatos gerados para criar um contêiner que pode ser implantado em um cluster.

9. Implante um contêiner de app em um cluster de destino.

   Implante a imagem no cluster de destino.

10. Excluir uma migração.

    Exclua a migração para liberar os recursos usados por ela.

Migrar um servidor JBoss

O diagrama a seguir ilustra as etapas de migração de uma carga de trabalho do JBoss:

Ao usar o Migrate to Containers para migrar as cargas de trabalho do JBoss, é possível aproveitar os recursos e a arquitetura do JBoss para copiar volumes de dados específicos e declarações de volume de dados das VMs de origem.

Pré-requisitos

• Servidor de apps JBoss AS v8.1.0 ou mais recente ou o servidor de apps JBoss EAP v7.0, v7.1, v7.2, v7.3 e v7.4.

  Observação: os servidores de aplicativo JBoss AS e JBoss EAP serão migrados para os contêineres da comunidade JBoss AS.

• Configurar um cluster do Google Cloud para migrar VMs.

Procedimento de migração

As etapas da migração com o Migrate to Containers são as seguintes:

1. Adicione uma origem de migração.

   Inicie uma migração configurando uma origem que representa a plataforma de origem de onde você vai migrar. Se você já tiver uma origem de uma migração anterior e as VMs que estiver migrando forem da mesma origem, é possível reutilizá-la.

2. Crie uma migração.

   Crie um objeto de migração com um plano de migração inicial.

3. Migre os dados do JBoss.

   Escolha se você quer migrar os dados.

4. Personalize o plano de migração.

   Edite o plano de migração de acordo com os seus requisitos específicos antes de executar a migração.

5. Execute a migração.

   Execute a migração para extrair os artefatos do contêiner, que incluem o Dockerfile e outros arquivos necessários para criar uma imagem de contêiner.

6. Monitore a migração.

   Monitore o progresso de uma migração e inspecione os registros de atividade da migração.

7. Criar uma imagem do contêiner do JBoss

   Use os artefatos gerados para criar um contêiner que pode ser implantado em um cluster.

8. Excluir uma migração.

   Exclua a migração para liberar os recursos usados por ela.

Recursos não suportados

Não há suporte para os seguintes recursos do JBoss:

• Dados confidenciais e secrets: dados confidenciais e secrets armazenados no diretório JBOSS_HOME/standalone não são removidos. Esses dados são incluídos na imagem do contêiner.
• Configuração do logger do JBoss: a configuração do logger é retirada no estado em que se encontra da máquina de origem. Ele não é modificado durante o processo de migração, a menos que o jbossServer.tar.gz seja modificado manualmente antes da criação do contêiner do JBoss.
• Alocação de memória: a alocação de recursos da máquina virtual Java (JVM, na sigla em inglês) é retirada do contêiner da comunidade e não depende dos recursos da JVM de origem.
• Variáveis de ambiente: as variáveis de ambiente e os parâmetros de JVM da máquina de origem não são migrados para a imagem do contêiner.
• Avaliação off-line: não é possível determinar a adequação da carga de trabalho do JBoss para migração.

Migrar um servidor Apache

O diagrama a seguir ilustra as etapas de migração de uma carga de trabalho do Apache:

Ao usar o Migrate to Containers para migrar as cargas de trabalho do Apache, é possível aproveitar os recursos e a arquitetura do Apache para:

• copiar volumes de dados específicos e declarações de volumes de dados das VMs de origem.

Pré-requisitos

• Um servidor da Web Apache 2 baseado em uma VM Linux.
• Configurar um cluster do Google Cloud para migrar VMs do Linux.

Procedimento de migração

As etapas da migração com o Migrate to Containers são as seguintes:

1. Adicione uma origem de migração.

   Inicie uma migração configurando uma origem que represente a plataforma de origem da qual você está migrando. Se você já tiver uma origem de uma migração anterior e as VMs que estiver migrando forem da mesma origem, será possível reutilizá-la.

2. Crie uma migração.

   Crie um objeto de migração com um plano de migração inicial.

3. Migrar dados.

   Escolha se você quer migrar os dados.

4. Personalize o plano de migração.

   Edite o plano de migração de acordo com os seus requisitos específicos antes de executar a migração.

5. Execute a migração.

   Execute a migração para extrair os artefatos do contêiner, que incluem o Dockerfile e outros arquivos necessários para criar uma imagem de contêiner.

6. Monitore a migração.

   Monitore o progresso de uma migração e inspecione os registros de atividade da migração.

7. Criar uma imagem de contêiner do Apache

   Use os artefatos gerados para criar um contêiner que pode ser implantado em um cluster.

8. Excluir uma migração.

   Exclua a migração para liberar os recursos usados por ela.

Recursos não suportados

As cargas de trabalho do Apache 1 não são compatíveis.

Não há suporte para os seguintes recursos do Apache:

• Certificados.

• Suporte do Windows para migrações do Apache usando cargas de trabalho do Windows.

Migrar um site do WordPress

Ao usar o Migrate to Containers para migrar as cargas de trabalho do WordPress, você aproveita os recursos e a arquitetura do WordPress para copiar volumes de dados específicos e declarações de volume de dados das VMs de origem.

Pré-requisitos

• WordPress versão 4.0 ou posterior, executado em servidores da Web Apache 2 baseados em VM do Linux.
• Configurar um cluster do Google Cloud para migrar VMs do Linux.

Procedimento de migração

As etapas da migração com o Migrate to Containers são as seguintes:

1. Adicione uma origem de migração.

   Inicie uma migração configurando uma origem que representa a plataforma de origem de onde você vai migrar. Se você já tiver uma origem de uma migração anterior e as VMs que estiver migrando forem da mesma origem, é possível reutilizá-la.

2. Crie uma migração.

   Crie um objeto de migração com um plano de migração inicial.

3. Personalize o plano de migração.

   Edite o plano de migração de acordo com os seus requisitos específicos antes de executar a migração.

4. Migrar dados do WordPress.

   Revise e edite o plano de migração de dados de acordo com seus requisitos específicos antes de fazer a migração.

5. Execute a migração.

   Execute a migração para extrair os artefatos do contêiner, que incluem o Dockerfile e outros arquivos necessários para criar uma imagem de contêiner.

6. Monitore a migração.

   Monitore o progresso de uma migração e inspecione os registros de atividade da migração.

7. Criar uma imagem de contêiner do WordPress

   Use os artefatos gerados para criar um contêiner que pode ser implantado em um cluster.

8. Excluir uma migração.

   Exclua a migração para liberar os recursos usados por ela.

Recursos não suportados

Os sites do WordPress em execução em hosts que não são o servidor da Web Apache 2 baseado em VM do Linux não são compatíveis.

Os recursos do WordPress a seguir não são compatíveis:

• Migração de bancos de dados do WordPress.

  Para mais informações sobre como migrar um aplicativo que depende de um banco de dados, consulte Garantir que os bancos de dados sejam acessíveis.

• Exportar dados armazenados localmente no servidor WordPress, como uploads de mídia, plug-ins e temas, para um drive NFS.

  Para mais informações sobre como exportar dados armazenados localmente para NFS, consulte Definir montagens NFS como volumes permanentes.

• Escalonamento horizontal da implantação migrada.

  Os dados armazenados localmente no servidor WordPress são exportados para o disco permanente do Compute Engine, que é montado no pod de implantação migrado. Não é possível anexar um disco permanente do Compute Engine a vários pods, o que impede o escalonamento horizontal da implantação migrada.

• Exportar certificados e dados sensíveis para objetos de secret do Kubernetes.

A seguir

• Saiba como adicionar uma origem da migração.