Déployer des clusters en périphérie à grande échelle avec Anthos sur solution Bare Metal

Cet article présente une solution avancée et prête à l'emploi pour les opérateurs et développeurs de plates-formes qui exploitent Anthos sur solution Bare Metal et Anthos Config Management pour déployer des clusters Kubernetes en périphérie à grande échelle. Pour les besoins de ce guide, nous partons du principe que vous connaissez les éléments suivants :

  • Playbooks Ansible
  • Déploiements en périphérie et défis associés
  • Utilisation d'un projet Google Cloud
  • Interfaces de ligne de commande gcloud et kubectl

Le code source de l'application qui constitue la charge de travail de périphérie et les scripts permettant de configurer l'infrastructure Bare Metal sont disponibles dans le dépôt GitHub anthos-edge-usecases. Les scripts vous permettent de répliquer ce déploiement et de le personnaliser en fonction de vos besoins.

À propos des déploiements en périphérie

L'une des caractéristiques clés de l'exploitation à grande échelle est de disposer d'un plan de gestion centralisé pour toutes les parties de la plate-forme. Les entreprises qui se développent au-delà des centres de données traditionnels dans des emplacements périphériques ont toutefois des exigences uniques. Les déploiements en périphérie doivent exécuter leurs charges de travail de manière isolée, recevoir des mises à jour au plus vite, signaler des métriques critiques et être conçus pour permettre l'expansion à d'autres emplacements périphériques à l'avenir. Anthos sur solution Bare Metal est la réponse de Google pour ces exigences de déploiement en périphérie à grande échelle.

À partir de la version 1.8, les clusters Anthos sur solution Bare Metal sont dotés d'un profil de périphérie. Celui-ci minimise les besoins en ressources système et est recommandé pour les appareils de périphérie présentant de contraintes importantes. Le profil de périphérie n'est disponible que pour les clusters autonomes. Les clusters autonomes sont des clusters autogérés qui exécutent des charges de travail. Ils ne gèrent pas d'autres clusters, ce qui élimine le besoin d'exécuter un cluster d'administrateur distinct dans les scénarios à ressources limitées. Le profil de périphérie fournit des exigences minimales pour les processeurs virtuels et la mémoire RAM, à l'exception des charges de travail de l'utilisateur. Le profil de périphérie Anthos sur solution Bare Metal offre les avantages suivants :

  • Réduction de 75 % des besoins en processeur à 1 nœud x 2 processeurs virtuels au lieu de 2 nœuds x 4 processeurs virtuels.
  • Réduction de 90 % des besoins en mémoire à 1 nœud x 4 Gio au lieu de 2 nœuds x 32 Gio pour Ubuntu.

Pour en savoir plus sur la configuration d'un cluster avec le profil de périphérie, consultez la page Créer des clusters autonomes. Le tableau suivant montre comment la configuration système minimale requise pour Anthos sur solution Bare Metal a été réduite pour offrir un encombrement minimal compatible avec les appareils de périphérie.

Anthos 1.7 Anthos 1.8 et versions ultérieures Anthos 1.8 et versions ultérieures avec le profil de périphérie
Processeur 2 nœuds x (4 processeurs virtuels) 1 nœud x (4 processeurs virtuels) 1 nœud x (2 processeurs virtuels)
RAM 2 nœuds x (32 Gio de RAM) 1 nœud x (16 Gio de RAM) 1 nœud x (4 Gio de RAM Ubuntu)
1 nœud x (6 Gio de RAM RHEL/CentOS)
Stockage 2 nœuds x (128 Gio) 1 nœud x (128 Gio) 1 nœud x (128 Gio)

Dans les sections suivantes, vous allez utiliser des VM Compute Engine et un exemple d'application de point de vente en tant que charge de travail de périphérie pour émuler des nœuds déployés en périphérie. Les clusters Anthos sur solution Bare Metal et Anthos Config Management fournissent une gestion et un contrôle centralisés pour votre cluster de périphérie. Anthos Config Management extrait de manière dynamique de nouvelles configurations de GitHub, et applique ces règles et configurations à vos clusters.

Schéma de l'architecture d'un déploiement en périphérie

Le schéma suivant présente l'architecture d'un déploiement en périphérie, en montrant comment l'application est exécutée sur Anthos sur solution Bare Metal et gérée par Anthos Config Management. Dans le schéma, ABM fait référence à Anthos sur solution Bare Metal et ACM fait référence à Anthos Config Management.

Explique comment l'application est exécutée sur Anthos sur solution Bare Metal et gérée par Anthos Config Management
Architecture d'un déploiement en périphérie Anthos sur solution Bare Metal gérée par Anthos Config Management

Schéma de l'architecture d'une charge de travail en périphérie

Le schéma suivant illustre l'architecture de la charge de travail d'une application de point de vente simple que nous utilisons dans ce guide. Il décrit également comment l'application est déployée dans des clusters Anthos sur solution Bare Metal dans un emplacement périphérique émulé. Les VM Compute Engine sont semblables aux nœuds qui s'exécutent en périphérie.

Architecture et déploiement de l'application de point de vente.
Architecture de l'application de point de vente (cliquez sur l'image pour l'agrandir)

Workflow de la solution

Dans cette solution, nous allons effectuer les opérations suivantes :

  • Émuler une infrastructure Bare Metal exécutée dans un emplacement périphérique à l'aide de VM Compute Engine
  • Déployer un cluster Anthos sur solution Bare Metal sur l'infrastructure périphérique émulée
  • Connecter et enregistrer le cluster Anthos sur solution Bare Metal avec Google Cloud
  • Déployer un exemple de charge de travail d'application de point de vente sur le cluster Anthos sur solution Bare Metal
  • Vérifier et surveiller l'application exécutée en périphérie via Cloud Console
  • Utiliser Anthos Config Management pour mettre à jour l'application exécutée sur le cluster Anthos sur solution Bare Metal

Ce guide peut prendre 55 à 60 minutes si vous avez déjà configuré tous les prérequis (répertoriés dans la section Avant de commencer ci-après).

Avant de commencer

Pour effectuer le déploiement en périphérie décrit dans ce guide, vous devez disposer des éléments suivants :

Configurer l'environnement de la station de travail

  1. Dupliquez le dépôt anthos-edge-usecases pour créer votre propre copie du code source pour cette solution de déploiement en périphérie. Pour obtenir plus d'informations sur la duplication, y compris des instructions permettant de dupliquer un dépôt, consultez la page Dupliquer un dépôt.

  2. Créez un jeton d'accès personnel pour votre dépôt dupliqué, comme décrit dans la documentation GitHub Créer un jeton d'accès personnel.

    • Sélectionnez uniquement le niveau d'accès public_repo.
    • Enregistrez le jeton d'accès que vous avez créé dans un endroit sûr, car vous en aurez besoin ultérieurement.
  3. Clonez votre dépôt dupliqué sur votre station de travail.

    git clone https://github.com/GITHUB_USERNAME/anthos-edge-usecases
    cd anthos-edge-usecases/anthos-baremetal-edge-deployment
    
    • Remplacez GITHUB_USERNAME par votre nom d'utilisateur GitHub.
  4. 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"
    
    # path to which the Google Service Account key file is downloaded to
    export LOCAL_GSA_FILE="$(pwd)/remote-gsa-key.json"
    
    # port on the admin Compute Engine instance we use to set up an nginx proxy to allow traffic into the Anthos on bare metal cluster
    export PROXY_PORT="8082"
    
    # should be a multiple of 3 since N/3 clusters are created with each having 3 nodes
    export MACHINE_COUNT="3"
    
    # url to the fork of: https://github.com/GoogleCloudPlatform/anthos-edge-usecases
    export ROOT_REPO_URL="https://github.com/GITHUB_USERNAME/anthos-edge-usecases"
    
    # 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"
    
    • 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.
  5. Initialisez le SDK Cloud.

    gcloud config set project "${PROJECT_ID}"
    gcloud services enable compute.googleapis.com
    
    gcloud config set compute/region "${REGION}"
    gcloud config set compute/zone "${ZONE}"
    
  6. Créez le compte de service Google Cloud utilisé par les instances Compute Engine.

    # when prompted "Create a new key for GSA? [y/n]" type "y" and press the return key
    # the service account key file is downloaded to the path referred to by $LOCAL_GSA_FILE
    ./scripts/create-primary-gsa.sh
    

Provisionner les instances Compute Engine

  1. Créez des clés SSH et des instances Compute Engine sur lesquelles Anthos sur solution Bare Metal est installé.

    # press the return key when asked for a passphrase for the SSH key (i.e. empty string)
    ./scripts/cloud/easy-install.sh
    
  2. Testez la connectivité SSH aux instances Compute Engine.

    # If the checks fail the first time with errors like
    # "sh: connect to host cnuc-1 port 22: Connection refused",
    # then wait a few seconds and retry
    for i in `seq $MACHINE_COUNT`; do
        HOSTNAME="cnuc-$i"
        ssh abm-admin@${HOSTNAME} 'ping -c 3 google.com'
    done
    

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

    PING google.com (74.125.124.113) 56(84) bytes of data.
    64 bytes from jp-in-f113.1e100.net (74.125.124.113): icmp_seq=1 ttl=115 time=1.10 ms
    64 bytes from jp-in-f113.1e100.net (74.125.124.113): icmp_seq=2 ttl=115 time=1.10 ms
    64 bytes from jp-in-f113.1e100.net (74.125.124.113): icmp_seq=3 ttl=115 time=0.886 ms
    
    --- google.com ping statistics ---
    3 packets transmitted, 3 received, 0% packet loss, time 2003ms
    rtt min/avg/max/mdev = 0.886/1.028/1.102/0.100 ms
    PING google.com (108.177.112.139) 56(84) bytes of data.
    ...
    ...
    

Installer Anthos sur solution 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. Par exemple, vous définissez la variable d'environnement MACHINE_COUNT sur 6 pour créer deux clusters Anthos sur solution Bare Metal comportant chacun trois instances. Le nom des instances doit commencer par le préfixe cnuc-, suivi d'un numéro. La première instance de chaque cluster agit en tant qu'instance d'administration à partir de laquelle l'installation d'Anthos sur solution Bare Metal est déclenchée. Les clusters d'utilisateur Anthos sur solution Bare Metal tiennent également leur nom de ces instances d'administration (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 Anthos sur solution Bare Metal sur les instances Compute Engine configurées.
  • Il crée un cluster d'utilisateur 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-baremetal-edge-deployment/acm-config-sink dans votre dépôt dupliqué.

Suivez ces étapes pour configurer et lancer le processus d'installation.

  1. Générez le fichier d'inventaire Ansible à partir du modèle.

    # replace environment variables in the template
    envsubst < templates/inventory-cloud-example.yaml > inventory/gcp.yaml
    
  2. Vérifiez la configuration de la station de travail et l'accès aux hôtes Compute Engine.

    # verify workstation environment setup
    ./scripts/verify-pre-installation.sh
    
    # verify access to hosts
    ./scripts/health-check.sh
    

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

    Proceed!!
    
    cnuc-1 | SUCCESS => {"ansible_facts": {"discovered_interpreter_python": "/usr/bin/python3"},"changed": false,"ping": "pong"}
    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"}
    
    SUCCESS!!
    
  3. Exécutez le playbook Ansible pour installer Anthos sur solution Bare Metal sur des instances Compute Engine.

    ansible-playbook -i inventory cloud-full-install.yml
    

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

    ...
    ...
    PLAY RECAP ********************************************************************************************************
    cnuc-1                     : ok=136  changed=106  unreachable=0    failed=0    skipped=33   rescued=0    ignored=8
    cnuc-2                     : ok=86   changed=67   unreachable=0    failed=0    skipped=71   rescued=0    ignored=2
    cnuc-3                     : ok=86   changed=67   unreachable=0    failed=0    skipped=71   rescued=0    ignored=2
    

Se connecter au cluster Anthos sur solution Bare Metal dans Cloud Console

  1. Pour copier le script utilitaire dans l'instance d'administration Compute Engine et générer un jeton de compte de service Kubernetes, exécutez les scripts et les commandes suivants.

    # Copy the utility script into the admin node of the cluster
    scp -i ~/.ssh/cnucs-cloud scripts/cloud/cnuc-k8s-login-setup.sh abm-admin@cnuc-1:
    
    # Use SSH to connect to the admin node of the cluster
    ssh -i ~/.ssh/cnucs-cloud abm-admin@cnuc-1
    
    # execute the script and copy token that is printed out
    ./cnuc-k8s-login-setup.sh
    

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

    ...
    ...
    💡 Retrieving Kubernetes Service Account Token
    
    🚀 ------------------------------TOKEN-------------------------------- 🚀
    eyJhbGciOiJSUzI1NiIsImtpZCI6Imk2X3duZ3BzckQyWmszb09sZHFMN0FoWU9mV1kzOWNGZzMyb0x2WlMyalkifQ.eyJpc3MiOiJrdW
    mljZS1hY2NvdW50LnVpZCI6IjQwYWQxNDk2LWM2MzEtNDhiNi05YmUxLWY5YzgwODJjYzgzOSIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYW
    iZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6ImVkZ2Etc2EtdG9rZW4tc2R4MmQiLCJrdWJlcm5ldGVzLmlvL3Nl
    cnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoiZWRnYS1zYSIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2Vyd
    4CwanGlof6s-fbu8IUy1_bTgCminylNKb3VudC5uYW1lIjoiZWRnYS1zYSIsImt1YmVybmV0ZXuaP-hDEKURb5O6IxulTXWH6dxYxg66x
    Njb3VudDpkZWZhdWx0OmVkZ2Etc2EifQ.IXqXwX5pg9RIyNHJZTM6cBKTEWOMfQ4IQQa398f0qwuYlSe12CA1l6P8TInf0S1aood7NJWx
    xe-5ojRvcG8pdOuINq2yHyQ5hM7K7R4h2qRwUznRwuzOp_eXC0z0Yg7VVXCkaqnUR1_NzK7qSu4LJcuLzkCYkFdSnvKIQABHSvfvZMrJP
    Jlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3V
    MgyLOd9FJyhZgjbf-a-3cbDci5YABEzioJlHVnV8GOX_q-MnIagA9-t1KpHA
    🚀 ------------------------------------------------------------------- 🚀
    
  2. Copiez le jeton à partir de la sortie.

  3. Dans Cloud Console, 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).
  4. Dans Cloud Console, 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&#39;Anthos Config Management avec le dépôt source.

Configurer un proxy pour le trafic externe

Le produit Anthos sur solution Bare Metal 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). Nous avons donc configuré un service de proxy inverse dans l'hôte administrateur (cnuc-1) pour acheminer le trafic entrant vers l'équilibreur de charge groupé via son adresse IP externe. Cela nous 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 auraient déjà installé nginx sur les hôtes administrateur, avec un exemple de fichier de configuration. Nous mettons à jour ce fichier pour utiliser l'adresse IP du service d'équilibrage de charge et redémarrer nginx.

  1. Configurez le proxy inverse nginx pour qu'il achemine le trafic vers le service d'équilibrage de charge du serveur d'API.

    # get the IP address of the Load balancer type Kubernetes service
    ABM_INTERNAL_IP=$(kubectl get services api-server-lb -n pos | awk '{print $4}' | tail -n 1)
    
    # update the template configuration file with the fetched IP address
    sudo sh -c "sed 's/<K8_LB_IP>/${ABM_INTERNAL_IP}/g' /etc/nginx/nginx.conf.template > /etc/nginx/nginx.conf"
    
    # restart nginx to ensure the new configuration is picked up
    sudo systemctl restart nginx
    
    # check and verify the status of the nginx server to be "active (running)"
    sudo systemctl status nginx
    

    Lorsque les scripts s'exécutent correctement, ils génèrent un résultat semblable au 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: ....
                ...
                ...
    
  2. Quittez la session SSH dans l'instance d'administration.

    exit
    

Accéder à l'application de point de vente

Vous exécutez les commandes suivantes sur votre station de travail locale.

  1. Obtenez l'adresse IP externe de l'instance d'administration Compute Engine et accédez à l'UI 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
    
    Version 1 de l&#39;application de point de vente déployée.

Mettre à jour la version du serveur d'API et observer l'évolution

  1. 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-baremetal-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. 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 Cloud Console, 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 Cloud Console, accédez à la page Charges de travail Kubernetes Engine pour vérifier que le déploiement est 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.

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

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

  • Dans Cloud Console, 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. La définition de la variable d'environnement MACHINE_COUNT sur 6 et la réexécution des mêmes étapes que dans les sections précédentes créent trois instances Compute Engine (cnuc-4, cnuc-5, cnuc-6) et un cluster d'utilisateur Anthos sur solution Bare Metal 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 de ce guide, les scripts impliqués et la mise en œuvre de l'application de point de vente, consultez le dépôt anthos-edge-usecases.