1. Introduzione
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 eseguiremo i microservizi in Google Kubernetes Engine (GKE). 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.
Per questo lab, eseguiremo il deployment di un'applicazione monolitica esistente su un cluster Google Kubernetes Engine e quindi la suddivideremo in microservizi.
Diagramma dell'architettura dei nostri microservizi
Inizieremo suddividendo il monolite in tre microservizi, uno per volta. I microservizi sono Orders, Products e Frontend. Creiamo un'immagine Docker per ogni microservizio utilizzando Cloud Build, che attiviamo da Cloud Shell. Poi eseguiremo il deployment dei microservizi e li esporremo su Google Kubernetes Engine (GKE) selezionando il tipo di servizio Kubernetes LoadBalancer. Eseguiremo 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.
Che cosa imparerai a fare:
- 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 Platform con accesso amministrativo per creare progetti o un progetto con ruolo di Proprietario progetto.
- Conoscenza di base di Docker e Kubernetes
2. Configurazione dell'ambiente
Configurazione dell'ambiente autonomo
Se non hai ancora un Account Google (Gmail o Google Apps), devi crearne uno. Accedi alla console di Google Cloud ( console.cloud.google.com) e crea un nuovo progetto:
Ricorda l'ID progetto, un nome univoco tra tutti i progetti Google Cloud (il nome sopra è già stato utilizzato e non funzionerà per te, mi dispiace). In questo codelab verrà chiamato PROJECT_ID.
Successivamente, devi abilitare la fatturazione in Developers Console per utilizzare le risorse Google Cloud e abilitare l'API Container Engine.
L'esecuzione di questo codelab non dovrebbe costarti più di qualche dollaro, ma potrebbe essere più cara se decidi di utilizzare più risorse o se le lasci in esecuzione (vedi la sezione "Pulizia" alla fine di questo documento). I prezzi di Google Kubernetes Engine sono documentati qui.
I nuovi utenti di Google Cloud Platform possono beneficiare di una prova senza costi di 300$.
Google Cloud Shell
Sebbene Google Cloud e Kubernetes possano essere gestiti da remoto dal tuo laptop, in questo codelab utilizzeremo Google Cloud Shell, un ambiente a riga di comando in esecuzione nel cloud.
Questa macchina virtuale basata su Debian viene caricata con tutti gli strumenti di sviluppo di cui avrai bisogno. Offre una home directory permanente da 5 GB e viene eseguita in Google Cloud, migliorando notevolmente le prestazioni e l'autenticazione della rete. Ciò significa che per questo codelab ti servirà solo un browser (sì, funziona su Chromebook).
- Per attivare Cloud Shell dalla console Cloud, fai clic su Attiva Cloud Shell
(bastano pochi istanti per eseguire il provisioning e connettersi all'ambiente).
Una volta eseguita la connessione a Cloud Shell, dovresti vedere che il tuo account è già autenticato e il progetto è già impostato sul tuo PROJECT_ID.
gcloud auth list
Output comando
Credentialed accounts: - <myaccount>@<mydomain>.com (active)
gcloud config list project
Output comando
[core] project = <PROJECT_ID>
Se per qualche motivo il progetto non è impostato, esegui questo comando:
gcloud config set project <PROJECT_ID>
Stai cercando PROJECT_ID? Controlla l'ID che hai utilizzato nei passaggi di configurazione o cercalo nella dashboard della console Cloud:
Cloud Shell imposta anche alcune variabili di ambiente per impostazione predefinita, che potrebbero essere utili quando esegui i comandi futuri.
echo $GOOGLE_CLOUD_PROJECT
Output comando
<PROJECT_ID>
- Infine, imposta la zona e la configurazione del progetto predefinite.
gcloud config set compute/zone us-central1-f
Puoi scegliere una serie di zone diverse. Per saperne di più, consulta Regioni e zone.
3. Clona il repository dei file sorgente
Utilizziamo 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. Installeremo anche le dipendenze di NodeJS per testare il monolite prima del deployment. L'esecuzione dello script potrebbe richiedere alcuni minuti.
cd ~ git clone https://github.com/googlecodelabs/monolith-to-microservices.git cd ~/monolith-to-microservices ./setup.sh
In questo modo verrà clonato il repository GitHub, verrà modificata la directory e verranno installate le dipendenze necessarie per eseguire l'applicazione localmente. L'esecuzione dello script potrebbe richiedere alcuni minuti.
4. 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. Prima di poter creare un cluster, dobbiamo assicurarci che siano abilitate le API appropriate. Esegui il comando seguente per abilitare l'API Containers e utilizzare Google Kubernetes Engine:
gcloud services enable container.googleapis.com
Ora siamo pronti per creare il nostro cluster. Esegui il comando seguente per creare un cluster GKE denominato fancy-cluster con 3 nodi.
gcloud container clusters create fancy-cluster --num-nodes 3
La creazione del cluster potrebbe richiedere diversi minuti. Quando il comando è completato, esegui il comando seguente e osserva le tre istanze 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 us-east4-a n1-standard-1 10.150.0.7 XX.XX.XX.XX RUNNING gke-fancy-cluster-default-pool-ad92506d-4fvq us-east4-a n1-standard-1 10.150.0.5 XX.XX.XX.XX RUNNING gke-fancy-cluster-default-pool-ad92506d-4zs3 us-east4-a n1-standard-1 10.150.0.6 XX.XX.XX.XX RUNNING
Puoi visualizzare il cluster Kubernetes e le relative informazioni anche nella console Google Cloud. Fai clic sul pulsante del menu in alto a sinistra, 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.
5. 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 nel nostro cluster GKE ai fini di questo lab:
cd ~/monolith-to-microservices ./deploy-monolith.sh
Accedere al monolite
Per trovare l'indirizzo IP esterno della nostra applicazione monolitica, esegui questo comando.
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
NOTA: per questa operazione è necessario eseguire il provisioning di un bilanciatore del carico e di un IP esterni, pertanto l'operazione richiederà un po' di tempo. Se nell'output l'indirizzo IP esterno figura come
<pending> Attendi qualche minuto e riprova.
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.
Dovresti vedere la pagina di benvenuto del sito web monolitico come nella figura riportata sopra. La pagina di benvenuto è una pagina statica che in seguito sarà fornita dal microservizio Frontend. Il monolite ora è eseguito completamente su Kubernetes.
6. Esegui la migrazione di Orders a un microservizio
Ora che il sito web monolitico esistente è in esecuzione su GKE, possiamo iniziare a suddividere ogni servizio in microservizi. In genere sarebbe opportuno eseguire una pianificazione per valutare quali servizi suddividere in parti più piccole, soprattutto per quanto riguarda specifiche parti dell'applicazione come il dominio aziendale. A scopo dimostrativo, abbiamo creato un esempio banale e scorporato ciascun servizio relativo al dominio aziendale: Orders, Products e Frontend. La migrazione del codice è già stata eseguita e ci concentreremo sulla creazione e sul deployment dei servizi su Google Kubernetes Engine (GKE).
Crea un nuovo microservizio per gli ordini
Il primo servizio che scorporeremo è il servizio Orders. Utilizzeremo il codebase separato fornito e creeremo un container Docker distinto per questo servizio.
Crea un container Docker con Google Cloud Build
Poiché abbiamo già eseguito la migrazione del codebase per te, il nostro primo passaggio consisterà nel creare un container Docker del nostro servizio Orders utilizzando Google Cloud Build.
Normalmente useresti un approccio in due fasi che comprende la creazione di un container Docker e il relativo push a un registry per archiviare l'immagine da cui GKE esegue il pull. Ma possiamo semplificare le cose: possiamo utilizzare Google Cloud Build per creare il container Docker e inserire l'immagine in Google Cloud Container Registry con un unico comando. In questo modo, possiamo inviare un solo comando per creare e spostare l'immagine nel Container Registry. Puoi consultare il processo manuale di creazione di un file Docker e del relativo push qui.
Google Cloud Build comprime i file della directory e li sposta in un bucket di Google Cloud Storage. Il processo di compilazione preleva quindi tutti i file dal bucket e utilizza il Dockerfile per eseguire il processo di compilazione Docker. Dal momento che abbiamo specificato il flag --tag indicando gcr.io come host per l'immagine Docker, verrà eseguito il push dell'immagine Docker risultante nel Container Registry di Google Cloud.
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 richiederà qualche minuto, ma al termine verrà restituito un output simile al seguente nel terminale:
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ID CREATE_TIME DURATION SOURCE IMAGES STATUS 1ae295d9-63cb-482c-959b-bc52e9644d53 2019-08-29T01:56:35+00:00 33S gs://<PROJECT_ID>_cloudbuild/source/1567043793.94-abfd382011724422bf49af1558b894aa.tgz gcr.io/<PROJECT_ID>/orders:1.0.0 SUCCESS
Per visualizzare la cronologia delle build o per osservare lo svolgimento del processo in tempo reale, puoi andare alla console Google Cloud. Fai clic sul pulsante del menu in alto a sinistra e scorri verso il basso fino a Strumenti → Cloud Build e fai clic su 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 della build, verranno visualizzati tutti i dettagli relativi a quella build, incluso l'output del log.
Nella pagina dei dettagli della build puoi visualizzare l'immagine del container creato facendo clic sul nome dell'immagine nella sezione delle informazioni sulla build.
Esegui il deployment del container in GKE
Ora che abbiamo containerizzato il sito web ed eseguito il push del container sul Container Registry 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.
Per prima cosa, creiamo 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
Verifica il deployment
Per verificare che il deployment sia stato creato correttamente, esegui questo comando. Possono essere necessari alcuni minuti perché lo stato del pod diventi In esecuzione:
kubectl get all
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 <none> 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
Questo output mostra diverse cose. Possiamo vedere il nostro deployment corrente, il nostro ReplicaSet con il numero di pod desiderato pari a 1 e il nostro pod in esecuzione. Tutti gli elementi sono stati creati correttamente.
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 della tua applicazione. GKE crea un indirizzo IP esterno e un bilanciatore del carico (soggetto a fatturazione) per la tua applicazione.
Quando abbiamo eseguito il deployment del servizio Orders, lo abbiamo esposto internamente sulla porta 8081 tramite un deployment di Kubernetes. Per esporre questo servizio esternamente, dobbiamo creare un servizio Kubernetes di tipo LoadBalancer per instradare il traffico dalla porta 80 aperta verso l'esterno alla porta interna 8081 per il servizio Orders. 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 3d
Dopo aver determinato l'indirizzo IP esterno della tua applicazione, copialo e conservalo per il prossimo passaggio, quando modificheremo il monolite in modo che punti al nuovo servizio Orders.
Riconfigura il monolite
Poiché abbiamo rimosso il servizio Orders dal monolite, dobbiamo 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. Poiché il microservizio è in esecuzione su un server diverso, non possiamo più fare riferimento agli URL di servizio come percorsi assoluti, ma dobbiamo eseguire il routing al nuovo indirizzo del server del microservizio Orders. Tieni presente che 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.
Dobbiamo aggiornare il file di configurazione nel monolite in modo che punti al nuovo indirizzo IP del microservizio Orders. Utilizza l'editor nano per sostituire l'URL locale con l'indirizzo IP del nostro nuovo microservizio Orders. Esegui questo comando per modificare il
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
Sostituisci REACT_APP_ORDERS_URL con il nuovo formato durante la sostituzione 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
Premi CTRL+O, ENTER e poi CTRL+X per salvare il file nell'editor nano.
Puoi testare il nuovo microservizio accedendo all'URL che hai appena impostato in questo file. La pagina web dovrebbe restituire una risposta in formato JSON dal nostro microservizio Orders.
A questo punto, dobbiamo ricompilare il frontend del monolite e ripetere 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:
Ricrea i file di configurazione del monolite
npm run build:monolith
Crea un container Docker con Google Cloud Build
cd ~/monolith-to-microservices/monolith
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:2.0.0 .
Esegui il deployment del container in GKE
kubectl set image deployment/monolith monolith=gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:2.0.0
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:
7. Esegui la migrazione di Products a un microservizio
Crea un nuovo microservizio Products
Possiamo continuare a scorporare i servizi eseguendo la migrazione del servizio Products. Seguiremo la stessa procedura del passaggio precedente. Esegui il seguente comando per creare un container Docker, eseguire il deployment del container ed esporlo utilizzando un servizio Kubernetes.
Crea un container Docker con Google Cloud Build
cd ~/monolith-to-microservices/microservices/src/products
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/products:1.0.0 .
Esegui il deployment del container in GKE
kubectl create deployment products --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/products:1.0.0
Esponi il container GKE
kubectl expose deployment products --type=LoadBalancer --port 80 --target-port 8082
Trova l'IP pubblico dei nostri servizi Products come avevamo fatto per il servizio Orders con il seguente comando:
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
Salva l'indirizzo IP per il passaggio successivo, quando riconfigureremo il monolite in modo che punti al nuovo microservizio Products.
Riconfigura il monolite
Utilizza 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
Sostituisci REACT_APP_PRODUCTS_URL con il nuovo formato durante la sostituzione 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
Premi CTRL+O, ENTER e poi CTRL+X per salvare il file nell'editor nano.
Puoi testare il nuovo microservizio accedendo all'URL che hai appena impostato in questo file. La pagina web dovrebbe restituire una risposta in formato JSON dal nostro microservizio Products.
A questo punto, dobbiamo ricompilare il frontend del monolite e ripetere 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:
Ricrea i file di configurazione del monolite
npm run build:monolith
Crea un container Docker con Google Cloud Build
cd ~/monolith-to-microservices/monolith
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:3.0.0 .
Esegui il deployment del container in GKE
kubectl set image deployment/monolith monolith=gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:3.0.0
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:
8. 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 il nuovo microservizio Frontend
Seguiamo la stessa procedura degli ultimi due passaggi per creare un nuovo microservizio frontend.
In precedenza, quando abbiamo ricompilato il monolite, abbiamo aggiornato la configurazione in modo che puntasse al monolite, ma ora dobbiamo utilizzare la stessa configurazione per il microservizio Frontend. 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
Al termine, seguiremo 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.
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 .
Esegui il deployment del container in GKE
kubectl create deployment frontend --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/frontend:1.0.0
Esponi il container GKE
kubectl expose deployment frontend --type=LoadBalancer --port 80 --target-port 8080
Elimina il monolite
Ora che tutti i nostri servizi sono in esecuzione come microservizi, possiamo 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, 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 visualizzare un elenco di tutti i servizi e indirizzi IP, utilizza 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 <none> 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 suddividessimo il monolite in microservizi.
9. Esegui la pulizia
Quando è tutto pronto, il modo più semplice per eliminare tutte le attività eseguite è eliminare il progetto. L'eliminazione del progetto comporta l'eliminazione di tutte le risorse create in questo Codelab per garantire che non si verifichino addebiti ricorrenti imprevisti. Esegui il seguente comando in Cloud Shell, dove PROJECT_ID è l'ID progetto completo e non solo il nome del progetto.
gcloud projects delete [PROJECT_ID]
Conferma l'eliminazione inserendo "Y" quando richiesto.
10. Complimenti!
Hai suddiviso la tua applicazione monolitica in microservizi di cui hai eseguito il deployment su Google Kubernetes Engine.
Passaggi successivi
Consulta i seguenti codelab per scoprire di più su Kubernetes:
- Eseguire il deployment, scalare e aggiornare il tuo sito web su Google Kubernetes Engine
- Crea un bot Slack con Node.js su Kubernetes
- Distribuzione continua su Kubernetes utilizzando Spinnaker
- Esegui il deployment di un'applicazione Java in Kubernetes su Google Kubernetes Engine
Risorse aggiuntive
- Docker - https://docs.docker.com/
- Kubernetes - https://kubernetes.io/docs/home/
- Google Kubernetes Engine (GKE) - https://cloud.google.com/kubernetes-engine/docs/
- Google Cloud Build - https://cloud.google.com/cloud-build/docs/
- Google Container Registry - https://cloud.google.com/container-registry/docs/
- Migrating Monoliths to Microservices - https://cloud.google.com/solutions/migrating-a-monolithic-app-to-microservices-gke