Checkpoint
Create a GKE Cluster
/ 20
Deploy Existing Monolith
/ 20
Migrate Orders to a microservice
/ 20
Migrate Products to microservice
/ 20
Migrate Frontend to microservice
/ 20
Migrazione di un sito web monolitico ai microservizi su Google Kubernetes Engine
- GSP699
- Panoramica
- Configurazione e requisiti
- Attività 1: clona il repository del codice sorgente
- Attività 2: crea un cluster GKE
- Attività 3: esegui il deployment del monolite esistente
- Attività 4: esegui la migrazione di Orders a un microservizio
- Attività 5: esegui la migrazione di Products a un microservizio
- Attività 6: esegui la migrazione del frontend a un microservizio
- Complimenti!
GSP699
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).
- È ora di completare il lab: ricorda che, una volta iniziato, non puoi metterlo in pausa.
Come avviare il lab e accedere alla console Google Cloud
-
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:
- Il pulsante Apri console Google Cloud
- Tempo rimanente
- Credenziali temporanee da utilizzare per il lab
- Altre informazioni per seguire questo lab, se necessario
-
Fai clic su Apri console Google Cloud (o fai clic con il tasto destro del mouse e seleziona Apri link in finestra di navigazione in incognito se utilizzi il browser Chrome).
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.
Nota: se visualizzi la finestra di dialogo Scegli un account, fai clic su Usa un altro account. -
Se necessario, copia il Nome utente di seguito e incollalo nella finestra di dialogo di accesso.
{{{user_0.username | "Username"}}} Puoi trovare il Nome utente anche nel riquadro Dettagli lab.
-
Fai clic su Avanti.
-
Copia la Password di seguito e incollala nella finestra di dialogo di benvenuto.
{{{user_0.password | "Password"}}} Puoi trovare la Password anche nel riquadro Dettagli lab.
-
Fai clic su Avanti.
Importante: devi utilizzare le credenziali fornite dal lab. Non utilizzare le credenziali del tuo account Google Cloud. Nota: utilizzare il tuo account Google Cloud per questo lab potrebbe comportare addebiti aggiuntivi. -
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.
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.
- Fai clic su 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:
gcloud
è lo strumento a riga di comando di Google Cloud. È preinstallato su Cloud Shell e supporta il completamento tramite tasto Tab.
- (Facoltativo) Puoi visualizzare il nome dell'account attivo con questo comando:
-
Fai clic su Autorizza.
-
L'output dovrebbe avere ora il seguente aspetto:
Output:
- (Facoltativo) Puoi elencare l'ID progetto con questo comando:
Output:
Output di esempio:
gcloud
, in Google Cloud, fai riferimento alla Panoramica dell'interfaccia a riga di comando gcloud.
Imposta la zona e la configurazione del progetto predefinite:
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:
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.
- Esegui il comando seguente per abilitare l'API Containers e utilizzare Google Kubernetes Engine:
- Esegui il comando seguente per creare un cluster GKE denominato fancy-cluster con 3 nodi:
La creazione del cluster potrebbe richiedere diversi minuti.
- Quando il comando è completato, esegui il codice seguente per vedere le tre istanze di VM worker del cluster:
Output:
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.
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:
Accedi al monolite
- Esegui il comando seguente per trovare l'indirizzo IP esterno dell'applicazione monolitica:
Dovresti vedere un output simile al seguente:
-
Se nell'output l'indirizzo IP esterno figura come
<pending>
, attendi qualche istante ed esegui di nuovo il comando. -
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 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.
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.
- Esegui i seguenti comandi per creare il container Docker ed eseguirne il push al Container Registry di Google:
Il processo richiede qualche minuto, ma al termine verrà restituito nel terminale un output simile al seguente:
- 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:
Verifica il deployment
- Per verificare se il deployment è stato creato correttamente, esegui questo comando:
Possono essere necessari alcuni minuti perché lo stato del pod diventi In esecuzione.
Output:
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:
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:
Output:
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.
- Utilizza l'editor
nano
per sostituire l'URL locale con l'indirizzo IP del microservizio Orders:
All'apertura dell'editor, il file dovrebbe avere l'aspetto seguente:
- 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:
-
Premi
Ctrl+O
,Invio
e quindiCtrl+X
per salvare il file nell'editor nano. -
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.
-
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:
- Crea il container in Docker con Cloud Build:
- Esegui il deployment del container in GKE:
- 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:
- 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.
- Crea il container in Docker con Cloud Build:
- Esegui il deployment del container in GKE:
- Esponi il container GKE:
- Trova l'IP pubblico del servizio Products come avevi fatto per il servizio Orders:
Output:
Utilizzerai l'indirizzo IP nel passaggio successivo quando riconfigurerai 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 nuovi microservizi Products:
All'apertura dell'editor, il file dovrebbe avere l'aspetto seguente:
- 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:
-
Premi
Ctrl+O
,Invio
e quindiCtrl+X
per salvare il file. -
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.
-
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:
-
Ricrea i file di configurazione del monolite:
- Crea il container in Docker con Cloud Build:
- Esegui il deployment del container in GKE:
- 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:
- 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.
- Esegui i comandi seguenti per copiare i file di configurazione dell'URL dei microservizi nel codebase del microservizio frontend:
-
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.
-
Crea un container Docker con Google Cloud Build:
- Esegui il deployment del container in GKE:
- Esponi il container GKE
- 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:
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:
Dovresti vedere un output simile al seguente:
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:
- Hosting di un'app web su Google Cloud mediante Compute Engine
- Guarda questo video dal titolo Hosting a Static Web App on Google Cloud
Passaggi successivi/Ulteriori risorse
- [Docker documentation]https://docs.docker.com/
- Documentazione relativa a Kubernetes
- Documentazione relativa a Google Kubernetes Engine (GKE)
- Documentazione relativa a Google Cloud Build
- Documentazione relativa a Google Container Registry
- Migrazione di monoliti in microservizi
- Best practice per i microservizi
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.