Deployment di Anthos su cluster Bare Metal a livello perimetrale

Questo tutorial introduce una soluzione pronta per l'uso che utilizza i cluster Anthos su Bare Metal e Anthos Config Management per eseguire il deployment di cluster Kubernetes a livello perimetrale su larga scala. Questo tutorial è rivolto agli operatori e agli sviluppatori di piattaforme. Avere familiarità con i seguenti concetti e tecnologie:

In questo tutorial, utilizzerai le macchine virtuali (VM) di Compute Engine per emulare i nodi di cui è stato eseguito il deployment a livello perimetrale e un'applicazione point of sale di esempio come carico di lavoro periferico. Cluster Anthos on bare metal e Anthos Config Management offrono gestione e controllo centralizzati per il tuo cluster perimetrale. Anthos Config Management estrae dinamicamente nuove configurazioni da GitHub e applica questi criteri e configurazioni ai tuoi cluster.

Architettura di deployment a livello perimetrale

Un deployment edge per la vendita al dettaglio è un buon modo per illustrare l'architettura utilizzata in un tipico cluster Anthos su deployment Bare Metal.

Un negozio fisico è il punto di interazione più vicino tra un'attività e il consumatore. I sistemi software all'interno dei negozi devono eseguire i carichi di lavoro, ricevere aggiornamenti tempestivi e segnalare le metriche critiche isolate dal sistema di gestione centrale dell'azienda. Inoltre, questi sistemi software devono essere progettati in modo da poter essere espansi in altre località dei negozi in futuro. Sebbene Cluster Anthos on bare metal soddisfi tutti questi requisiti per i sistemi software per i negozi, il profilo perimetrale consente un caso d'uso importante: i deployment in ambienti con risorse hardware limitate come la vetrina di un negozio di vendita al dettaglio.

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

Mostra un deployment Anthos su Bare Metal che utilizza il profilo perimetrale in un negozio di vendita al dettaglio
Un cluster Anthos sul deployment bare metal in un negozio di vendita al dettaglio

Il diagramma precedente mostra un tipico negozio fisico. Il negozio dispone di smart device come lettori di schede, macchine POS, fotocamere e stampanti. Il negozio ha anche tre dispositivi hardware per il calcolo fisico (con etichetta Node 1, Node 2 e Node 3). Tutti questi dispositivi sono collegati a uno switch di rete centrale. Di conseguenza, 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. Cluster Anthos on bare metal è in esecuzione all'interno di ciascuno dei tre dispositivi informatici. Questi dispositivi hanno anche il proprio spazio di archiviazione su disco e sono configurati per la replica dei dati tra loro per un'alta disponibilità.

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

  • Il componente contrassegnato come MetalLB è il bilanciatore del carico in bundle di cui viene eseguito il deployment con Cluster Anthos on bare metal.
  • Il componente Anthos Config Management consente di sincronizzare lo stato del cluster con i repository di origine. Si tratta di un componente aggiuntivo facoltativo altamente consigliato che richiede installazione e configurazione separate. Per ulteriori informazioni su come configurare Anthos Config Management e sulla diversa metodologia, consulta la documentazione di Anthos Config Management.

  • Il repository root e il repository spazio dei nomi mostrati nella parte superiore del diagramma al di fuori dell'area geografica del negozio rappresentano due repository di origine.

    le modifiche al cluster vengono trasferite a questi repository di codice sorgente centrali. I cluster Anthos su deployment bare metal in varie località perimetrali estraggono aggiornamenti dai repository di origine. Questo comportamento è rappresentato dalle frecce che collegano i due repository nel diagramma ai componenti Anthos Config Management all'interno del cluster Anthos su Bare Metal in esecuzione nei dispositivi.

  • Un altro componente chiave descritto come parte del cluster è Anthos VM Runtime. Anthos VM Runtime consente di eseguire carichi di lavoro esistenti basati su VM all'interno del cluster senza bisogno di containerizzazione. La documentazione di Anthos VM Runtime illustra come abilitarlo ed eseguire il deployment dei carichi di lavoro VM nel cluster.

  • Il componente Applicazione indica il software di cui è stato eseguito il deployment nel cluster da parte del negozio di vendita al dettaglio. Un'applicazione point of sale visibile nei kiosk di un negozio di vendita al dettaglio potrebbe essere un esempio di questa applicazione.

Le caselle nella parte inferiore del diagramma rappresentano i molti dispositivi (come kiosk, tablet o videocamere) all'interno di un negozio di vendita al dettaglio, tutti collegati a uno switch di rete centrale. Il networking locale all'interno dell'archivio consente alle applicazioni in esecuzione all'interno dei cluster Anthos sul deployment Bare Metal di raggiungere questi dispositivi.

Nella sezione successiva vedrai l'emulazione del deployment di questo punto vendita in Google Cloud utilizzando le VM di Compute Engine. Questa emulazione è quella che utilizzi nel tutorial che segue per sperimentare con Cluster Anthos on bare metal.

Deployment perimetrale emulato in Google Cloud

Il seguente diagramma ritrae tutto ciò che hai configurato in Google Cloud in questo tutorial. Questo diagramma è correlato al diagramma del negozio di vendita al dettaglio della sezione precedente. Questo deployment rappresenta una località perimetrale emulata in cui viene eseguito il deployment dell'applicazione point of sale. L'architettura mostra anche un semplice carico di lavoro di esempio di un'applicazione point of sale che puoi utilizzare in questo tutorial. Puoi accedere al 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 viene eseguito il deployment all'interno di un cluster Anthos su Bare Metal in esecuzione sulle VM di Compute Engine.
Un'applicazione di esempio di cui è stato eseguito il deployment all'interno di un cluster Anthos su Bare Metal

Le tre macchine virtuali (VM) di Compute Engine nel diagramma precedente rappresentano l'hardware fisico (o i nodi) in una tipica posizione perimetrale. Questo hardware verrà collegato insieme agli switch di rete per creare l'infrastruttura Bare Metal. Nel nostro ambiente emulato in Google Cloud, queste VM sono connesse tra loro tramite la rete Virtual Private Cloud (VPC) predefinita nel progetto Google Cloud.

In una tipica installazione di Cluster Anthos on bare metal, puoi configurare i tuoi bilanciatori del carico. Tuttavia, per questo tutorial non devi configurare un bilanciatore del carico esterno. Utilizza invece il bilanciatore del carico MetalLB in bundle installato con i cluster Anthos 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 mediante la creazione di una rete overlay VxLAN sulla rete VPC (Virtual Private Cloud) predefinita.

All'interno del rettangolo con etichetta "L2 overlay network (VxLAN)", vengono visualizzati i componenti software in esecuzione all'interno delle tre VM di Compute Engine. Questo rettangolo include il cluster Anthos su Bare Metal e un proxy inverso. Il cluster è rappresentato dal rettangolo "Cluster Anthos on bare metal". Questo rettangolo che rappresenta il cluster include un altro rettangolo contrassegnato come "spazio dei nomi Kubernetes (pos)". Rappresenta uno spazio dei nomi Kubernetes all'interno del cluster. Tutti i componenti all'interno di questo spazio dei nomi Kubernetes costituiscono l'applicazione point of sale di cui viene eseguito il deployment nel cluster Anthos. L'applicazione point of sale ha tre microservizi: API Server, Inventory e Payments. Insieme, tutti questi componenti rappresentano una "applicazione" mostrata nel diagramma dell'architettura di implementazione precedente di 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 per instradare il traffico in entrata nelle VM di Compute Engine al bilanciatore del carico. Questa è una soluzione alternativa solo per gli scopi di questo tutorial, in cui i nodi periferici vengono emulati utilizzando le VM di Google Cloud Compute Engine. In una posizione perimetrale reale, è possibile farlo con una configurazione di rete adeguata.

Obiettivi

  1. Utilizza le VM di Compute Engine per emulare un'infrastruttura bare metal in esecuzione in una località perimetrale.
  2. Crea un cluster Anthos su Bare Metal nell'infrastruttura perimetrale emulata.
  3. Connetti e registra il cluster con Google Cloud.
  4. Eseguire il deployment di un carico di lavoro di applicazione point of sale d'esempio sul cluster Anthos.
  5. Utilizza la console Google Cloud per verificare e monitorare l'applicazione point of sale che opera nella località perimetrale.
  6. Utilizza Anthos Config Management per aggiornare l'applicazione point of sale in esecuzione sul cluster Anthos.

Prima di iniziare

  1. Nella pagina del selettore dei progetti, nella console Google Cloud, seleziona o crea un progetto Google Cloud.

    Vai alla selezione del progetto

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

  3. Installa e inizializza Google Cloud CLI.

Crea un fork e clona il repository degli esempi di Anthos

Tutti gli script utilizzati in questo tutorial sono archiviati nel repository anthos-samples. La struttura delle cartelle in /anthos-bm-edge-deployment/acm-config-sink è organizzata in base a quanto previsto da Anthos Config Management. Clona questo repository nel tuo account GitHub prima di continuare con i passaggi seguenti.

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

  2. Crea un token di accesso personale da utilizzare nella configurazione di Anthos Config Management. Questo è necessario affinché i componenti di Anthos Config Management nel cluster possano autenticarsi con il proprio account GitHub quando si tenta 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. Il sistema ti reindirizzerà automaticamente alla pagina con la tua versione creata mediante fork del repository anthos-samples.

  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

Configurare l'ambiente della workstation

Per completare il deployment perimetrale descritto in questo documento, è necessaria una workstation con accesso a Internet e i seguenti strumenti installati:

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

  1. Nella workstation, inizializza le variabili di ambiente in una nuova istanza di 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 illustrate nelle sezioni seguenti.

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

  3. Sulla workstation, crea l'account di servizio Google Cloud per le istanze di Compute Engine. Questo script crea il file della chiave JSON per il nuovo account di servizio all'indirizzo <REPO_ROOT>/anthos-bm-edge-deployment/build-artifacts/consumer-edge-gsa.json. Configura anche il keyring e la chiave Cloud Key Management Service per la crittografia delle chiavi private SSH.

    ./scripts/create-primary-gsa.sh

    Una parte dello script è visibile di seguito. Fai clic sul link View on GitHub per vedere l'intero script.

    anthos-bm-edge-deployment/scripts/create-primary-gsa.sh 
    # ...
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 verranno installati i cluster Anthos su Bare Metal. Inoltre, devi verificare la connettività a queste VM prima di passare alla sezione relativa all'installazione.

  1. Sulla workstation, crea 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 tramite 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 crealo come origine. Dopo aver creato il file .envrc, esaminalo 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 un file .envrc generato sostituendo le variabili di ambiente nel file templates/envrc-template.sh. Nota che le righe aggiornate sono evidenziate:

    anthos-bm-edge-deployment/templates/envrc.example 
    # 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 in cui sono installati i cluster Anthos su Bare Metal.

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

Installa Cluster Anthos on bare metal con Ansible

Lo script utilizzato in questa guida crea cluster Anthos su Bare Metal in gruppi di tre istanze Compute Engine. Il numero di cluster creati è controllato dalla variabile di ambiente GCE_COUNT. Ad esempio, hai impostato la variabile di ambiente GCE_COUNT su 6 per creare due cluster Anthos su Bare Metal con 3 istanze VM ciascuna. Per impostazione predefinita, la variabile di ambiente GCE_COUNT è impostata su 3. Pertanto, in questa guida verrà creato un cluster con istanze 3 di Compute Engine. Il nome delle istanze VM è preceduto da cnuc- e seguito da un numero. La prima istanza VM di ogni cluster funge da workstation di amministrazione da cui viene attivata l'installazione. Il cluster ha 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 i cluster Anthos su Bare Metal nelle istanze di Compute Engine configurate.
  • Crea un cluster autonomo Anthos on bare metal denominato cnuc-1.
  • Registra il cluster cnuc-1 con Google Cloud.
  • Installa Anthos Config Management nel cluster cnuc-1.
  • Configura Anthos Config Management per la sincronizzazione con le configurazioni del cluster che si trovano in anthos-bm-edge-deployment/acm-config-sink nel repository creato con fork.
  • Genera la Login token per il cluster.

Completa i seguenti passaggi per configurare e avviare il processo di installazione:

  1. Sulla workstation, crea l'immagine Docker utilizzata per l'installazione. Questa immagine include tutti gli strumenti necessari per il processo di installazione, come Ansible, Python e Google Cloud CLI.

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

    Quando la build viene eseguita correttamente, produce un output come il seguente:

    ...
latest: digest: sha256:99ded20d221a0b2bcd8edf3372c8b1f85d6c1737988b240dd28ea1291f8b151a size: 4498
DONE
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
ID                                    CREATE_TIME                DURATION  SOURCE                                                                                         IMAGES                                                  STATUS
2238baa2-1f41-440e-a157-c65900b7666b  2022-08-17T19:28:57+00:00  6M53S     gs://my_project_cloudbuild/source/1660764535.808019-69238d8c870044f0b4b2bde77a16111d.tgz  gcr.io/my_project/consumer-edge-install (+1 more)  SUCCESS

  2. Genera il file di inventario Ansible dal modello.

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

    ./install.sh

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

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

    ./scripts/health-check.sh

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

  5. Dall'interno del container Docker, esegui il playbook Ansible per installare i cluster Anthos su Bare Metal sulle istanze di Compute Engine. Al termine, vedrai il cluster Login Token stampato per il cluster sullo schermo.

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

    Quando l'installazione viene eseguita correttamente, viene visualizzato 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 Anthos clusters on bare metal nella console Google Cloud

Una volta eseguito il playbook Ansible, il cluster Anthos on bare metal autonomo viene installato all'interno delle VM di Compute Engine. Questo cluster è registrato anche in Google Cloud tramite l'agente Connect. Tuttavia, per visualizzare i dettagli di questo cluster, devi accedere al cluster da Google Cloud Console. Per accedere al cluster Anthos, 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 Cluster di 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).

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

    Vai alla pagina Config Management

    Anthos Config Management sincronizzato con il repository di origine.

Configurare un proxy per il traffico esterno

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

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

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

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

  2. Dall'interno della workstation di amministrazione, configura il proxy inverso NGINX per instradare il traffico al servizio bilanciatore del carico dell'API Server. Ottieni l'indirizzo IP del servizio Kubernetes del tipo di bilanciatore del carico:

    ABM_INTERNAL_IP=$(kubectl get services api-server-lb -n pos | awk '{print $4}' | tail -n 1)

  3. 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"

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

    sudo systemctl restart nginx

  5. 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 nell'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: ....
            ...
            ...

  6. Esci dalla sessione SSH nella workstation di amministrazione:

    exit

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

    exit

Accedi all'applicazione del point of sale

Con la configurazione del proxy esterno puoi accedere all'applicazione in esecuzione all'interno del cluster Anthos. Per accedere all'applicazione point of sale di esempio, procedi nel seguente modo.

  1. Sulla workstation, recupera l'indirizzo IP esterno dell'istanza di Compute Engine amministratore e accedi all'interfaccia utente dell'applicazione point of sale:

    EXTERNAL_IP=$(gcloud compute instances list \
    --project ${PROJECT_ID} \
    --filter="name:cnuc-1" \
    --format="get(networkInterfaces[0].accessConfigs[0].natIP)")
echo "Point the browser to: ${EXTERNAL_IP}:${PROXY_PORT}"

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

    Point the browser to: 34.134.194.84: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:

    Versione 1 dell'applicazione del point of sale di cui è stato eseguito il deployment.

Utilizza Anthos Config Management per aggiornare il server API

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

  1. Sulla workstation, aggiorna il campo image per cambiare la versione del server API da v1 a v2. La configurazione YAML per il deployment è 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 
    containers:
- name: api-server
  image: us-docker.pkg.dev/anthos-dpe-abm-edge-pos/abm-edge-pos-images/api-server:v1

  2. Aggiungi, esegui il commit e il push delle modifiche nel tuo 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 Management (Gestione configurazione) per controllare lo stato delle specifiche di configurazione. Verifica che lo stato sia Sincronizzato.

    Vai alla pagina Config Management

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

    Vai alla pagina dei carichi di lavoro Kubernetes Engine

  5. Quando lo stato del deployment è OK, indirizza il browser all'indirizzo IP della sezione precedente per visualizzare l'applicazione point of sale. Tieni presente che la versione nel titolo mostra "V2" e indica che è stato eseguito il deployment della modifica dell'applicazione, come mostrato nel seguente screenshot di esempio:

    Versione 2 dell'applicazione del point of sale di cui è stato eseguito il deployment.

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

Esegui la pulizia

Per evitare addebiti Google Cloud non necessari, elimina le risorse utilizzate per questa guida quando hai finito. Puoi eliminare manualmente queste risorse o eliminare il tuo progetto Google Cloud, che comporta inoltre la rimozione di tutte le risorse. Inoltre, puoi eseguire la pulizia delle modifiche apportate nella workstation locale:

Workstation locale

I seguenti file devono essere aggiornati per annullare le modifiche apportate dagli script di installazione.

  • Rimuovi gli indirizzi IP VM di Compute Engine aggiunti al file /etc/hosts.
  • Rimuovi la configurazione SSH di cnuc-* nel file ~/.ssh/config.
  • Rimuovi le fingerprint 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 del progetto e fai clic su Chiudi per eliminare il progetto.

    • Manuale

    Se hai utilizzato un progetto esistente per questa procedura, procedi nel seguente modo:

    • Annulla la registrazione di tutti i cluster Kubernetes con un nome preceduto da cnuc-.
    • Elimina tutte le VM di Compute Engine con un nome preceduto da cnuc-.
    • Elimina il bucket Cloud Storage il cui 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.

    Quali sono i passaggi successivi?

    Puoi espandere la guida aggiungendo un'altra località perimetrale. Se imposti la variabile di ambiente GCE_COUNT su 6 ed esegui di nuovo gli stessi passaggi delle sezioni precedenti, vengono create tre nuove istanze di Compute Engine (cnuc-4, cnuc-5, cnuc-6) e un nuovo cluster autonomo Anthos su Bare Metal denominato cnuc-4.

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

    Per i dettagli sui singoli passaggi in questa guida, gli script in questione sono disponibili nel repository anthos-samples.