Como migrar uma VM monolítica - Otimização

Quando sua carga de trabalho é migrada de uma VM para um contêiner, muitas possibilidades são abertas. É possível otimizar seu contêiner e aplicar ferramentas e processos de modernização. Modificar o código-fonte da carga de trabalho e implantação da sua carga de trabalho ficou muito mais fácil. Ainda que as ferramentas de operações, como geração de registros e monitoramento, possam ser totalmente integradas à carga de trabalho pronta para uso.

Objetivos

Ao concluir este tutorial, você saberá como:

Explore os artefatos de migração.
Modifique o código-fonte e o Dockerfile da carga de trabalho migrada.
Use o Cloud Operations para monitorar e visualizar os registros da carga de trabalho migrada.
Otimize ainda mais a carga de trabalho usando práticas recomendadas de modernização.

Antes de começar

Este tutorial é um acompanhamento do tutorial de migração e implantação. Antes de começar, siga as instruções para criar e personalizar um plano de migração para sua VM. Em seguida, implante os artefatos conteinerizados resultantes.

Analise os artefatos de migração

Nesta seção, você aprenderá sobre alguns artefatos criados durante o processo de migração e quais são os papéis deles. Será possível modificar esses arquivos para aumentar e atualizar a carga de trabalho no futuro.

Ver a configuração de Dockerfile.

cat  ${HOME}/bank-of-anthos/src/ledgermonolith/Dockerfile

FROM anthos-migrate.gcr.io/v2k-run-embedded:v1.12.1 as migrate-for-anthos-runtime
FROM gcr.io/my-project/ledgermonolith-service-non-runnable-base:8-25-2022--22-12-57 as source-content

COPY --from=migrate-for-anthos-runtime / /

ADD blocklist.yaml /.m4a/blocklist.yaml
ADD logs.yaml /code/config/logs/logsArtifact.yaml
ADD services-config.yaml /.m4a/

ENTRYPOINT [ "/.v2k.go" ]

Esse arquivo contém a etapa necessária para gerar a imagem do contêiner dessa carga de trabalho. É possível adicionar e atualizar bibliotecas, fazer modificações no código-fonte e adicionar novos arquivos. Veja uma referência atualizada para essa configuração aqui.

Visualize o arquivo deployment_spec.yaml.

cat  ${HOME}/bank-of-anthos/src/ledgermonolith/deployment_spec.yaml

apiVersion: apps/v1
kind: StatefulSet
metadata:
  creationTimestamp: null
  labels:
    app: ledgermonolith-service
    migrate-for-anthos-optimization: "true"
    migrate-for-anthos-version: v1.12.1
  name: ledgermonolith-service
spec:
  replicas: 1
  selector:
    matchLabels:
      app: ledgermonolith-service
      migrate-for-anthos-optimization: "true"
      migrate-for-anthos-version: v1.12.1
  serviceName: ledgermonolith-service
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: ledgermonolith-service
        migrate-for-anthos-optimization: "true"
        migrate-for-anthos-version: v1.12.1
    spec:
      containers:
      - env:
        - name: HC_V2K_SERVICE_MANAGER
          value: "true"
        image: gcr.io/my-project/ledgermonolith-service:8-25-2022--22-12-57
        imagePullPolicy: IfNotPresent
        name: ledgermonolith-service
        resources: {}
        volumeMounts:
        - mountPath: /var/lib/postgresql
          name: ledgermonolith-db
          subPath: var/lib/postgresql
      volumes:
      - name: ledgermonolith-db
        persistentVolumeClaim:
          claimName: ledgermonolith-db
  updateStrategy: {}
. . .
. . .

Esse arquivo contém as definições de recursos do Kubernetes para a carga de trabalho migrada. Ele define um StatefulSet para os processos, um serviço para a porta e um par de PersistentVolumeClaim e PersistentVolume que contém o banco de dados migrado.

Nesta saída de amostra, a imagem do Docker definida para o StatefulSet é gcr.io/my-project/ledgermonolith-service:11-24-2021--16-22-59, que foi gerada durante o processo de migração e contém a carga de trabalho da VM original.

Modificar o código-fonte

Em seguida, você aprenderá a modificar o código-fonte da carga de trabalho e do Dockerfile, adicionar uma tag e enviar uma nova imagem de contêiner e implantar essa carga de trabalho atualizada no cluster.

Modifique o controlador principal do livro-razão para sempre retornar um saldo estático quando um saldo for consultado. Execute o seguinte comando, que substituirá Long balance = info.getBalance(); por Long balance = 12345L;.
```
sed -i 's/Long balance = info.getBalance();/Long balance = 12345L;/g' \
${HOME}/bank-of-anthos/src/ledgermonolith/src/main/java/anthos/samples/bankofanthos/ledgermonolith/LedgerMonolithController.java
```
Navegue até a raiz do código-fonte do serviço e crie o artefato Java.
```
cd ${HOME}/bank-of-anthos/src/ledgermonolith/
mvn -f . package
```
Observação: o Java 17 ou versão mais recente é necessário para criar o Bank of Anthos.

Adicione um comando COPY no Dockerfile para copiar o artefato Java recém-criado na imagem do contêiner.

echo "COPY ${HOME}/bank-of-anthos/src/ledgermonolith/target/ledgermonolith-1.0.jar /opt/monolith/ledgermonolith.jar" >> ${HOME}/bank-of-anthos/src/ledgermonolith/Dockerfile

Crie e envie a imagem do contêiner.

docker build . -t gcr.io/$PROJECT_ID/ledgermonolith-service:static-balance --no-cache
docker push gcr.io/$PROJECT_ID/ledgermonolith-service:static-balance

Mude a origem da imagem para uma imagem enviada recentemente.

sed -i 's/image:.*/gcr.io\/$PROJECT_ID\/ledgermonolith-service:static-balance/g' ${HOME}/bank-of-anthos/src/ledgermonolith/deployment_spec.yaml
kubectl apply -f ${HOME}/bank-of-anthos/src/ledgermonolith/deployment_spec.yaml

Use o comando a seguir para visualizar o estado dos pods:

kubectl get pods

Pode levar alguns segundos para que o pod ledgermonolith-service esteja em execução.

NAME                           READY   STATUS    RESTARTS   AGE
accounts-db-0                  1/1     Running   0          3m53s
contacts-d5dcdc87c-jbrhf       1/1     Running   0          3m53s
frontend-5768bd978-xdvpl       1/1     Running   0          3m53s
ledgermonolith-service-0       1/1     Running   0          1m11s
loadgenerator-8485dfd-582xv    1/1     Running   0          3m53s
userservice-8477dfcb46-rzw7z   1/1     Running   0          3m53s

Quando todos os pods estiverem definidos como Running, será possível encontrar o endereço IP externo frontend do LoadBalancer.

kubectl get service frontend

NAME       TYPE           CLUSTER-IP      EXTERNAL-IP     PORT(S)        AGE
frontend   LoadBalancer   10.79.248.161   ##.##.##.##.    80:31304/TCP   46m

Abra um navegador e visite a página da Web no endereço IP externo encontrado acima. Use HTTP, em vez de HTTPS.
```
http://EXTERNAL_IP
```
É possível fazer login com as credenciais padrão e ver as transações. Você perceberá que o saldo agora está mostrando US $123,45, conforme esperado na alteração do código-fonte.

Monitorar o contêiner

Nesta seção, você aprende a migrar suas cargas de trabalho para contêineres a fim de facilitar a observabilidade, como a navegação em registros e o monitoramento de aplicativos e serviços.

Abra o console do Google Cloud, navegue até o produto do GKE e clique em "Cargas de trabalho".
Encontre a carga de trabalho ledgermonolith-service e clique nela para visualizar o status atual e histórico. Nesta página, é possível ver o uso de memória e CPU, além de eventos e especificações.
Clique na guia "Registros" para conferir os registros históricos da carga de trabalho. Também é possível visualizar essas informações usando o Cloud Logging.

Otimização adicional

A partir daqui, há muitos processos e atividades de otimização que podem melhorar a experiência do contêiner. Veja abaixo alguns exemplos dessas atividades fora do escopo deste tutorial.

Adicione políticas de segurança e identidade. A definição de políticas permite restringir o acesso às várias cargas de trabalho e à configuração não apenas externamente, mas também internamente entre serviços. Políticas, como controle de acesso baseado em papéis e acesso de entrada e saída, estão incluídas.
Integração com um pipeline de integração e implantação contínuas. Ao integrar suas cargas de trabalho em um pipeline de integração e implantação contínuas, você acelera a velocidade de desenvolvimento e teste de recursos.
Separe a carga de trabalho migrada em microsserviços. Atualmente, a carga de trabalho ledgermonolith-service migrada é composta de três processos lógicos e um banco de dados. Eles podem ser divididos em vários microsserviços, o que permite configurar um escalonamento e políticas mais detalhados para serviços e processos específicos. Isso reduz o atrito durante o desenvolvimento e a iteração.
Configure uma malha de serviço. A implementação de uma malha de serviço nas cargas de trabalho fornece recursos como gerenciamento de tráfego, autenticação mútua e observabilidade. Uma malha de serviço pode ser implementada em um único cluster ou em vários clusters.
Ative o escalonamento automático e as atualizações graduais. Ao configurar o escalonamento automático e as atualizações graduais, o Kubernetes permite que as cargas de trabalho sejam tolerantes a falhas e altamente disponíveis. O escalonamento automático inclui pods e nós de escalonamento horizontal e recursos alocados verticalmente. Programe várias réplicas das cargas de trabalho e faça upgrade delas uma de cada vez, de maneira resiliente, para configurar esse recurso.

Resumo

Você iniciou esta série de tutoriais com um aplicativo ativo composto de vários serviços. Alguns serviços residem em um cluster do GKE e outros em uma VM do Compute Engine. Você migrou um serviço e um banco de dados monolíticos de uma VM para o cluster do GKE. Esse processo reduz os custos de computação e aumenta a facilidade de desenvolvimento para os desenvolvedores. Por fim, você aprendeu a iterar rapidamente o código-fonte e as práticas recomendadas de modernização.

Limpar

Para evitar cobranças desnecessárias do Google Cloud, exclua os recursos usados neste tutorial quando terminar. Esses recursos são:

O cluster do GKE boa-cluster
O cluster do GKE migration-processing
A VM do Compute Engine ledgermonolith-service

Exclua esses recursos manualmente ou siga as etapas abaixo para excluir seu projeto, o que também removerá todos os recursos.

Cuidado: excluir um projeto tem os seguintes efeitos:

Tudo no projeto é excluído. Se você tiver usado um projeto existente para as tarefas neste documento, a exclusão dele incluirá a exclusão de quaisquer outros trabalhos feitos no projeto.
Os IDs do projeto personalizados são perdidos. Ao criar o projeto, você pode ter criado um código do projeto personalizado para ser usado no futuro. Para preservar os URLs que usam o ID do projeto, como um URL appspot.com, exclua recursos específicos do projeto, em vez de excluir o projeto inteiro.

Se você planeja passar por várias arquiteturas, tutoriais ou guias de início rápido, a reutilização de projetos pode evitar que você exceda os limites da cota do projeto.

No Console do Google Cloud, acesse a página Gerenciar recursos.

Acessar "Gerenciar recursos"

Na lista de projetos, selecione o projeto que você quer excluir e clique em Excluir .

Na caixa de diálogo, digite o ID do projeto e clique em Encerrar para excluí-lo.

A seguir

Saiba mais sobre o planejamento das práticas recomendadas para migração.