Migrazione di una VM monolitica - Ottimizzazione

Dopo la migrazione del carico di lavoro da una VM a un container, si aprono molte possibilità. Puoi ottimizzare il container e applicare strumenti e processi di modernizzazione. La modifica del codice sorgente del carico di lavoro e del deployment è molto più semplice. Mentre gli strumenti operativi, come il logging e il monitoraggio, possono essere integrati completamente con il carico di lavoro.

Obiettivi

Al termine di questo tutorial, avrai imparato a:

Esplora gli artefatti della migrazione.
Modifica il codice sorgente e il Dockerfile del carico di lavoro di cui è stata eseguita la migrazione.
Sfrutta la suite operativa di Google Cloud per monitorare e visualizzare i log del carico di lavoro di cui è stata eseguita la migrazione.
Ottimizza ulteriormente il carico di lavoro utilizzando le best practice per la modernizzazione.

Prima di iniziare

Questo tutorial è un follow-up del tutorial Migrazione e deployment. Prima di iniziare, segui le istruzioni per creare e personalizzare un piano di migrazione per la tua VM. Quindi esegui il deployment degli artefatti containerizzati risultanti.

Esplora gli artefatti della migrazione

In questa sezione scoprirai alcuni degli artefatti creati durante il processo di migrazione e i loro ruoli. Potrai quindi modificare questi file per aumentare e aggiornare il carico di lavoro in futuro.

Visualizza la configurazione di 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" ]

Questo file contiene il passaggio necessario per generare l'immagine container per questo carico di lavoro. Puoi aggiungere e aggiornare librerie, apportare modifiche al codice sorgente e aggiungere nuovi file. Un riferimento aggiornato per questa configurazione è disponibile qui.

Visualizza il file 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: {}
. . .
. . .

Questo file contiene le definizioni delle risorse Kubernetes per il carico di lavoro di cui è stata eseguita la migrazione. Definisce uno StatefulSet per i processi, un servizio per la porta e una coppia di PersistentVolumeClaim e PersistentVolume che contengono il database di cui è stata eseguita la migrazione.

In questo output di esempio, l'immagine Docker impostata per lo StatefulSet è gcr.io/my-project/ledgermonolith-service:11-24-2021--16-22-59, che è stata generata durante il processo di migrazione e contiene il carico di lavoro della VM originale.

Modifica il codice sorgente

Ora imparerai come modificare il codice sorgente del carico di lavoro e Dockerfile, taggare ed eseguire il push di una nuova immagine container ed eseguire il deployment di questo carico di lavoro aggiornato nel cluster.

Modifica il controller principale del registro in modo che restituisca sempre un saldo statico quando viene eseguita una query su un saldo. Esegui questo comando che sostituirà Long balance = info.getBalance(); con 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
```
Vai alla radice del codice sorgente del servizio e crea l'artefatto Java.
```
cd ${HOME}/bank-of-anthos/src/ledgermonolith/
mvn -f . package
```
Nota: per creare Bank of Anthos è necessario Java 17 o versioni successive.

Aggiungi un comando COPY nel Dockerfile per copiare l'artefatto Java appena creato nell'immagine container.

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

Crea ed esegui il push dell'immagine container.

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

Cambia l'origine dell'immagine con quella inviata di recente,

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

Puoi visualizzare lo stato dei pod utilizzando il seguente comando:

kubectl get pods

Potrebbero essere necessari alcuni secondi prima che il pod ledgermonolith-service sia attivo e funzionante.

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

Una volta che tutti i pod sono impostati su Running, puoi trovare l'indirizzo IP esterno frontend del LoadBalancer.

kubectl get service frontend

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

Apri un browser e visita la pagina web all'indirizzo IP esterno rilevato in precedenza (assicurati di utilizzare HTTP, anziché HTTPS).
```
http://EXTERNAL_IP
```
Dovresti riuscire ad accedere con le credenziali predefinite e a visualizzare le transazioni. Come previsto dalla modifica del codice sorgente, il saldo ora mostra 123,45 $.

Monitorare il container

In questa sezione scoprirai come la migrazione dei carichi di lavoro ai container facilita l'osservabilità, ad esempio l'esplorazione dei log e il monitoraggio di applicazioni e servizi.

Apri la Google Cloud Console, vai al prodotto GKE e fai clic su Carichi di lavoro.
Trova il carico di lavoro ledgermonolith-service e fai clic per visualizzarne lo stato attuale e storico. In questa pagina puoi visualizzare l'utilizzo di memoria e CPU, nonché eventi e specifiche.
Fai clic sulla scheda Log per visualizzare i log storici del carico di lavoro. Puoi visualizzare queste informazioni anche utilizzando Cloud Logging.

Ulteriore ottimizzazione

Da qui, ci sono molti processi e attività di ottimizzazione che possono migliorare l'esperienza con i container. Di seguito sono riportati alcuni esempi di queste attività che esulano dall'ambito di questo tutorial.

Aggiungi criteri di sicurezza e identità. La configurazione dei criteri consente di limitare l'accesso ai vari carichi di lavoro e alla configurazione non solo esternamente, ma anche internamente tra i servizi. Sono inclusi i criteri, come controllo dell'accesso basato sui ruoli e l'accesso in entrata e in uscita.
Integrazione con una pipeline di deployment e integrazione continui. Integrando i tuoi carichi di lavoro in una pipeline di integrazione e deployment continui, accelera la velocità di sviluppo e test delle funzionalità.
Disaccoppia il carico di lavoro di cui è stata eseguita la migrazione in microservizi. Attualmente il carico di lavoro ledgermonolith-service migrato è composto da tre processi logici e un database. Possono essere suddivisi in più microservizi, il che ti consente di configurare scalabilità e criteri più dettagliati per servizi e processi specifici. In questo modo si riduce l'attrito durante lo sviluppo e l'iterazione.
Configura un mesh di servizi. L'implementazione di un mesh di servizi nei tuoi carichi di lavoro offre funzionalità come gestione del traffico, autenticazione reciproca e osservabilità. Un mesh di servizi può essere implementato all'interno di un singolo cluster o in più cluster.
Abilita la scalabilità automatica e gli aggiornamenti in sequenza. Impostando la scalabilità automatica e gli aggiornamenti in sequenza, Kubernetes consente ai carichi di lavoro di essere a tolleranza di errore e ad alta disponibilità. La scalabilità automatica include nodi e pod con scalabilità orizzontale e scalabilità verticale delle risorse allocate. Per configurare questa funzionalità, pianifica più repliche dei carichi di lavoro ed eseguine l'upgrade una alla volta in modo resiliente.

Riepilogo

Hai iniziato questa serie di tutorial con un'applicazione live composta da più servizi. Alcuni servizi risiedono in un cluster GKE, mentre altri su una VM in Compute Engine. Hai eseguito correttamente la migrazione di un servizio e database monolitici da una VM al cluster GKE. Questo processo riduce i costi di elaborazione e aumenta la facilità di sviluppo per gli sviluppatori. Infine, hai appreso come eseguire rapidamente l'iterazione del codice sorgente e hai imparato alcune best practice per la modernizzazione.

Esegui la pulizia

Per evitare addebiti Google Cloud inutili, devi eliminare le risorse utilizzate per questo tutorial quando hai finito. Queste risorse sono:

Il cluster GKE boa-cluster
Il cluster GKE migration-processing
La VM di Compute Engine ledgermonolith-service

Puoi eliminare queste risorse manualmente o seguire i passaggi riportati di seguito per eliminare il progetto, il che eliminerà anche tutte le risorse.

Attenzione: l'eliminazione di un progetto ha i seguenti effetti:

L'intero contenuto del progetto viene eliminato. Se hai utilizzato un progetto esistente per le attività in questo documento, quando lo elimini elimini anche qualsiasi altro lavoro svolto nel progetto.
Gli ID progetto personalizzati non sono più disponibili. Quando hai creato questo progetto, potresti aver creato un ID progetto personalizzato che vuoi utilizzare in futuro. Per conservare gli URL che utilizzano l'ID progetto, ad esempio un URL appspot.com, elimina le risorse selezionate all'interno del progetto anziché eliminare l'intero progetto.

Se intendi esplorare più architetture, tutorial o guide rapide, puoi riutilizzare i progetti ed evitare così di superare i limiti di quota.

Nella console Google Cloud, vai alla pagina Gestisci risorse.

Vai a Gestisci risorse

Nell'elenco dei progetti, seleziona il progetto che vuoi eliminare, quindi fai clic su Elimina.

Nella finestra di dialogo, digita l'ID del progetto e fai clic su Chiudi per eliminare il progetto.

Passaggi successivi

Scopri di più sulle best practice di pianificazione per la migrazione.