Questo è il terzo tutorial di un percorso di apprendimento che ti insegna come modularizzare e containerizzare un'app monolitica.
Il percorso di apprendimento è composto dai seguenti tutorial:
- Panoramica
- Comprendere il monolite
- Modularizzare il monolite
- Preparare l'app modulare per la containerizzazione (questo tutorial)
- Containerizzare l'app modulare
- Eseguire il deployment dell'app in un cluster GKE
Nel tutorial precedente, Modularizzare il monolite, hai visto come suddividere l'app Cymbal Books in moduli Flask indipendenti. In questo tutorial, scoprirai una singola modifica da apportare all'app modulare per prepararla alla containerizzazione.
Costi
Puoi completare questo tutorial senza incorrere in addebiti. Tuttavia, se segui i passaggi del tutorial finale di questa serie, ti verranno addebitati costi sul tuo Google Cloud account. I costi iniziano quando abiliti GKE ed esegui il deployment dell'app Cymbal Books in un cluster GKE. Questi costi includono gli addebiti per cluster per GKE, come indicato nella pagina dei prezzi, e gli addebiti per l'esecuzione delle VM Compute Engine.
Per evitare addebiti non necessari, assicurati di disabilitare GKE o eliminare il progetto al termine di questo tutorial.
Prima di iniziare
Prima di iniziare questo tutorial, assicurati di aver completato i tutorial precedenti della serie. Per una panoramica dell'intera serie e per i link a tutorial specifici, consulta Percorso di apprendimento: trasformare un monolite in un'app GKE - Panoramica.
Se hai già completato il primo tutorial, hai clonato un repository GitHub. Tutte e tre le versioni dell'app Cymbal Books si trovano in questo repository, all'interno delle seguenti cartelle:
monolith/modular/containerized/
Prima di continuare, verifica che queste cartelle siano presenti sulla tua macchina.
Modificare il codice modulare
Nel tutorial precedente, hai scoperto che il modulo della home page comunica con gli altri moduli. Invia richieste agli endpoint degli altri moduli per recuperare dettagli, recensioni e immagini dei libri, quindi presenta questi dati nelle pagine HTML.
Nella cartella modular/, gli endpoint sono hardcoded in home.py, utilizzando localhost, come in questo esempio:
BOOK_SERVICE_URL = "http://localhost:8081" # Book details module listens on port 8081
REVIEW_SERVICE_URL = "http://localhost:8082" # Book reviews module listens on port 8082
IMAGE_SERVICE_URL = "http://localhost:8083" # Image module listens on port 8083
Questi URL funzionano quando tutti i moduli vengono eseguiti sulla stessa macchina. Tuttavia, in un ambiente Kubernetes, i moduli possono essere spostati su macchine diverse per gestire gli errori o bilanciare il carico, il che significa che i loro indirizzi IP potrebbero cambiare.
Per assicurarti che il modulo della home page possa ancora raggiungere gli altri moduli, gli URL devono utilizzare i nomi dei servizi Kubernetes anziché localhost. Un nome di servizio funge da alias che Kubernetes utilizza per instradare le richieste al modulo corretto, indipendentemente da dove viene eseguito. Ad esempio, quando il modulo della home page invia una richiesta a http://book-details-service/book/1, Kubernetes contribuisce a garantire che la richiesta raggiunga il modulo dei dettagli del libro.
Non devi aggiornare questi URL. La versione dell'app nella cartella containerized/ include già questa modifica: gli URL localhost hardcoded sono stati sostituiti con i nomi dei servizi Kubernetes. Puoi visualizzare la versione aggiornata in containerized/home_app/home_app.py:
BOOK_SERVICE_URL = "http://book-details-service"
REVIEW_SERVICE_URL = "http://book-reviews-service"
IMAGE_SERVICE_URL = "http://images-service"
Questo aggiornamento contribuisce a garantire che l'app funzioni correttamente quando viene eseguita in un ambiente Kubernetes.
Il manifest di Kubernetes
Nella sezione precedente, hai visto come gli endpoint dei moduli sono stati aggiornati per utilizzare i nomi dei servizi Kubernetes. Definisci i nomi dei servizi nel manifest di Kubernetes.
Il manifest di Kubernetes è un file di configurazione che definisce il tipo di cluster Kubernetes che vuoi creare per ospitare la tua app modulare. Il manifest è scritto in YAML o JSON. In questo file, definisci elementi come i servizi (per il routing tra i moduli), il numero di repliche (istanze) di ogni modulo e la quantità di CPU e memoria che ogni modulo può utilizzare.
Si potrebbe scrivere un'intera serie di tutorial su
manifest di Kubernetes.
Il manifest è complesso perché definisce tutto ciò che riguarda il cluster Kubernetes: la sua struttura, il suo comportamento e le sue funzionalità. In questo tutorial, esaminerai solo come i nomi dei servizi nel manifest corrispondono ai nomi utilizzati negli endpoint dei moduli. In un tutorial successivo, eseguirai il comando kubectl apply per creare il cluster GKE in base alla configurazione definita nel manifest, ma in questo tutorial esaminerai solo il manifest.
Visualizzare il manifest
In questa sezione, esaminerai come vengono definiti i servizi in un manifest di Kubernetes scritto per te. Il file manifest, che è un file YAML, si trova nella cartella
the containerized/ del repository GitHub che hai clonato nel primo
tutorial di questa serie. Segui questi passaggi per visualizzare una definizione di servizio:
Nel terminale, vai alla directory containerized nel repository clonato:
cd containerizedIn un editor di testo, apri il file manifest di Kubernetes:
cat kubernetes_manifest.yamlTrova la definizione del servizio per il modulo
book-details. Dovrebbe essere simile all'esempio seguente:apiVersion: v1 kind: Service metadata: name: book-details-service spec: selector: app: book-details-app ports: - protocol: TCP port: 80 # External traffic on port 80 targetPort: 8080 # Targeting container port 8080 type: ClusterIP
Il nome del servizio book-details-service nel manifest corrisponde al nome utilizzato nell'endpoint del modulo: http://book-details-service. Quando l'app viene eseguita in Kubernetes, Kubernetes utilizza questi nomi di servizio per instradare le richieste ai moduli corretti.
Il manifest di Kubernetes definisce le funzionalità del cluster Kubernetes, inclusi i servizi che gestiscono il routing delle richieste. Ogni modulo dell'app ha un servizio corrispondente definito nel manifest. Aggiornando gli URL nel codice modulare in modo che corrispondano a questi nomi di servizio, ti assicuri che Kubernetes possa instradare le richieste ai moduli corretti quando l'app viene eseguita in un cluster.
Riepilogo
In questo tutorial, hai visto come gli URL nel codice modulare sono stati aggiornati per utilizzare i nomi dei servizi Kubernetes, come http://book-details-service. Questi nomi di servizio consentono a Kubernetes di instradare le richieste tra i moduli anche quando le loro posizioni nel cluster cambiano. Hai anche esaminato il manifest di Kubernetes e hai visto come i nomi dei servizi nel codice modulare corrispondono ai nomi definiti nel manifest.
Passaggi successivi
Nel tutorial successivo, Containerizzare l'app modulare, imparerai a containerizzare un modulo inserendolo in un elemento chiamato immagine container. Poi vedrai come eseguire un'immagine container come container, testarne le funzionalità ed eseguirne il push in Artifact Registry di Google.