← Back to list

🚀Lift & Shift + Modernização de Aplicação: Convertendo uma aplicação legado para rodar em…

Em um projeto desafiador que simula um cenário real de migração corporativa, atuei como Especialista em Cloud Computing para liderar a…

Fabio Pettian · 2025-06-06 11:53 · 0 claps · 7.6 min read
#kubernetes-cluster #docker #gke #anthos #database-migration-tool
Open on Medium ↗
Wiki topics: ☁️ · DevOps & Cloud

🚀Lift & Shift + Modernização de Aplicação: Convertendo uma aplicação legado para rodar em containers no Google Kubernetes Engine (GKE) usando o Anthos

Em um projeto desafiador que simula um cenário real de migração corporativa, atuei como Especialista em Cloud Computing para liderar a jornada de modernização de uma aplicação de Gestão de Talentos. O objetivo era ambicioso: migrar a infraestrutura de um datacenter tradicional para a Google Cloud em apenas três meses.

Arquitetura da Solução

Dividimos o projeto em duas grandes fases:

  1. Lift & Shift — migração inicial da aplicação para a GCP com mínima alteração;
  2. Modernização — reestruturação da aplicação para rodar de forma containerizada no Google Kubernetes Engine (GKE), com suporte do Migrate to Containers (M2C), parte do Anthos.

🧱 Fase 1 — Lift & Shift na Google Cloud Platform —

1.1 — Criando o Projeto na Google Cloud e Ativando APIs Essenciais

Comecei criando um novo projeto chamado tcb-m2c e o vinculei a uma conta de faturamento. Em seguida, habilitei as APIs necessárias para computação e gerenciamento de recursos:

  • Compute Engine API
  • Kubernetes Engine API
  • Cloud Resource Manager API

1.2 — Configuração do Ambiente via Cloud Shell

gcloud config set project PROJECT_ID
gcloud config set compute/zone us-west1-a

gcloud compute firewall-rules create allow-ssh --network default --allow tcp:22 \
--source-ranges 0.0.0.0/0
gcloud compute firewall-rules create allow-http --network default --allow tcp:80 \
--source-ranges 0.0.0.0/0

⚠️ Observação: A regra de SSH pode ser desnecessária caso a VPC padrão já tenha uma regra ativa para a porta 22.

1.3 — Provisionamento da VM de Origem

gcloud compute instances create app-01-vm --project=$DEVSHELL_PROJECT_ID \
--zone=us-west1-a --machine-type=n1-standard-1 --subnet=default \
--scopes="cloud-platform" --tags=http-server,https-server \
--image=ubuntu-2204-jammy-v20240319 --image-project=ubuntu-os-cloud \
--boot-disk-size=10GB --boot-disk-type=pd-standard --boot-disk-device-name=app-01-vm

1.4 — Instalação e Testes da Aplicação Web

sudo apt update && sudo apt install apache2 unzip -y
cd /var/www/html
sudo mv index.html index.html.bkp
sudo curl -O https://storage.googleapis.com/bootcamp-gcp-en/hands-on-compute-website-files-en.zip
sudo unzip hands-on-compute-website-files-en.zip
sudo chmod 644 *

💡 Após isso, com o IP externo da VM, validei no navegador se a aplicação estava rodando corretamente. ✅ Lift & Shift concluído com sucesso.

🔄 Parte 2 — Modernizando a Aplicação com Migrate to Containers (M2C)

Com a aplicação legada já funcional na VM da Google Cloud, a próxima etapa foi reestruturar essa solução para o ambiente de containers. A estratégia escolhida foi o uso do Migrate to Containers (M2C), uma ferramenta da Google que automatiza a conversão de VMs para workloads em Kubernetes.

2.1 — Criando a VM de Suporte à Migração

Para iniciar o processo de conversão, criei uma nova instância de VM que servirá como base para executar os comandos e ferramentas de migração:

gcloud compute instances create tcb-vm \
  --zone=us-west1-a --machine-type=e2-medium \
  --subnet=default --scopes="cloud-platform" \
  --tags=http-server,https-server --image=ubuntu-2204-jammy-v20240319 \
  --image-project=ubuntu-os-cloud --boot-disk-size=50GB --boot-disk-type=pd-standard \
  --boot-disk-device-name=tcb-vm

2.2 — Provisionando o Cluster no GKE

Com a VM de migração pronta, o próximo passo foi criar um cluster Kubernetes no Google Kubernetes Engine, que hospedará a versão containerizada da aplicação.

gcloud container clusters create app-01-cluster --project=$DEVSHELL_PROJECT_ID \
--zone=us-west1-c --machine-type n1-standard-4 --release-channel=stable \
--image-type ubuntu_containerd --num-nodes 1 --logging=SYSTEM --monitoring=SYSTEM \
--subnetwork "projects/$DEVSHELL_PROJECT_ID/regions/us-west1/subnetworks/default"

2.3 — Preparando o Ambiente de Migração

Conectei-me via SSH na tcb-vm e iniciei a instalação das ferramentas necessárias para migração e manipulação de containers:

Instalando Google Cloud CLI:

curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo gpg --dearmor -o /usr/share/keyrings/cloud.google.gpg
echo "deb [signed-by=/usr/share/keyrings/cloud.google.gpg] https://packages.cloud.google.com/apt cloud-sdk main" | sudo tee -a /etc/apt/sources.list.d/google-cloud-sdk.list
sudo apt-get update && sudo apt-get install google-cloud-cli -y
gcloud init

Instalando Docker:

curl -fsSL https://get.docker.com -o install-docker.sh
sudo sh install-docker.sh
sudo usermod -aG docker $USER
newgrp docker
docker ps -a

Instalando o Skaffold:

curl -Lo skaffold https://storage.googleapis.com/skaffold/releases/latest/skaffold-linux-amd64
sudo install skaffold /usr/local/bin/
skaffold version

🧠 O Skaffold é essencial para automação de build, push e deploy no Kubernetes durante o ciclo de desenvolvimento.

Instalando Migrate to Containers CLI (m2c):

curl -O "https://m2c-cli-release.storage.googleapis.com/$(curl -s https://m2c-cli-release.storage.googleapis.com/latest)/linux/amd64/m2c"
chmod +x ./m2c
./m2c version

2.4 — Ajustando Filtros de Migração

Por padrão, o m2c exclui diretórios que considera desnecessários. No entanto, o Apache exige o diretório /var/log/ para iniciar corretamente. Por isso, editei os filtros de exclusão:

./m2c copy default-filters > filters.txt
vi filters.txt
# Remover a linha: - /var/log/*
:x

2.5 — Copiando o Filesystem da VM Original

./m2c copy gcloud --project YOUR-PROJECT-ID --zone us-west1-a \
--vm-name app-01-vm --output app-01-vm-filesystem --filters filters.txt

⏳ O comando usa rsync para transferir arquivos – o processo pode demorar alguns minutos, dependendo do volume de dados.

2.6 — Validação

Após a cópia do sistema de arquivos, explorei a estrutura transferida para garantir a integridade da aplicação:

ls app-01-vm-filesystem/var/www/html
cat app-01-vm-filesystem/var/www/html/index.html

⚠️ Finalizei essa fase desligando a VM original:

gcloud compute instances stop app-01-vm --zone=us-west1-a

🚀 Parte 3 — Gerando os Artefatos de Migração e Implantando no GKE

Com o sistema de arquivos da aplicação legado já disponível, iniciei o processo de análise e transformação para que o m2c gerasse os manifestos necessários à execução da aplicação no Kubernetes.

3.1 — Análise e Geração do Plano de Migração

Dentro da tcb-vm, executei o comando de análise apontando para o filesystem copiado:

./m2c analyze \
--source app-01-vm-filesystem --plugin linux-vm-container \
--output analysis-output

Após alguns minutos, foi gerado um diretório analysis-output com o arquivo de configuração config.yaml, que define como o sistema será containerizado.

3.2 — Gerando os Artefatos Kubernetes

Com a análise concluída, o próximo passo foi transformar esse plano em arquivos Kubernetes utilizáveis:

./m2c generate --input analysis-output --output migration-artifacts

Esse processo pode demorar um pouco, pois ele empacota o sistema legado, cria os manifests e prepara o ambiente para o deploy.

📁 Os arquivos foram salvos no diretório migration-artifacts, incluindo:

  • Dockerfile
  • deployment_spec.yaml
  • vmFiles.tar.gz

3.3 — Instalando o Plugin de Autenticação para GKE

Antes de aplicar os manifests, preparei o ambiente para autenticar com o cluster GKE via kubectl:

sudo apt-get install google-cloud-sdk-gke-gcloud-auth-plugin -y
sudo apt-get install kubectl
gcloud container clusters get-credentials app-01-cluster --zone us-west1-c --project YOUR-PROJECT-ID

3.4 — Criando um Serviço de LoadBalancer

Para expor a aplicação migrada ao público externo, editei o arquivo deployment_spec.yaml:

cd migration-artifacts
vi deployment_spec.yaml

Adicionei ao final do arquivo:

apiVersion: v1
kind: Service
metadata:
  name: talent-management-portal
spec:
  selector:
    app: linux-system
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: LoadBalancer

3.5 — Configurando o Artifact Registry e Executando o Deploy com Skaffold

Para armazenar a imagem container da aplicação, criei um repositório Docker no Artifact Registry:

gcloud artifacts repositories create linux-system-repo --repository-format=docker \
--location=us-west1 --description="Docker repository"
gcloud auth configure-docker us-west1-docker.pkg.dev

Com tudo pronto, o comando abaixo deu início ao processo completo de build, push da imagem e deploy no cluster:

skaffold run -d us-west1-docker.pkg.dev/YOUR-PROJECT-ID/linux-system-repo

⏳ Esse processo leva entre 15 e 20 minutos e realiza:

  • Criação da imagem Docker com o vmFiles.tar.gz
  • Upload para o Artifact Registry
  • Deploy automático no GKE via manifestos

3.6 — Validação Final

Após a execução, validei todos os recursos implantados:

kubectl get service talent-management-portal
kubectl get nodes
kubectl get pods
kubectl get deployments
kubectl get svc

🔍 O serviço do tipo LoadBalancer exibe um IP externo. Ao acessá-lo via navegador, confirmei o funcionamento completo da aplicação agora dentro de um cluster Kubernetes moderno, escalável e gerenciável.

📸 Evidências

  • IP do serviço LoadBalancer

  • Screenshot da aplicação acessada via IP externo

  • Kubernetes Engine Workloads, demonstrando o estado saudável dos deploys

🧹 Cleanup dos Recursos

Ao final da demonstração, limpei os recursos criados para evitar cobranças indevidas:

gcloud container clusters delete app-01-cluster --zone=us-west1-a
gcloud compute instances delete app-01-vm tcb-vm --zone=us-west1-a
gcloud artifacts repositories delete linux-system-repo --location=us-west1

✅ Conclusão

Esse projeto prático evidenciou como é possível realizar uma migração eficiente de sistemas legados para a nuvem com mínimo downtime e máxima modernização. Utilizando Google Cloud, Kubernetes, Docker, M2C e Skaffold, foi possível converter uma aplicação monolítica em um workload Kubernetes pronto para produção.

📌 Este case reforça minha capacidade de atuar com Cloud Native Transformation, DevOps e Containers, entregando resultados técnicos concretos que impulsionam a jornada de modernização digital de qualquer organização.


메타데이터
post_id
18aaa3613cc2
slug
lift-shift-modernização-de-aplicação-convertendo-uma-aplicação-legado-para-rodar-em-18aaa3613cc2
url
https://medium.com/@fabio.pettian/lift-shift-moderniza%C3%A7%C3%A3o-de-aplica%C3%A7%C3%A3o-convertendo-uma-aplica%C3%A7%C3%A3o-legado-para-rodar-em-18aaa3613cc2
canonical_url
https://medium.com/@fabio.pettian/lift-shift-moderniza%C3%A7%C3%A3o-de-aplica%C3%A7%C3%A3o-convertendo-uma-aplica%C3%A7%C3%A3o-legado-para-rodar-em-18aaa3613cc2
author_url
https://medium.com/@fabio.pettian
status
ok
fetched_at
2026-07-19 13:46:34