Déployer des clusters Google Distributed Cloud sur le réseau de périphérie

Ce tutoriel présente une solution prête à l'emploi qui utilise Google Distributed Cloud et Config Sync pour déployer des clusters Kubernetes en périphérie à grande échelle. Ce tutoriel s'adresse aux opérateurs de plates-formes et aux développeurs. Avant de lire ce document, assurez-vous de connaître les technologies et concepts suivants :

Dans ce tutoriel, vous allez utiliser des machines virtuelles (VM) Compute Engine pour émuler des nœuds déployés en périphérie, et un exemple d'application de point de vente en tant que charge de travail de périphérie. Google Distributed Cloud et Config Sync fournissent une gestion et un contrôle centralisés pour votre cluster de périphérie. Config Sync extrait de manière dynamique de nouvelles configurations de GitHub, et applique ces règles et configurations à vos clusters.

Architecture de déploiement Edge

Un déploiement de réseau de périphérie de vente au détail est un bon moyen d'illustrer l'architecture utilisée dans un déploiement Google Distributed Cloud classique.

Un magasin physique est le point d'interaction le plus proche entre une unité commerciale d'entreprise et le consommateur. Les systèmes logiciels des magasins doivent exécuter leurs charges de travail, recevoir des mises à jour en temps opportun et signaler des métriques critiques de manière isolée du système de gestion central de l'entreprise. De plus, ces systèmes logiciels doivent être conçus de manière à pouvoir être étendus à d'autres magasins à l'avenir. Bien que Google Distributed Cloud réponde à toutes ces exigences pour les systèmes logiciels de magasin, le profil de périphérie permet un cas d'utilisation important : les déploiements dans des environnements dotés de ressources matérielles limitées, comme un magasin de détail.

Le schéma suivant illustre un déploiement Google Distributed Cloud qui utilise le profil de périphérie dans un magasin :

Déploiement de Google Distributed Cloud qui utilise le profil de périphérie dans un magasin

Le schéma précédent illustre un magasin physique type. Le magasin dispose d'appareils intelligents tels que des lecteurs de cartes, des machines de point de vente, des caméras et des imprimantes. Le magasin dispose également de trois appareils physiques (étiquetés Node 1, Node 2 et Node 3). Tous ces appareils sont connectés à un commutateur réseau central. Ainsi, les trois appareils informatiques sont connectés entre eux via un réseau de couche 2. Les appareils informatiques connectés en réseau constituent l'infrastructure bare metal. Google Distributed Cloud s'exécute sur chacun des trois appareils informatiques. Ces appareils disposent également de leur propre espace de stockage sur disque et sont configurés pour la réplication des données entre eux afin d'assurer une haute disponibilité.

Le schéma montre également les composants clés suivants qui font partie d'un déploiement Google Distributed Cloud :

  • Le composant marqué comme MetalLB est l'équilibreur de charge groupé déployé avec Google Distributed Cloud.
  • Le composant Config Sync permet de synchroniser l'état du cluster avec les dépôts sources. Il s'agit d'un module complémentaire facultatif, mais fortement recommandé, qui nécessite une installation et une configuration distinctes. Pour en savoir plus sur la configuration de Config Sync et sur les différentes nomenclatures, consultez la documentation sur Config Sync.

  • Le dépôt racine et le dépôt d'espace de noms affichés en haut du schéma en dehors de l'emplacement du magasin représentent deux dépôts sources.

    Les modifications apportées au cluster sont transférées vers ces dépôts sources centraux. Les déploiements Google Distributed Cloud dans différents emplacements de périphérie collectent les mises à jour à partir des dépôts sources. Ce comportement est représenté par les flèches reliant les deux dépôts du schéma aux composants Config Sync du cluster Google Distributed Cloud exécuté sur les appareils.

  • L'environnement d'exécution de la VM sur GDC est un autre composant clé représenté dans le cluster. L'environnement d'exécution de VM sur GDC permet d'exécuter des charges de travail basées sur des VM existantes dans le cluster sans avoir besoin de conteneurisation. La documentation sur l'environnement d'exécution de VM sur GDC explique comment l'activer et déployer vos charges de travail de VM dans le cluster.

  • Le composant marqué comme Application désigne le logiciel déployé dans le cluster par le magasin. L'application de point de vente des bornes d'un magasin est un exemple de ce type d'application.

Les cases en bas du schéma représentent les nombreux appareils (tels que les bornes, les tablettes ou les caméras) d'un magasin, qui sont tous connectés à un commutateur réseau central. Le réseau local dans le magasin permet aux applications exécutées dans le déploiement Google Distributed Cloud d'atteindre ces appareils.

Dans la section suivante, vous allez voir l'émulation de ce déploiement de magasin dans Google Cloud à l'aide de VM Compute Engine. C'est cette émulation que vous utiliserez dans le tutoriel suivant pour tester Google Distributed Cloud.

Déploiement d'un environnement de périphérie émulé dans Google Cloud

Le schéma suivant illustre tout ce que vous avez configuré dans Google Cloud dans ce tutoriel. Ce schéma correspond au schéma de la boutique de la section précédente. Ce déploiement représente un emplacement de périphérie émulé dans lequel l'application de point de vente est déployée. L'architecture montre également une charge de travail d'application de point de vente simple que vous utiliserez dans ce tutoriel. Pour accéder à l'application de point de vente dans le cluster, utilisez un navigateur Web en mode kiosque.

Architecture de l'application de point de vente et son déploiement dans un cluster Google Distributed Cloud s'exécutant sur des VM Compute Engine

Les trois machines virtuelles (VM) Compute Engine du schéma précédent représentent le matériel physique (ou les nœuds) d'un emplacement d'accès périphérique type. Ce matériel est connecté à des commutateurs réseau pour constituer l'infrastructure bare metal. Dans notre environnement émulé dans Google Cloud, ces VM sont connectées entre elles via le réseau Virtual Private Cloud (VPC) par défaut du projet Google Cloud.

Dans une installation Google Distributed Cloud standard, vous pouvez configurer vos propres équilibreurs de charge. Toutefois, pour ce tutoriel, vous ne configurerez pas d'équilibreur de charge externe. Vous utiliserez plutôt l'équilibreur de charge MetalLB groupé installé avec Google Distributed Cloud. L'équilibreur de charge MetalLB fourni nécessite une connectivité de réseau de couche 2 entre les nœuds. Ainsi, la connectivité de la couche 2 entre les VM Compute Engine est activée en créant un réseau de superposition VxLAN au-dessus du réseau Virtual Private Cloud (VPC) par défaut.

Dans le rectangle intitulé Réseau de superposition L2 (VxLAN), les composants logiciels exécutés dans les trois VM Compute Engine sont affichés. Ce rectangle inclut le cluster Google Distributed Cloud et un proxy inverse. Le cluster est représenté par le rectangle "Google Distributed Cloud". Ce rectangle représentant le cluster inclut un autre rectangle marqué comme "Espace de noms Kubernetes (pos)". Il représente un espace de noms Kubernetes dans le cluster. Tous les composants de cet espace de noms Kubernetes constituent l'application de point de vente déployée dans le cluster Google Distributed Cloud. L'application de point de vente comporte trois microservices : serveur d'API, inventaire et paiements. Tous ces composants représentent une application comme celle illustrée dans le précédent schéma d'architecture de déploiement de périphérie.

L'équilibreur de charge MetalLB fourni du cluster Google Distributed Cloud n'est pas directement accessible depuis l'extérieur des VM. Le schéma montre un proxy inverse NGINX configuré pour s'exécuter dans les VM afin d'acheminer le trafic entrant dans les VM Compute Engine vers l'équilibreur de charge. Il ne s'agit que d'une solution de contournement pour les besoins de ce tutoriel, dans lequel les nœuds de périphérie sont émulés à l'aide de VM Google Cloud Compute Engine. Dans un emplacement de périphérie réel, cela peut être fait avec une configuration réseau appropriée.

Objectifs

  1. Utilisez des VM Compute Engine pour émuler une infrastructure Bare Metal exécutée dans un emplacement périphérique.
  2. Créez un cluster Google Distributed Cloud dans l'infrastructure de périphérie émulée.
  3. Connectez et enregistrez le cluster auprès de Google Cloud.
  4. Déployer un exemple de charge de travail d'application de point de vente sur le cluster Google Distributed Cloud
  5. Utilisez la console Google Cloud pour vérifier et surveiller l'application de point de vente qui fonctionne sur le site de périphérie.
  6. Utilisez Config Sync pour mettre à jour l'application de point de vente exécutée sur le cluster Google Distributed Cloud.

Avant de commencer

  1. Dans la console Google Cloud, sur la page de sélection du projet, sélectionnez ou créez un projet Google Cloud.

    Accéder à la sélection de projets

  2. Assurez-vous que la facturation est activée pour votre projet Cloud. Découvrez comment vérifier si la facturation est activée sur un projet.

  3. Installez et initialisez Google Cloud CLI.

Dupliquer le dépôt anthos-samples

Tous les scripts utilisés dans ce tutoriel sont stockés dans le dépôt anthos-samples. La structure de dossiers sous /anthos-bm-edge-deployment/acm-config-sink est organisée selon les attentes de Config Sync. Clonez ce dépôt sur votre propre compte GitHub avant de poursuivre les étapes suivantes.

  1. Si vous n'avez pas encore de compte, créez-en un sur GitHub.

  2. Créez un jeton d'accès personnel à utiliser dans la configuration de Config Sync. Cette étape est nécessaire pour que les composants Config Sync du cluster puissent s'authentifier avec votre compte GitHub lorsque vous essayez de synchroniser de nouvelles modifications.

    1. Sélectionnez uniquement le niveau d'accès public_repo.
    2. Enregistrez le jeton d'accès que vous avez créé dans un endroit sûr pour pouvoir l'utiliser ultérieurement.

  3. Dupliquez le dépôt anthos-samples sur votre propre compte GitHub :

    1. Accédez au dépôt anthos-samples.
    2. Cliquez sur l'icône Dupliquer en haut à droite de la page.
    3. Cliquez sur le compte utilisateur GitHub vers lequel vous souhaitez dupliquer le dépôt. Vous êtes automatiquement redirigé vers la page contenant votre version dupliquée du dépôt anthos-samples.

  4. Ouvrez un terminal dans votre environnement local.

  5. Clonez le dépôt dupliqué en exécutant la commande suivante, où GITHUB_USERNAME correspond au nom d'utilisateur de votre compte GitHub :

    git clone https://github.com/GITHUB_USERNAME/anthos-samples
cd anthos-samples/anthos-bm-edge-deployment

Configurer l'environnement de la station de travail

Pour effectuer le déploiement en périphérie décrit dans ce document, vous avez besoin d'un poste de travail avec accès à Internet et sur lequel les outils suivants sont installés :

Exécutez toutes les commandes du tutoriel sur le poste de travail que vous configurez dans cette section.

  1. Sur votre poste de travail, initialisez les variables d'environnement dans une nouvelle instance d'interface système :

    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"

    Remplacez les valeurs suivantes :

    • PROJECT_ID : ID de votre projet Google Cloud.
    • GITHUB_USERNAME : votre nom d'utilisateur GitHub.
    • ACCESS_TOKEN : jeton d'accès personnel que vous avez créé pour votre dépôt GitHub.

    Conservez les valeurs par défaut des autres variables d'environnement. Elles sont expliquées dans les sections suivantes.

  2. Sur votre poste de travail, initialisez 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. Sur votre poste de travail, créez le compte de service Google Cloud pour les instances Compute Engine. Ce script crée le fichier de clé JSON pour le nouveau compte de service à l'adresse <REPO_ROOT>/anthos-bm-edge-deployment/build-artifacts/consumer-edge-gsa.json. Il configure également le trousseau de clés et la clé de Cloud Key Management Service pour le chiffrement de la clé privée SSH.

    ./scripts/create-primary-gsa.sh

    L'exemple suivant n'est qu'une partie du script. Pour afficher le script complet, cliquez sur Afficher sur 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
# ...

Provisionner les instances Compute Engine

Dans cette section, vous allez créer les VM Compute Engine sur lesquelles Google Distributed Cloud sera installé. Vous devez également vérifier la connectivité de ces VM avant de passer à la section d'installation.

  1. Sur votre poste de travail, créez des clés SSH utilisées pour la communication entre les instances Compute Engine.

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

  2. Chiffrer la clé privée SSH à l'aide de 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. Générez le fichier de configuration de l'environnement .envrc et fournissez-le. Après la création, inspectez le fichier .envrc pour vous assurer que les variables d'environnement ont été remplacées par les valeurs appropriées.

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

    Voici un exemple de fichier .envrc généré en remplaçant les variables d'environnement dans le fichier templates/envrc-template.sh. Notez que les lignes mises à jour sont mises en surbrillance : 

    # 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. Créez des instances Compute Engine sur lesquelles Google Distributed Cloud est installé.

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

Installer Google Distributed Cloud avec Ansible

Le script utilisé dans ce guide crée des clusters Google Distributed Cloud dans des groupes de trois instances Compute Engine. Le nombre de clusters créés est contrôlé par la variable d'environnement GCE_COUNT. Par exemple, vous définissez la variable d'environnement GCE_COUNT sur 6 pour créer deux clusters Google Distributed Cloud avec 3 instances de VM chacune. Par défaut, la variable d'environnement GCE_COUNT est définie sur 3. Ainsi, dans ce guide, un cluster avec 3 instances Compute Engine sera créé. Le nom des instances doit commencer par le préfixe cnuc-, suivi d'un numéro. La première instance de VM de chaque cluster agit en tant que poste de travail administrateur à partir duquel l'installation est déclenchée. Le cluster porte également le même nom que la VM de la station de travail administrateur (cnuc-1, cnuc-4, cnuc-7, par exemple).

Le playbook Ansible effectue les opérations suivantes :

  • Il configure les instances Compute Engine avec les outils nécessaires, tels que docker, bmctl, gcloud et nomos.
  • Il installe Google Distributed Cloud dans les instances Compute Engine configurées.
  • Il crée un cluster autonome Google Distributed Cloud appelé cnuc-1.
  • Il enregistre le cluster cnuc-1 à l'aide de Google Cloud.
  • Il installe Config Sync dans le cluster cnuc-1.
  • Il configure Config Sync pour permettre la synchronisation avec les configurations de cluster situées dans anthos-bm-edge-deployment/acm-config-sink dans votre dépôt dupliqué.
  • Génère le Login token pour le cluster.

Pour configurer et lancer le processus d'installation, procédez comme suit :

  1. Sur votre poste de travail, créez l'image Docker utilisée pour l'installation. Cette image contient tous les outils nécessaires au processus d'installation, tels qu'Ansible, Python et Google Cloud CLI.

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

    Lorsque la compilation s'exécute correctement, elle génère un résultat semblable à celui-ci :

    ...
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. Générez le fichier d'inventaire Ansible à partir du modèle.

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

  3. Exécutez le script d'installation qui démarre un conteneur Docker à partir de l'image créée précédemment. Le script utilise en interne Docker pour générer le conteneur avec une installation de volume dans le répertoire de travail actuel. Une fois ce script exécuté, vous devez vous trouver dans le conteneur Docker qui a été créé. Vous déclencherez l'installation d'Ansible à partir de ce conteneur.

    ./install.sh

    Lorsque le script s'exécute correctement, il génère un résultat semblable à celui-ci :

    ...
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. Dans le conteneur Docker, vérifiez l'accès aux instances Compute Engine.

    ./scripts/health-check.sh

    Lorsque le script s'exécute correctement, il génère un résultat semblable à celui-ci :

    ...
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. À partir du conteneur Docker, exécutez le playbook Ansible pour installer Google Distributed Cloud sur des instances Compute Engine. Une fois l'opération terminée, le Login Token du cluster s'affiche à l'écran.

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

    Lorsque l'installation s'exécute correctement, elle génère un résultat semblable à celui-ci :

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

Se connecter au cluster Google Distributed Cloud dans la console Google Cloud

Une fois le playbook Ansible terminé, un cluster Google Distributed Cloud autonome est installé dans les VM Compute Engine. Ce cluster est également enregistré dans Google Cloud à l'aide de l'agent Connect. Toutefois, pour afficher les détails de ce cluster, vous devez vous y connecter depuis la console Google Cloud. Pour vous connecter au cluster GKE, procédez comme suit :

  1. Copiez le jeton à partir de la sortie du playbook Ansible dans la section précédente.

  2. Dans la console Google Cloud, accédez à la page des clusters Kubernetes et utilisez le jeton copié pour vous connecter au cluster cnuc-1.

    Accéder à la page des clusters Kubernetes

    1. Dans la liste des clusters, cliquez sur  Actions à côté du cluster cnuc-1, puis sur Se connecter.
    2. Sélectionnez Jeton et collez le jeton copié.
    3. Cliquez sur Login (Connexion).
  3. Dans la console Google Cloud, accédez à la page Configuration sous la section Fonctionnalités.

    Accéder à la page "Configuration"

    4. Dans l'onglet Packages, vérifiez la colonne État de la synchronisation dans le tableau du cluster. Vérifiez que l'état est Synchronisé. Un état Synchronisé indique que Config Sync a synchronisé vos configurations GitHub avec votre cluster cnuc-1 déployé.

s

Configurer un proxy pour le trafic externe

Le cluster Google Distributed Cloud installé lors des étapes précédentes utilise un équilibreur de charge groupé appelé MetalLB. Ce service d'équilibrage de charge n'est accessible qu'à l'aide d'une adresse IP de cloud privé virtuel (VPC). Pour acheminer le trafic entrant via son adresse IP externe vers l'équilibreur de charge groupé, configurez un service de proxy inverse dans l'hôte administrateur (cnuc-1). Ce service de proxy inverse vous permet d'accéder au serveur d'API de l'application de point de vente via l'adresse IP externe de l'hôte administrateur (cnuc-1).

Les scripts d'installation des étapes précédentes ont installé NGINX sur les hôtes administrateur, avec un exemple de fichier de configuration. Mettez à jour ce fichier pour utiliser l'adresse IP du service d'équilibrage de charge et redémarrer NGINX.

  1. Sur votre poste de travail, utilisez SSH pour vous connecter au poste de travail administrateur :

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

  2. Depuis le poste de travail de l'administrateur, configurez le proxy inverse NGINX pour acheminer le trafic vers le service d'équilibrage de charge du serveur d'API. Obtenez l'adresse IP du service Kubernetes de type équilibrage de charge :

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

  3. Mettez à jour le fichier de configuration du modèle avec l'adresse IP récupérée :

    sudo sh -c "sed 's/<K8_LB_IP>/${ABM_INTERNAL_IP}/g' \
    /etc/nginx/nginx.conf.template > /etc/nginx/nginx.conf"

  4. Redémarrez NGINX pour vous assurer que la nouvelle configuration est appliquée :

    sudo systemctl restart nginx

  5. Vérifiez que l'état du serveur NGINX est "actif (en cours d'exécution)" :

    sudo systemctl status nginx

    Lorsque NGINX s'exécute correctement, il génère un résultat semblable à l'exemple suivant :

    ● 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. Quittez la session SSH dans l'instance d'administration :

    exit

  7. Quittez la session d'interface système dans le conteneur Docker. Lorsque vous quittez l'instance d'administration, vous êtes toujours dans le conteneur Docker utilisé pour l'installation :

    exit

Accéder à l'application de point de vente

Avec la configuration du proxy externe, vous pouvez accéder à l'application exécutée dans le cluster GKE. Pour accéder à l'exemple d'application de point de vente, procédez comme suit.

  1. Sur votre poste de travail, obtenez l'adresse IP externe de l'instance d'administration Compute Engine et accédez à l'interface utilisateur de l'application de point de vente :

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

    Lorsque les scripts s'exécutent correctement, ils génèrent un résultat semblable au suivant :

    Point the browser to: 34.134.194.84:8082

  2. Ouvrez votre navigateur Web et accédez à l'adresse IP affichée dans le résultat de la commande précédente. Vous pouvez accéder à l'exemple d'application de point de vente et le tester, comme illustré dans la capture d'écran suivante :

    Version 1 de l&#39;application de point de vente déployée.

Utiliser Config Sync pour mettre à jour le serveur d'API

L'exemple d'application peut être mis à niveau vers une version plus récente en mettant à jour les fichiers de configuration du dépôt racine. Config Sync détecte les mises à jour et applique automatiquement les modifications à votre cluster. Dans cet exemple, le dépôt racine est le dépôt anthos-samples que vous avez cloné au début de ce guide. Pour voir comment l'application de point de vente peut passer par un déploiement de mise à niveau vers une version plus récente, procédez comme suit.

  1. Sur votre poste de travail, mettez à jour le champ image pour remplacer la version du serveur d'API v1 par v2. La configuration YAML du déploiement se trouve dans le fichier à l'adresse 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. Ajoutez, validez et transférez les modifications vers votre dépôt dupliqué :

    git add acm-config-sink/namespaces/pos/api-server.yaml
git commit -m "chore: updated api-server version to v2"
git push

  3. Dans la console Google Cloud, accédez à la page Config Sync pour vérifier l'état des spécifications de configuration. Vérifiez que l'état est Synchronisé.

    Accéder à la page Config Sync

  4. Dans la console Google Cloud, accédez à la page Charges de travail Kubernetes Engine pour vérifier que le déploiement est bien mis à jour.

    Accéder à la page des charges de travail Kubernetes Engine

  5. Lorsque l'état du déploiement est OK, faites pointer votre navigateur vers l'adresse IP de la section précédente pour afficher l'application de point de vente. Notez que la version du titre affiche "V2", ce qui indique que la modification de votre application a été déployée, comme illustré dans la capture d'écran suivante :

    Version 2 de l&#39;application de point de vente déployée.

    Vous devrez peut-être actualiser l'onglet du navigateur pour voir les modifications.

Effectuer un nettoyage

Pour éviter d'encourir des frais inutiles liés à Google Cloud, supprimez les ressources utilisées dans ce guide lorsque vous n'en avez plus besoin. Vous pouvez supprimer ces ressources manuellement ou supprimer votre projet Google Cloud, ce qui supprime également toutes les ressources associées. En outre, vous pouvez supprimer les modifications apportées sur votre station de travail locale :

Station de travail locale

Vous devez mettre à jour les fichiers suivants pour supprimer les modifications apportées par les scripts d'installation.

  • Supprimez les adresses IP des VM Compute Engine ajoutées au fichier /etc/hosts.
  • Supprimez la configuration SSH de cnuc-* dans le fichier ~/.ssh/config.
  • Supprimez les empreintes des VM Compute Engine du fichier ~/.ssh/known_hosts.

Supprimer le projet

Si vous avez créé un projet dédié pour cette procédure, supprimez le projet Google Cloud de la console Google Cloud.

  • In the Google Cloud console, go to the Manage resources page.

    Go to Manage resources

  • In the project list, select the project that you want to delete, and then click Delete.
  • In the dialog, type the project ID, and then click Shut down to delete the project.

    • Manuel

    Si vous avez utilisé un projet existant pour cette procédure, procédez comme suit :

    • Annulez l'enregistrement de tous les clusters Kubernetes dont le nom commence par le préfixe cnuc-.
    • Supprimez toutes les VM Compute Engine dont le nom commence par le préfixe cnuc-.
    • Supprimez le bucket Cloud Storage dont le nom commence par le préfixe abm-edge-boot.
    • Supprimez les règles de pare-feu allow-pod-ingress et allow-pod-egress.
    • Supprimez le secret Secret Manager install-pub-key.

    Étape suivante

    Vous pouvez développer ce guide en ajoutant un autre emplacement périphérique. La définition de la variable d'environnement GCE_COUNT sur 6 et la réexécution des mêmes étapes que dans les sections précédentes créent trois nouvelles instances Compute Engine (cnuc-4, cnuc-5, cnuc-6) et un nouveau cluster autonome Google Distributed Cloud appelé cnuc-4.

    Vous pouvez également essayer de mettre à jour les configurations de cluster dans votre dépôt dupliqué pour appliquer de manière sélective différentes versions de l'application de point de vente aux deux clusters, cnuc-1 et cnuc-4, à l'aide de ClusterSelectors.

    Pour en savoir plus sur les étapes individuelles du présent guide ainsi que sur les scripts impliqués, consultez le dépôt anthos-samples.