Déployer des clusters GKE sur Bare Metal en périphérie

Ce tutoriel présente une solution prête à l'emploi qui utilise GKE sur Bare Metal et Config Sync pour déployer des clusters Kubernetes en périphérie à grande échelle. Ce tutoriel est destiné aux opérateurs de plate-forme et aux développeurs. Vous devez 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, ainsi qu'un exemple d'application de point de vente en tant que charge de travail périphérique. GKE sur Bare Metal et Config Sync fournissent une gestion et un contrôle centralisés pour votre cluster périphérique. Config Sync extrait de manière dynamique les nouvelles configurations de GitHub et applique ces règles et configurations à vos clusters.

Architecture de déploiement en périphérie

Un déploiement en périphérie du retail est un bon moyen d'illustrer l'architecture utilisée dans un déploiement GKE sur une solution Bare Metal 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 à l'intérieur des magasins doivent exécuter leurs charges de travail, recevoir des mises à jour ponctuelles et générer des rapports sur les métriques critiques indépendamment 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 GKE sur Bare Metal répond à toutes ces exigences pour les systèmes logiciels de magasin, le profil périphérique offre un cas d'utilisation important: les déploiements dans des environnements avec des ressources matérielles limitées, comme une vitrine de magasin.

Le schéma suivant illustre un déploiement GKE sur une solution Bare Metal qui utilise le profil périphérique dans un magasin:

Déploiement de GKE sur Bare Metal qui utilise le profil périphérique d'un magasin

Le schéma précédent illustre un magasin physique classique. Le magasin dispose d'appareils intelligents tels que des lecteurs de cartes, des points de vente, des appareils photo et des imprimantes. Le magasin dispose également de trois matériels informatiques physiques (identifié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 les uns aux autres via un réseau de couche 2. Les appareils informatiques mis en réseau constituent l'infrastructure Bare Metal. GKE sur Bare Metal s'exécute dans chacun des trois appareils de calcul. 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 GKE sur Bare Metal:

  • Le composant indiqué comme MetalLB est l'équilibreur de charge groupé déployé avec GKE sur une solution Bare Metal.
  • 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 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 nomsenclatures, consultez la documentation de Config Sync.

  • Le dépôt racine et le dépôt d'espace de noms affichés en haut du diagramme en dehors 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 centralisés. Les déploiements GKE sur Bare Metal dans différents emplacements périphériques extraient les mises à jour 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 situés dans le cluster GKE sur bare metal exécuté sur les appareils.

  • Un autre composant clé présenté dans le cluster est l'environnement d'exécution de VM sur GDC. L'environnement d'exécution de VM sur GDC permet d'exécuter des charges de travail existantes basées sur des VM dans le cluster sans nécessiter 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 indiqué comme Application désigne le logiciel déployé dans le cluster par le magasin. C'est le cas, par exemple, de l'application de point de vente utilisée dans les kiosques d'un magasin de détail.

Les cases au bas du schéma représentent les nombreux appareils d'un magasin (comme les kiosques, les tablettes ou les caméras), qui sont tous connectés à un commutateur réseau central. Le réseau local à l'intérieur du magasin permet aux applications exécutées dans le déploiement GKE sur Bare Metal d'atteindre ces appareils.

Dans la section suivante, vous allez voir l'émulation de ce déploiement en magasin dans Google Cloud à l'aide de VM Compute Engine. Cette émulation est celle que vous utiliserez dans le tutoriel qui suit pour tester GKE sur une solution Bare Metal.

Déploiement en périphérie émulé dans Google Cloud

Le schéma suivant représente tout ce que vous allez configurer dans Google Cloud dans ce tutoriel. Ce diagramme correspond au diagramme du magasin de la section précédente. Ce déploiement représente un emplacement périphérique émulé dans lequel l'application de point de vente est déployée. L'architecture présente également un exemple de charge de travail d'application de point de vente simple que vous utilisez dans ce tutoriel. Accédez à l'application de point de vente dans le cluster en utilisant un navigateur Web en tant que kiosque.

Architecture de l'application de point de vente et déploiement dans un cluster GKE sur bare metal exécuté sur des VM Compute Engine

Les trois machines virtuelles (VM) Compute Engine présentées dans le schéma précédent représentent le matériel physique (ou les nœuds) dans un emplacement périphérique typique. Ce matériel serait connecté aux commutateurs réseau pour constituer l'infrastructure nue. Dans notre environnement émulé dans Google Cloud, ces VM sont connectées les unes aux autres via le réseau cloud privé virtuel (VPC) par défaut du projet Google Cloud.

Dans une installation GKE sur Bare Metal, vous pouvez configurer vos propres équilibreurs de charge. Toutefois, pour ce tutoriel, vous ne configurez pas d'équilibreur de charge externe. Utilisez plutôt l'équilibreur de charge MetalLB groupé qui est installé avec GKE sur une solution Bare Metal. L'équilibreur de charge MetalLB groupé nécessite une connectivité réseau de couche 2 entre les nœuds. Ainsi, la connectivité de couche 2 entre les VM Compute Engine est activée en créant un réseau superposé VxLAN au-dessus du réseau cloud privé virtuel (VPC) par défaut.

Les composants logiciels qui s'exécutent dans les trois VM Compute Engine sont affichés dans le rectangle intitulé L2overlay network (VxLAN) (Réseau en superposition L2 (VxLAN)). Ce rectangle inclut le cluster GKE sur Bare Metal et un proxy inverse. Le cluster est représenté par le rectangle GKE sur une solution Bare Metal. Ce rectangle représentant le cluster comprend un autre rectangle marqué "Kubernetesnamespace (pos)" (Espace de noms Kubernetes (pos)). Il s'agit d'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 GKE sur solution Bare Metal. L'application de point de vente comporte trois microservices: Serveur d'API, Inventaire et Paiements. Tous ces composants représentent ensemble une "application" illustrée dans le schéma précédent de l'architecture du déploiement Edge.

L'équilibreur de charge MetalLB du cluster GKE sur Bare Metal n'est pas accessible directement 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 des VM Compute Engine vers l'équilibreur de charge. Il s'agit uniquement d'une solution de contournement pour les besoins de ce tutoriel, où les nœuds périphériques sont émulés à l'aide de VM Google Cloud Compute Engine. Dans un emplacement périphérique réel, cette opération peut être effectuée avec une configuration réseau appropriée.

Objectifs

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

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 initialize la Google Cloud CLI.

Dupliquer et cloner 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 en fonction des attentes de Config Sync. Clonez ce dépôt vers votre propre compte GitHub avant de passer aux é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 opération est nécessaire pour que les composants Config Sync du cluster puissent s'authentifier avec votre compte GitHub lors de la tentative de synchronisation des 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 le ré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 devez disposer d'un poste de travail ayant accès à Internet et des outils suivants installés:

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

  1. Sur votre poste de travail, initialisez les variables d'environnement dans une nouvelle instance de 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"

    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. Ils sont expliqués 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'emplacement <REPO_ROOT>/anthos-bm-edge-deployment/build-artifacts/consumer-edge-gsa.json. Elle configure également le trousseau de clés et la clé Cloud Key Management Service pour le chiffrement de clé privée SSH.

    ./scripts/create-primary-gsa.sh

    L'exemple suivant ne constitue 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 GKE sur Bare Metal sera installé. Vous allez également vérifier la connectivité à 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 utilisez-le comme source. 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éer des instances Compute Engine dans lesquelles GKE sur Bare Metal est installé

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

Installer GKE sur une solution Bare Metal avec Ansible

Le script utilisé dans ce guide crée des clusters GKE sur Bare Metal 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 GKE sur Bare Metal comportant chacun des instances de VM 3. Par défaut, la variable d'environnement GCE_COUNT est définie sur 3. Ainsi, dans ce guide, un cluster sera créé avec 3 instances Compute Engine. Les instances de VM sont nommées avec le préfixe cnuc- suivi d'un numéro. La première instance de VM de chaque cluster sert de poste de travail administrateur à partir de laquelle l'installation est déclenchée. Le cluster porte également le même nom que la VM du poste de travail administrateur (par exemple, cnuc-1, cnuc-4, cnuc-7).

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 GKE sur Bare Metal dans les instances Compute Engine configurées.
  • crée un cluster GKE sur solution Bare Metal autonome 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 qu'il se synchronise avec les configurations de cluster situées dans anthos-bm-edge-deployment/acm-config-sink dans votre dépôt dupliqué.
  • Il génère le Login token pour le cluster.

Pour configurer et démarrer 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 Docker en interne pour générer le conteneur avec un volume installé dans le répertoire de travail actuel. Une fois l'exécution de ce script terminée, vous devez vous trouver dans le conteneur Docker qui a été créé. Vous déclenchez l'installation d'Ansible depuis 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. Depuis l'intérieur du 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. Depuis le conteneur Docker, exécutez le playbook Ansible pour installer GKE sur des instances Bare Metal sur Compute Engine. Une fois l'opération terminée, le fichier Login Token du cluster s'affiche à l'écran.

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

    Une fois l'installation exécutée, le résultat suivant s'affiche:

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

Connectez-vous au cluster GKE sur Bare Metal dans la console Google Cloud

Une fois le playbook Ansible exécuté jusqu'à la fin, un cluster GKE sur solution Bare Metal autonome est installé dans les VM Compute Engine. Ce cluster est également enregistré dans Google Cloud à l'aide de Connect Agent. Toutefois, pour afficher les détails de ce cluster, vous devez vous y connecter à partir de la console Google Cloud. Pour vous connecter au cluster GKE, procédez comme suit.

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

  2. Dans la console Google Cloud, accédez à la page 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 dans la section Fonctionnalités.

    Accéder à Config

    4. Dans l'onglet Packages, consultez la colonne État de synchronisation dans la table des clusters. Vérifiez que l'état est Synchronisé. L'état Synced (Synchronisé) indique que Config Sync a bien synchronisé vos configurations GitHub avec votre cluster déployé, cnuc-1.

Configurer un proxy pour le trafic externe

Le cluster GKE sur Bare Metal installé aux étapes précédentes utilise un équilibreur de charge groupé appelé MetalLB. Ce service d'équilibrage de charge est accessible uniquement via 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'atteindre le 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 de l'administrateur, ainsi qu'un exemple de fichier de configuration. Mettez à jour ce fichier pour utiliser l'adresse IP du service d'équilibrage de charge et redémarrez 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 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 Équilibreur 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 l'état du serveur NGINX pour indiquer "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 et accédez au poste de travail administrateur:

    exit

  7. Quittez la session de shell et accédez au conteneur Docker. Lorsque vous quittez l'instance d'administrateur, vous vous trouvez 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 s'exécutant 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 Compute Engine d'administrateur 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 indiqué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'application de point de vente déployée

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

Vous pouvez mettre à niveau l'exemple d'application vers une version plus récente en mettant à jour les fichiers de configuration dans le dépôt racine. Config Sync détecte les mises à jour et effectue automatiquement les modifications dans 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 savoir comment l'exemple d'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 pour le déploiement se trouve dans le fichier à l'emplacement 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 déployez les modifications dans 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 Management pour vérifier l'état des spécifications de configuration. Vérifiez que l'état est Synchronisé.

    Accéder à la page Config Management

  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 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 figurant dans le 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'application de point de vente déployée

    Vous devrez peut-être effectuer une actualisation forcée de 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.

Suppression du projet

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

  • Dans la console Google Cloud, accédez à la page Gérer les ressources.

    Accéder à la page Gérer les ressources

  • Dans la liste des projets, sélectionnez le projet que vous souhaitez supprimer, puis cliquez sur Supprimer.
  • Dans la boîte de dialogue, saisissez l'ID du projet, puis cliquez sur Arrêter pour supprimer le projet.

    • Mode 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. Définissez la variable d'environnement GCE_COUNT sur 6 et répétez les étapes décrites dans les sections précédentes pour créer trois instances Compute Engine (cnuc-4, cnuc-5, cnuc-6) et un nouveau cluster GKE sur bare metal autonome 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.