arrow_back

Migrazione di un sito web monolitico ai microservizi su Google Kubernetes Engine

Partecipa Accedi
Test and share your knowledge with our community!
done
Get access to over 700 hands-on labs, skill badges, and courses

Migrazione di un sito web monolitico ai microservizi su Google Kubernetes Engine

Lab 1 ora 30 minuti universal_currency_alt 5 crediti show_chart Intermedio
Test and share your knowledge with our community!
done
Get access to over 700 hands-on labs, skill badges, and courses

GSP699

Laboratori autogestiti Google Cloud

Panoramica

Perché eseguire la migrazione da un'applicazione monolitica a un'architettura a microservizi? La suddivisione di un'applicazione in microservizi presenta i seguenti vantaggi, la maggior parte dei quali deriva dal fatto che i microservizi sono a basso accoppiamento:

  • I microservizi possono essere testati e distribuiti in modo indipendente. La facilità di deployment è direttamente proporzionale alle dimensioni dell'unità da distribuire.
  • I microservizi possono essere implementati utilizzando linguaggi e framework diversi. Per ogni microservizio, si è liberi di scegliere la tecnologia più adatta al caso d'uso specifico.
  • I microservizi possono essere gestiti da team diversi. Le linee di demarcazione tra microservizi facilitano l'assegnazione di un team a uno o più microservizi.
  • Il passaggio ai microservizi consente di allentare le dipendenze tra i team. Ciascun team sarà interessato soltanto alle API dei microservizi da cui dipende il proprio lavoro e non dovrà preoccuparsi di come sono implementati quei microservizi, dei loro cicli di release e così via.
  • È più facile progettare la gestione degli errori. Dal momento che i confini tra servizi sono chiari, è più semplice stabilire cosa fare quando un servizio non è disponibile.

Alcuni svantaggi rispetto ai monoliti:

  • Un'app basata su microservizi è costituita da una rete di servizi diversi che spesso interagiscono in modi che non sono ovvi, pertanto la complessità generale del sistema tende ad aumentare.
  • A differenza dei componenti interni di un monolite, i microservizi comunicano su una rete. In alcuni casi questo aspetto può essere percepito come un rischio per la sicurezza. Istio risolve questo problema criptando automaticamente il traffico tra microservizi.
  • A causa delle latenze tra i servizi, può essere difficile raggiungere lo stesso livello di prestazioni offerto da un approccio monolitico.
  • Il comportamento del sistema non dipende dal singolo servizio, ma da molti servizi e dalle loro interazioni. Per questo motivo, l'osservabilità del sistema, ossia la comprensione del suo funzionamento in ambiente di produzione, risulta più difficile. Istio risolve anche questo problema.

In questo lab eseguirai il deployment di un'applicazione monolitica esistente su un cluster Google Kubernetes Engine e quindi la suddividerai in microservizi. Kubernetes è una piattaforma utilizzata per la gestione, l'hosting, la scalabilità e il deployment di container. I container rappresentano un modo portabile per confezionare ed eseguire codice. Sono particolarmente indicati per i pattern a microservizi, in cui ciascun microservizio può essere eseguito nel proprio container.

Diagramma dell'architettura dei nostri microservizi

Per iniziare, suddividi il monolite in tre microservizi, uno per volta. I microservizi sono Orders, Products e Frontend. Crea un'immagine Docker per ciascun microservizio utilizzando Cloud Build, quindi esegui il deployment dei microservizi ed esponili su Google Kubernetes Engine (GKE) selezionando il tipo di servizio Kubernetes LoadBalancer. Eseguirai questa operazione per ciascun servizio, scorporando allo stesso tempo ciascuno dal monolite mediante refactoring. Durante questo processo sia il monolite sia i microservizi saranno in esecuzione fino alla fine, quando potrai eliminare il monolite.

Obiettivi didattici

  • Suddividere un monolite in microservizi
  • Creare un cluster Google Kubernetes Engine
  • Creare un'immagine Docker
  • Eseguire il deployment delle immagini Docker su Kubernetes

Prerequisiti

  • Un account Google Cloud con accesso amministrativo per creare progetti o un progetto con ruolo di Proprietario progetto.
  • Conoscenza di base di Docker e Kubernetes

Configurazione e requisiti

Prima di fare clic sul pulsante Avvia lab

Leggi le seguenti istruzioni. I lab sono a tempo e non possono essere messi in pausa. Il timer si avvia quando fai clic su Avvia lab e ti mostra per quanto tempo avrai a disposizione le risorse Google Cloud.

Con questo lab pratico avrai la possibilità di completare le attività in prima persona, in un ambiente cloud reale e non di simulazione o demo. Riceverai delle nuove credenziali temporanee che potrai utilizzare per accedere a Google Cloud per la durata del lab.

Per completare il lab, avrai bisogno di:

  • Accesso a un browser internet standard (Chrome è il browser consigliato).
Nota: utilizza una finestra del browser in incognito o privata per eseguire questo lab. Ciò evita eventuali conflitti tra il tuo account personale e l'account Studente, che potrebbero causare addebiti aggiuntivi sul tuo account personale.
  • È ora di completare il lab: ricorda che, una volta iniziato, non puoi metterlo in pausa.
Nota: se hai già un account o un progetto Google Cloud personale, non utilizzarlo per questo lab per evitare addebiti aggiuntivi al tuo account.

Come avviare il lab e accedere alla console Google Cloud

  1. Fai clic sul pulsante Avvia lab. Se devi effettuare il pagamento per il lab, si apre una finestra popup per permetterti di selezionare il metodo di pagamento. A sinistra, trovi il riquadro Dettagli lab con le seguenti informazioni:

    • Pulsante Apri console Google
    • Tempo rimanente
    • Credenziali temporanee da utilizzare per il lab
    • Altre informazioni per seguire questo lab, se necessario
  2. Fai clic su Apri console Google. Il lab avvia le risorse e apre un'altra scheda con la pagina di accesso.

    Suggerimento: disponi le schede in finestre separate posizionate fianco a fianco.

    Note: se visualizzi la finestra di dialogo Scegli un account, fai clic su Utilizza un altro account.
  3. Se necessario, copia il Nome utente dal riquadro Dettagli lab e incollalo nella finestra di dialogo di accesso. Fai clic su Avanti.

  4. Copia la Password dal riquadro Dettagli lab e incollala nella finestra di dialogo di benvenuto. Fai clic su Avanti.

    Importante: devi utilizzare le credenziali presenti nel riquadro di sinistra. Non utilizzare le tue credenziali Google Cloud Skills Boost. Nota: utilizzare il tuo account Google Cloud per questo lab potrebbe comportare addebiti aggiuntivi.
  5. Fai clic nelle pagine successive:

    • Accetta i termini e le condizioni.
    • Non inserire opzioni di recupero o l'autenticazione a due fattori, perché si tratta di un account temporaneo.
    • Non registrarti per le prove gratuite.

Dopo qualche istante, la console Google Cloud si apre in questa scheda.

Nota: puoi visualizzare il menu con un elenco di prodotti e servizi Google Cloud facendo clic sul menu di navigazione in alto a sinistra. Icona menu di navigazione

Attiva Cloud Shell

Cloud Shell è una macchina virtuale in cui sono caricati strumenti per sviluppatori. Offre una home directory permanente da 5 GB e viene eseguita su Google Cloud. Cloud Shell fornisce l'accesso da riga di comando alle risorse Google Cloud.

  1. Fai clic su Attiva Cloud Shell Icona Attiva Cloud Shell nella parte superiore della console Google Cloud.

Quando la connessione è attiva, l'autenticazione è già avvenuta e il progetto è impostato sul tuo PROJECT_ID. L'output contiene una riga che dichiara il PROJECT_ID per questa sessione:

Your Cloud Platform project in this session is set to YOUR_PROJECT_ID

gcloud è lo strumento a riga di comando di Google Cloud. È preinstallato su Cloud Shell e supporta il completamento tramite tasto Tab.

  1. (Facoltativo) Puoi visualizzare il nome dell'account attivo con questo comando:
gcloud auth list
  1. Fai clic su Autorizza.

  2. L'output dovrebbe avere ora il seguente aspetto:

Output:

ACTIVE: * ACCOUNT: student-01-xxxxxxxxxxxx@qwiklabs.net To set the active account, run: $ gcloud config set account `ACCOUNT`
  1. (Facoltativo) Puoi elencare l'ID progetto con questo comando:
gcloud config list project

Output:

[core] project = <project_ID>

Output di esempio:

[core] project = qwiklabs-gcp-44776a13dea667a6 Nota: per la documentazione completa di gcloud, in Google Cloud, fai riferimento alla Panoramica dell'interfaccia a riga di comando gcloud.

Imposta la zona e la configurazione del progetto predefinite:

gcloud config set compute/zone {{{project_0.default_zone | (zone)}}}

Attività 1: clona il repository del codice sorgente

Utilizzerai un'applicazione monolitica esistente di un sito web di e-commerce immaginario, con una semplice pagina di benvenuto, una pagina per i prodotti e una pagina con la cronologia degli ordini. Dovremo solo clonare i file sorgente dal nostro repository Git, così potremo concentrarci sulla sua suddivisione in microservizi e sul deployment in Google Kubernetes Engine (GKE).

  • Esegui i comandi seguenti per clonare il repository Git sulla tua istanza di Cloud Shell e passa alla directory appropriata. Installerai anche le dipendenze di NodeJS per testare il monolite prima del deployment:
cd ~ git clone https://github.com/googlecodelabs/monolith-to-microservices.git cd ~/monolith-to-microservices ./setup.sh

L'esecuzione dello script potrebbe richiedere alcuni minuti.

Attività 2: crea un cluster GKE

Ora che il tuo ambiente di sviluppo è pronto, ti serve un cluster Kubernetes in cui eseguire il deployment del monolite e, in seguito, anche dei microservizi. Per poter creare il cluster, devi prima verificare che siano abilitate le API appropriate.

  1. Esegui il comando seguente per abilitare l'API Containers e utilizzare Google Kubernetes Engine:
gcloud services enable container.googleapis.com
  1. Esegui il comando seguente per creare un cluster GKE denominato fancy-cluster con 3 nodi:
gcloud container clusters create fancy-cluster --num-nodes 3 --machine-type=e2-standard-4 Avviso: se viene visualizzato un errore che segnala che non è specificata la regione o la zona, consulta la sezione sulla configurazione dell'ambiente per accertarti di aver impostato la zona di computing predefinita.

La creazione del cluster potrebbe richiedere diversi minuti.

  1. Quando il comando è completato, esegui il codice seguente per vedere le tre istanze di VM worker del cluster:
gcloud compute instances list

Output:

NAME ZONE MACHINE_TYPE PREEMPTIBLE INTERNAL_IP EXTERNAL_IP STATUS gke-fancy-cluster-default-pool-ad92506d-1ng3 {{{project_0.default_zone | (zone)}}} e2-standard-4 10.150.0.7 XX.XX.XX.XX RUNNING gke-fancy-cluster-default-pool-ad92506d-4fvq {{{project_0.default_zone | (zone)}}} e2-standard-4 10.150.0.5 XX.XX.XX.XX RUNNING gke-fancy-cluster-default-pool-ad92506d-4zs3 {{{project_0.default_zone | (zone)}}} e2-standard-4 10.150.0.6 XX.XX.XX.XX RUNNING

Puoi visualizzare il cluster Kubernetes e le relative informazioni anche nella console Cloud. Nel menu di navigazione, scorri verso il basso fino a Kubernetes Engine e fai clic su Cluster.

Dovresti vedere il cluster denominato fancy-cluster.

Complimenti! Hai appena creato il tuo primo cluster Kubernetes.

Fai clic su Controlla i miei progressi per verificare l'obiettivo. Crea un cluster GKE.

Attività 3: esegui il deployment del monolite esistente

L'obiettivo di questo lab è la suddivisione di un monolite in microservizi, pertanto devi avere a disposizione un'applicazione monolitica funzionante.

  • Esegui lo script seguente per eseguire il deployment di un'applicazione monolitica sul tuo cluster GKE:
cd ~/monolith-to-microservices ./deploy-monolith.sh

Accedi al monolite

  1. Esegui il comando seguente per trovare l'indirizzo IP esterno dell'applicazione monolitica:
kubectl get service monolith

Dovresti vedere un output simile al seguente:

NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE monolith 10.3.251.122 203.0.113.0 80:30877/TCP 3d
  1. Se nell'output l'indirizzo IP esterno figura come <pending>, attendi qualche istante ed esegui di nuovo il comando.

  2. Quando hai determinato l'indirizzo IP esterno del tuo monolite, copialo. Accedi con il browser all'URL (ad esempio http://203.0.113.0) per verificare che il monolite sia accessibile.

Nota: segnati questo indirizzo IP perché continuerai a utilizzarlo man mano che andiamo avanti. Puoi sempre recuperarlo utilizzando il comando precedente.

Dovresti visualizzare la pagina di benvenuto per il sito web monolitico. La pagina di benvenuto è una pagina statica che in seguito sarà fornita dal microservizio Frontend. Il monolite ora è eseguito completamente su Kubernetes.

Fai clic su Controlla i miei progressi per verificare l'obiettivo. Esegui il deployment del monolite esistente.

Attività 4: esegui la migrazione di Orders a un microservizio

Ora che il sito web monolitico è in esecuzione su GKE, inizia a scomporre i singoli servizi in microservizi. In genere sarebbe opportuno eseguire una pianificazione per decidere quali servizi suddividere in parti più piccole, soprattutto per quanto riguarda specifiche parti dell'applicazione, come il dominio aziendale.

Per questo lab creerai un esempio e scorporerai ciascun servizio relativo al dominio aziendale: Orders, Products e Frontend. La migrazione del codice è già stata eseguita, quindi ti puoi concentrare sulla creazione e sul deployment dei servizi su Google Kubernetes Engine (GKE).

Crea un nuovo microservizio per gli ordini

Il primo servizio da scorporare è il servizio Orders. Utilizza il codebase separato fornito e crea un container Docker distinto per questo servizio.

Crea un container Docker con Cloud Build

Il codebase è già disponibile, pertanto il tuo primo passaggio consisterà nel creare un container Docker del tuo servizio Orders utilizzando Cloud Build.

Normalmente questa procedura si esegue in due passaggi, che comprendono la creazione di un container Docker e il push del container a un registry per archiviare l'immagine da cui GKE esegue il pull. Si può utilizzare Cloud Build per creare il container Docker e inserire l'immagine nel Container Registry con un unico comando. Questo ti permette di inviare un solo comando per creare e spostare l'immagine nel Container Registry. Per conoscere il processo manuale di creazione di un file docker e di push, vai alla documentazione di Google Cloud relativa a Container Registry e consulta la Guida rapida per Container Registry.

Google Cloud Build comprime i file della directory e li sposta in un bucket Cloud Storage. Il processo di compilazione preleva quindi tutti i file dal bucket e utilizza il Dockerfile per eseguire il processo di compilazione Docker. Nel flag --tag viene specificato l'host gcr.io per l'immagine Docker e, quindi, viene eseguito il push dell'immagine Docker al Container Registry Google Cloud.

  1. Esegui i seguenti comandi per creare il container Docker ed eseguirne il push al Container Registry di Google:
cd ~/monolith-to-microservices/microservices/src/orders gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/orders:1.0.0 .

Il processo richiede qualche minuto, ma al termine verrà restituito nel terminale un output simile al seguente:

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ID CREATE_TIME DURATION SOURCE IMAGES STATUS 1ae295d9-63cb-482c-959b-bc52e9644d53 2019-08-29T01:56:35+00:00 33S gs://_cloudbuild/source/1567043793.94-abfd382011724422bf49af1558b894aa.tgz gcr.io//orders:1.0.0 SUCCESS
  1. Per visualizzare la cronologia delle build o per osservare lo svolgimento del processo in tempo reale, nella console fai clic sul pulsante Menu di navigazione in alto a sinistra e scorri verso il basso fino a CI/CD, quindi fai clic su Cloud Build > Cronologia. Qui puoi vedere un elenco di tutte le build precedenti. Dovrebbe essere riportata solo quella che hai appena creato.

Se fai clic sull'ID build, vedrai tutti i dettagli relativi a quella build, incluso l'output di log.

Dalla pagina dei dettagli della build, per visualizzare l'immagine container creata, fai clic nella sezione destra sulla scheda Dettagli esecuzione e visualizza Immagine.

Esegui il deployment del container in GKE

Ora che hai containerizzato il sito web ed eseguito il push del container al Container Registry di Google, è il momento di eseguire il deployment su Kubernetes.

Kubernetes rappresenta le applicazioni come Pod, che corrispondono a unità che rappresentano un container (o gruppo di container strettamente associati). Il Pod è l'unità più piccola di cui è possibile eseguire il deployment in Kubernetes. In questo tutorial, ogni Pod contiene solo il container dei tuoi microservizi.

Per eseguire il deployment e gestire applicazioni su un cluster GKE, devi comunicare con il sistema di gestione dei cluster di Kubernetes. A questo scopo, in genere si utilizza lo strumento a riga di comando kubectl da Cloud Shell.

Prima di tutto, crea una risorsa di tipo Deployment. Il Deployment gestisce più copie della tua applicazione, dette repliche, e ne pianifica l'esecuzione sui singoli nodi del tuo cluster. In questo caso, il Deployment eseguirà soltanto un pod della tua applicazione. I Deployment assicurano questa funzionalità creando un ReplicaSet. Il ReplicaSet assicura che sia sempre in esecuzione il numero di repliche specificato.

Il comando kubectl create deployment riportato di seguito fa sì che Kubernetes crei sul tuo cluster un Deployment denominato Orders con 1 replica.

  • Esegui questo comando per eseguire il deployment della tua applicazione:
kubectl create deployment orders --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/orders:1.0.0 Nota: come best practice, ti consigliamo di utilizzare un file YAML per dichiarare le modifiche apportate al cluster Kubernetes (ad esempio, la creazione o la modifica di un deployment o di un servizio) e un sistema di controllo dei file sorgente come GitHub o Cloud Source Repositories per archiviare le modifiche. Per saperne di più, consulta la documentazione relativa ai deployment di Kubernetes.

Verifica il deployment

  • Per verificare se il deployment è stato creato correttamente, esegui questo comando:
kubectl get all

Possono essere necessari alcuni minuti perché lo stato del pod diventi In esecuzione.

Output:

NAME READY STATUS RESTARTS AGE pod/monolith-779c8d95f5-dxnzl 1/1 Running 0 15h pod/orders-5bc6969d76-kdxkk 1/1 Running 0 21s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/kubernetes ClusterIP 10.39.240.1 443/TCP 19d service/monolith LoadBalancer 10.39.241.130 34.74.209.57 80:30412/TCP 15h NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/monolith 1/1 1 1 15h deployment.apps/orders 1/1 1 1 21s NAME DESIRED CURRENT READY AGE replicaset.apps/monolith-779c8d95f5 1 1 1 15h replicaset.apps/orders-5bc6969d76 1 1 1 21s

Puoi vedere il tuo deployment corrente, il replicaset con il numero di pod desiderato pari a 1 e il pod che è in esecuzione. Tutti gli elementi sono stati creati correttamente.

Puoi visualizzare i tuoi deployment Kubernetes anche in Cloud Console dal menu di navigazione: vai a Kubernetes Engine > Carichi di lavoro.

Esponi il container GKE

Abbiamo eseguito il deployment della nostra applicazione su GKE, ma non abbiamo modo di accedervi al di fuori del cluster. Per impostazione predefinita, i container che esegui su GKE non sono accessibili da internet perché non hanno un indirizzo IP esterno. Devi esporre esplicitamente la tua applicazione al traffico di internet tramite una risorsa di tipo Servizio. Un Servizio fornisce il supporto IP e di networking ai pod dell'applicazione. GKE crea un indirizzo IP esterno e un bilanciatore del carico (soggetto a fatturazione - dal sito web di Google Cloud, consulta Prezzi di Compute Engine) per la tua applicazione.

Per questo lab, l'esposizione del servizio è stata semplificata. Normalmente si userebbe un gateway API per proteggere gli endpoint pubblici. Nel Centro architetture di Google Cloud, leggi ulteriori informazioni sulle best practice relative ai microservizi.

Quando hai eseguito il deployment del servizio Orders, lo hai esposto internamente sulla porta 8081 tramite un deployment di Kubernetes. Per esporre questo servizio esternamente, devi creare un servizio Kubernetes di tipo LoadBalancer per instradare il traffico dalla porta 80 aperta verso l'esterno alla porta interna 8081.

  • Per esporre il sito web su internet, esegui questo comando:
kubectl expose deployment orders --type=LoadBalancer --port 80 --target-port 8081

Accedi al servizio

GKE assegna l'indirizzo IP esterno alla risorsa Servizio, non a quella Deployment.

  • Se vuoi conoscere l'indirizzo IP esterno di cui GKE ha eseguito il provisioning per la tua applicazione, puoi utilizzare il comando kubectl get service per esaminare il servizio:
kubectl get service orders

Output:

NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE orders 10.3.251.122 203.0.113.0 80:30877/TCP 3s

Dopo aver determinato l'indirizzo IP esterno della tua applicazione, copialo e conservalo per il prossimo passaggio, quando modificherai il monolite in modo che punti al nuovo servizio Orders.

Riconfigura il monolite

Poiché hai rimosso il servizio Orders dal monolite, devi modificare quest'ultimo in modo che punti al nuovo microservizio esterno Orders.

La suddivisione di un monolite comporta lo spostamento di parti di codice da un singolo codebase a più microservizi e l'esecuzione di deployment separati. Dal momento che i microservizi sono in esecuzione su un server diverso, non puoi più fare riferimento agli URL di servizio come percorsi assoluti, ma devi eseguire il routing all'indirizzo del server del microservizio Orders. Per farlo è necessario prevedere un certo tempo di inattività, così da consentire al servizio del monolite di aggiornare l'URL di ciascun servizio che è stato scorporato. Questo è un elemento da tenere presente quando si pianifica lo spostamento dei microservizi e del monolite in un ambiente di produzione durante il processo di migrazione dei microservizi.

Devi aggiornare il file di configurazione nel monolite in modo che punti al nuovo indirizzo IP del microservizio Orders.

  1. Utilizza l'editor nano per sostituire l'URL locale con l'indirizzo IP del microservizio Orders:
cd ~/monolith-to-microservices/react-app nano .env.monolith

All'apertura dell'editor, il file dovrebbe avere l'aspetto seguente:

REACT_APP_ORDERS_URL=/service/orders REACT_APP_PRODUCTS_URL=/service/products
  1. Sostituisci il valore di REACT_APP_ORDERS_URL utilizzando il nuovo formato per la sostituzione del percorso con l'indirizzo IP del microservizio Orders, in modo che corrisponda a quanto segue:
REACT_APP_ORDERS_URL=http://<ORDERS_IP_ADDRESS>/api/orders REACT_APP_PRODUCTS_URL=/service/products
  1. Premi Ctrl+O, Invio e quindi Ctrl+X per salvare il file nell'editor nano.

  2. Accedi all'URL che hai appena impostato nel file per testare il nuovo microservizio. La pagina web dovrebbe restituire una risposta in formato JSON dal microservizio Orders.

  3. A questo punto, ricrea il Frontend del monolite e ripeti il processo di compilazione per creare il container per il monolite ed eseguire di nuovo il deployment nel cluster GKE:

  • Ricrea i file di configurazione del monolite:
npm run build:monolith
  1. Crea il container in Docker con Cloud Build:
cd ~/monolith-to-microservices/monolith gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:2.0.0 .
  1. Esegui il deployment del container in GKE:
kubectl set image deployment/monolith monolith=gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:2.0.0
  1. Vai all'applicazione monolitica utilizzando il browser e naviga alla pagina Orders per verificare che l'applicazione ora utilizzi il microservizio Orders. Tutti gli ID degli ordini devono terminare con il suffisso -MICROSERVICE come illustrato di seguito:

Tabella Orders con colonne per l&#39;ID ordine, la data, il totale degli elementi e il costo. Il formato dell&#39;ID ordine è il seguente: ORD-000001-MICROSERVICE

  1. Fai clic su Controlla i miei progressi per verificare l'obiettivo. Esegui la migrazione di Orders a un microservizio.

Attività 5: esegui la migrazione di Products a un microservizio

Crea un nuovo microservizio Products

Continua a scorporare i servizi eseguendo la migrazione del servizio Products. Segui la procedura precedente. Esegui il seguente comando per creare un container Docker, eseguire il deployment del container ed esporlo utilizzando un servizio Kubernetes.

  1. Crea il container in Docker con Cloud Build:
cd ~/monolith-to-microservices/microservices/src/products gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/products:1.0.0 .
  1. Esegui il deployment del container in GKE:
kubectl create deployment products --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/products:1.0.0
  1. Esponi il container GKE:
kubectl expose deployment products --type=LoadBalancer --port 80 --target-port 8082
  1. Trova l'IP pubblico del servizio Products come avevi fatto per il servizio Orders:
kubectl get service products

Output:

NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE products 10.3.251.122 203.0.113.0 80:30877/TCP 3d

Utilizzerai l'indirizzo IP nel passaggio successivo quando riconfigurerai il monolite in modo che punti al nuovo microservizio Products.

Riconfigura il monolite

  1. Usa l'editor nano per sostituire l'URL locale con l'indirizzo IP dei nuovi microservizi Products:
cd ~/monolith-to-microservices/react-app nano .env.monolith

All'apertura dell'editor, il file dovrebbe avere l'aspetto seguente:

REACT_APP_ORDERS_URL=http://<ORDERS_IP_ADDRESS>/api/orders REACT_APP_PRODUCTS_URL=/service/products
  1. Sostituisci il valore di REACT_APP_PRODUCTS_URL utilizzando il nuovo formato per la sostituzione del percorso con l'indirizzo IP del microservizio Products, in modo che corrisponda a quanto segue:
REACT_APP_ORDERS_URL=http://<ORDERS_IP_ADDRESS>/api/orders REACT_APP_PRODUCTS_URL=http://<PRODUCTS_IP_ADDRESS>/api/products
  1. Premi Ctrl+O, Invio e quindi Ctrl+X per salvare il file.

  2. Accedi all'URL che hai appena impostato nel file per testare il nuovo microservizio. La pagina web dovrebbe restituire una risposta in formato JSON dal microservizio Products.

  3. A questo punto, ricrea il Frontend del monolite e ripeti il processo di compilazione per creare il container per il monolite ed eseguire di nuovo il deployment nel cluster GKE. Esegui i comandi seguenti per completare questi passaggi:

  4. Ricrea i file di configurazione del monolite:

npm run build:monolith
  1. Crea il container in Docker con Cloud Build:
cd ~/monolith-to-microservices/monolith gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:3.0.0 .
  1. Esegui il deployment del container in GKE:
kubectl set image deployment/monolith monolith=gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:3.0.0
  1. Vai all'applicazione monolitica utilizzando il browser e naviga alla pagina Products per verificare che l'applicazione ora utilizzi il microservizio Products. Tutti i nomi di prodotto devono essere preceduti da MS, come illustrato di seguito:

Riquadri di immagini con ogni immagine etichettata nel seguente formato: MS - nome immagine - prezzo. Esempio: MS-Macchina da scrivere vintage Typewriter-67,99 €.

  1. Fai clic su Controlla i miei progressi per verificare l'obiettivo. Esegui la migrazione di Products a un microservizio

Attività 6: esegui la migrazione del frontend a un microservizio

L'ultimo passaggio del processo di migrazione consiste nello spostare il codice del frontend in un microservizio e arrestare il monolite. Quando avrai completato questo passaggio, avremo completato correttamente la migrazione del monolite a un'architettura a microservizi.

Crea un nuovo microservizio frontend

Per creare un nuovo microservizio frontend, segui la stessa procedura utilizzata per i due ultimi passaggi.

In precedenza, quando avevi ricompilato il monolite avevi aggiornato la configurazione in modo che puntasse al monolite. Ora devi utilizzare la stessa configurazione per il microservizio Frontend.

  1. Esegui i comandi seguenti per copiare i file di configurazione dell'URL dei microservizi nel codebase del microservizio frontend:
cd ~/monolith-to-microservices/react-app cp .env.monolith .env npm run build
  1. Al termine, segui la stessa procedura dei passaggi precedenti. Esegui il seguente comando per creare un container Docker, eseguire il deployment del container ed esporlo utilizzando un servizio Kubernetes.

  2. Crea un container Docker con Google Cloud Build:

cd ~/monolith-to-microservices/microservices/src/frontend gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/frontend:1.0.0 .
  1. Esegui il deployment del container in GKE:
kubectl create deployment frontend --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/frontend:1.0.0
  1. Esponi il container GKE
kubectl expose deployment frontend --type=LoadBalancer --port 80 --target-port 8080
  1. Fai clic su Controlla i miei progressi per verificare l'obiettivo. Esegui la migrazione del frontend a un microservizio.

Elimina il monolite

Ora che tutti i servizi sono in esecuzione come microservizi, puoi eliminare l'applicazione monolitica. Tieni presente che, in una migrazione reale, questo comporta anche modifiche al DNS e così via, per fare in modo che i nomi di dominio esistenti facciano riferimento ai nuovi microservizi di frontend della nostra applicazione.

  • Esegui i seguenti comandi per eliminare il monolite:
kubectl delete deployment monolith kubectl delete service monolith

Verifica l'attività completata

Per verificare che tutto funzioni correttamente, a questo punto il vecchio indirizzo IP del servizio monolitico non dovrebbe più funzionare e il nuovo indirizzo IP del servizio frontend dovrebbe ospitare la nuova applicazione.

  • Per vedere un elenco di tutti i servizi e indirizzi IP, esegui questo comando:
kubectl get services

Dovresti vedere un output simile al seguente:

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE frontend LoadBalancer 10.39.246.135 35.227.21.154 80:32663/TCP 12m kubernetes ClusterIP 10.39.240.1 443/TCP 18d orders LoadBalancer 10.39.243.42 35.243.173.255 80:32714/TCP 31m products LoadBalancer 10.39.250.16 35.243.180.23 80:32335/TCP 21m

Dopo aver determinato l'indirizzo IP esterno del tuo microservizio Frontend, copia l'indirizzo IP. Accedi con il browser all'URL (ad esempio http://203.0.113.0) per verificare che il frontend sia accessibile. Il tuo sito web dovrebbe essere uguale a com'era prima che suddividessi il monolite in microservizi.

Complimenti!

Hai suddiviso la tua applicazione monolitica in microservizi di cui hai eseguito il deployment su Google Kubernetes Engine.

Completa la Quest

Questo self-paced lab fa parte della Quest Website on Google Cloud. Una Quest è una serie di lab collegati tra loro che formano un percorso di apprendimento. Iscriviti a questa Quest e ottieni subito un riconoscimento per aver completato questo lab. Consulta il catalogo di Google Cloud Skills Boost per tutte le Quest disponibili.

Stai cercando un Challenge Lab pratico per dimostrare le tue abilità e convalidare le tue conoscenze? Dopo aver completato questa Quest, termina il Challenge Lab aggiuntivo.

Segui il prossimo lab

Per approfondire l'argomento guarda il video del case study Hosting Scalable Web Applications on Google Cloud o dai uno sguardo a questi suggerimenti:

Passaggi successivi/Ulteriori risorse

Formazione e certificazione Google Cloud

… per utilizzare al meglio le tecnologie Google Cloud. I nostri corsi ti consentono di sviluppare competenze tecniche e best practice per aiutarti a metterti subito al passo e avanzare nel tuo percorso di apprendimento. Offriamo vari livelli di formazione, dal livello base a quello avanzato, con opzioni di corsi on demand, dal vivo e virtuali, in modo da poter scegliere il più adatto in base ai tuoi impegni. Le certificazioni ti permettono di confermare e dimostrare le tue abilità e competenze relative alle tecnologie Google Cloud.

Ultimo aggiornamento del manuale: 20 settembre 2023

Ultimo test del lab: 20 settembre 2023

Copyright 2024 Google LLC Tutti i diritti riservati. Google e il logo Google sono marchi di Google LLC. Tutti gli altri nomi di società e prodotti sono marchi delle rispettive società a cui sono associati.