Questo tutorial introduce una soluzione pronta all'uso che utilizza Anthos clusters on bare metal e Anthos Config Management per eseguire il deployment dei cluster Kubernetes su larga scala. Questo tutorial è rivolto agli operatori e agli sviluppatori di piattaforme. Avere familiarità con i seguenti concetti e tecnologie:
- playbook ansible.
- Deployment a livello perimetrale e relative sfide.
- Come lavorare con un progetto Google Cloud.
- Deployment di un'applicazione web containerizzata.
- Interfacce a riga di comando
gcloudekubectl.
In questo tutorial utilizzerai le macchine virtuali (VM) di Compute Engine per emulare i nodi di cui è stato eseguito il deployment a livello perimetrale e un'applicazione point of sale di esempio come carico di lavoro periferico. Anthos clusters on bare metal e Anthos Config Management forniscono gestione e controllo centralizzati per il tuo cluster perimetrale. Anthos Config Management estrae nuove configurazioni da GitHub e applica questi criteri e configurazioni ai tuoi cluster.
Architettura di deployment perimetrale
Un deployment Edge per la vendita al dettaglio è un buon modo per illustrare l'architettura utilizzata in un tipico deployment Anthos clusters on bare metal.
Un negozio fisico è il punto di interazione più vicino tra un'azienda e il consumatore. I sistemi software all'interno dei negozi devono eseguire i carichi di lavoro, ricevere aggiornamenti tempestivi e segnalare le metriche critiche isolate dal sistema di gestione centrale dell'azienda. Inoltre, questi sistemi software devono essere progettati in modo da poter essere estesi a più località dei negozi in futuro. Sebbene Anthos clusters on bare metal soddisfi tutti questi requisiti per i sistemi software per i negozi, il profilo perimetrale consente un caso d'uso importante: i deployment in ambienti con risorse hardware limitate come la vetrina di un negozio di vendita al dettaglio.
Il seguente diagramma mostra un deployment Anthos clusters on bare metal che utilizza il profilo perimetrale in un negozio di vendita al dettaglio:
Il diagramma precedente mostra un tipico negozio fisico di vendita al dettaglio. Il negozio dispone di smart device come lettori di schede, macchine POS, macchine fotografiche e stampanti.
Il negozio ha anche tre dispositivi hardware per il calcolo fisico (etichettati Node 1, Node 2 e Node 3).
Tutti questi dispositivi sono collegati a uno switch di rete centrale. Pertanto, i tre dispositivi di calcolo sono collegati tra loro tramite una rete di livello 2. I dispositivi di calcolo in rete insieme costituiscono l'infrastruttura bare metal.
Anthos clusters on bare metal sono in esecuzione all'interno di ciascuno dei tre dispositivi di computing. Questi dispositivi hanno anche un proprio spazio di archiviazione su disco e sono configurati per la replica dei dati tra loro per un'alta disponibilità.
Il diagramma mostra anche i seguenti componenti chiave che fanno parte di un deployment di Anthos clusters on bare metal:
- Il componente contrassegnato come MetalLB è il bilanciatore del carico in bundle di cui viene eseguito il deployment con Anthos clusters on bare metal.
- Il componente Anthos Config Management consente di sincronizzare lo stato del cluster con i repository di origine. È un componente aggiuntivo facoltativo altamente consigliato, che richiede un'installazione e una configurazione separate. Per saperne di più su come configurare Anthos Config Management e le diverse definizioni, consulta la documentazione di Anthos Config Management.
Il repository root e il repository spazio dei nomi mostrati nella parte superiore del diagramma all'esterno della posizione del negozio rappresentano due repository di origine.
il push delle modifiche al cluster viene eseguito in questi repository di codice sorgente centrale. I cluster Anthos su deployment Bare Metal in varie località periferiche estraggono aggiornamenti dai repository di origine. Questo comportamento è rappresentato dalle frecce che collegano i due repository nel diagramma ai componenti di Anthos Config Management all'interno del cluster Anthos on bare metal in esecuzione nei dispositivi.
Un altro componente chiave descritto come parte del cluster è l'Anthos VM Runtime. Anthos VM Runtime consente di eseguire carichi di lavoro basati su VM esistenti all'interno del cluster senza necessità di containerizzazione. La documentazione di Anthos VM Runtime spiega come abilitarlo ed eseguire il deployment dei carichi di lavoro delle VM nel cluster.
Il componente contrassegnato come Applicazione indica il software di cui è stato eseguito il deployment nel cluster dall'archivio retail. Un'applicazione del point of sale visibile nei kiosk di un negozio può essere un esempio di questa applicazione.
Le caselle nella parte inferiore del diagramma rappresentano i vari dispositivi (ad esempio kiosk, tablet o videocamere) all'interno di un negozio di vendita al dettaglio, tutti collegati a uno switch di rete centrale. Il networking locale all'interno dello store consente alle applicazioni in esecuzione all'interno dei deployment Anthos clusters on bare metal di raggiungere questi dispositivi.
Nella sezione successiva vedrai l'emulazione di questo deployment di vendita al dettaglio in Google Cloud utilizzando le VM di Compute Engine. Questa emulazione è quella che utilizzi nel tutorial che segue per sperimentare con Anthos clusters on bare metal.
Deployment perimetrale emulato in Google Cloud
Il seguente diagramma illustra una rappresentazione di tutto ciò che hai configurato in Google Cloud in questo tutorial. Questo diagramma è correlato al diagramma del negozio di vendita al dettaglio della sezione precedente. Questo deployment rappresenta una località perimetrale emulata in cui viene eseguito il deployment dell'applicazione point of sale. L'architettura mostra anche un semplice carico di lavoro di esempio di applicazione point of sale che utilizzi in questo tutorial. Si accede all'applicazione point of sale all'interno del cluster utilizzando un browser web come kiosk.
Le tre macchine virtuali (VM) di Compute Engine nel diagramma precedente rappresentano l'hardware fisico (o nodi) in una posizione perimetrale tipica. Questo hardware verrà collegato insieme agli switch di rete per creare l'infrastruttura Bare Metal. Nel nostro ambiente emulato in Google Cloud, queste VM sono connesse tra loro tramite la rete predefinita Virtual Private Cloud (VPC) nel progetto Google Cloud.
In una tipica installazione di Anthos clusters on bare metal, puoi configurare i tuoi bilanciatori del carico. Tuttavia, per questo tutorial non devi configurare un bilanciatore del carico esterno. Utilizza invece il bilanciatore del carico MetalLB in bundle installato con Anthos clusters on bare metal. Il bilanciatore del carico MetalLB in bundle richiede la connettività di rete di livello 2 tra i nodi. Pertanto, la connettività di livello 2 tra le VM di Compute Engine viene abilitata creando una rete overlay VxLAN che si aggiunge alla rete Virtual Private Cloud (VPC) predefinita.
Nel rettangolo con etichetta "L2 overlay network (VxLAN)", vengono mostrati i componenti del software in esecuzione all'interno delle tre VM di Compute Engine. Questo rettangolo include il cluster Anthos on bare metal e un proxy inverso. Il cluster è rappresentato dal rettangolo rettangolare "Anthos clusters on bare metal". Questo rettangolo che rappresenta il cluster include un altro rettangolo contrassegnato come "spazio dei nomi Kubernetes (pos)". Rappresenta uno spazio dei nomi Kubernetes all'interno del cluster. Tutti i componenti all'interno di questo spazio dei nomi Kubernetes costituiscono l'applicazione point of sale di cui viene eseguito il deployment nel cluster Anthos. L'applicazione point of sale ha tre microservizi: API Server, Inventory e Payments. Tutti questi componenti insieme rappresentano una "applicazione" mostrata nel precedente diagramma dell'architettura di implementazione di Edge.
Non è possibile raggiungere direttamente il bilanciatore del carico MetalLB in bundle del cluster Anthos dall'esterno delle VM. Il diagramma mostra un proxy inverso NGINX in configurazione per l'esecuzione all'interno delle VM per instradare il traffico in entrata nelle VM di Compute Engine al bilanciatore del carico. Questa è solo una soluzione alternativa per gli scopi di questo tutorial in cui i nodi periferici vengono emulati utilizzando le VM di Google Cloud Compute Engine. In una posizione perimetrale reale, ciò può essere fatto con una configurazione di rete adeguata.
Obiettivi
- Utilizza le VM di Compute Engine per emulare un'infrastruttura bare metal in esecuzione in una località perimetrale.
- Crea un cluster Anthos on bare metal nell'infrastruttura perimetrale emulata.
- Connetti e registra il cluster con Google Cloud.
- Eseguire il deployment di un carico di lavoro di esempio di applicazione point of sale sul cluster Anthos.
- Utilizza la console Google Cloud per verificare e monitorare l'applicazione point of sale che opera sulla località perimetrale.
- Utilizza Anthos Config Management per aggiornare l'applicazione point of sale in esecuzione sul cluster Anthos.
Prima di iniziare
Nella pagina del selettore dei progetti nella console Google Cloud, seleziona o crea un progetto Google Cloud.
Verifica che la fatturazione sia attivata per il tuo progetto Cloud. Scopri come controllare se la fatturazione è abilitata per un progetto.
Installa e inizializza Google Cloud CLI.
Crea un fork e clona il repository degli esempi di anthos
Tutti gli script utilizzati in questo tutorial sono archiviati nel repository anthos-samples. La struttura delle cartelle in
/anthos-bm-edge-deployment/acm-config-sink
è organizzata in base a quanto previsto da Anthos Config Management.
Clona questo repository nel tuo account GitHub prima di continuare con i passaggi seguenti.
Se non ne hai già uno, crea un account su GitHub.
Crea un token di accesso personale da utilizzare nella configurazione di Anthos Config Management. Questo è necessario per consentire ai componenti Anthos Config Management nel cluster di eseguire l'autenticazione con il tuo account GitHub quando si cerca di sincronizzare le nuove modifiche.
- Seleziona solo l'ambito
public_repo. - Salva il token di accesso che hai creato in un luogo sicuro per utilizzarlo in un secondo momento.
- Seleziona solo l'ambito
Crea un fork del repository
anthos-samplesnel tuo account GitHub:- Vai al repository anthos-samples.
- Fai clic sull'icona Fork nell'angolo in alto a destra della pagina.
- Fai clic sull'account utente GitHub in cui vuoi creare un fork del repository. Ti reindirizzeremo automaticamente alla pagina con la versione creata mediante fork del repository anthos-samples.
Apri un terminale nel tuo ambiente locale.
Per clonare il repository creato mediante fork, esegui il comando riportato di seguito, dove GITHUB_USERNAME è il nome utente per il tuo account GitHub:
git clone https://github.com/GITHUB_USERNAME/anthos-samples cd anthos-samples/anthos-bm-edge-deployment
Configura l'ambiente della workstation
Per completare il deployment perimetrale descritto in questo documento, è necessaria una workstation con accesso a Internet e i seguenti strumenti installati:
- Docker
- Strumento a interfaccia a riga di comando envsubst (in genere preinstallato su Linux e altri sistemi operativi simili a Unix)
Esegui tutti i comandi del tutorial sulla workstation che configuri in questa sezione.
Sulla workstation, inizializza le variabili di ambiente in una nuova istanza shell:
export PROJECT_ID="PROJECT_ID" export REGION="us-central1" export ZONE="us-central1-a" # port on the admin Compute Engine instance you use to set up an nginx proxy # this allows to reach the workloads inside the cluster via the VM IP export PROXY_PORT="8082" # should be a multiple of 3 since N/3 clusters are created with each having 3 nodes export GCE_COUNT="3" # url to the fork of: https://github.com/GoogleCloudPlatform/anthos-samples export ROOT_REPO_URL="https://github.com/GITHUB_USERNAME/anthos-samples" # this is the username used to authenticate to your fork of this repository export SCM_TOKEN_USER="GITHUB_USERNAME" # access token created in the earlier step export SCM_TOKEN_TOKEN="ACCESS_TOKEN"Sostituisci i seguenti valori:
- PROJECT_ID: il tuo ID progetto Google Cloud.
- GITHUB_USERNAME: il tuo nome utente GitHub.
- ACCESS_TOKEN: il token di accesso personale che hai creato per il repository GitHub.
Mantieni i valori predefiniti per le altre variabili di ambiente. Sono illustrate nelle sezioni seguenti.
Sulla workstation, inizializza Google Cloud CLI:
gcloud config set project "${PROJECT_ID}" gcloud services enable compute.googleapis.com gcloud config set compute/region "${REGION}" gcloud config set compute/zone "${ZONE}"Sulla workstation, crea l'account di servizio Google Cloud per le istanze di Compute Engine. Questo script crea il file della chiave JSON per il nuovo account di servizio in
<REPO_ROOT>/anthos-bm-edge-deployment/build-artifacts/consumer-edge-gsa.json. Configura inoltre il keyring e la chiave del servizio di gestione delle chiavi Cloud per la crittografia delle chiavi private SSH../scripts/create-primary-gsa.shUna parte dello script è visibile di seguito. Fai clic sul link
View on GitHubper visualizzare l'intero script.
Esegui il provisioning delle istanze di Compute Engine
In questa sezione creerai le VM di Compute Engine in cui verranno installati i Anthos clusters on bare metal. Inoltre, devi verificare la connettività a queste VM prima di passare alla sezione di installazione.
Sulla workstation, crea chiavi SSH utilizzate per la comunicazione tra le istanze di Compute Engine.
ssh-keygen -f ./build-artifacts/consumer-edge-machineCripta la chiave privata SSH utilizzando Cloud Key Management Service.
gcloud kms encrypt \ --key gdc-ssh-key \ --keyring gdc-ce-keyring \ --location global \ --plaintext-file build-artifacts/consumer-edge-machine \ --ciphertext-file build-artifacts/consumer-edge-machine.encryptedGenera il file di configurazione dell'ambiente
.envrce impostalo come origine. Dopo aver creato il file.envrc, controlla che le variabili di ambiente siano state sostituite con i valori corretti.envsubst < templates/envrc-template.sh > .envrc source .envrcDi seguito è riportato un esempio di un file
.envrcgenerato sostituendo le variabili di ambiente nel filetemplates/envrc-template.sh. Tieni presente che le righe aggiornate sono evidenziate:Crea istanze di Compute Engine in cui è installato Anthos clusters on bare metal.
./scripts/cloud/create-cloud-gce-baseline.sh -c "$GCE_COUNT" | \ tee ./build-artifacts/gce-info
Installa Anthos clusters on bare metal con Ansible
Lo script utilizzato in questa guida crea cluster Anthos on bare metal in gruppi di tre istanze di Compute Engine. Il numero di cluster creati è controllato dalla variabile di ambiente GCE_COUNT. Ad esempio, hai impostato la variabile di ambiente GCE_COUNT su 6 per creare due cluster Anthos on bare metal con 3 istanze VM ciascuna. Per impostazione predefinita, la variabile di ambiente GCE_COUNT è impostata su 3. Pertanto, in questa guida, verrà creato un cluster con istanze 3 di Compute Engine. Le istanze VM vengono denominate con un prefisso cnuc- seguito da un numero. La prima istanza VM di ogni cluster funge da workstation di amministrazione da cui viene attivata l'installazione. Al cluster viene inoltre assegnato lo stesso nome della VM della workstation di amministrazione (ad esempio cnuc-1, cnuc-4, cnuc-7).
Il playbook Ansible:
- Configura le istanze di Compute Engine con gli strumenti necessari, come
docker,bmctl,gcloudenomos. - Installa Anthos clusters on bare metal nelle istanze Compute Engine configurate.
- Crea un cluster autonomo Anthos on bare metal denominato
cnuc-1. - Registra il cluster
cnuc-1con Google Cloud. - Installa Anthos Config Management nel cluster
cnuc-1. - Configura Anthos Config Management per la sincronizzazione con le configurazioni del cluster che si trovano in
anthos-bm-edge-deployment/acm-config-sinknel repository creato con fork. - Genera
Login tokenper il cluster.
Completa i seguenti passaggi per configurare e avviare la procedura di installazione:
Sulla workstation, crea l'immagine Docker utilizzata per l'installazione. Questa immagine contiene tutti gli strumenti necessari per il processo di installazione, come Ansible, Python e Google Cloud CLI.
gcloud builds submit --config docker-build/cloudbuild.yaml docker-build/Quando la build viene eseguita correttamente, produce un output come il seguente:
... latest: digest: sha256:99ded20d221a0b2bcd8edf3372c8b1f85d6c1737988b240dd28ea1291f8b151a size: 4498 DONE ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ID CREATE_TIME DURATION SOURCE IMAGES STATUS 2238baa2-1f41-440e-a157-c65900b7666b 2022-08-17T19:28:57+00:00 6M53S gs://my_project_cloudbuild/source/1660764535.808019-69238d8c870044f0b4b2bde77a16111d.tgz gcr.io/my_project/consumer-edge-install (+1 more) SUCCESSGenera il file di inventario Ansible dal modello.
envsubst < templates/inventory-cloud-example.yaml > inventory/gcp.yamlEsegui lo script di installazione che avvia un container Docker dall'immagine creata in precedenza. Lo script utilizza internamente Docker per generare il container con un montaggio di volume nella directory di lavoro attuale. Una volta completato correttamente lo script, devi trovarti all'interno del container Docker creato. Puoi attivare l'installazione di Ansible dall'interno di questo container.
./install.shQuando lo script viene eseguito correttamente, produce un output come il seguente:
... Check the values above and if correct, do you want to proceed? (y/N): y Starting the installation Pulling docker install image... ============================== Starting the docker container. You will need to run the following 2 commands (cut-copy-paste) ============================== 1: ./scripts/health-check.sh 2: ansible-playbook all-full-install.yaml -i inventory 3: Type 'exit' to exit the Docker shell after installation ============================== Thank you for using the quick helper script! (you are now inside the Docker shell)All'interno del container Docker, verifica l'accesso alle istanze di Compute Engine.
./scripts/health-check.shQuando lo script viene eseguito correttamente, produce un output come il seguente:
... cnuc-2 | SUCCESS => {"ansible_facts": {"discovered_interpreter_python": "/usr/bin/python3"},"changed": false,"ping": "pong"} cnuc-3 | SUCCESS => {"ansible_facts": {"discovered_interpreter_python": "/usr/bin/python3"},"changed": false,"ping": "pong"} cnuc-1 | SUCCESS => {"ansible_facts": {"discovered_interpreter_python": "/usr/bin/python3"},"changed": false,"ping": "pong"}All'interno del container Docker, esegui il playbook Ansible per installare i Anthos clusters on bare metal sulle istanze di Compute Engine. Al termine, visualizzerai
Login Tokenper il cluster stampato sullo schermo.ansible-playbook all-full-install.yaml -i inventory | tee ./build-artifacts/ansible-run.logQuando l'installazione viene eseguita correttamente, genera un output come il seguente:
... TASK [abm-login-token : Display login token] ************************************************************************** ok: [cnuc-1] => { "msg": "eyJhbGciOiJSUzI1NiIsImtpZCI6Imk2X3duZ3BzckQyWmszb09sZHFMN0FoWU9mV1kzOWNGZzMyb0x2WlMyalkifQ.eymljZS1hY2NvdW iZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6ImVkZ2Etc2EtdG9rZW4tc2R4MmQiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2Nvd 4CwanGlof6s-fbu8" } skipping: [cnuc-2] skipping: [cnuc-3] PLAY RECAP *********************************************************************************************************** cnuc-1 : ok=205 changed=156 unreachable=0 failed=0 skipped=48 rescued=0 ignored=12 cnuc-2 : ok=128 changed=99 unreachable=0 failed=0 skipped=108 rescued=0 ignored=2 cnuc-3 : ok=128 changed=99 unreachable=0 failed=0 skipped=108 rescued=0 ignored=2
Accedi al cluster Anthos clusters on bare metal nella console Google Cloud
Una volta eseguito il playbook Ansible, fino al completamento, un cluster Anthos on bare metal autonomo viene installato all'interno delle VM di Compute Engine. Questo cluster è registrato anche in Google Cloud tramite l'agente Connect. Tuttavia, per visualizzare i dettagli di questo cluster, devi accedere al cluster dalla console Google Cloud. Per accedere al cluster Anthos, completa i seguenti passaggi.
Copia il token dall'output del playbook Ansible nella sezione precedente.
Nella console Google Cloud, vai alla pagina Cluster Kubernetes e utilizza il token copiato per accedere al cluster
cnuc-1.Vai alla pagina Cluster Kubernetes
- Nell'elenco dei cluster, fai clic su Azioni accanto al cluster
cnuc-1, quindi fai clic su Accedi. - Seleziona Token e incolla il token copiato.
- Fai clic su Accedi.
- Nell'elenco dei cluster, fai clic su Azioni accanto al cluster
Nella console Google Cloud, vai alla pagina Config Management per controllare lo stato delle specifiche di configurazione. Verifica che lo stato sia Sincronizzato. Lo stato Sincronizzato indica che Anthos Config Management ha sincronizzato correttamente le configurazioni GitHub con il cluster di cui hai eseguito il deployment,
cnuc-1.Vai alla pagina Config Management
Configura un proxy per il traffico esterno
Il cluster Anthos on bare metal installato nei passaggi precedenti utilizza un bilanciatore del carico in bundle denominato MetalLB.
Questo servizio del bilanciatore del carico è accessibile solo tramite un indirizzo IP Virtual Private Cloud (VPC). Per indirizzare il traffico in entrata
tramite l'IP esterno al bilanciatore del carico in bundle, configura un servizio proxy inverso nell'host
amministratore (cnuc-1). Questo servizio proxy inverso consente di raggiungere l'API
Server dell'applicazione point of sale tramite l'IP esterno dell'host
amministratore (cnuc-1).
Gli script di installazione nei passaggi precedenti hanno installato NGINX negli host amministrativi insieme a un file di configurazione di esempio. Aggiorna questo file per utilizzare l'indirizzo IP del servizio bilanciatore del carico e riavvia NGINX.
Sulla workstation, utilizza SSH per accedere alla workstation di amministrazione:
ssh -F ./build-artifacts/ssh-config abm-admin@cnuc-1Dall'interno della workstation di amministrazione, configura il proxy inverso NGINX per instradare il traffico al servizio bilanciatore del carico API Server. Recupera l'indirizzo IP del servizio Kubernetes del tipo di bilanciatore del carico:
ABM_INTERNAL_IP=$(kubectl get services api-server-lb -n pos | awk '{print $4}' | tail -n 1)Aggiorna il file di configurazione del modello con l'indirizzo IP recuperato:
sudo sh -c "sed 's/<K8_LB_IP>/${ABM_INTERNAL_IP}/g' \ /etc/nginx/nginx.conf.template > /etc/nginx/nginx.conf"Riavvia NGINX per assicurarti che la nuova configurazione venga applicata:
sudo systemctl restart nginxControlla e verifica lo stato del server NGINX per segnalare "attivo (in esecuzione)":
sudo systemctl status nginxQuando NGINX è in esecuzione correttamente, produce un output come il seguente esempio:
● nginx.service - A high performance web server and a reverse proxy server Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled) Active: active (running) since Fri 2021-09-17 02:41:01 UTC; 2s ago Docs: man:nginx(8) Process: 92571 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=0/SUCCESS) Process: 92572 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; (code=exited, status=0/SUCCESS) Main PID: 92573 (nginx) Tasks: 17 (limit: 72331) Memory: 13.2M CGroup: /system.slice/nginx.service ├─92573 nginx: master process /usr/sbin/nginx -g daemon on; master_process on; ├─92574 nginx: worker process ├─92575 nginx: worker process ├─92577 nginx: .... ... ...Esci dalla sessione SSH nella workstation di amministrazione:
exitEsci dalla sessione della shell nel container Docker. Quando esci dall'istanza di amministrazione, sei ancora all'interno del container Docker utilizzato per l'installazione:
exit
Accedere all'applicazione point of sale
Con la configurazione del proxy esterno, puoi accedere all'applicazione in esecuzione all'interno del cluster Anthos. Per accedere all'applicazione POS di esempio, segui questi passaggi.
Sulla workstation, recupera l'indirizzo IP esterno dell'istanza di Compute Engine di amministrazione e accedi all'interfaccia utente dell'applicazione point of sale:
EXTERNAL_IP=$(gcloud compute instances list \ --project ${PROJECT_ID} \ --filter="name:cnuc-1" \ --format="get(networkInterfaces[0].accessConfigs[0].natIP)") echo "Point the browser to: ${EXTERNAL_IP}:${PROXY_PORT}"Quando gli script vengono eseguiti correttamente, generano un output simile al seguente:
Point the browser to: 34.134.194.84:8082Apri il browser web e vai all'indirizzo IP visualizzato nell'output del comando precedente. Puoi accedere e testare l'applicazione POS di esempio, come mostrato nel seguente screenshot di esempio:
Usa Anthos Config Management per aggiornare il server API
È possibile eseguire l'upgrade dell'applicazione di esempio a una versione più recente aggiornando i file di configurazione nel repository principale. Anthos Config Management rileva gli aggiornamenti e apporta automaticamente le modifiche al cluster. In questo esempio, il repository principale è il repository anthos-samples che hai clonato all'inizio di questa guida. Per sapere in che modo l'applicazione POS di esempio può passare da un deployment di upgrade a una versione più recente, completa i seguenti passaggi.
Sulla workstation, aggiorna il campo
imageper cambiare la versione API Server dav1av2. La configurazione YAML per il deployment è nel file all'indirizzoanthos-bm-edge-deployment/acm-config-sink/namespaces/pos/api-server.yaml.Aggiungi, esegui il commit e il push delle modifiche nel repository creato con fork:
git add acm-config-sink/namespaces/pos/api-server.yaml git commit -m "chore: updated api-server version to v2" git pushNella console Google Cloud, vai alla pagina Config Management per controllare lo stato delle specifiche di configurazione. Verifica che lo stato sia Sincronizzato.
Nella console Google Cloud, vai alla pagina Carichi di lavoro Kubernetes Engine per verificare che il deployment sia aggiornato.
Quando lo stato del deployment è OK, indirizza il browser all'indirizzo IP della sezione precedente per visualizzare l'applicazione point of sale. Tieni presente che la versione nel titolo mostra "V2", a indicare che è stato eseguito il deployment della modifica dell'applicazione, come mostrato nel seguente screenshot di esempio:
Per visualizzare le modifiche potrebbe essere necessario eseguire un aggiornamento forzato della scheda del browser.
Esegui la pulizia
Per evitare addebiti Google Cloud non necessari, elimina le risorse utilizzate per questa guida al termine delle operazioni. Puoi eliminare manualmente queste risorse oppure eliminare il tuo progetto Google Cloud, che si occuperà anche dell'eliminazione di tutte le risorse. Inoltre, potresti anche voler eliminare le modifiche apportate nella tua workstation locale:
Postazione di lavoro locale
I seguenti file devono essere aggiornati per includere le modifiche apportate dagli script di installazione.
- Rimuovi gli indirizzi IP delle VM di Compute Engine aggiunti al file
/etc/hosts. - Rimuovi la configurazione SSH di
cnuc-*nel file~/.ssh/config. - Rimuovi le impronte della VM di Compute Engine dal file
~/.ssh/known_hosts.
Elimina progetto
Se hai creato un progetto dedicato per questa procedura, elimina il progetto Google Cloud dalla console Google Cloud.
Manuale
Se hai utilizzato un progetto esistente per questa procedura, procedi nel seguente modo:
- Annulla la registrazione di tutti i cluster Kubernetes con un nome preceduto da
cnuc-. - Elimina tutte le VM di Compute Engine con un nome preceduto da
cnuc-. - Elimina il bucket Cloud Storage con un nome preceduto da
abm-edge-boot. - Elimina le regole firewall
allow-pod-ingresseallow-pod-egress. - Elimina il secret di Secret Manager
install-pub-key.
Quali sono i passaggi successivi?
Puoi espandere questa guida aggiungendo un'altra posizione perimetrale. Se imposti la variabile di ambiente GCE_COUNT su 6 ed esegui nuovamente gli stessi passaggi delle sezioni precedenti, vengono create tre nuove istanze di Compute Engine (cnuc-4, cnuc-5, cnuc-6) e un nuovo cluster autonomo Anthos on bare metal chiamato cnuc-4.
Puoi anche provare ad aggiornare le configurazioni del cluster nel tuo repository creato con fork per applicare selettivamente diverse versioni dell'applicazione point of sale ai due cluster, cnuc-1 e cnuc-4, utilizzando ClusterSelector.
Per i dettagli sui singoli passaggi in questa guida, gli script in questione, consulta il repository anthos-samples.