1. Introduzione
Perché eseguire la migrazione da un'applicazione monolitica a un'architettura a microservizi? La suddivisione di un'applicazione in microservizi offre i seguenti vantaggi: la maggior parte di questi 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 in 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 alla volta. I microservizi sono Orders, Products e Frontend. Creiamo un'immagine Docker per ogni microservizio utilizzando Cloud Build, che attiviamo dall'interno di Cloud Shell. Successivamente eseguiremo il deployment dei nostri microservizi ed esploreremo i nostri microservizi su Google Kubernetes Engine (GKE) con un tipo di servizio Kubernetes LoadBalancer. Eseguiremo questa operazione per ogni 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 saremo in grado di 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 autogestito
Se non disponi già di un account Google (Gmail o Google Apps), devi crearne uno. Accedi alla console della piattaforma Google Cloud ( console.cloud.google.com) e crea un nuovo progetto:
Ricorda l'ID progetto, un nome univoco in tutti i progetti Google Cloud (il nome precedente è già stato utilizzato e non funzionerà correttamente). Verrà indicato più avanti in questo codelab come PROJECT_ID.
Successivamente, dovrai 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 costare più di qualche euro, ma potrebbe essere più costoso se decidi di utilizzare più risorse o se le lasci in esecuzione (consulta la sezione relativa alla pulizia alla fine di questo documento). I prezzi di Google Kubernetes Engine sono documentati qui.
I nuovi utenti della piattaforma Google Cloud hanno diritto a una prova senza costi di$300.
Google Cloud Shell
Mentre Google Cloud e Kubernetes possono 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 necessari. Offre una home directory permanente da 5 GB e viene eseguita in Google Cloud, migliorando notevolmente le prestazioni di rete e l'autenticazione. Ciò significa che per questo codelab è sufficiente un browser (sì, funziona su Chromebook).
- Per attivare Cloud Shell dalla console Cloud, fai semplicemente clic su Attiva Cloud Shell
(il provisioning e la connessione all'ambiente dovrebbero richiedere solo pochi minuti).
Dopo la connessione a Cloud Shell, dovresti vedere che hai già eseguito l'autenticazione e che il progetto è già impostato su 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, invia semplicemente il seguente comando:
gcloud config set project <PROJECT_ID>
Stai cercando il tuo PROJECT_ID? Controlla l'ID utilizzato nei passaggi di configurazione o cercalo nella dashboard della console Cloud:
Cloud Shell imposta anche alcune variabili di ambiente per impostazione predefinita, cosa che può essere utile quando eseguirai 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 zone diverse. Per ulteriori informazioni, 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 dei prodotti e una pagina per 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 NodeJS in modo da poter 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
Questo clonerà il nostro repository GitHub, passerà alla directory e installerà le dipendenze necessarie per eseguire l'applicazione in locale. L'esecuzione dello script potrebbe richiedere alcuni minuti.
4. Crea un cluster GKE
Ora che il tuo ambiente di sviluppo è pronto, abbiamo bisogno di un cluster Kubernetes in cui eseguire il deployment del monolite e, in seguito, dei nostri microservizi. Prima di poter creare un cluster, è necessario verificare che siano abilitate le API appropriate. Esegui questo comando per abilitare l'API container in modo da poter utilizzare Google Kubernetes Engine:
gcloud services enable container.googleapis.com
Ora siamo pronti a 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. Una volta completato, esegui questo comando 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 abbiamo bisogno di rendere operativa un'applicazione monolitica. 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 dell'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: è necessario eseguire il provisioning di un bilanciatore del carico e dell'IP esterni, quindi occorrerà un po' di tempo. Se nell'output l'IP esterno sarà elencato 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 semplice esempio e abbiamo suddiviso ciascun servizio relativo al dominio aziendale, Orders, Products e Frontend. Il codice è già stato migrato e ci concentreremo sulla creazione e sul deployment dei servizi su Google Kubernetes Engine (GKE).
Crea nuovo microservizio Orders
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 in Docker con Google Cloud Build
Poiché abbiamo già eseguito la migrazione del codebase, il primo passaggio sarà 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. Per rendere la vita più semplice, possiamo usare Google Cloud Build per creare il container Docker e inserire l'immagine nel Container Registry di Google Cloud con un solo comando. Questo ci consente di inviare un singolo 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. Poiché abbiamo specificato il flag --tag con l'host gcr.io 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 il 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 container che è stata creata facendo clic sul suo nome 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 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.
Per prima cosa creeremo 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 un deployment denominato orders sul tuo cluster 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. Potrebbero 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 attuale, il nostro ReplicaSet con un numero di pod desiderato pari a 1 e il nostro pod che è 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 nostro 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 all'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 trovare l'IP esterno di cui GKE ha eseguito il provisioning per la tua applicazione, puoi ispezionare il servizio con il comando kubectl get service:
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, dovremo modificare quest'ultimo in modo che punti al nuovo microservizio esterno Orders.
Quando scomponiamo un monolite, rimuoviamo parti di codice da un singolo codebase a più code e ne eseguiamo il deployment separatamente. Poiché il microservizio è in esecuzione su un server diverso, non possiamo più fare riferimento agli URL del nostro servizio come percorsi assoluti, ma dobbiamo eseguire il routing al nuovo indirizzo del server del microservizio Orders. Tieni presente che l'aggiornamento dell'URL di ogni servizio scorporato da parte del servizio monolite richiederà un certo tempo di inattività. 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
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, premi ENTER e quindi CTRL+X per salvare il file nell'editor nano.
Puoi testare il nuovo microservizio navigando nell'URL che hai appena impostato in questo file. La pagina web dovrebbe restituire una risposta in formato JSON dal microservizio Orders.
A questo punto, dovremo ricreare il frontend del monolite e ripetere il processo di compilazione per creare il container per il monolite ed eseguire nuovamente il deployment nel nostro cluster GKE. Esegui i comandi seguenti per completare questi passaggi:
Ricrea i file di configurazione del monolite
npm run build:monolith
Crea un container in 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
Per verificare che la tua applicazione ora utilizzi il nuovo microservizio Orders, accedi all'applicazione monolitica e vai alla pagina 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 nuovo microservizio Products
Possiamo continuare a suddividere i nostri 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 in 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 abbiamo fatto per il nostro 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
Usa l'editor nano per sostituire l'URL locale con l'indirizzo IP dei nostri 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 Product, 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, premi ENTER e quindi CTRL+X per salvare il file nell'editor nano.
Puoi testare il nuovo microservizio navigando nell'URL che hai appena impostato in questo file. La pagina web dovrebbe restituire una risposta in formato JSON dal microservizio Products.
A questo punto, dovremo ricreare il frontend del monolite e ripetere il processo di compilazione per creare il container per il monolite ed eseguire nuovamente il deployment nel nostro cluster GKE. Esegui i comandi seguenti per completare questi passaggi:
Ricrea i file di configurazione del monolite
npm run build:monolith
Crea un container in 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
Per verificare che l'applicazione ora utilizzi il microservizio Products, accedi all'applicazione monolitica e vai alla pagina Products. Tutti i nomi di prodotto devono essere preceduti da MS, come illustrato di seguito:
8. Esegui la migrazione di 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
Per creare un nuovo microservizio frontend, seguiamo la stessa procedura utilizzata per i due ultimi passaggi.
In precedenza, quando abbiamo ricreato il monolite aggiornavamo la configurazione in modo che puntasse al monolite, ma ora dobbiamo usare la stessa configurazione per il microservizio Frontend. Esegui questi comandi 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 in 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 questi 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 monolite non dovrebbe funzionare e il nuovo indirizzo IP del servizio frontend dovrebbe ospitare la nuova applicazione. Per visualizzare un elenco di tutti i servizi e gli indirizzi IP, utilizza il seguente 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 ripulire tutte le attività eseguite è eliminare il progetto. L'eliminazione del progetto elimina tutte le risorse create in questo codelab per garantire che non si verifichino addebiti ricorrenti imprevisti. Esegui quanto segue in Cloud Shell, dove PROJECT_ID è l'ID completo del progetto 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
Scopri i seguenti codelab per saperne 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 in Kubernetes con 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