Esegui il deployment dei cluster sull'edge

La combinazione del software Distributed Cloud solo per bare metal con Config Sync ti consente di eseguire il deployment e gestire i cluster Kubernetes perimetrali su larga scala da una posizione centralizzata. Config Sync estrae dinamicamente le configurazioni da GitHub e applica automaticamente queste policy ai tuoi cluster. In questo tutorial, progettato per operatori e sviluppatori di piattaforme, utilizzerai le macchine virtuali (VM) di Compute Engine per emulare i nodi perimetrali che eseguono un workload di esempio per i punti vendita.

Prima di iniziare, assicurati di avere familiarità con i progetti Google Cloud , le CLI gcloud e kubectl, le sfide del deployment perimetrale, i playbook Ansible e il deployment di applicazioni web containerizzate.

Architettura di deployment perimetrale

Un deployment per il retail edge è un buon modo per illustrare l'architettura utilizzata in un tipico deployment di cluster bare metal.

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

Il seguente diagramma mostra il deployment di un cluster Bare Metal che utilizza il profilo perimetrale in un negozio di vendita al dettaglio:

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

Il diagramma precedente mostra un tipico negozio di vendita al dettaglio fisico. Il negozio dispone di smart device come lettori di carte, macchine per i punti vendita, videocamere e stampanti. Il negozio ha anche tre dispositivi hardware di physical computing (etichettati come Node 1, Node 2 e Node 3). Tutti questi dispositivi sono collegati a uno switch di rete centrale. Pertanto, i tre dispositivi di computing sono collegati tra loro tramite una rete di livello 2. I dispositivi di computing collegati in rete costituiscono l'infrastruttura bare metal. Il software Google Distributed Cloud è in esecuzione all'interno di ciascuno dei tre dispositivi di computing. Questi dispositivi hanno anche il proprio spazio di archiviazione su disco e sono configurati per la replica dei dati tra loro per garantire l'alta affidabilità.

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

  • Il componente contrassegnato come MetalLB è il bilanciatore del carico in bundle.

  • Il componente Config Sync consente di sincronizzare lo stato del cluster con i repository di origine. Si tratta di un componente aggiuntivo facoltativo altamente consigliato che richiede un'installazione e una configurazione separate. Per ulteriori informazioni su come configurare Config Sync e sulle diverse nomenclature, consulta la documentazione di Config Sync

  • Il repository root e il repository dello spazio dei nomi mostrati nella parte superiore del diagramma al di fuori della sede del negozio rappresentano due repository di codice sorgente.

    Le modifiche al cluster vengono inviate a questi repository di origine centrali. I deployment dei cluster in varie località perimetrali estraggono gli aggiornamenti dai repository di origine. Questo comportamento è rappresentato dalle frecce che collegano i due repository nel diagramma ai componenti di Config Sync all'interno del cluster in esecuzione nei dispositivi.

  • Un altro componente chiave raffigurato come parte del cluster è il runtime VM su GDC. VM Runtime on GDC consente di eseguire i workload esistenti basati su VM all'interno del cluster senza la necessità di containerizzazione. La documentazione del runtime VM su GDC spiega come abilitarlo ed eseguire il deployment dei workload delle VM nel cluster.

  • Il componente contrassegnato come Applicazione indica il software di cui il negozio di vendita al dettaglio ha eseguito il deployment nel cluster. L'applicazione point of sale visualizzata nei kiosk di un negozio di vendita al dettaglio potrebbe essere un esempio di questo tipo di applicazione.

Le caselle nella parte inferiore del diagramma rappresentano i numerosi dispositivi (come kiosk, tablet o videocamere) all'interno di un negozio di vendita al dettaglio, tutti collegati a uno switch di rete centrale. La rete locale all'interno del negozio consente alle applicazioni in esecuzione nel cluster di raggiungere questi dispositivi.

Nella sezione successiva, vedrai l'emulazione di questo deployment di un negozio di vendita al dettaglio inGoogle Cloud utilizzando le VM di Compute Engine. Questa emulazione è quella che utilizzerai nel tutorial seguente per sperimentare con un cluster bare metal.

Deployment perimetrale emulato in Google Cloud

Il seguente diagramma mostra tutto ciò che configuri inGoogle 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 workload di un'applicazione di esempio per i punti vendita che utilizzerai in questo tutorial. Puoi accedere all'applicazione per i punti vendita all'interno del cluster utilizzando un browser web come kiosk.

Architettura dell'applicazione per i punti vendita e modalità di deployment all'interno di un cluster in esecuzione su VM di Compute Engine

Le tre macchine virtuali (VM) di Compute Engine nel diagramma precedente rappresentano l'hardware fisico (o i nodi) in una tipica località perimetrale. Questo hardware verrebbe collegato con 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 Virtual Private Cloud (VPC) predefinita nel progetto Google Cloud .

In una tipica installazione di cluster 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 integrato. Il bilanciatore del carico MetalLB integrato richiede la connettività di rete di livello 2 tra i nodi. Pertanto, la connettività di livello 2 tra le VM di Compute Engine viene attivata creando una rete overlay VxLAN sulla rete Virtual Private Cloud (VPC) predefinita.

All'interno del rettangolo con l'etichetta "Rete overlay L2 (VxLAN)" sono mostrati i componenti software in esecuzione all'interno delle tre VM di Compute Engine. Questo rettangolo VxLAN include il deployment del cluster, che contiene uno spazio dei nomi Kubernetes all'interno del cluster. Tutti i componenti all'interno di questo spazio dei nomi Kubernetes costituiscono l'applicazione per i punti vendita di cui è stato eseguito il deployment nel cluster. L'applicazione Point of Sale ha tre microservizi: server API, Inventory e Payments. Tutti questi componenti insieme rappresentano un'"applicazione" mostrata nel diagramma dell'architettura di implementazione di Edge precedente.

Il bilanciatore del carico MetalLB integrato del cluster non può essere raggiunto direttamente dall'esterno delle VM. Il diagramma mostra un reverse proxy NGINX configurato per l'esecuzione all'interno delle VM per instradare il traffico in entrata nelle VM di Compute Engine al bilanciatore del carico. Si tratta solo di una soluzione alternativa ai fini di questo tutorial, in cui i nodi perimetrali vengono emulati utilizzando le VM di Google CloudCompute Engine. In una località perimetrale reale, questa operazione può essere eseguita con una configurazione di rete adeguata.

Obiettivi

  1. Utilizza le VM di Compute Engine per emulare un'infrastruttura bare metal eseguita in una località perimetrale.
  2. Utilizza Google Distributed Cloud per creare un cluster nell'infrastruttura perimetrale emulata.
  3. Connetti e registra il cluster con Google Cloud.
  4. Eseguire il deployment di un workload di un'applicazione per punti vendita di esempio nel cluster.
  5. Utilizza la console Google Cloud per verificare e monitorare l'applicazione per i punti vendita che opera nella località perimetrale.
  6. Utilizza Config Sync per aggiornare l'applicazione per i punti vendita in esecuzione sul cluster.

Prima di iniziare

  1. Nella console Google Cloud , nella pagina di selezione del progetto, seleziona o crea un progetto Google Cloud .

    Vai alla selezione dei progetti

  2. Verifica che la fatturazione sia attivata per il tuo progetto Cloud. Scopri come verificare se la fatturazione è abilitata per un progetto.

  3. Installa e inizializza 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 quanto previsto da Config Sync. Clona questo repository nel tuo account GitHub prima di continuare con i passaggi seguenti.

  1. Se non ne hai già uno, crea un account su GitHub.

  2. Crea un token di accesso personale da utilizzare nella configurazione di Config Sync. Questo è necessario affinché i componenti di Config Sync nel cluster possano autenticarsi con il tuo account GitHub quando tentano di sincronizzare le 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.

  3. Crea un fork del repository anthos-samples nel tuo account GitHub:

    1. Vai al repository anthos-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. Verrà visualizzata automaticamente la pagina con la tua versione del repository anthos-samples creata mediante fork.

  4. Apri un terminale nel tuo ambiente locale.

  5. 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, devi avere una workstation con accesso a internet e i seguenti strumenti installati:

Esegui tutti i comandi del tutorial sulla workstation che configuri in questa sezione.

  1. Sulla tua 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: 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 tuo repository GitHub.

    Mantieni i valori predefiniti per le altre variabili di ambiente. Sono descritti nelle sezioni seguenti.

  2. Sulla tua 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}"

  3. Nella tua workstation, crea il service account 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 anche il keyring e la chiave di Cloud Key Management Service per la crittografia della chiave privata SSH.

    ./scripts/create-primary-gsa.sh

    L'esempio seguente è solo una parte dello script. Per visualizzare l'intero script, 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 Compute Engine

In questa sezione, creerai le VM di Compute Engine in cui verrà installato solo il software Distributed Cloud. Verificherai anche la connettività a queste VM prima di procedere alla sezione di installazione.

  1. Sulla tua workstation, crea le chiavi SSH utilizzate per la comunicazione tra le istanze di Compute Engine:

    ssh-keygen -f ./build-artifacts/consumer-edge-machine

  2. Cripta 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.encrypted

  3. Genera il file di configurazione dell'ambiente .envrc e utilizzalo come origine. Dopo la creazione, 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 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

  4. Crea istanze di Compute Engine:

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

Installa un cluster Bare Metal con Ansible

Lo script utilizzato in questa guida crea cluster 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 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. Le istanze VM sono 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 assegnato lo stesso nome della VM della workstation di amministrazione (ad esempio cnuc-1, cnuc-4, cnuc-7).

Il playbook Ansible esegue le seguenti operazioni:

  • Configura le istanze di Compute Engine con gli strumenti necessari, come docker, bmctl, gcloud e nomos.
  • Installa un cluster bare metal nelle istanze Compute Engine configurate.
  • Crea un cluster autonomo 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 le configurazioni del cluster che si trovano in anthos-bm-edge-deployment/acm-config-sink nel repository di cui hai eseguito il fork.
  • Genera il Login token per il cluster.

Per configurare e avviare la procedura di installazione, completa i seguenti passaggi:

  1. Sulla tua 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 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

  2. Genera il file di inventario Ansible dal template:

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

  3. 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 volume montato nella directory di lavoro corrente. Al termine dell'esecuzione di questo script, dovresti trovarti all'interno del container Docker creato. L'installazione di Ansible viene attivata dall'interno di questo container.

    ./install.sh

    Se lo script viene eseguito correttamente, genera 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)

  4. Dal container Docker, verifica l'accesso alle istanze di Compute Engine:

    ./scripts/health-check.sh

    Se lo script viene eseguito correttamente, genera 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"}

  5. Dall'interno del container Docker, esegui il playbook Ansible per l'installazione di un cluster bare metal sulle istanze 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

    Se l'installazione viene eseguita correttamente, genera 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 nella console Google Cloud

Al termine dell'esecuzione del playbook Ansible, viene installato un cluster autonomo all'interno delle VM di Compute Engine. Questo cluster è registrato anche inGoogle Cloud, utilizzando l'agente Connect. Tuttavia, per visualizzare i dettagli di questo cluster devi accedere al cluster dalla console Google Cloud .

Per accedere al cluster, completa i seguenti passaggi:

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

  2. 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 su Accedi.
    2. Seleziona Token e incolla il token copiato.
    3. Fai clic su Login (Accedi).
  3. Nella console Google Cloud , vai alla pagina Config nella sezione Funzionalità.

    Vai alla configurazione

    4. Nella scheda Pacchetti, controlla la colonna Stato sincronizzazione nella tabella in cluster. Verifica che lo stato sia Sincronizzato. Lo stato Sincronizzato indica che Config Sync ha sincronizzato correttamente le configurazioni di GitHub con il cluster di cui hai eseguito il deployment, cnuc-1.

Configura un proxy per il traffico esterno

Il cluster installato nei passaggi precedenti utilizza un bilanciatore del carico in bundle chiamato MetalLB. Questo servizio di bilanciatore del carico è accessibile solo tramite un indirizzo IP Virtual Private Cloud (VPC). Per instradare il traffico in entrata tramite il suo IP esterno al bilanciatore del carico integrato, configura un servizio di reverse proxy nell'host di amministrazione (cnuc-1). Questo servizio di reverse proxy ti consente di raggiungere il server API dell'applicazione del punto vendita tramite l'IP esterno dell'host di amministrazione (cnuc-1).

Gli script di installazione nei passaggi precedenti hanno installato NGINX negli host di amministrazione insieme a un file di configurazione di esempio. Aggiorna questo file per utilizzare l'indirizzo IP del servizio del bilanciatore del carico e riavvia NGINX.

  1. Sulla tua workstation, utilizza SSH per accedere alla workstation di amministrazione:

    ssh -F ./build-artifacts/ssh-config abm-admin@cnuc-1

  2. Dalla workstation di amministrazione, configura il reverse proxy NGINX per instradare il traffico al servizio di bilanciatore del carico del server API. Recupera 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)

  3. Aggiorna il file di configurazione del template 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"

  4. Riavvia NGINX per assicurarti che la nuova configurazione venga applicata:

    sudo systemctl restart nginx

  5. Controlla e verifica che lo stato dei report del server NGINX sia "active (running)":

    sudo systemctl status nginx

    Quando NGINX è in esecuzione, produce un output simile al 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: ....
            ...
            ...

  6. Esci dalla sessione SSH nella workstation di amministrazione:

    exit

  7. Esci dalla sessione della shell nel container Docker. Quando esci dall'istanza di amministrazione, ti trovi ancora all'interno del container Docker utilizzato per l'installazione:

    exit

Accedi all'applicazione point of sale

Con la configurazione del proxy esterno puoi accedere all'applicazione in esecuzione all'interno del cluster. Per accedere all'applicazione per punti vendita di esempio, completa i seguenti passaggi.

  1. Sulla tua workstation, ottieni l'indirizzo IP esterno dell'istanza Compute Engine amministratore e accedi alla UI dell'applicazione per i punti vendita:

    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}"

    Se gli script vengono eseguiti correttamente, generano un output simile al seguente:

    Point the browser to: 34.134.194.84:8082

  2. 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 seguente:

    Deployment della versione 1 dell'applicazione point of sale

Utilizza Config Sync per aggiornare il server API

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

  1. Sulla tua workstation, aggiorna il campo image per modificare la versione del server API da v1 a v2. La configurazione YAML per il deployment si trova nel file in 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

  2. Aggiungi, fai il commit e fai 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 push

  3. Nella console Google Cloud , vai alla pagina Config Sync per controllare lo stato della specifica di configurazione. Verifica che lo stato sia Sincronizzato.

    Vai alla pagina Config Sync

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

    Vai alla pagina Workload di Kubernetes Engine

  5. Quando lo stato del deployment è OK, indirizza il browser all'indirizzo IP della sezione precedente per visualizzare l'applicazione del punto vendita. 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 seguente:

    Deployment della versione 2 dell'applicazione point of sale

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

Esegui la pulizia

Per evitare addebiti non necessari di Google Cloud , elimina le risorse utilizzate per questa guida quando non ti servono più. Puoi eliminare queste risorse manualmente o eliminare il progetto Google Cloud , eliminando anche tutte le risorse. Inoltre, potresti voler ripulire le modifiche apportate alla tua 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-* nel 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 .

  • 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 progetto, quindi 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 località 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 denominato cnuc-4.

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

    Per informazioni dettagliate sui singoli passaggi di questa guida e sugli script coinvolti, consulta il repository anthos-samples.