Aperçu

À terme, de nombreuses applications devront être distribuées et disposer de services s'exécutant sur plusieurs clusters Anthos. Anthos Service Mesh permet cela, avec les réseaux maillés multiclusters.

Un maillage de services multicluster est un maillage composé de services qui s'exécutent sur plusieurs clusters.

L'avantage du maillage de services multicluster est que tous les services sont semblables pour les clients, quel que soit l'endroit où les charges de travail s'exécutent réellement. Le fait qu'un service soit déployé dans un maillage de services unique ou multicluster est transparent pour l'application.

Dans cet atelier, vous allez créer un maillage de services englobant deux clusters, west et east. Vous déploierez une application composée de services, certains fonctionnant sur le cluster west et d'autres sur le cluster east. Vous testerez l'application pour vous assurer que les services peuvent communiquer entre les clusters sans problème.

Objectifs

Cet atelier va vous apprendre à effectuer les tâches suivantes :

• Installer et configurer un réseau maillé multicluster

• Déployer et utiliser l'exemple d'application Online Boutique dans plusieurs configurations

  • Examiner les déploiements dans chaque cluster
  • Comprendre le flux de service à service entre clusters
  • Migrer des charges de travail d'un cluster vers un autre

Tâche 1. Mettre en place l'atelier

Dans cette tâche, vous allez utiliser Qwiklabs pour procéder à l'initialisation de votre atelier.

Accéder à Qwiklabs

Pour chaque atelier, nous vous attribuons un nouveau projet Google Cloud et un nouvel ensemble de ressources pour une durée déterminée, sans frais.

1. Connectez-vous à Qwiklabs dans une fenêtre de navigation privée.

2. Vérifiez le temps imparti pour l'atelier (par exemple : 01:15:00) : vous devez pouvoir le terminer dans ce délai.
   Une fois l'atelier lancé, vous ne pouvez pas le mettre en pause. Si nécessaire, vous pourrez le redémarrer, mais vous devrez tout reprendre depuis le début.

3. Lorsque vous êtes prêt, cliquez sur Démarrer l'atelier.

4. Notez vos identifiants pour l'atelier (Nom d'utilisateur et Mot de passe). Ils vous serviront à vous connecter à Google Cloud Console.

5. Cliquez sur Ouvrir la console Google.

6. Cliquez sur Utiliser un autre compte, puis copiez-collez les identifiants de cet atelier lorsque vous y êtes invité.
   Si vous utilisez d'autres identifiants, des messages d'erreur s'afficheront ou des frais seront appliqués.

7. Acceptez les conditions d'utilisation et ignorez la page concernant les ressources de récupération des données.

Une fois la connexion initiale effectuée, le tableau de bord du projet s'affiche.

Cliquez sur Select a project (Sélectionner un projet), puis sur l'ID de votre projet GCP. Enfin, cliquez sur OPEN (Ouvrir).

Activer Google Cloud Shell

Google Cloud Shell est une machine virtuelle qui contient de nombreux outils pour les développeurs. Elle comprend un répertoire d'accueil persistant de 5 Go et s'exécute sur Google Cloud.

Google Cloud Shell vous permet d'accéder à vos ressources Google Cloud grâce à une ligne de commande.

1. Dans la barre d'outils située en haut à droite dans la console Cloud, cliquez sur le bouton "Ouvrir Cloud Shell".

   

2. Cliquez sur Continuer.

Le provisionnement et la connexion à l'environnement prennent quelques instants. Une fois connecté, vous êtes en principe authentifié et le projet est défini sur votre ID_PROJET. Par exemple :

gcloud est l'outil de ligne de commande pour Google Cloud. Il est préinstallé sur Cloud Shell et permet la complétion par tabulation.

• Vous pouvez lister les noms des comptes actifs à l'aide de cette commande :

gcloud auth list

Résultat :

Credentialed accounts: - @.com (active)

Exemple de résultat :

Credentialed accounts: - google1623327_student@qwiklabs.net

• Vous pouvez lister les ID de projet à l'aide de cette commande :

gcloud config list project

Résultat :

[core] project =

Exemple de résultat :

[core] project = qwiklabs-gcp-44776a13dea667a6 Remarque : Pour consulter la documentation complète sur gcloud, accédez au guide de présentation de la gcloud CLI.

Tâche 2. Préparer l'installation d'Anthos Service Mesh

1. Vérifiez que vous disposez déjà de deux clusters GKE (accédez au menu de navigation > Kubernetes Engine > Clusters ou utilisez la commande gcloud container clusters list).

2. Vérifiez que les deux clusters ont été enregistrés auprès d'Anthos Connect Hub en accédant au menu de navigation > Anthos > Dashboard (Tableau de bord).

3. Configurez les variables d'environnement que vous utiliserez dans les scripts tout au long de l'atelier :

export PROJECT_ID=${PROJECT_ID:-$(gcloud config get-value project)} export C1_NAME=west export C2_NAME=east export C1_LOCATION=us-west1-b export C2_LOCATION=us-east1-b export FLEET_PROJECT_ID=${FLEET_PROJECT_ID:-$PROJECT_ID} export DIR_PATH=${DIR_PATH:-$(pwd)} export GATEWAY_NAMESPACE=asm-gateways export ASM_VERSION=1.11.2-asm.17 export SAMPLES_DIR=$DIR_PATH/istio-$ASM_VERSION

3. Installez l'utilitaire de ligne de commande asmcli qui vous servira à installer Anthos Service Mesh :

   curl https://storage.googleapis.com/csm-artifacts/asm/asmcli_1.11 > asmcli chmod +x asmcli

4. Ajoutez les informations de contexte de chaque cluster dans votre fichier kubeconfig et créez un alias facile à mémoriser pour chaque contexte :

   # configure the west cluster context gcloud container clusters get-credentials $C1_NAME --zone $C1_LOCATION --project $PROJECT_ID kubectx $C1_NAME=. # configure the east cluster context gcloud container clusters get-credentials $C2_NAME --zone $C2_LOCATION --project $PROJECT_ID kubectx $C2_NAME=.

   Vous pouvez vérifier que les deux contextes avec alias sont présents et que le contexte east est actuellement sélectionné à l'aide de la commande suivante :

   kubectx

   Le résultat doit ressembler à ceci :

   

Tâche 3 : Installer Anthos Service Mesh sur les deux clusters

1. Installez Anthos Service Mesh sur le cluster west à l'aide de la commande suivante :

   # switch to west context kubectx west # install Anthos Service Mesh ./asmcli install \ --project_id $PROJECT_ID \ --cluster_name $C1_NAME \ --cluster_location $C1_LOCATION \ --fleet_id $FLEET_PROJECT_ID \ --output_dir $DIR_PATH \ --enable_all \ --ca mesh_ca

Avant l'installation, l'utilitaire asmcli effectue les opérations suivantes si vous utilisez le bouton enable_all :

• Fournir les autorisations nécessaires sur le projet
• Activer les API nécessaires
• Ajouter un libellé au cluster pour identifier le réseau maillé
• Créer un compte de service permettant aux composants d'accéder en toute sécurité aux ressources
• Enregistrer le cluster si ce n'est déjà fait

Il télécharge ensuite les fichiers d'installation nécessaires, génère les fichiers de configuration requis et installe le logiciel sur votre cluster.

Lors de l'installation d'Anthos Service Mesh, vous devez choisir une autorité de certification. Dans cet atelier, vous utilisez Mesh CA, le service d'autorité de certification géré de Google. Cette autorité de certification est disponible pour les clusters GKE, Anthos on VMware et Anthos sur solution Bare Metal.

Si vous créez un réseau maillé multicluster incluant des clusters Anthos clusters on AWS ou des clusters associés, vous devez installer Istio CA. La procédure est semblable, mais comporte quelques étapes supplémentaires qui sont disponibles dans la documentation en ligne.

2. Installez une passerelle d'entrée sur votre cluster west :

# create the gateway namespace kubectl create namespace $GATEWAY_NAMESPACE # enable sidecar injection on the gateway namespace kubectl label ns $GATEWAY_NAMESPACE \ istio.io/rev=$(kubectl -n istio-system get pods -l app=istiod -o json | jq -r '.items[0].metadata.labels["istio.io/rev"]') \ --overwrite # Apply the configurations kubectl apply -n $GATEWAY_NAMESPACE \ -f $DIR_PATH/samples/gateways/istio-ingressgateway

Anthos Service Mesh vous permet de déployer et de gérer des passerelles avec votre maillage de services. Une passerelle décrit un équilibreur de charge fonctionnant à la périphérie du réseau maillé qui reçoit des connexions HTTP/TCP entrantes ou sortantes. Les passerelles sont des proxys Envoy qui vous permettent de contrôler avec précision le trafic entrant et sortant du réseau maillé.

Pour configurer votre passerelle d'entrée, vous devez créer un espace de noms pour les composants de la passerelle, puis appliquer les fichiers manifestes dans le répertoire ingress-gateway afin de créer les ressources nécessaires sur votre cluster.

Prenez quelques instants pour afficher le contenu des fichiers manifestes dans le répertoire ingress-gateway afin de mieux comprendre ce qui est déployé. Vous devez voir les éléments suivants :

• Un déploiement des pods de passerelle, ainsi que des configurations d'autoscaling et de budget d'interruption
• Un service qui expose le déploiement
• Un compte de service, un rôle de client et une liaison de rôle attribuant le rôle au nouveau compte de service

3. Passez au contexte east et installez Anthos Service Mesh sur le cluster east à l'aide des commandes suivantes :

   # switch to the east context kubectx east # install Anthos Service Mesh ./asmcli install \ --project_id $PROJECT_ID \ --cluster_name $C2_NAME \ --cluster_location $C2_LOCATION \ --fleet_id $FLEET_PROJECT_ID \ --output_dir $DIR_PATH \ --enable_all \ --ca mesh_ca # create the gateway namespace kubectl create namespace $GATEWAY_NAMESPACE # enable sidecar injection on the gateway namespace kubectl label ns $GATEWAY_NAMESPACE \ istio.io/rev=$(kubectl -n istio-system get pods -l app=istiod -o json | jq -r '.items[0].metadata.labels["istio.io/rev"]') \ --overwrite # Apply the configurations kubectl apply -n $GATEWAY_NAMESPACE \ -f $DIR_PATH/samples/gateways/istio-ingressgateway

Tâche 4 : Configurer le réseau maillé pour couvrir les deux clusters

GKE ajoute automatiquement des règles de pare-feu à chaque nœud pour autoriser le trafic au sein du même sous-réseau. Si votre réseau maillé contient plusieurs sous-réseaux, vous devez configurer explicitement les règles de pare-feu pour autoriser le trafic entre sous-réseaux. Vous devez ajouter une règle de pare-feu pour chaque sous-réseau afin d'autoriser les blocs CIDR des adresses IP sources et les ports cibles pour l'ensemble du trafic entrant.

1. Créez une règle de pare-feu qui autorise tout le trafic entre les deux clusters dans votre réseau maillé :

   function join_by { local IFS="$1"; shift; echo "$*"; } # get the service IP CIDRs for each cluster ALL_CLUSTER_CIDRS=$(gcloud container clusters list \ --filter="name:($C1_NAME,$C2_NAME)" \ --format='value(clusterIpv4Cidr)' | sort | uniq) ALL_CLUSTER_CIDRS=$(join_by , $(echo "${ALL_CLUSTER_CIDRS}")) # get the network tags for each cluster ALL_CLUSTER_NETTAGS=$(gcloud compute instances list \ --filter="name:($C1_NAME,$C2_NAME)" \ --format='value(tags.items.[0])' | sort | uniq) ALL_CLUSTER_NETTAGS=$(join_by , $(echo "${ALL_CLUSTER_NETTAGS}")) # create the firewall rule allowing traffic between the clusters gcloud compute firewall-rules create istio-multi-cluster-pods \ --allow=tcp,udp,icmp,esp,ah,sctp \ --direction=INGRESS \ --priority=900 \ --source-ranges="${ALL_CLUSTER_CIDRS}" \ --target-tags="${ALL_CLUSTER_NETTAGS}" --quiet

Pour que chaque cluster puisse découvrir les points de terminaison de l'autre cluster, ceux-ci doivent tous deux être enregistrés dans le même parc. Chacun d'entre eux doit également être configuré avec un secret qui permet d'accéder au serveur d'API de l'autre cluster pour l'énumération des points de terminaison. L'utilitaire asmcli configure ce processus automatiquement.

2. Configurez les clusters pour le fonctionnement du réseau maillé multicluster à l'aide de l'utilitaire asmcli :

./asmcli create-mesh \ $FLEET_PROJECT_ID \ ${PROJECT_ID}/${C1_LOCATION}/${C1_NAME} \ ${PROJECT_ID}/${C2_LOCATION}/${C2_NAME}

Étant donné que vos deux clusters Anthos GKE sont des clusters de VPC natif situés sur le même réseau VPC, le trafic peut circuler de l'un à l'autre sans configuration particulière.

Toutefois, si vous créez un réseau maillé multicluster à l'aide de clusters situés sur différents réseaux, par exemple, un cluster GKE et un cluster Anthos sur solution Bare Metal, vous devez suivre quelques étapes supplémentaires pour activer la fonctionnalité de réseau maillé.

La première étape consiste à installer des passerelles east-west sur chaque cluster. Le trafic acheminé depuis le cluster west vers le cluster east sortira via une passerelle sur le cluster west, et inversement.

Une fois les passerelles en place, vous devez exposer tous les services de la passerelle aux deux clusters. Pour ce faire, vous appliquez la configuration "expose-services.yaml" fournie avec la distribution d'Anthos Service Mesh.

Pour en savoir plus, consultez la documentation.

Tâche 5 : Examiner les plans de contrôle du maillage de services

Vérifions que toutes les ressources Anthos Service Mesh ont été correctement créées sur les deux clusters.

1. Vérifiez que les espaces de noms requis ont été créés sur le cluster west :

   kubectx west kubectl get namespaces NAME STATUS AGE asm-gateways Active 31m asm-system Active 37m default Active 127m gke-connect Active 125m istio-system Active 38m kube-node-lease Active 127m kube-public Active 127m kube-system Active 127m

L'espace de noms istio-system est l'endroit où Istiod s'exécutera. L'espace de noms asm-gateways est l'endroit où vos pods de passerelle s'exécuteront. De plus, l'espace de noms asm-system sera utilisé par le contrôleur de service canonique (consultez la documentation sur le service canonique pour en savoir plus).

2. Assurez-vous que les mêmes espaces de noms existent sur le cluster east.

3. Vérifiez les déploiements en cours d'exécution dans chacun des trois nouveaux espaces de noms pour vous assurer que les fonctionnalités attendues sont opérationnelles.

Tâche 6 : Déployer l'application Online Boutique sur plusieurs clusters

Dans cette section, vous allez installer l'application Online Boutique sur les deux clusters. Online Boutique comprend 10 microservices écrits dans différents langages de programmation.

Dans cet atelier, vous allez diviser l'application entre les clusters west et east.

Installer les services Online Boutique dans le cluster west

1. Commencez par créer un espace de noms pour les services Online Boutique sur le cluster west, puis activez l'injection side-car sur cet espace de noms :

# switch to the west context kubectx west # create the namespace kubectl create ns boutique # enable sidecar injection kubectl label ns boutique \ istio.io/rev=$(kubectl -n istio-system get pods -l app=istiod -o json | jq -r '.items[0].metadata.labels["istio.io/rev"]') \ --overwrite

2. Consultez le fichier manifeste qui déploie les charges de travail sur le cluster west en accédant à cette page dans GitHub.

Quels services sont déployés sur le cluster west ?

3. Examinez le fichier manifeste pour les services créés sur le cluster west sur cette page dans GitHub.

• Quels types de services sont déployés ?
• Comment ces services seront-ils accessibles depuis l'extérieur du cluster ?

4. Consultez le fichier manifeste qui crée les composants de maillage de services sur le cluster en accédant à cette page dans GitHub.

Voyez-vous maintenant comment les services seront accessibles depuis l'extérieur du cluster ?

5. Appliquez le fichier manifeste pour créer des ressources d'application de déploiement sur le cluster west :

   kubectl apply -n boutique -f https://raw.githubusercontent.com/haggman/training-data-analyst/ahybrid081_fix/courses/ahybrid/v1.0/AHYBRID081/boutique/west/deployments.yaml kubectl apply -n boutique -f https://raw.githubusercontent.com/haggman/training-data-analyst/ahybrid081_fix/courses/ahybrid/v1.0/AHYBRID081/boutique/west/services.yaml kubectl apply -n boutique -f https://raw.githubusercontent.com/haggman/training-data-analyst/ahybrid081_fix/courses/ahybrid/v1.0/AHYBRID081/boutique/west/istio-defaults.yaml

6. À l'aide des pages Kubernetes Engine de la console ou de kubectl dans Cloud Shell, vérifiez que les charges de travail et les services ont bien été déployés.

Installer les services Online Boutique sur le cluster east

7. Passez au contexte east, créez un espace de noms pour les services Online Boutique sur le cluster east, puis activez l'injection side-car sur cet espace de noms :

# switch to the east context kubectx east # create the namespace kubectl create ns boutique # enable sidecar injection kubectl label ns boutique \ istio.io/rev=$(kubectl -n istio-system get pods -l app=istiod -o json | jq -r '.items[0].metadata.labels["istio.io/rev"]') \ --overwrite

8. Examinez les fichiers manifestes pour le cluster east, en notant les charges de travail et les services déployés.

• Déploiements east

• Composants du maillage de services east

• Services east

9. Appliquez les fichiers manifestes au cluster east :

   kubectl apply -n boutique -f https://raw.githubusercontent.com/haggman/training-data-analyst/ahybrid081_fix/courses/ahybrid/v1.0/AHYBRID081/boutique/east/deployments.yaml kubectl apply -n boutique -f https://raw.githubusercontent.com/haggman/training-data-analyst/ahybrid081_fix/courses/ahybrid/v1.0/AHYBRID081/boutique/east/services.yaml kubectl apply -n boutique -f https://raw.githubusercontent.com/haggman/training-data-analyst/ahybrid081_fix/courses/ahybrid/v1.0/AHYBRID081/boutique/east/istio-defaults.yaml

10. À l'aide de la console ou de Cloud Shell, examinez les déploiements et les services de votre cluster east.

Tâche 7 : Évaluer votre application multicluster

1. Obtenez une URL pour accéder au service istio-ingressgateway sur chaque cluster :

   # get the IP address for the west cluster service kubectx west export WEST_GATEWAY_URL=http://$(kubectl get svc istio-ingressgateway \ -o=jsonpath='{.status.loadBalancer.ingress[0].ip}' -n asm-gateways) # get the IP address for the east cluster service kubectx east export EAST_GATEWAY_URL=http://$(kubectl get svc istio-ingressgateway \ -o=jsonpath='{.status.loadBalancer.ingress[0].ip}' -n asm-gateways) # compose and output the URLs for each service echo "The gateway address for west is $WEST_GATEWAY_URL The gateway address for east is $EAST_GATEWAY_URL "

2. Cliquez sur chacune des URL fournies et vérifiez que les applications Online Boutique se chargent.

L'utilisateur se connecte au service istio-ingressgateway, où les proxys ont été configurés à la fois par la passerelle et la configuration du service virtuel. La requête entrante est analysée par le proxy. Celui-ci se connecte ensuite au service frontend, lequel présente l'interface utilisateur du magasin.

Chaque cluster dispose d'un service istio-ingressgateway et d'un déploiement istio-ingressgateway afin que l'utilisateur puisse se connecter à l'un ou l'autre des clusters. Cependant, le service frontend et la charge de travail ne s'exécutent que sur le cluster west. Ainsi, lorsque vous vous connectez à la passerelle du cluster east, le proxy reçoit votre requête entrante, mais se connecte via le réseau maillé au service frontend exécuté sur le cluster west. Nous verrons ce flux de trafic en détail plus tard.

3. Prenez quelques instants pour parcourir les produits, ajouter des articles à votre panier et procéder au règlement. Tout doit fonctionner, même si la moitié des services s'exécutent sur un cluster et l'autre moitié sur l'autre.

4. Dans la console, accédez au menu de navigation > Anthos > Anthos Service Mesh.

5. Vous devez voir 13 services déployés dans votre réseau maillé, répartis entre vos clusters. Si une bannière Action Required (Action requise) s'affiche, actualisez la page dans votre navigateur. Cet avertissement ne doit plus s'afficher.

   

6. Si vous souhaitez afficher les services exécutés sur un seul cluster, vous pouvez filtrer l'affichage. Filtrez pour n'afficher que les services exécutés sur le cluster west.

   

7. Cliquez sur l'entrée de service frontend dans votre liste pour afficher les détails.

   

Notez que le service d'interface reçoit le trafic provenant des services istio-ingressgateway et loadgenerate.

8. Sur la gauche, cliquez sur Connected Services (Services connectés). Sélectionnez ensuite l'onglet Outbound (Sortant) dans la section Requests (Requêtes).

   

Notez que les connexions entre le service frontend et les utilitaires utilisent toutes l'authentification mTLS, quel que soit le cluster sur lequel les services cibles sont exécutés. Cliquez sur quelques services dans le tableau en bas de la fenêtre et notez l'emplacement où s'exécute chaque service (les informations s'affichent dans le menu déroulant à droite).

9. Revenez au menu de navigation > Anthos > Anthos Service Mesh.

10. Cliquez sur TOPOLOGY (TOPOLOGIE) en haut à droite de la fenêtre.

11. Cliquez sur chaque nœud et notez l'emplacement où s'exécute le service.

Tâche 8 : Distribuer un service sur les deux clusters

1. Dans la console, accédez au menu de navigation > Kubernetes Engine > Services & Ingress (Services et entrées).

2. Examinez les entrées "recommendationservice" dans le tableau. Chaque cluster comporte une entrée de service de recommandation. Notez que le cluster west comporte un pod en arrière-plan et que le cluster east n'en comporte pas.

   

   La charge de travail réelle est déployée sur le cluster west et non sur le cluster east. Vous allez également déployer la charge de travail sur le cluster east.

3. Prenez quelques instants pour vérifier le fichier manifeste de déploiement pour la charge de travail recommendationservice.

4. Appliquez le fichier manifeste au cluster east à l'aide de la commande suivante dans Cloud Shell :

   kubectl apply -n boutique -f https://raw.githubusercontent.com/haggman/training-data-analyst/ahybrid081_fix/courses/ahybrid/v1.0/AHYBRID081/boutique/east/rec-east.yaml

5. Revenez au menu de navigation > Kubernetes Engine > Services. Notez que l'entrée east du service recommendationservice affiche désormais un pod s'exécutant sur le cluster east.

   

6. Revenez au menu de navigation > Anthos > Anthos Service Mesh. Notez que l'entrée recommendationservice affiche désormais le service sur les deux clusters.

   

7. Cliquez sur l'entrée recommendationservice, puis sur l'option Infrastructure à gauche. Notez que vous disposez maintenant de métriques pour le service en cours d'exécution sur les deux clusters.

   

   Si vous ne voyez pas les métriques de la deuxième charge de travail, attendez une minute, puis actualisez la page.

8. Cliquez sur Traffic (Trafic) à gauche. Cliquez sur l'entrée recommendationservice pour ouvrir la zone d'informations à droite. Dans la zone d'informations, cliquez sur l'onglet DETAILS (DÉTAILS) et notez les charges de travail exécutées sur les deux clusters.

   

9. Revenez au menu de navigation > Anthos > Anthos Service Mesh. Cliquez sur TOPOLOGY (TOPOLOGIE) en haut à droite.

10. Cliquez sur le nœud recommendationservice dans le graphique et notez dans la zone d'informations située à droite que le service s'exécute sur les deux clusters.

    

Félicitations !

Dans cet atelier, vous avez déployé Anthos Service Mesh sur deux clusters, configuré les deux clusters pour participer à un seul réseau maillé, déployé une application avec des services répartis sur les deux clusters et créé un service distribué s'exécutant sur les deux clusters.

Terminer l'atelier

Une fois l'atelier terminé, cliquez sur Terminer l'atelier. Google Cloud Skills Boost supprime les ressources que vous avez utilisées, puis efface le compte.

Si vous le souhaitez, vous pouvez noter l'atelier. Sélectionnez un nombre d'étoiles, saisissez un commentaire, puis cliquez sur Envoyer.

Le nombre d'étoiles correspond à votre degré de satisfaction :

• 1 étoile = très insatisfait(e)
• 2 étoiles = insatisfait(e)
• 3 étoiles = ni insatisfait(e), ni satisfait(e)
• 4 étoiles = satisfait(e)
• 5 étoiles = très satisfait(e)

Si vous ne souhaitez pas donner votre avis, vous pouvez fermer la boîte de dialogue.

Pour soumettre des commentaires, suggestions ou corrections, veuillez accéder à l'onglet Assistance.

Dernière mise à jour du manuel : 18 septembre 2020

Dernier test de l'atelier : 1er octobre 2020

Copyright 2020 Google LLC Tous droits réservés. Google et le logo Google sont des marques de Google LLC. Tous les autres noms d'entreprises et de produits peuvent être des marques des entreprises auxquelles ils sont associés.