Modernize cargas de trabalho tradicionais
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:
.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.
-
Crie um objeto de migração com um plano de migração inicial.
-
Escolha se você quer migrar os dados.
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.
-
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.
-
Monitore o progresso de uma migração e inspecione os registros de atividade da 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:
As etapas da migração com o Migrate to Containers são as seguintes:
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.
-
Crie um objeto de migração com um plano de migração inicial.
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.
-
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.
-
Monitore o progresso de uma migração e inspecione os registros de atividade da migração.
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.
-
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.
Procedimento de migração
As etapas da migração com o Migrate to Containers são as seguintes:
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.
-
Crie um objeto de migração com um plano de migração inicial.
-
Escolha se você quer migrar os dados.
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.
-
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.
-
Monitore o progresso de uma migração e inspecione os registros de atividade da migração.
Criar uma imagem de contêiner do Tomcat
Use os artefatos gerados para criar um contêiner que pode ser implantado em um cluster.
-
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
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:
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.
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
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
:
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.Execute o seguinte comando para extrair o arquivo
binaryAppScanner.jar
e aceitar o Contrato de Licença:java -jar binaryAppScannerInstaller.jar --acceptLicense --verbose
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.Navegue até o diretório /wamt. Por exemplo:
cd /tmp/wamt
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 /
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
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
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:
Adicione uma origem de migração.
Adicione a origem da migração que representa a plataforma de origem.
-
Crie um objeto de migração com um plano de migração inicial.
-
Escolha se você quer migrar os dados.
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.
-
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.
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.
-
Monitore o progresso de uma migração e inspecione os registros de atividade da migração.
Crie uma imagem de contêiner do app.
Use os artefatos gerados para criar um contêiner que pode ser implantado em um cluster.
Implante um contêiner de app em um cluster de destino.
Implante a imagem no cluster de destino.
-
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.
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:
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.
-
Crie um objeto de migração com um plano de migração inicial.
-
Escolha se você quer migrar os dados.
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.
-
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.
-
Monitore o progresso de uma migração e inspecione os registros de atividade da migração.
Criar uma imagem do contêiner do JBoss
Use os artefatos gerados para criar um contêiner que pode ser implantado em um cluster.
-
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:
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.
-
Crie um objeto de migração com um plano de migração inicial.
-
Escolha se você quer migrar os dados.
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.
-
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.
-
Monitore o progresso de uma migração e inspecione os registros de atividade da migração.
Criar uma imagem de contêiner do Apache
Use os artefatos gerados para criar um contêiner que pode ser implantado em um cluster.
-
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:
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.
-
Crie um objeto de migração com um plano de migração inicial.
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.
-
Revise e edite o plano de migração de dados de acordo com seus requisitos específicos antes de fazer 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.
-
Monitore o progresso de uma migração e inspecione os registros de atividade da migração.
Criar uma imagem de contêiner do WordPress
Use os artefatos gerados para criar um contêiner que pode ser implantado em um cluster.
-
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.