Esegui il deployment di cluster Google Distributed Cloud Virtual for Bare Metal a livello perimetrale

Questo tutorial introduce una soluzione pronta all'uso che utilizza GKE su Bare Metal e Gestione della configurazione per eseguire il deployment di cluster Kubernetes a livello perimetrale su larga scala. Questo tutorial è rivolto a operatori e sviluppatori della piattaforma. Dovresti avere familiarità con le tecnologie e i concetti seguenti:

playbook Ansible.
Deployment a livello perimetrale e relative sfide.
Come lavorare con un progetto Google Cloud.
Deployment di un'applicazione web containerizzata.
Le interfacce a riga di comando gcloud e kubectl.

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 perimetrale. GKE su Bare Metal e Config Management offrono gestione e controllo centralizzati per il tuo cluster perimetrale. Config Management estrae in modo dinamico nuove configurazioni da GitHub e applica questi criteri e configurazioni ai tuoi cluster.

Architettura di deployment perimetrale

Un deployment a livello perimetrale del retail è un buon modo per illustrare l'architettura utilizzata in un tipico deployment GKE su Bare Metal.

Un negozio fisico di vendita al dettaglio è il punto di interazione più vicino tra una unità aziendale aziendale e il consumatore. I sistemi software all'interno dei negozi devono eseguire i carichi di lavoro, ricevere aggiornamenti tempestivi e segnalare metriche critiche in isolamento dal sistema di gestione centrale dell'azienda. Inoltre, questi sistemi software devono essere progettati in modo da poter essere ampliati in più sedi di negozi in futuro. Sebbene GKE su Bare Metal soddisfi tutti questi requisiti per i sistemi software del negozio, il profilo perimetrale consente un caso d'uso importante: deployment in ambienti con risorse hardware limitate, come la facciata di un negozio al dettaglio.

Il seguente diagramma mostra un deployment GKE su Bare Metal che utilizza il profilo perimetrale in un negozio 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, fotocamere e stampanti. Lo store ha anche tre dispositivi hardware di elaborazione fisici (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 connessi tra loro tramite una rete di livello 2. I dispositivi di calcolo connessi in rete costituiscono l'infrastruttura bare metal. GKE su Bare Metal è in esecuzione all'interno di ciascuno dei tre dispositivi di elaborazione. Questi dispositivi dispongono anche di un proprio spazio di archiviazione su disco e sono configurati per la replica dei dati tra loro per garantire l'alta disponibilità.

Il diagramma mostra anche i seguenti componenti chiave che fanno parte di un deployment di GKE su Bare Metal:

Il componente contrassegnato come MetalLB è il bilanciatore del carico in bundle di cui è stato eseguito il deployment con GKE su Bare Metal.
Il componente Config Management consente di sincronizzare lo stato del cluster con i repository di origine. È un componente aggiuntivo facoltativo consigliato che richiede un'installazione e una configurazione separate. Per saperne di più su come configurare Config Management e la diversa nomenclatura, consulta la documentazione di Config Management.
Il repository radice e il repository dello spazio dei nomi mostrati nella parte superiore del diagramma all'esterno della posizione dell'archivio rappresentano due repository di codice sorgente.

Il push delle modifiche al cluster viene eseguito in questi repository di origine centrali. I deployment di GKE su Bare Metal in varie località perimetrali eseguono il pull degli aggiornamenti dai repository di origine. Questo comportamento è rappresentato dalle frecce che collegano i due repository nel diagramma ai componenti di Config Management all'interno del cluster Google Distributed Cloud Virtual for Bare Metal in esecuzione nei dispositivi.
Un altro componente chiave raffigurato nel cluster è il runtime VM su Google Distributed Cloud. Il runtime VM su Google Distributed Cloud consente di eseguire carichi di lavoro basati su VM esistenti all'interno del cluster senza la necessità di containerizzazione. La documentazione sul runtime VM su Google Distributed Cloud spiega come abilitarlo ed eseguire il deployment dei carichi di lavoro delle VM nel cluster.
Il componente contrassegnato come Applicazione indica il software implementato nel cluster dal negozio al dettaglio. L'applicazione point of sale nei kiosk di un negozio al dettaglio potrebbe essere un esempio di tale applicazione.

Le caselle nella parte inferiore del diagramma rappresentano i numerosi dispositivi (ad esempio kiosk, tablet o videocamere) all'interno di un negozio al dettaglio, tutti collegati a uno switch di rete centrale. Il networking locale all'interno del negozio consente alle applicazioni in esecuzione all'interno del deployment di GKE su Bare Metal di raggiungere questi dispositivi.

Nella sezione successiva vedrai l'emulazione di questo deployment del negozio al dettaglio in Google Cloud utilizzando le VM di Compute Engine. Questa emulazione è quella che userai nel tutorial che segue per sperimentare GKE su Bare Metal.

Deployment perimetrale emulato in Google Cloud

Il seguente diagramma illustra tutto ciò che hai configurato in Google Cloud in questo tutorial. Questo diagramma è correlato al diagramma del negozio 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 dell'applicazione point of sale di esempio che utilizzerai in questo tutorial. Puoi accedere all'applicazione point of sale all'interno del cluster utilizzando un browser web come kiosk.

L'immagine mostra l'architettura dell'applicazione point of sale e come ne viene eseguito il deployment all'interno di un cluster Google Distributed Cloud Virtual for Bare Metal in esecuzione sulle VM di Compute Engine — Un'applicazione di esempio di cui è stato eseguito il deployment all'interno di un cluster Google Distributed Cloud Virtual for Bare Metal

Le tre macchine virtuali (VM) Compute Engine nel diagramma precedente rappresentano l'hardware fisico (o i nodi) in una tipica località perimetrale. Questo hardware viene collegato insieme a switch di rete per comporre 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 GKE su Bare Metal puoi configurare i tuoi bilanciatori del carico. Tuttavia, per questo tutorial non configurerai un bilanciatore del carico esterno. Utilizza invece il bilanciatore del carico MetalLB in bundle installato con GKE su 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 sulla rete VPC (Virtual Private Cloud) predefinita.

Nel rettangolo "L2 overlay network (VxLAN)" vengono mostrati i componenti software in esecuzione all'interno delle tre VM di Compute Engine. Questo rettangolo include il cluster Google Distributed Cloud Virtual for Bare Metal e un proxy inverso. Il cluster è rappresentato dal rettangolo "GKE on Bare Metal". Questo rettangolo che rappresenta il cluster include un altro rettangolo contrassegnato come "Spazio dei nomi Kubernetes (pos)". che rappresenta uno spazio dei nomi Kubernetes all'interno del cluster. Tutti i componenti 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: server API, inventario e pagamenti. Tutti questi componenti insieme rappresentano una singola "applicazione" mostrata nel precedente diagramma dell'architettura dell'implementazione Edge.

Il bilanciatore del carico MetalLB in bundle del cluster Anthos non può essere raggiunto direttamente dall'esterno delle VM. Il diagramma mostra un proxy inverso NGINX configurato per l'esecuzione all'interno delle VM al fine di instradare il traffico in entrata dalle VM di Compute Engine al bilanciatore del carico. Questa è solo una soluzione alternativa per gli scopi di questo tutorial, in cui i nodi perimetrali vengono emulati utilizzando le VM di Google Cloud Compute Engine. In una località sul perimetro reale, questo può essere fatto con una configurazione di rete adeguata.

Obiettivi

Utilizza le VM di Compute Engine per emulare un'infrastruttura bare metal eseguita in una località perimetrale.
Crea un cluster Google Distributed Cloud Virtual for Bare Metal nell'infrastruttura perimetrale emulata.
Connetti e registra il cluster con Google Cloud.
Esegui il deployment di un carico di lavoro di un'applicazione point-of-sale di esempio sul cluster Anthos.
Utilizza la console Google Cloud per verificare e monitorare l'applicazione point-of-sale che opera a livello perimetrale.
Utilizza Config Management per aggiornare l'applicazione point of sale in esecuzione sul cluster Anthos.

Prima di iniziare

Nella pagina del selettore progetti della console Google Cloud, seleziona o crea un progetto Google Cloud.

Nota: se non prevedi di conservare le risorse che crei in questa procedura, crea un progetto anziché selezionarne uno esistente. Dopo aver completato questi passaggi, puoi eliminare il progetto, rimuovendo tutte le risorse associate.

Vai alla selezione del progetto
Verifica che la fatturazione sia attivata per il tuo progetto Cloud. Scopri come verificare se la fatturazione è abilitata su un progetto.
Installa e initialize Google Cloud CLI.

Crea un fork e clona il repository anthos-samples

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 ciò che ci si aspetta da 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 Config Management. Questa operazione è necessaria per consentire ai componenti di gestione della configurazione nel cluster di eseguire l'autenticazione con il tuo account GitHub quando tenti di sincronizzare nuove modifiche.
1. Seleziona solo l'ambito public_repo.
2. Salva il token di accesso che hai creato in un luogo sicuro per utilizzarlo in un secondo momento.
Crea un fork del repository anthos-samples nel tuo account GitHub:
1. Vai al repository anthos-samples.
2. Fai clic sull'icona Forchetta nell'angolo in alto a destra della pagina.
3. Fai clic sull'account utente GitHub in cui vuoi creare un fork del repository. Verrai reindirizzato automaticamente alla pagina con la tua versione di fork del repository anthos-samples.
Apri un terminale nel tuo ambiente locale.
Clona il repository creato mediante fork eseguendo il comando seguente, dove GITHUB_USERNAME è il nome utente del tuo account GitHub:
```
git clone https://github.com/GITHUB_USERNAME/anthos-samples
cd anthos-samples/anthos-bm-edge-deployment
```
Nota: sia il repository di codice sorgente per questa soluzione sia il fork del repository sono repository pubblici. Questo documento mostra l'uso di un token di accesso per imitare un caso d'uso effettivo con un repository privato.

Configura l'ambiente workstation

Per completare il deployment perimetrale descritto in questo documento, devi avere una workstation con accesso a internet e i seguenti strumenti installati:

Docker
Strumento di interfaccia a riga di comando envsubst (di solito 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 della 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: l'ID del tuo progetto Google Cloud.
GITHUB_USERNAME: il tuo nome utente GitHub.
ACCESS_TOKEN: il token di accesso personale che hai creato per il tuo repository GitHub.

Mantieni i valori predefiniti per le altre variabili di ambiente. Queste vengono spiegate 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 di chiave JSON per il nuovo account di servizio all'indirizzo <REPO_ROOT>/anthos-bm-edge-deployment/build-artifacts/consumer-edge-gsa.json. Consente inoltre di configurare il keyring e la chiave Cloud Key Management Service per la crittografia della chiave privata SSH.

./scripts/create-primary-gsa.sh

Una parte dello script è visibile sotto. Fai clic sul link View on GitHub per visualizzare l'intero script.

anthos-bm-edge-deployment/scripts/create-primary-gsa.sh

Visualizza su GitHub

# ...
EXISTS=$(gcloud iam service-accounts list \
  --filter="email=${GSA_EMAIL}" \
  --format="value(name, disabled)" \
  --project="${PROJECT_ID}")

if [[ -z "${EXISTS}" ]]; then
  echo "GSA [${GSA_EMAIL}]does not exist, creating it"

  # GSA does NOT exist, create
  gcloud iam service-accounts create ${GSA_NAME} \
    --description="GSA used on each Target machine to make gcloud commands" \
    --display-name="target-machine-gsa" \
    --project "${PROJECT_ID}"
else
  if [[ "${EXISTS}" =~ .*"disabled".* ]]; then
    # Found GSA is disabled, enable
    gcloud iam service-accounts enable "${GSA_EMAIL}" --project "${PROJECT_ID}"
  fi
  # otherwise, no need to do anything
fi
# ...

Esegui il provisioning delle istanze di Compute Engine

In questa sezione creerai le VM di Compute Engine in cui verrà installato GKE su Bare Metal. Devi inoltre verificare la connettività a queste VM prima di passare alla sezione di installazione.

Sulla workstation, crea chiavi SSH da utilizzare per la comunicazione tra le istanze di Compute Engine.
```
ssh-keygen -f ./build-artifacts/consumer-edge-machine
```

Criptare la chiave privata SSH con 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.encrypted

Genera il file di configurazione dell'ambiente .envrc e recuperalo. Dopo averlo creato, esamina il file .envrc per assicurarti che le variabili di ambiente siano state sostituite con i valori corretti.

envsubst < templates/envrc-template.sh > .envrc
source .envrc

Di seguito è riportato un esempio di file .envrc generato sostituendo le variabili di ambiente nel file templates/envrc-template.sh. Nota che le righe che sono state aggiornate sono evidenziate:

anthos-bm-edge-deployment/templates/envrc.example

Visualizza su GitHub

# GSA Key used for provisioning (result of running ./scripts/create-primary-gsa.sh)
LOCAL_GSA_FILE=$(pwd)/build-artifacts/consumer-edge-gsa.json
export LOCAL_GSA_FILE
# GCP Project ID
export PROJECT_ID="abm-edge-project"
# Bucket to store cluster snapshot information
export SNAPSHOT_GCS="abm-edge-project-cluster-snapshots"

# GCP Project Region (Adjust as desired)
export REGION="us-central1"
# GCP Project Zone (Adjust as desired)
export ZONE="us-central1-a"

# Gitlab Personal Access Token credentials (generated in Quick Start step 2)
export SCM_TOKEN_USER="LarryPage"
export SCM_TOKEN_TOKEN="oo901Sp-FHuzmz__dgl0393atkf69c8L"

# Default Root Repo setup for multiple locations
export ROOT_REPO_URL="https://github.com/LarryPage/anthos-samples"
export ROOT_REPO_BRANCH="main"
export ROOT_REPO_DIR="/anthos-bm-edge-deployment/acm-config-sink"

# OIDC Configuration (off by default)
export OIDC_CLIENT_ID="" # Optional, requires GCP API setup work
export OIDC_CLIENT_SECRET="" # Optional
export OIDC_USER="" # Optional
export OIDC_ENABLED="false" # Flip to true IF implementing OIDC on cluster

Crea istanze di Compute Engine in cui è installato GKE su Bare Metal.

./scripts/cloud/create-cloud-gce-baseline.sh -c "$GCE_COUNT" | \
    tee ./build-artifacts/gce-info

Installa GKE su Bare Metal con Ansible

Lo script utilizzato in questa guida crea cluster Google Distributed Cloud Virtual for Bare Metal in gruppi di tre istanze Compute Engine. Il numero di cluster creati è controllato dalla variabile di ambiente GCE_COUNT. Ad esempio, imposti la variabile di ambiente GCE_COUNT su 6 per creare due cluster Google Distributed Cloud Virtual for Bare Metal con 3 istanze VM ciascuno. Per impostazione predefinita, la variabile di ambiente GCE_COUNT è impostata su 3. Pertanto, in questa guida verrà creato un cluster con 3 istanze di Compute Engine. Il nome delle istanze VM include 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 anche assegnato lo stesso nome della VM della workstation di amministrazione (ad esempio cnuc-1, cnuc-4, cnuc-7).

Ecco i risultati della guida pratica di Ansible:

Configura le istanze di Compute Engine con gli strumenti necessari, ad esempio docker, bmctl, gcloud e nomos.
Installa GKE su Bare Metal nelle istanze di Compute Engine configurate.
Crea un cluster autonomo Google Distributed Cloud Virtual for Bare Metal chiamato cnuc-1.
Registra il cluster cnuc-1 con Google Cloud.
Installa Config Management nel cluster cnuc-1.
Configura Config Management per la sincronizzazione con le configurazioni dei cluster che si trovano in anthos-bm-edge-deployment/acm-config-sink nel repository creato con fork.
Genera il valore Login token per 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 include tutti gli strumenti necessari per il processo di installazione, ad esempio Ansible, Python e Google Cloud CLI.

gcloud builds submit --config docker-build/cloudbuild.yaml docker-build/

Una volta eseguita correttamente, la build produce un output simile al 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)  SUCCESS

Genera il file dell'inventario Ansible da un modello.

envsubst < templates/inventory-cloud-example.yaml > inventory/gcp.yaml

Esegui 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 del volume nella directory di lavoro attuale. Una volta completato correttamente questo script, devi trovarti all'interno del container Docker che è stato creato. Puoi attivare l'installazione di Ansible dall'interno di questo container.

./install.sh

Una volta eseguito correttamente, lo script produce un output simile al 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)

Dall'interno del container Docker, verifica l'accesso alle istanze di Compute Engine.

./scripts/health-check.sh

Una volta eseguito correttamente, lo script produce un output simile al 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"}

Dall'interno del container Docker, esegui il playbook di Ansible per l'installazione di GKE su istanze Bare Metal su Compute Engine. Al termine, vedrai Login Token per il cluster stampato sullo schermo.

ansible-playbook all-full-install.yaml -i inventory | tee ./build-artifacts/ansible-run.log

Quando l'installazione viene eseguita correttamente, produce un output simile al 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 GKE su Bare Metal nella console Google Cloud

Una volta completato il playbook Ansible, nelle VM di Compute Engine viene installato un cluster Google Distributed Cloud Virtual for Bare Metal autonomo. Questo cluster è anche registrato 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 GKE, completa i seguenti passaggi.

Copia il token dall'output del playbook Ansible nella sezione precedente.

Nota: se non hai più accesso all'output della console, controlla il file di log all'indirizzo ./build-artifacts/ansible-run.log per ottenere il token. Puoi anche eseguire il seguente playbook Ansible per recuperare di nuovo il token: ansible-playbook all-get-login-tokens.yaml -i inventory
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
1. Nell'elenco dei cluster, fai clic su Azioni accanto al cluster cnuc-1, quindi fai clic su Accedi.
2. Seleziona Token e incolla il token copiato.
3. Fai clic su Accedi.

Nella console Google Cloud, vai alla pagina Gestione configurazione per controllare lo stato delle specifiche di configurazione. Verifica che lo stato sia Sincronizzato. Lo stato Synched indica che Config Management ha sincronizzato correttamente le configurazioni di GitHub con il cluster di cui hai eseguito il deployment, cnuc-1.

Vai alla pagina Config Management

Configurazione di un proxy per il traffico esterno

Il cluster Google Distributed Cloud Virtual for Bare Metal installato nei passaggi precedenti utilizza un bilanciatore del carico in bundle chiamato MetalLB. Questo servizio di bilanciamento del carico è accessibile solo tramite un indirizzo IP VPC (Virtual Private Cloud). Per instradare il traffico in entrata attraverso il suo IP esterno al bilanciatore del carico in bundle, configura un servizio proxy inverso nell'host amministratore (cnuc-1). Questo servizio proxy inverso ti consente di raggiungere il server API dell'applicazione point of sale attraverso l'IP esterno dell'host amministratore (cnuc-1).

Gli script di installazione indicati nei passaggi precedenti installavano NGINX negli host di amministrazione 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-1
```
Dall'interno della workstation di amministrazione, configura il proxy inverso NGINX per instradare il traffico al servizio di bilanciamento del carico del server API. Ottieni l'indirizzo IP del servizio Kubernetes di tipo 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 venga applicata la nuova configurazione:
```
sudo systemctl restart nginx
```

Controlla e verifica lo stato del server NGINX per segnalare "attivo (in esecuzione)":

sudo systemctl status nginx

Quando NGINX viene eseguito 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:
```
exit
```
Esci dalla sessione shell nel container Docker. All'uscita dall'istanza di amministrazione, ti trovi 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 GKE. Per accedere all'applicazione point of sale di esempio, completa i seguenti passaggi.

Sulla workstation, recupera l'indirizzo IP esterno dell'istanza 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, producono un output simile al seguente:

Point the browser to: 34.134.194.84:8082

Apri il browser web e vai all'indirizzo IP mostrato nell'output del comando precedente. Puoi accedere all'applicazione point of sale di esempio e testarla, come mostrato nello screenshot di esempio:

Utilizzare 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 radice. Config Management rileva gli aggiornamenti e apporta automaticamente le modifiche al cluster. In questo esempio, il repository radice è il repository anthos-samples che hai clonato all'inizio di questa guida. Per scoprire in che modo l'applicazione point of sale di esempio può eseguire il deployment di un upgrade a una versione più recente, completa i passaggi seguenti.

Sulla workstation, aggiorna il campo image per cambiare la versione del server API da v1 a v2. La configurazione YAML per il deployment si trova nel file all'indirizzo anthos-bm-edge-deployment/acm-config-sink/namespaces/pos/api-server.yaml.

anthos-bm-edge-deployment/acm-config-sink/namespaces/pos/api-server.yaml

Visualizza su GitHub
```
containers:
- name: api-server
  image: us-docker.pkg.dev/anthos-dpe-abm-edge-pos/abm-edge-pos-images/api-server:v1
```

Aggiungi le modifiche, esegui il commit e il push 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 push

Nella console Google Cloud, vai alla pagina Gestione configurazione per controllare lo stato delle specifiche di configurazione. Verifica che lo stato sia Sincronizzato.

Vai alla pagina Config Management

Nella console Google Cloud, vai alla pagina Carichi di lavoro Kubernetes Engine per verificare che il deployment sia aggiornato.

Vai alla pagina Carichi di lavoro Kubernetes Engine

Quando lo stato del deployment è OK, punta il browser sull'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 nello screenshot di esempio che segue:

Per vedere le modifiche, potrebbe essere necessario eseguire un aggiornamento forzato della scheda del browser.

Esegui la pulizia

Per evitare addebiti Google Cloud inutili, elimina le risorse utilizzate per questa guida al termine dell'operazione. Puoi eliminare queste risorse manualmente o eliminare il progetto Google Cloud. In questo modo vengono eliminate anche tutte le risorse. Inoltre, potresti anche voler eseguire la pulizia delle modifiche apportate nella workstation locale:

Workstation locale

I seguenti file devono essere aggiornati per cancellare 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 per cnuc-* dal file ~/.ssh/config.
Rimuovi le fingerprint 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.

Attenzione: l'eliminazione di un progetto ha i seguenti effetti:

L'intero contenuto del progetto viene eliminato. Se hai utilizzato un progetto esistente per le attività in questo documento, quando lo elimini elimini anche qualsiasi altro lavoro svolto nel progetto.
Gli ID progetto personalizzati non sono più disponibili. Quando hai creato questo progetto, potresti aver creato un ID progetto personalizzato che vuoi utilizzare in futuro. Per conservare gli URL che utilizzano l'ID progetto, ad esempio un URL appspot.com, elimina le risorse selezionate all'interno del progetto anziché eliminare l'intero progetto.

Se intendi esplorare più architetture, tutorial o guide rapide, puoi riutilizzare i progetti ed evitare così di superare i limiti di quota.

Nella console Google Cloud, vai alla pagina Gestisci risorse.

Vai a Gestisci risorse

Nell'elenco dei progetti, seleziona il progetto che vuoi eliminare, quindi fai clic su Elimina.

Nella finestra di dialogo, digita l'ID del progetto e fai clic su Chiudi per eliminare il progetto.

Manuale

Se hai utilizzato un progetto esistente per questa procedura:

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-ingress e allow-pod-egress.
Elimina il secret di Secret Manager install-pub-key.

Che cosa succede dopo?

Puoi espandere questa guida aggiungendo un'altra posizione perimetrale. Se imposti la variabile di ambiente GCE_COUNT su 6 e riesegui gli stessi passaggi delle sezioni precedenti, vengono create tre nuove istanze di Compute Engine (cnuc-4, cnuc-5, cnuc-6) e un nuovo cluster Google Distributed Cloud Virtual for Bare Metal autonomo chiamato cnuc-4.

Puoi anche provare ad aggiornare le configurazioni dei cluster nel repository creato con fork per applicare selettivamente versioni diverse dell'applicazione point of sale ai due cluster, cnuc-1 e cnuc-4, utilizzando ClusterSelectors.

Per i dettagli sui singoli passaggi di questa guida e sugli script interessati, consulta il repository anthos-samples.