Anthos clusters on bare metal è ora Google Distributed Cloud (solo software) per bare metal. Per ulteriori informazioni, consulta la panoramica del prodotto.

Questa pagina è stata tradotta dall'API Cloud Translation.

Esegui il deployment di cluster Google Distributed Cloud a livello perimetrale

Questo tutorial introduce una soluzione pronta all'uso che utilizza Google Distributed Cloud e Config Sync per eseguire il deployment di cluster Kubernetes a livello perimetrale. Questo tutorial è rivolto operatori di piattaforma e sviluppatori. Dovresti avere familiarità con le seguenti tecnologie e concetti:

Guida pratica Ansible.
Deployment a livello perimetrale e le relative sfide.
Come lavorare con un progetto Google Cloud.
Deployment di un'applicazione web containerizzata.
Interfacce a riga di comando gcloud e kubectl.

In questo tutorial utilizzerai le macchine virtuali (VM) Compute Engine per emulare nodi di cui è stato eseguito il deployment a livello perimetrale e un'applicazione point of sale di esempio come carico di lavoro. Google Distributed Cloud e Config Sync forniscono gestione e controllo centralizzati per il tuo cluster perimetrale. Config Sync estrae dinamicamente le nuove configurazioni da GitHub e applica di questi criteri e configurazioni ai tuoi cluster.

Architettura di deployment a livello perimetrale

Un deployment a livello retail è un buon modo per illustrare l'architettura utilizzata in un tipico deployment Google Distributed Cloud.

Un negozio fisico è il punto di interazione più vicino tra l'enterprise e il consumatore. I sistemi software all'interno dei negozi devono i carichi di lavoro, ricevere aggiornamenti tempestivi e generare report sulle metriche critiche dall'isolamento dal sistema di gestione centrale dell'azienda. Inoltre, questi i sistemi software devono essere progettati in modo da poter essere ampliati in modo da località in futuro. Sebbene Google Distributed Cloud soddisfi tutti questi requisiti, per i sistemi software dei negozi, profilo edge consente un caso d'uso importante: deployment in ambienti con risorse hardware limitate come la vetrina di un negozio.

Il seguente diagramma mostra un deployment Google Distributed Cloud che utilizza il in un negozio di vendita al dettaglio:

Deployment di Google Distributed Cloud che utilizza il profilo perimetrale in un negozio di vendita al dettaglio

Il diagramma precedente mostra un tipico negozio fisico. Il negozio ha smart dispositivi come lettori di carte, macchine point of sale, fotocamere e stampanti. Lo store ha anche tre dispositivi hardware di elaborazione fisica (etichettati Node 1, Node 2 e Node 3). Tutti questi dispositivi sono collegati a uno switch di rete centrale. Pertanto, i tre sono connessi tra loro tramite una rete di livello 2. La I dispositivi di elaborazione dati in rete costituiscono l'infrastruttura bare metal. Google Distributed Cloud è in esecuzione all'interno di ognuno dei tre dispositivi di elaborazione. Questi I dispositivi dispongono inoltre 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 Google Distributed Cloud:

Il componente contrassegnato come MetalLB è il bilanciatore del carico in bundle di cui viene eseguito il deployment con Google Distributed Cloud.
Il componente Config Sync consente di sincronizzare lo stato del cluster rispetto ai repository di origine. Si tratta di un modello facoltativo che richiede installazione e configurazione separate. Per ulteriori informazioni informazioni su come configurare Config Sync e le diverse della nomenclatura, vedi documentazione di Config Sync.
Il repository root e il repository dello spazio dei nomi mostrati nella parte superiore della esterno alla posizione del negozio rappresentano due repository di origine.

Le modifiche al cluster vengono inviate tramite push a questi repository di origine centrali. I deployment Google Distributed Cloud in varie località perimetrali scaricano gli aggiornamenti dal repository di codice sorgente. Questo comportamento è rappresentato dalle frecce che collegano tra i due repository nel diagramma a Config Sync all'interno del cluster Google Distributed Cloud in esecuzione dispositivi mobili.
Un altro componente chiave raffigurato come parte del cluster è Runtime VM su GDC. Il runtime VM su GDC consente l'esecuzione di applicazioni Carichi di lavoro basati su VM all'interno del cluster senza la necessità di containerizzazione. La Documentazione sul runtime VM su GDC 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 in dal punto vendita. L'applicazione point of sale visualizzata nei kiosk un negozio di vendita al dettaglio potrebbe essere un esempio di questa applicazione.

Le caselle nella parte inferiore del diagramma rappresentano i vari dispositivi (come chioschi, tablet o fotocamere) all'interno di un negozio, tutti collegati a un switch di rete centrale. Il networking locale all'interno dello store consente applicazioni in esecuzione all'interno del deployment Google Distributed Cloud per raggiungere dispositivi mobili.

Nella sezione successiva, vedrai l'emulazione del deployment di questo negozio su Google Cloud usando le VM di Compute Engine. L'emulazione viene utilizzata nel tutorial che segue per sperimentare con Google Distributed Cloud.

Deployment perimetrale emulato in Google Cloud

Il seguente diagramma è una rappresentazione di tutto ciò che hai configurato Google Cloud in questo tutorial. Questo diagramma è correlato al punto vendita diagramma della sezione precedente. Questo deployment rappresenta un perimetro emulato località in cui è stato eseguito il deployment dell'applicazione point of sale. L'architettura mostra anche un semplice carico di lavoro dell'applicazione di esempio point of sale questo tutorial. Puoi accedere all'applicazione point of sale all'interno del cluster usando un browser web come kiosk.

Architettura dell'applicazione point of sale e modalità di deployment all'interno di un cluster Google Distributed Cloud in esecuzione sulle VM di Compute Engine

Le tre macchine virtuali (VM) Compute Engine nel diagramma precedente rappresentano l'hardware (o i nodi) fisico in una tipica località perimetrale. Questo l'hardware verrebbe collegato insieme a switch di rete per compensare lo spazio la tua infrastruttura metallica. Nel nostro ambiente emulato in Google Cloud, queste VM sono connesse tra loro tramite Virtual Private Cloud (VPC) nel progetto Google Cloud.

In una tipica installazione di Google Distributed Cloud puoi configurare i tuoi bilanciatori del carico. Tuttavia, per questo tutorial non devi configurare un carico esterno con il bilanciatore del carico di rete passthrough esterno regionale. Utilizza invece il bilanciatore del carico MetalLB in bundle installato con Google Distributed Cloud. Il bilanciatore del carico MetalLB in bundle richiede il livello 2 e la connettività di rete tra i nodi. Di conseguenza, la connettività di livello 2 Per abilitare le VM di Compute Engine, devi creare VxLAN rete overlay sopra la rete Virtual Private Cloud (VPC) predefinita.

All'interno del rettangolo con l'etichetta "Rete overlay L2 (VxLAN)", il software in esecuzione all'interno delle tre VM di Compute Engine. Questo rettangolo include il cluster Google Distributed Cloud e una Inverti proxy. Il cluster è rappresentato dal cluster "Google Distributed Cloud" rettangolo. Questo rettangolo che rappresenta l'ammasso 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 l'applicazione point of sale di cui è stato eseguito il deployment nel cluster Google Distributed Cloud. Il punto di vendita ha tre microservizi: Server API, Inventario e Pagamenti. Tutti questi componenti rappresentano una singola "application" mostrata nella precedente Diagramma dell'architettura di implementazione perimetrale.

Il bilanciatore del carico MetalLB in bundle del cluster Google Distributed Cloud non possono essere raggiunte direttamente dall'esterno delle VM. Il diagramma mostra una proxy inverso NGINX configurato per essere eseguito all'interno delle VM per instradare il traffico in entrata di Compute Engine al bilanciatore del carico. Questa è solo una soluzione alternativa per agli scopi di questo tutorial in cui i nodi perimetrali vengono emulati utilizzando Google Cloud di Compute Engine. In una posizione perimetrale reale, questo può essere fatto con la configurazione di rete.

Obiettivi

Utilizza le VM di Compute Engine per emulare un'infrastruttura bare metal eseguita in una località perimetrale.
Crea un cluster Google Distributed Cloud 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 Google Distributed Cloud.
Utilizzare la console Google Cloud per verificare e monitorare l'applicazione point of sale che opera sulla località perimetrale.
Utilizza Config Sync per aggiornare l'applicazione point-of-sale in esecuzione sul cluster Google Distributed Cloud.

Prima di iniziare

Nella pagina del selettore progetti della console Google Cloud, seleziona oppure creare un progetto Google Cloud.

Nota: se non prevedi di conservare le risorse create in questo crea un progetto invece di selezionarne uno esistente. Dopo il giorno puoi completare questi passaggi, puoi eliminare il progetto, rimuovendo tutte le risorse associati al progetto.

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

Crea un fork e clona il repository anthos-samples

Tutti gli script utilizzati in questo tutorial sono archiviati in anthos-samples repository Git. La struttura delle cartelle in /anthos-bm-edge-deployment/acm-config-sink è organizzato in base a ciò che previsto da Config Sync. Clona questo repository nel tuo account GitHub prima di continuare con le i seguenti passaggi.

Se non ne hai già uno, crea un account su GitHub.
Creare un token di accesso personale da utilizzare nella configurazione di Config Sync. Questa informazione è obbligatoria per Componenti di Config Sync nel cluster per l'autenticazione all'account GitHub quando provi a 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 anhos-samples.
2. Fai clic sull'icona Fork nell'angolo in alto a destra della pagina.
3. Fai clic sull'account utente GitHub in cui vuoi creare un fork del repository. Tu vengono reindirizzati automaticamente alla pagina con la versione creata con fork Repository anthos-samples.
Apri un terminale nel tuo ambiente locale.
Clona il repository creato con fork eseguendo il comando seguente, dove GITHUB_USERNAME è il nome utente per il tuo 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 tuo fork di quella sono repository pubblici. Questo documento illustra l'utilizzo di un accesso per imitare un caso d'uso effettivo con un repository privato.

Configura l'ambiente di workstation

Per completare il deployment a livello perimetrale descritto in questo documento, è necessario workstation con accesso a internet e i seguenti strumenti installati:

Docker
Strumento dell'interfaccia a riga di comando envsubst (di solito preinstallati 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: 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. Sono illustrato nelle sezioni che seguono.

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 di Compute Engine. Questo script crea il file chiave JSON per nuovo account di servizio in <REPO_ROOT>/anthos-bm-edge-deployment/build-artifacts/consumer-edge-gsa.json. Configura inoltre Cloud Key Management Service il keyring e la chiave per la crittografia della chiave privata SSH.

./scripts/create-primary-gsa.sh

Il seguente esempio è solo una parte dello script. Per vedere l'intera fai clic su 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 Google Distributed Cloud verrà installata. Verificherai anche la connettività a queste VM prima di procedere alla sezione relativa all'installazione.

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

Cripta 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 ed eseguine l'origine. Dopo il giorno creato, esamina il file .envrc per assicurarti che le variabili di ambiente abbiano siano stati sostituiti dai valori corretti.

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

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

# 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 Google Distributed Cloud.

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

Installa Google Distributed Cloud con Ansible

Lo script utilizzato in questa guida crea cluster Google Distributed Cloud 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 in 6 per crearne due Cluster Google Distributed Cloud con 3 istanze VM ciascuno. Per impostazione predefinita la variabile di ambiente GCE_COUNT è impostata su 3. In questa guida, verrà creato un cluster con 3 di istanze Compute Engine. La VM le istanze sono denominate con il prefisso cnuc- seguito da un numero. La prima VM di ogni cluster funge da workstation di amministrazione l'installazione. Al cluster viene anche assegnato lo stesso nome dell'amministratore VM workstation (ad esempio cnuc-1, cnuc-4, cnuc-7).

Il playbook Ansible fa quanto segue:

Configura le istanze di Compute Engine con gli strumenti necessari, come come docker, bmctl, gcloud e nomos.
Installa Google Distributed Cloud nelle istanze di Compute Engine configurate.
Crea un cluster autonomo Google Distributed Cloud denominato cnuc-1.
Registra il cluster cnuc-1 con Google Cloud.
Installa Config Sync nel cluster cnuc-1.
Configura Config Sync per la sincronizzazione con il cluster configurazioni situate in anthos-bm-edge-deployment/acm-config-sink nel repository creato con fork.
Genera 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. Questo l'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/

Una volta eseguita correttamente, la build 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)  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 creato in precedenza. Lo script utilizza internamente Docker per generare il container con un montaggio del volume nella directory di lavoro attuale. Con successo di questo script devi trovarti all'interno del container Docker è stato creato. Attiva l'installazione di Ansible dall'interno di questo contenitore.

./install.sh

Una volta eseguito correttamente, lo script 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)

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

./scripts/health-check.sh

Una volta eseguito correttamente, lo script 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"}

Dal container Docker, esegui il playbook Ansible per l'installazione Google Distributed Cloud on istanze di Compute Engine. Al termine, vedrai l'Login Token del cluster stampato sullo schermo.

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

Una volta eseguita correttamente l'installazione, viene generato 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 Google Distributed Cloud nella console Google Cloud

Una volta eseguito il playbook Ansible fino al completamento, Il cluster Google Distributed Cloud è installato all'interno di Compute Engine delle VM in esecuzione. Questo cluster viene registrato anche in Google Cloud utilizzando Agente Connect. Tuttavia, per visualizzare i dettagli di questo cluster, devi registrare al cluster dalla console Google Cloud. Per accedere al Completa i seguenti passaggi per il cluster GKE.

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

Nota: se non hai più accesso all'output della console, controlla il log su ./build-artifacts/ansible-run.log per ottenere il token. Puoi inoltre Esegui 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 dei 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 Login (Accedi).
Nella console Google Cloud, vai alla pagina Configurazione nella sezione Funzionalità.

Vai a Configurazione

Nella scheda Pacchetti, controlla la colonna Stato sincronizzazione nella tabella dei cluster. Verifica che lo stato sia Synced (Sincronizzato). Lo stato Synced (Sincronizzato) indica che Sincronizzazione di configurazione abbia sincronizzato correttamente le tue configurazioni GitHub con cnuc-1.

Configura un proxy per il traffico esterno

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

Gli script di installazione nei passaggi precedenti hanno installato NGINX negli host dell'amministratore insieme a un file di configurazione di esempio. Aggiorna questo file in utilizza 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 il routing il traffico al servizio del bilanciatore del carico dell'API Server Load. Ottieni l'indirizzo IP del carico servizio Kubernetes di tipo di bilanciatore:
```
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 segnalarlo come "attivo (in esecuzione)":

sudo systemctl status nginx

Quando NGINX viene eseguito correttamente, produce un output come l'esempio seguente:

● 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 alla workstation di amministrazione:
```
exit
```
Esci dalla sessione di shell al container Docker. All'uscita dalla pagina 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, ottieni l'indirizzo IP esterno dell'amministratore Compute Engine 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}"

Una volta eseguiti correttamente, gli script producono output come il seguente:

Point the browser to: 34.134.194.84:8082

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

Utilizza Config Sync per aggiornare il server API

È possibile eseguire l'upgrade dell'applicazione di esempio a una versione più recente aggiornando il di configurazione nel repository principale. Config Sync rileva gli aggiornamenti e apporta automaticamente le modifiche al cluster. In questo esempio il repository radice è il repository anthos-samples che hai clonato nel all'inizio di questa guida. Per vedere come può andare l'applicazione point of sale di esempio un deployment a una versione più recente, completa i seguenti passaggi.

Sulla workstation, aggiorna il campo image per cambiare il server API versione da v1 a v2. La configurazione YAML per il deployment file all'indirizzo anthos-bm-edge-deployment/acm-config-sink/namespaces/pos/api-server.yaml.
```
containers:
- name: api-server
  image: us-docker.pkg.dev/anthos-dpe-abm-edge-pos/abm-edge-pos-images/api-server:v1
```

Aggiungi, esegui il commit delle modifiche ed esegui il push delle modifiche al 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 Config Sync per verificare lo stato delle specifiche di configurazione. Verifica che lo stato sia Synced (Sincronizzato).

Vai alla pagina Config Sync
Nella console Google Cloud, vai a Carichi di lavoro di Kubernetes Engine per verificare che il Deployment sia aggiornato.

Vai alla pagina dei carichi di lavoro di Kubernetes Engine
Quando lo stato del deployment è OK, punta il browser alla Indirizzo IP della sezione precedente per visualizzare l'applicazione point of sale. Tieni presente che la versione nel titolo è "V2", a indicare che di modifica dell'applicazione, come mostrato nell'esempio seguente screenshot:

Potrebbe essere necessario aggiornare manualmente la scheda del browser per vedere le modifiche.

Esegui la pulizia

Per evitare addebiti inutili per Google Cloud, elimina le risorse utilizzate di questa guida quando hai finito. Puoi eliminarli manualmente le risorse o eliminare il tuo progetto Google Cloud, di tutte le risorse. Potresti anche voler eliminare le modifiche apportate nella workstation locale:

Workstation locale

I seguenti file devono essere aggiornati per cancellare le modifiche apportate dal script di installazione.

Rimuovi gli indirizzi IP delle VM di Compute Engine aggiunti al file /etc/hosts.
Rimuovi la configurazione SSH per cnuc-* nel file ~/.ssh/config.
Rimuovi le fingerprint delle 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, segui questi passaggi:

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.

Passaggi successivi

Puoi espandere questa guida aggiungendo un'altra posizione sul perimetro. L'impostazione del parametro GCE_COUNT variabile di ambiente 6 ed eseguendo nuovamente gli stessi passaggi da precedenti crea tre nuove istanze (cnuc-4, cnuc-5, cnuc-6) e un nuovo Google Distributed Cloud cluster autonomo denominato cnuc-4.

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

Per maggiori dettagli sui singoli passaggi della guida, sugli script coinvolti, consulta anthos-samples repository Git.