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

Ce tutoriel présente une solution prête à l'emploi qui utilise des clusters Anthos sur solution Bare Metal et Anthos Config Management pour déployer des clusters Kubernetes à la périphérie du réseau à grande échelle. Ce tutoriel est destiné aux opérateurs et aux développeurs de plates-formes. Vous devez maîtriser les concepts et technologies suivants:

Dans ce tutoriel, vous utilisez 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 comme charge de travail de périphérie. Les clusters Anthos sur solution Bare Metal et Anthos Config Management permettent de centraliser la gestion et le contrôle de votre cluster périphérique. Anthos Config Management 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 en périphérie d'un magasin est un bon moyen d'illustrer l'architecture utilisée dans un déploiement classique d'Anthos sur solution Bare Metal.

Un magasin physique est le point d'interaction le plus proche entre une unité commerciale et le consommateur. Les systèmes logiciels au sein des magasins doivent exécuter leurs charges de travail, recevoir des mises à jour en temps opportun et générer des rapports sur les métriques critiques, indépendamment du système de gestion centralisée de l'entreprise. De plus, ces systèmes logiciels doivent être conçus de façon à pouvoir être étendus à davantage de magasins à l'avenir. Alors que les clusters Anthos sur solution Bare Metal répondent à toutes ces exigences pour les systèmes logiciels du stockage, le profil périphérique constitue 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 présente un déploiement de clusters Anthos sur solution Bare Metal qui utilise le profil périphérique dans un magasin de vente au détail:

Montre un déploiement d'clusters Anthos sur bare metal qui utilise le profil périphérique dans un magasin
Déploiement d'clusters Anthos sur bare metal dans un magasin

Le schéma précédent illustre un magasin de vente au détail classique. Le magasin dispose d'appareils connectés tels que des lecteurs de carte, des machines de point de vente, des appareils photo et des imprimantes. Le magasin dispose également de trois appareils matériels de calcul physiques (libellé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. Les clusters Anthos sur bare metal s'exécutent dans 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 de données entre eux pour la haute disponibilité.

Le schéma montre également les composants clés suivants qui font partie d'un déploiement de clusters Anthos sur bare metal:

  • Le composant marqué comme MetalLB est l'équilibreur de charge groupé déployé avec des clusters Anthos sur bare metal.
  • Le composant Anthos Config Management 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 d'Anthos Config Management et sur les différentes dénominations, consultez la documentation Anthos Config Management.

  • Le dépôt racine et le dépôt d'espace de noms indiqués en haut du diagramme 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 centrales. Les clusters Anthos sur bare metal déployés dans divers emplacements périphériques extraient des mises à jour des dépôts sources. Ce comportement est représenté par les flèches qui relient les deux dépôts du schéma aux composants Anthos Config Management dans le cluster Anthos sur solution Bare Metal s'exécutant dans les appareils.

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

  • Le composant marqué comme Application indique le logiciel déployé dans le cluster par la boutique. L'application de point de vente utilisée dans les kiosques d'un magasin pourrait être un exemple d'application de ce type.

Les cases au bas du schéma représentent les nombreux appareils (kiosques, tablettes ou appareils photo, par exemple) d'un magasin, qui sont tous connectés à un commutateur réseau central. La mise en réseau locale dans le magasin permet aux applications exécutées dans les clusters Anthos sur solution Bare Metal d'atteindre ces appareils.

Dans la section suivante, vous allez voir l'émulation de ce déploiement de magasins dans Google Cloud à l'aide de VM Compute Engine. Cette émulation est celle que vous utiliserez dans le tutoriel qui suit pour tester des clusters Anthos sur bare metal.

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

Le schéma suivant illustre tout ce que vous avez configuré dans Google Cloud dans ce tutoriel. Ce diagramme correspond au schéma de la section "Commerce de détail" 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 affiche également un exemple de charge de travail d'application de point de vente simple que vous utiliserez dans ce tutoriel. Vous accédez à l'application de point de vente à l'intérieur du cluster en utilisant un navigateur Web comme kiosque.

L'image montre l'architecture de l'application de point de vente et la façon dont elle est déployée dans un cluster Anthos sur solution Bare Metal s'exécutant sur des VM Compute Engine
Exemple d'application déployée dans un cluster Anthos sur solution Bare Metal

Les trois machines virtuelles (VM) Compute Engine du 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é à des commutateurs réseau pour constituer l'infrastructure dédiée. 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 dans le projet Google Cloud.

Dans une installation classique de clusters Anthos sur solution Bare Metal, vous pouvez configurer vos propres équilibreurs de charge. Toutefois, pour ce tutoriel, vous ne configurez pas d'équilibreur de charge externe. À la place, vous allez utiliser l'équilibreur de charge MetalLB groupé installé avec des clusters Anthos sur 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 VxLAN en superposition sur le réseau cloud privé virtuel (VPC) par défaut.

Les composants logiciels qui s'exécutent dans les trois VM Compute Engine sont présentés dans le rectangle intitulé "L2overlay network (VxLAN). Ce rectangle inclut le cluster Anthos sur solution Bare Metal et un proxy inverse. Le cluster est représenté par le rectangle "Clusters Anthos sur bare metal". Ce rectangle représentant le cluster inclut un autre rectangle appelé "Kubernetes namespace (pos)". Cela 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 Anthos. L'application de point de vente dispose de trois microservices: le serveur d'API, l'inventaire et les paiements. Tous ces composants représentent une "application" illustrée dans le schéma d'architecture de déploiement Edge précédent.

L'équilibreur de charge MetalLB groupé du cluster Anthos est inaccessible depuis l'extérieur des VM. Le schéma montre un proxy inverse NGINX configuré pour s'exécuter à l'intérieur des VM afin d'acheminer le trafic entrant vers 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, 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, cela peut être effectué avec une configuration réseau appropriée.

Objectifs

  1. Utilisez les VM Compute Engine pour émuler une infrastructure bare metal exécutée dans un emplacement périphérique.
  2. Créer un cluster Anthos sur solution Bare Metal dans l'infrastructure périphérique é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 Anthos
  5. Utilisez la console Google Cloud pour valider et surveiller l'application de point de vente qui opère dans l'emplacement périphérique.
  6. Utilisez Anthos Config Management pour mettre à jour l'application de point de vente qui s'exécute sur le cluster Anthos.

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 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 conformément aux attentes d'Anthos Config Management. Clonez ce dépôt vers 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 d'Anthos Config Management. Cette étape est nécessaire pour que les composants Anthos Config Management du cluster s'authentifient 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 une utilisation ultérieure.

  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 Fork (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 est le 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 Edge décrit dans ce document, vous avez besoin d'un poste de travail ayant accès à Internet et des outils suivants:

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 du nouveau compte de service sur <REPO_ROOT>/anthos-bm-edge-deployment/build-artifacts/consumer-edge-gsa.json. Elle configure également le trousseau Cloud Key Management Service et la clé de chiffrement de clé privée SSH.

    ./scripts/create-primary-gsa.sh

    Une partie du script est visible ci-dessous. Cliquez sur le lien View on GitHub pour afficher l'intégralité du 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
# ...

Provisionner les instances Compute Engine

Dans cette section, vous allez créer les VM Compute Engine sur lesquelles les clusters Anthos sur solution Bare Metal seront installés. Vous devez é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. Chiffrez 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, puis générez-le. Après avoir créé le fichier .envrc, vérifiez que les variables d'environnement ont été remplacées par les bonnes valeurs.

    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:

    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. Créez des instances Compute Engine sur lesquelles des clusters Anthos sur solution Bare Metal sont installés.

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

Installer des clusters Anthos sur bare metal avec Ansible

Le script utilisé dans ce guide crée des clusters Anthos sur solution 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 Anthos sur bare metal 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 des instances Compute Engine 3 sera créé. Les instances de VM sont nommées avec le préfixe cnuc- suivi d'un nombre. La première instance de VM de chaque cluster sert de poste de travail administrateur à partir duquel 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 les clusters Anthos sur bare metal dans les instances Compute Engine configurées.
  • Il crée un cluster autonome Anthos sur solution Bare Metal appelé cnuc-1.
  • Il enregistre le cluster cnuc-1 à l'aide de Google Cloud.
  • Il installe Anthos Config Management dans le cluster cnuc-1.
  • Il configure Anthos Config Management pour se synchroniser avec les configurations de cluster situées dans anthos-bm-edge-deployment/acm-config-sink dans votre dépôt dupliqué.
  • Génère la valeur Login token pour le cluster.

Pour configurer et démarrer l'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 requis pour le 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 produit le résultat suivant:

    ...
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 lance 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 montage de volume dans le répertoire de travail actuel. Une fois ce script terminé, vous devez vous trouver dans le conteneur Docker créé. Vous allez déclencher l'installation d'Ansible depuis ce conteneur.

    ./install.sh

    Lorsque le script s'exécute correctement, il génère le résultat suivant:

    ...
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 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 le résultat suivant:

    ...
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 des clusters Anthos sur solution Bare Metal 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

    Une fois l'installation réussie, vous obtenez 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 aux clusters Anthos sur bare metal dans la console Google Cloud

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

  1. Copiez le jeton à partir du résultat du playbook Ansible présenté 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 Config Management pour vérifier l'état des spécifications de configuration. Vérifiez que l'état est Synchronisé. Un état Synchronisé indique qu'Anthos Config Management a synchronisé vos configurations GitHub avec votre cluster cnuc-1 déployé.

    Accéder à la page Config Management

    Synchronisation d'Anthos Config Management avec le dépôt source.

Configurer un proxy pour le trafic externe

Le cluster Anthos sur solution Bare Metal installé à l'étape précédente utilise un équilibreur de charge groupé nommé MetalLB. Ce service d'équilibreur de charge n'est accessible que 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 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 dans les hôtes d'administration avec un exemple de fichier de configuration. Mettez à jour ce fichier pour utiliser l'adresse IP du service d'équilibrage de charge, puis 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 d'é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 signaler l'état "actif (en cours)":

    sudo systemctl status nginx

    Lorsque NGINX s'exécute correctement, il génère une sortie 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 sur le poste de travail administrateur:

    exit

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

    exit

Accéder à l'application de point de vente

La configuration du proxy externe vous permet d'accéder à l'application exécutée dans le cluster Anthos. 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 administrateur 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 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 l'exemple de capture d'écran suivant:

    Version 1 de l'application de point de vente déployée.

Utiliser Anthos Config Management 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. Anthos Config Management détecte les mises à jour et apporte 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'exemple d'application de point de vente peut passer à 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 faire passer la version du serveur d'API de v1 à v2. La configuration YAML du déploiement se trouve dans le fichier à l'emplacement 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. Ajoutez, validez et transférez 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 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 dans le titre affiche "V2", ce qui indique que votre modification d'application a été déployée, comme illustré dans l'exemple de capture d'écran suivant:

    Version 2 de l'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.

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.

    • 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. Si vous définissez la variable d'environnement GCE_COUNT sur 6 et réexécutez les étapes des sections précédentes, vous créez trois instances Compute Engine (cnuc-4, cnuc-5, cnuc-6) et un cluster Anthos sur solution Bare Metal nommé 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.