Premiers pas avec Google Cloud Platform #1

Connexion à Google Cloud Platform

• Nous pouvons nous connecter à Google Cloud Platform et commencer à utiliser les services fournis via la Console Google Cloud ou l'utilitaire de ligne de commande gcloud .
• Nous devons d'abord créer un compte en utilisant l'une de nos adresses e-mail (pas nécessairement une adresse Gmail) ou en créant un nouveau compte Gmail
• Nous devons également associer une carte de crédit valide à ce compte pour facturer les services payants que nous utiliserons éventuellement
• Il y a une offre de crédit unique de 300$ pour les nouveaux comptes Google Cloud
• Les utilisateurs de Google Cloud Platform bénéficient également d'une machine virtuelle de développement Linux gratuite (limitée à 50 heures/semaine) accessible depuis le navigateur Web, dans la console Google Cloud, via le service Cloud Shell :
  • pas de maintenance, le système d'exploitation et les outils installés sont mis à jour automatiquement
  • des outils utiles comme gcloud, kubectl, docker, git, mysql, minikube... sont déjà installés
  • nous obtenons 5 Go de stockage persistant pour le répertoire $HOME .
  • nous bénéficions d'un IDE préconfiguré pour le développement dans de nombreux langages de programmation, optimisé par l' IA Google et qui fournit des aperçus en direct pour les applications Web

Emplacements des infrastructures physiques et des ressources

• Les ressources créées dans GCP résident dans les centres de données Google
• Les centres de données sont physiquement situés dans différentes régions
• Une région GCP est une partie géographique à l'intérieur d'un pays spécifique sur un continent spécifique :
  • Johannesbourg = africa-south1
  • Paris = europe-west9
• Chaque région compte au moins 3 zones représentant 3 bâtiments de centres de données physiquement séparés
• Par exemple, la région africa-south1 comprend les zones suivantes :
  • afrique-south1-a
  • afrique-south1-b
  • afrique-south1-c
• Au moment de la rédaction de cet article, l’Iowa (us-central1) est la seule région qui possède exceptionnellement 4 zones
• Voici les différents types de disponibilité que les ressources dans GCP peuvent avoir :
  • zonal: une ressource disponible dans une zone spécifique (ex : moteurs de calcul ou disques persistants zonaux)
  • régional: une ressource disponible dans toutes les zones d'une région spécifique (ex : sous-réseaux VPC ou disques persistants régionaux)
  • multirégional: une ressource disponible dans plusieurs zones de plusieurs régions (ex : buckets GCS multirégionaux)
  • global: une ressource qui n'est pas liée à une région ou une zone spécifique (ex : VPC et équilibreurs de charge globaux)

Quelques liens utiles

• Une carte représentant la couverture du réseau privé GCP dans le monde (câbles, Edges / Cloud CDN / Media CDN Point of Presence...) : Réseau privé GCP
• Un outil qui aide à choisir les régions GCP en fonction de l'empreinte carbone, du prix et de la latence : Sélecteur de région
• Assurez-vous qu'un produit GCP spécifique est disponible dans une région spécifique ou dans un emplacement multirégional : Disponibilité des produits GCP par localisation
• Une liste des produits GCP disponibles dans le monde entier : Produits mondiaux
• Sécurité GCP, conformité, confidentialité des données, transparence : Ici
• Sécurité de l'infrastructure GCP : Ici
• Statuts des services GCP : Ici

Hiérarchie des ressources

• Organisation -> Dossier -> Projets -> Ressources
  • Les ressources GCP (machines virtuelles, bases de données...) résident à l'intérieur des Projets
  • Projets : sont créés à l'intérieur des Dossiers qui font partie d'une Organisation
• Si les comptes d'utilisateurs accédant à GCP ont Google Workspace activé, les projets qu'ils créent font automatiquement partie de leurs organisations associées à Google Workspace. Dans le cas contraire, une nouvelle organisation doit être créée
• Des organisations, des projets et des dossiers peuvent être créés à l'aide de la Console Google Cloud comme suit:
  • Organisation: IAM et administration -> Identité et organisation
  • Projet et dossiers : dans le Resource Manager (IAM et administration -> Gérer les ressources)
• Les projets ont 3 attributs :
  • Nom: unique dans le dossier. Peut être modifié à tout moment
  • Numéro : unique au monde. Ne peut être modifié
  • ID: unique au monde. Modifiable uniquement lors de la création du projet
• Les projets héritent des stratégies de l'organisation ou des dossiers
• Les stratégies définissent qui peut faire quoi sur quelles ressources
• Les stratégies permettant la création de projets ou l'administration de stratégies d'organisation et ne peuvent être créées qu'au niveau de l'organisation

Facturation, budget et alertes

• Un projet GCP doit être associé à un compte de facturation pour fonctionner correctement
• Le compte de facturation contient les détails de paiement du client et est utilisé pour facturer la consommation des ressources des projets
• Un compte de facturation peut être utilisé par plusieurs projets, mais chaque projet ne peut être associé qu'à un seul compte de facturation
• Les budgets peuvent être configurés pour des projets, et alertes déclenchées lorsque la consommation des ressources du projet atteint X pourcent du budget
• Les alertes budgétaires sont envoyées par défaut aux administrateurs de facturation
• Lors de la création d'une alerte budgétaire, nous pouvons également choisir de recevoir des alertes de consommation dans une rubrique Pub/Sub qui sera automatiquement créée
• Les informations de facturation peuvent également être exportées vers des fichiers à l'intérieur de compartiments GCS ou dans des ensembles de données BigQuery à des fins d'analyse.

Labels, tags et quotas

Les labels

• Les labels sont des chaînes définies par l'utilisateur au format clé-valeur qui peuvent être ajoutés aux ressources GCP
• Ils servent à organiser les ressources. Ils se propagent à travers la facturation et sont utiles pour le filtrage

Les tags

• Les tags sont des chaînes définies par l'utilisateur qui ne peuvent être ajoutées qu'aux machines virtuelles
• Ils sont utilisés pour créer des règles de pare-feu réseau et des politiques de routage qui s'appliquent uniquement à des machines virtuelles spécifiques.
• Un tag est associée à une règle de pare-feu réseau ou à une règle de routage lors de la création. Ensuite, les machines virtuelles utilisant la balise héritent des règles de pare-feu réseau et des règles de routage

Quotas

• Toutes les ressources de GCP sont soumises à des quotas ou des limites
• Les quotas définissent :
  • combien de ressources peuvent être créées par projet (ex : 15 réseaux VPC par projet)
  • à quelle vitesse les requêtes aux API peuvent-elles être effectuées dans un projet : limites de débit (ex : 5 actions d'administrateur par seconde sur Cloud Spanner)
  • combien de ressources peuvent être créées par région (ex : 24 CPU par région)
• Certains quotas augmentent automatiquement en fonction de l'utilisation. D'autres nécessitent que les utilisateurs fassent des demandes d'augmentation de quota
• Pour voir les valeurs de quota ou demander une augmentation de quota pour un projet donné, accédez à la page de quota dans la Console cloud
• Voici trois raisons pour lesquelles les quotas sont utilisés :
  • prévenir les consommations incontrôlables en cas d'erreur ou d'attaque malveillante
  • éviter les pics de facturation ou les surprises
  • oblige à faire attention au dimensionnement et à effectuer des audits périodiques

Gestion des identités et des accès (IAM)

Présentation d'IAM

• « IAM » permet aux administrateurs d'appliquer des stratégies qui définissent « qui » peut faire « quoi » sur « quelles ressources »
• Le « qui » pourrait être un compte Google, un groupe Google, un compte de service ou un domaine Cloud Identity .
• Le « quoi » est défini par un « rôle IAM », qui est une ressource contenant un ensemble d'autorisations
• L'attribution d'un rôle à l'entité « qui » lui accorde toutes les autorisations incluses dans le rôle
• Il existe de nombreux rôles prédéfinis pour différents types de ressources/services GCP qui simplifient la gestion des autorisations
• Les stratégies IAM sont héritées selon la hiérarchie des ressources GCP :
  • les stratégies créées au niveau de l'organisation sont héritées par tous les dossiers de l'organisation et donc par tous les projets à l'intérieur de ces dossiers
  • les stratégies créées au niveau du dossier sont héritées par tous les projets à l'intérieur du dossier
  • les stratégies créées dans le cadre d'un projet s'appliquent uniquement au projet
• Une règle de refus a toujours la priorité sur toute règle d'autorisation, quel que soit le rôle IAM attribué. IAM vérifie toujours les règles de refus avant celles d'autorisation
• Les règles de refus et d'autorisation sont héritées en fonction de la hiérarchie des ressources

Rôles IAM

• Les rôles IAM contiennent un ensemble d'autorisations qui peuvent être utilisées pour autoriser les identités (utilisateurs, groupes, comptes de service...) à effectuer des actions spécifiques dans GCP
• Il existe 3 types de rôles IAM :
  • Rôles de base: accorder un accès en lecture, en écriture ou en administrateur à toutes les ressources d'un projet
    • Lecteur: accorder un accès en lecture à toutes les ressources d'un projet
    • Éditeur: accorder l'accès en lecture et en écriture aux ressources d'un projet
    • Propriétaire: accorder l'accès administrateur à toutes les ressources d'un projet (lecture + écriture + autorisations pour accorder des autorisations + autorisations d'administrateur de facturation)
    • Administrateur de la facturation: pour la gestion de la facturation
  • Rôles prédéfinis: rôles spécifiques à certaines ressources GCP. Ex : Administrateur d'instance de calcul. Ce rôle accorde des privilèges d'administration sur Google Compute Engine
  • Rôles personnalisés: contient un ensemble d'autorisations définies par les utilisateurs GCP. Ne peut être appliqué qu'au niveau de l'organisation ou du projet, pas aux dossiers
  • Les rôles suivants sont requis pour gérer les rôles IAM :
    • roles/iam.organizationRoleAdmin: accorde des privilèges d'administration de rôles au niveau de l'organisation
    • roles/iam.roleAdmin: accorde des privilèges d'administration de rôles au niveau du dossier ou du projet

Les comptes de service

• Un « compte de service » est une identité (et également une ressource) destinée à être utilisée par d'autres ressources GCP, des applications ou des systèmes externes tels que des pipelines CI/CD pour s'authentifier auprès de GCP et effectuer des actions spécifiques
• De nombreuses ressources dans GCP utilisent des comptes de service par défaut qui sont automatiquement créés et gérés par Google
• L'association d'un compte de service à une ressource GCP donne à cette ressource l'identité du compte de service
• Les « clés » de compte de service peuvent être générées et exportées pour être utilisées par des applications ou des systèmes en dehors de GCP à des fins d'authentification
• Les actions qui peuvent être effectuées par des entités utilisant un compte de service sont déterminées par les autorisations du compte de service
• Les comptes de service sont identifiés par des adresses e-mail uniques qui peuvent prendre les formes suivantes :
  • PROJECT_NUMBER-compute@developer.gserviceaccount.com
  • PROJECT_ID@appspot.gserviceaccount.com
  • PROJECT_NUMBER@cloudservices.gserviceaccount.com
  • ...
• L'octroi du rôle « ServiceAccountUser » aux utilisateurs leur confère les privilèges nécessaires pour effectuer des actions spécifiques en tant que comptes de service spécifiques. Par exemple, un utilisateur effectuant une action d'arrêt sur une machine virtuelle GCE (à laquelle il n'est pas autorisé) réussira si le rôle « ServiceAccountUser » lui a été accordé et si le compte de service attaché au GCE est autorisé à arrêter la machine
• Pour en savoir plus sur les comptes de service, consultez aperçu du compte de service

Aperçu des produits et services

Réseau et sécurité

Croquis VPC

VPC et sous-réseaux

• VPC (Virtual Private Cloud) représente un réseau dans GCP
• La ressource VPC est globale et les sous-réseaux à l'intérieur du VPC sont régionaux
• Pour tous les projets GCP, un VPC nommé « default » est automatiquement créé
• À l'intérieur de ce VPC « default », il existe des sous-réseaux dans chaque région GCP disponible
• Il existe deux modes de création de VPC :
  • auto : les sous-réseaux sont automatiquement créés dans toutes les régions disponibles
  • custom : le VPC est créé sans sous-réseaux. Les sous-réseaux doivent être créés manuellement
• Le rôle IAM prédéfini pour l'administration réseau est :
  • Network Admin: pour la gestion des réseaux VPC uniquement. Accorde les autorisations suivantes : compute.networks.*

Règles de pare-feu

• Les règles de pare-feu sont utilisées pour autoriser ou refuser le trafic entrant ou sortant sur un réseau spécifique (VPC)
• Lorsque nous créons une règle de pare-feu, nous spécifions le VPC pour lequel nous voulons que la règle s'applique
• La règle s'applique par défaut à tous les sous-réseaux de ce VPC, donc sur les instances de calculs utilisant au moins l'un des sous-réseaux VPC
• Pour que la règle s'applique uniquement à des instances de calculs spécifiques, des comptes de service source/cible ou des tags peuvent être spécifiés dans la règle
• De cette façon, la règle ne s'appliquera qu'aux machines utilisant le compte de service source/cible ou marquées avec le tag réseau spécifié
• Le rôle IAM prédéfini pour l'administration de la sécurité est :
  • Security Admin: pour gérer les règles de pare-feu uniquement. Accorde les autorisations suivantes : compute.firewalls.*

Équilibreurs de charge et WAF (Cloud Armor)

Pour un bon aperçu de l'équilibrage de charge dans GCP, consultez Comprendre les équilibreurs de charge GCP.

Pour Cloud Armor, voici quelques liens utiles :

• Exemple d'utilisation de Cloud Armor pour protéger une application Web derrière un équilibreur de charge d'application HTTPS
• Page produit Cloud Armor
• Documentation de Cloud Armor

Machines virtuelles

Croquis de GCE | Maintenance des hyperviseurs de VM

Google Compute Engine (GCE)

• Google Compute Engine (GCE) est le service GCP qui peut être utilisé pour provisionner des machines virtuelles (VM ou instances de calcul)
• 2 types de machines : « prédéfinies » et « personnalisées »
• 3 familles de types de machines : « à usage général », « optimisées pour le calcul », « optimisées pour la mémoire »
• La bande passante réseau (en sortie) des machines virtuelles augmente lorsque le nombre de vCPU augmente
• La bande passante maximale est de 32 Gbps sur les machines virtuelles standard
• Pour augmenter la bande passante, les performances réseau « VM Tier 1 » peuvent être activées. La « carte d'interface gVNIC » peut ensuite être utilisée pour augmenter la bande passante maximale à 100 Gbit/s
• Les disques logiques des machines virtuelles consomment également de la bande passante réseau (jusqu'à 60 % de la bande passante de sortie du réseau) car ils sont connectés au réseau.
• L'augmentation de la taille des disques des machines virtuelles augmente également leurs performances d'E/S
• Plusieurs interfaces réseau (provenant de différents sous-réseaux) peuvent être utilisées pour permettre la communication avec d'autres GCE sur ces sous-réseaux
• Le nombre d'interfaces réseau supplémentaires pouvant être ajoutées à un GCE dépend de la taille de la machine GCE
• Les autorisations des machines virtuelles GCE sont les mêmes que celles du compte de service qui leur est associé + les « access scopes » configurés
• Un compte de service par défaut est automatiquement créé et associé à chaque machine virtuelle qui n'a pas de compte de service personnalisé associé. Cet ID de compte de service par défaut pour les VM a la forme suivante :
  • PROJECT_NUMBER-compute@developer.gserviceaccount.com
• Lors de la création d'une instance de calcul avec « gcloud », les options « --scopes=[SCOPE,...] » et « --service-account=SERVICE_ACCOUNT » peuvent être utilisées pour définir des étendues d'accès (access scopes) et un compte de service personnalisé pour la machine virtuelle
• Les valeurs des étendues d'accès (access scopes) peuvent être spécifiées sous forme d'URI ou d'alias. Ex :

Alias                  URI
compute-ro             https://www.googleapis.com/auth/compute.readonly
compute-rw             https://www.googleapis.com/auth/compute
logging-write          https://www.googleapis.com/auth/logging.write
monitoring             https://www.googleapis.com/auth/monitoring
monitoring-read        https://www.googleapis.com/auth/monitoring.read
monitoring-write       https://www.googleapis.com/auth/monitoring.write
sql-admin              https://www.googleapis.com/auth/sqlservice.admin
storage-full           https://www.googleapis.com/auth/devstorage.full_control
storage-ro             https://www.googleapis.com/auth/devstorage.read_only
storage-rw             https://www.googleapis.com/auth/devstorage.read_write
(...)

• Utilisez « gcloud compute instances create --help » et recherchez « --scopes » ou « --service-account » pour en savoir plus (descriptions détaillées, alias d'étendues disponibles...)

Le serveur de métadonnées

• Un serveur qui peut être interrogé à partir d'instances de calcul (sans authentification supplémentaire)
• Stocke des informations sur l'instance ou le projet GCE (nom de la VM, ID du projet, IP, compte de service...)
• Les communications avec le serveur de métadonnées sont chiffrées et ne quittent jamais l'hôte physique sur lequel la VM s'exécute
• Voici les URL racines qui peuvent être utilisées pour interroger le serveur de métadonnées :
  • http://metadata.google.internal/computeMetadata/v1
  • http://169.254.169.254/v1
  • http://metadata.goog/v1
• Lors de l'interrogation du serveur de métadonnées, les URL racines doivent être complétées par les URI de requête pour les métadonnées de projet ou d'instance
• L'URI racine pour interroger les « métadonnées du projet » est « /project » :
  • la liste des URI disponibles pour les métadonnées du projet peut être trouvée ici
• L'URI racine pour interroger les « métadonnées d'instance » est « /instance » :
  • la liste des URI disponibles pour les métadonnées d'instance peut être trouvée ici
• Lorsque nous interrogeons le serveur de métadonnées, nous devons définir l'en-tête de requête « Metadata-Flavor : Google » pour indiquer au serveur que nous devons récupérer les métadonnées. Sinon, la requête sera refusée
• Exemple de requête :

curl "http://metadata.google.internal/computeMetadata/v1/$metadata-uri" -H "Metadata-Flavor: Google"

• $metadata-uri:
  • URI d'une clé de métadonnées renvoyant une valeur unique, ex :
    • instance/image
    • instance/tags
  • URI d'un répertoire de métadonnées renvoyant une liste d'autres URI disponibles, ex :
    • instance/disks
• Le paramètre de requête « alt » peut être utilisé pour formater les données. Les valeurs possibles sont « text » ou « json ». Ex :
  • ${metadata_server_root_url}/instance/tags?alt=text
• Les entrées Etags du serveur de métadonnées sont présentes dans les en-têtes de réponse. Une valeur Etag différente signifie une version de valeur de métadonnées différente (la valeur a été mise à jour)
• Les codes d'état et les significations des réponses du serveur de métadonnées peuvent être trouvés ici
• Le serveur de métadonnées prend également en charge les métadonnées personnalisées qui peuvent être configurées pendant la Création de VM ou pour des VM déjà existantes
• Obtenir des informations sur les métadonnées à partir de la CLI :

# Project metadata
gcloud compute project-info describe --flatten="commonInstanceMetadata[]"

# Instance metadata
gcloud compute instances describe $vm_name --flatten="metadata[]"

GCE spot ou préemptif

GCE préemptif

• Une instance GCE dont la disponibilité n'est pas garantie en cas de besoin. Google peut utiliser ses ressources de calcul réservées à d'autres fins à tout moment
• Conçu pour le calcul par lots, tolérant aux pannes et à haut débit
• Instances à très faible coût et à court terme (jusqu'à 91 % d'économies par rapport aux instances standard)

Scripts de démarrage et d'arrêt

Scripts de démarrage

• Scripts exécutés au démarrage ou à l'arrêt des instances GCE
• Les scripts sont exécutés uniquement dans la mesure du possible
• Ils sont exécutés par l'utilisateur « root » sous Linux et par l'utilisateur « System » sous Windows
• Peut être configuré au niveau de la machine virtuelle ou du projet. Les scripts au niveau du projet se déclenchent pour chaque machine virtuelle du projet
• Les scripts au niveau des machines virtuelles ont priorité sur ceux au niveau du projet
• Les scripts d'arrêt ont des délais d'attente (timeouts) :
  • « 90 secondes » pour les machines virtuelles « standard »
  • « 30 secondes » pour les machines virtuelles « préemptibles »
• Transmis en tant que « métadonnées » aux machines virtuelles, soit « directement », soit à partir d'un « fichier » :

# Script passed at command line
gcloud compute instances create myvm --metadata=startup-script='#!/bin/bash
      the rest 
      of the script'`

# Script passed from a file
# The file path can also be a GCS bucket URL

# Startup
gcloud compute instances create myvm --metadata-from-file=startup-script=<file_path>

# Shutdown
gcloud compute instances create myvm --metadata-from-file=shutdown-script=<file_path>

Nœuds Sole-Tenant

Nœuds Sole-Tenant | Article de blog sur les nœuds Sole-Tenant

• Un service qui peut être utilisé pour réserver des machines physiques dédiées qui seront utilisées comme hyperviseurs pour créer des machines virtuelles
• Exécute des machines virtuelles pour consommer les ressources de l'hôte

Groupes d'instances gérés (MIG)

Groupes d'instances

• Un service qui peut être utilisé pour exécuter des machines virtuelles à grande échelle (jusqu'à des milliers de machines virtuelles)
• Prend en charge la mise à l'échelle, la réparation et la mise à jour automatiques
• Instances avec ou sans état, régionales, monozones ou multizones
• La mise à l'échelle automatique MIG pourrait être basée par exemple sur :
  • l'utilisation du processeur
  • le nombre de requêtes HTTP(s)
  • les métriques standard ou personnalisées provenant de la Cloud Monitoring service
• MIG dispose également d'une fonctionnalité permettant de planifier une mise à l'échelle automatique en spécifiant par exemple :
  • les instances de calcul min et max
  • la durée
  • l'heure de début
  • la fréquence
  • (...)
• MIG prend en charge plusieurs stratégies de déploiement telles que « rolling update » (mises à jour nœuds par nœuds) ou « canary »
• Voici quelques mots-clés importants pour la stratégie de mise à jour nœuds par nœuds (rolling update) :
  • maxSurge:combien d'instances supplémentaires doivent être temporairement provisionnées (au-dessus du nombre souhaité)
  • minReadySeconds: le temps minimum d'attente pour les instances avant qu'elles ne soient réellement considérées comme saines
  • maxUnavailable: le nombre maximal d'instances qui peuvent être indisponibles pendant la mise à jour
  • targetSize: combien d'instances mettre à jour

Tarification et optimisation des coûts

Calculateur de prix | Réductions GCE | Types de machines personnalisées

• Utiliser des « machines virtuelles préemptives » pour les charges de travail tolérantes aux pannes
• Rabais pour utilisation durable (Sustained Use Discounts) :
  • jusqu'à 30 % d'économies sur GCE et Cloud SQL
• Remises sur engagement d'utilisation (Committed Use Discounts) :
  • jusqu'à 70 % d'économies sans frais initiaux ni verrouillage du type d'instance
• Facturation par seconde :
  • jusqu'à 38 % d'économies en payant à la seconde et non à l'heure
• Redimensionnement :
  • Choisissez les familles GCE optimales et les types de machines personnalisées
• Niveaux de service réseau :
  • performance: 70% de bande passante en plus
  • réduction des coûts: 9% d'économie par rapport aux autres clouds

Google Cloud Storage (GCS)

Croquis GCS

• Un stockage d'objets durable et hautement disponible
• Le stockage d'objets est une architecture de stockage de données informatiques qui gère les données en tant qu'objet, et non en tant que hiérarchie de fichiers et de dossiers (stockage de fichiers) ou en tant que bloc de disque (stockage en blocs).
• Les objets sont stockés dans un format packagé :
  • forme binaire des données
  • métadonnées associées pertinentes (date de création, auteur, type, permissions...)
  • Identifiant unique au niveau mondial (sous forme d'URL => bonne interaction avec les technologies Web)
• La taille maximale de l'objet est de 5 To
• Couramment utilisé comme stockage d'objets binaires volumineux (BLOB) pour le contenu en ligne (vidéos, images, audio), la sauvegarde et l'archivage, le stockage de résultats intermédiaires et les flux de travail de traitement
• Peut également être utilisé pour :
  • hébergement de sites Web
  • archivage et reprise après sinistre
  • téléchargement direct
• Pour utiliser GCS, nous devons créer un . pour stocker les données
• Les noms des buckets GCS sont uniques au monde
• Lors de la création d'un bucket GCS, nous avons le choix entre une disponibilité régionale, birégionale ou multirégionale
• Voici quelques fonctionnalités intéressantes des buckets GCS :
  • stockage « illimité »
  • entièrement géré
  • évolutive
  • faible latence
  • haute durabilité
  • accessibilité mondiale
  • redondance géographique
  • TLS, HTTPS...
• Les objets stockés dans les buckets GCS sont immuables... de nouvelles versions sont créées à chaque modification apportée
• Par défaut, les nouvelles versions d'objets remplacent les anciennes. En activant la « gestion des versions d'objets », les anciennes versions d'objets sont conservées et l'historique peut être utilisé pour restaurer une version d'objet spécifique
• Les rôles IAM et les « ACL (listes de contrôle d'accès) » peuvent être utilisés pour accorder ou restreindre l'accès aux buckets GCS. Les ACL sont utilisées pour un contrôle plus précis
• Le stockage dans le cloud propose des « politiques de cycle de vie » qui peuvent être configurées pour effectuer des actions automatisées. Ex :
  • supprimer les objets datant de plus de 365 jours
  • supprimer les objets créés avant le MM/JJ/AA
  • conserver uniquement les 3 versions les plus récentes
• Coud Storage (GCS) propose également des « politiques de conservation » qui peuvent être utilisées pour empêcher la modification ou la suppression d'objets pendant une période donnée.
• Les « politiques de conservation » et la « gestion des versions d'objets » s'excluent mutuellement (lorsque l'une est active, l'autre est désactivée)
• Il est également possible de verrouiller la « politique de conservation ». Dans ce cas, personne ne pourra modifier les paramètres de la « politique de conservation » jusqu'à l'expiration de la période de conservation.
• Le stockage en cloud propose également des « classes de stockage » :
  • Standard:mieux pour les données fréquemment consultées ou chaudes et les données qui ne sont stockées que pendant une courte période => fréquence d'accès élevée + faible rétention
  • Près de la ligne:mieux pour les données consultées une fois par mois
  • Ligne froide:mieux pour les données consultées une fois tous les 3 mois
  • Archivage:mieux pour les données consultées une fois par an (option la moins coûteuse)
  • Classement automatique: déplace automatiquement les objets entre les quatre classes de stockage précédentes pour optimiser les coûts et l'accès aux données en fonction de chaque modèle d'accès aux objets. Les données les moins fréquemment consultées sont déplacées vers un stockage plus froid pour optimiser les coûts de stockage et celles fréquemment consultées depuis un stockage plus froid sont déplacées vers un stockage standard pour optimiser les accès futurs
• Les prix des buckets GCS sont les suivants :
  • il n'y a pas de tarif minimum, vous payez ce que vous consommez :
    • prix pour le volume de données stockées (varie selon la classe de stockage)
    • prix pour le volume de trafic réseau sortant
• Pour transférer des données vers des buckets GCS, nous pouvons utiliser :
  • l'utilitaire de ligne de commande « gsutil »
  • la « console cloud »
  • le « Service de transfert de stockage » pour les transferts de données volumineux (To ou Po) :
    • planifie et gère les transferts par lots à partir d'autres fournisseurs de cloud, d'une autre région GCS ou d'un point de terminaison HTTPS
  • le « dispositif de transfert », qui est un serveur de stockage rackable de grande capacité (jusqu'à Peta Byte de données) loué auprès de Google Cloud qui doit être connecté au réseau interne pour télécharger des données, puis expédié vers une installation de téléchargement pour télécharger les données vers GCS
• GCS dispose également d'une intégration avec d'autres produits Google Cloud comme CloudSQL, BigQuery... Par exemple, nous pouvons :
  • importer/exporter des tables vers/depuis BigQuery ou CloudSQL
  • stocker les journaux App Engine
  • stocker les objets utilisés par les applications App Engine (images...)
  • stocker des sauvegardes Firestore, des sauvegardes CloudSQL....
  • stocker les scripts de démarrage GCE, les images GCE...

Ressources de base de données

Croquis de bases de données

Cloud SQL

Croquis de Cloud SQL

• Cloud SQL est un service de base de données relationnelle entièrement géré pour MySQL, PostgreSQL et SQL Server
• Évolutif jusqu'à 128 cœurs de processeur, 864 Go de RAM et 64 To de stockage
• Prend en charge les sauvegardes et restaurations entièrement automatisées
• Le coût d'une instance couvre 7 sauvegardes
• Les données sont chiffrées sur le réseau interne de GCP et au repos
• Prend en charge les répliques de lecture, les instances régionales et multirégionales pour une haute disponibilité

AlloyDB

Présentation d'AlloyDB

• Service de base de données entièrement géré compatible PostgreSQL
• Pour des applications telles que le traitement transactionnel et analytique hybride
• Traitement transactionnel rapide, hautement disponible
• Tâches administratives automatisées : sauvegardes, réplication, correctifs, gestion de la capacité

Cloud Spanner

Croquis Cloud Spanner

• Service de base de données relationnelle entièrement géré
• Hautement disponible, évolutif (scalable) horizontalement, cohérence forte (strong consistency), parle SQL, réplication automatique => le meilleur des bases de données relationnelles et non relationnelles
• ~ pétaoctets en capacité
• Utilisé par certaines applications critiques de Google

Cloud Firestore

Croquis de Firestore

• Base de données NoSQL flexible et évolutive (scalable) horizontalement
• Transactions ACID => si une opération de la transaction échoue et ne peut pas être relancée, la transaction entière échouera
• Réplication multirégionale automatique et cohérence forte (strong consistency)
• Exécute des requêtes complexes sans dégradation des performances
• Données stockées dans des documents organisés en collections
• Les documents contiennent un ensemble de paires clé/valeur
• Taille maximale de l'unité : 1 Mo par entité
• Les requêtes noSQL de Firestore peuvent être utilisées pour récupérer des documents individuels ou tous les documents d'une collection. Elles peuvent inclure plusieurs filtres enchaînés ou combiner des options de filtrage et de tri
• Les requêtes sont indexées par défaut => performances proportionnelles à la taille de l'ensemble de résultats, et non à l'ensemble de données
• Firestore propose également :
  • réplication automatique de données multirégionales
  • une cohérence forte (strong consistency) garantie
  • des opérations par lots atomiques
  • une prise en charge des transactions en temps réel
  • des requêtes hors ligne
• Prix :
  • facturé pour chaque document lu, écrit et supprimé
  • requêtes facturées comme un document lu (par requête)
  • la quantité de stockage de base de données et de bande passante réseau utilisée (après avoir soustrait les jusqu'à 10 Go de trafic réseau en sortie gratuits par mois entre les régions des États-Unis)
• Dispose de quotas gratuits par jour :
  • 50,000 documents lus
  • 20,000 documents écrits
  • 20,000 documents supprimés
  • 1 Go de données stockées

Cloud Big Table

Croquis de Bigtable

• Service de base de données Big Data NoSQL
• Pas ACID => bon lorsque la cohérence transactionnelle (transactional consistency) n'est pas requise
• Capacité de stockage jusqu'au pétaoctets, débit de lecture et d'écriture élevé et faible latence
• Utilisée par le moteur de recherche Google, Analytics, Maps et Gmail
• Idéal pour les applications adtech, fintech, IOT et ML
• Intégration facile avec des outils Big Data open source comme Hadoop et Apache Hbase, mais aussi des services GCP comme Cloud Dataflow et Cloud Dataproc
• Taille maximale de l'unité : 10 Mo par cellule, 100 Mo par ligne
• Bon pour :
  • stocker une grande quantité d'objets structurés
  • données analytiques avec des événements de lecture et d'écriture importants
• Le plus petit cluster Bigtable :
  • 3 nœuds, jusqu'à 30000 opérations par seconde
  • rappelez-vous, vous payez pour ces nœuds, que les applications les utilisent ou non
• Utilisez Bigtable dans ces cas :
  • La taille de vos données est d'au moins 1 To
  • Vous avez un volume d'écritures élevé
  • Vous avez besoin d'une latence de lecture/écriture < 10 ms
  • Vous avez besoin d’une cohérence forte (strong consistency)
  • Vous avez besoin d'une API compatible HBase
• Sinon, utilisez Cloud Firestore

Ressources de conteneurs

Cloud Run

Croquis de Cloud Run

• Une plate-forme de calcul gérée qui peut exécuter des conteneurs sans état via des requêtes Web ou des événements de publication/abonnement
• Sans serveur => supprime le besoin de gestion de l'infrastructure
• Construit sur Knative, une API et un environnement d'exécution basés sur Kubernetes
• Rapide, scalable à partir de zéro presque instantanément, en facturant uniquement les ressources utilisées
• Flux de travail (workflow) du développeur Cloud Run :
  • écrire le code de l'application. L'application doit démarrer un serveur qui écoute les requêtes Web
  • créer + empaqueter l'application dans une image de conteneur et pousser l'image dans le Registre d'artefacts
  • déployer l'image du conteneur d'application dans Cloud Run
• Une fois déployée, nous obtenons une URL HTTPS unique pour accéder à l'application
• Cloud Run démarre ensuite les conteneurs d'application à la demande pour gérer les demandes et garantit que toutes les demandes entrantes sont traitées en ajoutant et en supprimant dynamiquement des conteneurs.
• L'utilisation du « flux de travail basé sur des conteneurs » offre transparence et flexibilité
• Avec Cloud Run, nous pouvons également utiliser le « flux de travail basé sur la source » pour déployer nos applications
• Le « flux de travail basé sur la source » déploie le code source au lieu d'une image de conteneur. Cloud Run crée et déploie automatiquement une image de conteneur contenant le code source de l'application à l'aide de « buildpacks » (un projet open source)
• Modèle de tarification :
  • payez uniquement pour les ressources système utilisées pendant que les conteneurs gèrent les requêtes Web, avec une granularité de 100 ms, et pendant le démarrage et l'arrêt des conteneurs... ressources non facturées lorsque le conteneur ne traite pas de requêtes HTTP
  • il y a également de petits frais pour chaque million de demandes traitées
  • le prix du temps de conteneur augmente avec le CPU et la mémoire... Un conteneur avec plus de vCPU et de mémoire est plus cher
  • Cloud Run peut exécuter n'importe quel binaire compilé pour Linux 64 bits => des langages populaires comme Java, Python, Node.js, PHP, GO, C++ peuvent être utilisés pour exécuter des applications Web dans Cloud Run. Des langages moins populaires comme Cobol, Haskell, Perl peuvent également être utilisés

Google Kubernetes Engine (GKE)

Croquis GKE | Documentation GKE | Versions et fonctionnalités de GKE

Voici quelques éléments importants que nous devons savoir lors de la création d'un cluster GKE « standard ».

Réseau du cluster

• La plage de sous-réseaux privés principale associée au cluster sera utilisée pour attribuer des adresses IP aux « nœuds » et aux services du cluster de type « LoadBalancer ». Ce sous-réseau est également appelé sous-réseau primaire
• En plus de la plage de sous-réseaux principale, un réseau GCP (VPC) peut également avoir des plages de sous-réseau secondaire qui lui sont associées
• Les plages de sous-réseaux secondaires seront utilisées pour attribuer des adresses IP aux « pods » et aux « services » du cluster GKE avec un type autre que « LoadBalancer »
• Vous choisissez le sous-réseau secondaire à utiliser pour les « pods » ou les « services » lors de la création d'un pool de nœuds dans le cluster, en spécifiant le nom du sous-réseau secondaire
• Vous pouvez créer N sous-réseaux secondaires à utiliser par les « pods » et les « services » de vos pools de nœuds comme vous le souhaitez. Vous êtes simplement limité par le nombre de sous-réseaux secondaires que vous pouvez ajouter à un réseau GCP (VPC)

Nombre de pods par nœud

• Le nombre de pods par nœud que vous choisissez lors de la création d'un pool de nœuds est très important car il définit également le nombre de nœuds que vous pourrez créer dans ce pool de nœuds.
• Supposons que la plage réseau « 10.100.1.0/20 » soit celle réservée aux pods sur le pool de nœuds principal. Les plages de sous-réseaux les plus petites et les plus grandes qui peuvent être réservées aux pods sur un seul nœud dans ce pool de nœuds sont respectivement « /28 » et « /24 » extraites du réseau « 10.100.1.0/20 »
• La plage de sous-réseau « /28 » sera réservée aux pods sur les nœuds du pool de nœuds principal lorsque la valeur des pods par nœud est définie sur « 8 » et la plage « /24 » réservée lorsque cette valeur est comprise entre « 65 » et « 110 »
• Si un '/28' est réservé, et parce que dans le '10.100.1.0/20' nous avons '256' sous-réseaux de taille '/28', le nombre de nœuds que vous pourrez créer dans le pool de nœuds principal sera '256'
• Si un '/24' est réservé, et parce que dans le '10.100.1.0/20' nous avons '16' sous-réseaux de taille '/24', le nombre de nœuds que vous pourrez créer dans le pool de nœuds principal sera '16'
• La relation entre la valeur des pods par nœud sur un pool de nœuds donné et la taille du sous-réseau réservé aux pods sur ce pool de nœuds est décrite sur cette page : gcp flexible pod cidr

Ressources serverless

Fonctions cloud

Croquis de fonctions cloud

• Solution de calcul légère, basée sur les événements et asynchrone
• Permet de créer de petites fonctions à usage unique qui répondent aux événements du cloud sans avoir besoin de gérer des serveurs ou des environnements d'exécution
• Peut être utilisé pour construire des flux de travail d'applications à partir de tâches de logique métier individuelles et pour connecter et étendre des services cloud
• Facturé à 100 ms près, et uniquement pendant que le code est en cours d'exécution
• Les langages pris en charge incluent : Node.js, Python, Go, Java, .Net Core, Ruby et PHP
• Les événements GCS et Pub/Sub peuvent déclencher des « fonctions Cloud » de manière asynchrone
• L'invocation HTTP peut également être utilisée pour exécuter des fonctions Cloud de manière synchrone

Ressources d'analyse de données

Croquis d'analyse de données | Croquis du pipeline d'analyse des données

• Dataflow: service managé pour le traitement de données
• Dataproc: service managé Spark et Hadoop
• Service BigQuery: frontière entre le stockage et le traitement des données. Analyse Big Data et capacité de requête interactive
• Data/looker studio: transformez les données en tableaux de bord informatifs entièrement personnalisables, faciles à lire et à partager

Autres services de stockage

Filestore

Page produit Filestore | Documentation de Filestore

• NAS managé pour GCE et GKE
• Performances prévisibles
• Prise en charge complète de NFSv3
• Verrouillage de fichiers (lock)
• Jusqu'à ~ 100 To de capacité

Memorystore

Page produit Memorystore | Documentation de Memorystore

• Service de stockage de données en mémoire
• Haute disponibilité, basculement (failover), correctifs et surveillance
• Jusqu'à 300 Go d'espace de stockage, latence inférieure à la milliseconde
• Débit réseau de 13 Gbit/s
• Entièrement compatible avec le protocole Redis => déplacez et déplacez vos applications sans aucune modification de code

Artifact registry

Documentation d'artifact registry

Stockez des images de conteneurs et des packages d'applications... peut servir de proxy vers des référentiels de packages officiels pour de nombreux langages de programmation (npm, pypi, maven...).

Surveillance et journalisation

Le Monitoring

• Le service de surveillance dans GCP s'appelle Cloud Monitoring (anciennement Stackdriver)
• La surveillance est la base de l'ingénierie de fiabilité de site (SRE)
• SRE (Site Reliability Engineering) est une discipline née chez Google
• Google utilise les principes SRE pour créer, surveiller et maintenir certains des plus grands systèmes logiciels au monde
• SRE applique certains principes d'ingénierie logicielle aux opérations afin de créer des systèmes logiciels très fiables et faciles à faire évoluer
• Les principes SRE incluent la « surveillance », la « réponse aux incidents », les « analyses post-mortem » ou « analyses des causes profondes », les « procédures de test et de publication », la « planification des capacités », etc.
• Le service Cloud Monitoring de GCP configure dynamiquement la surveillance après le déploiement d'une ressource, avec des valeurs par défaut intelligentes
• Cela permet de surveiller les plateformes via :
  • les métriques de plateformes, systèmes et applications
  • tableaux de bord/graphiques et alertes
  • contrôles de disponibilité/santé

La journalisation (logs)

• Le service de journalisation de GCP s'appelle Cloud Logging (anciennement Stackdriver)
• Tous les journaux des ressources d'un projet GCP sont stockés dans des buckets GCS
• Pour voir les buckets utilisés pour stocker les journaux d'un projet, utilisez :

$ gcloud logging buckets list
LOCATION  BUCKET_ID  RETENTION_DAYS  CMEK  RESTRICTED_FIELDS  INDEX_CONFIGS  LIFECYCLE_STATE  LOCKED  CREATE_TIME  UPDATE_TIME
global    _Default   30                                                      ACTIVE
global    _Required  400                                                     ACTIVE           True

• Les journaux (logs) des projets sont par défaut stockés à l'intérieur des buckets _Default et _Required .
• À l'intérieur des « buckets de journalisation », les journaux sont organisés en « conteneurs de journaux » (selon leurs types)
• Pour répertorier les conteneurs de journaux d'un projet, utilisez :

$ gcloud logging logs list
projects/myproject/logs/GCEGuestAgent
projects/myproject/logs/OSConfigAgent
projects/myproject/logs/cloudaudit.googleapis.com%2Faccess_transparency
projects/myproject/logs/cloudaudit.googleapis.com%2Factivity
projects/myproject/logs/cloudaudit.googleapis.com%2Fdata_access        
projects/myproject/logs/cloudaudit.googleapis.com%2Fsystem_event       
projects/myproject/logs/clouderrorreporting.googleapis.com%2Finsights  
projects/myproject/logs/cloudscheduler.googleapis.com%2Fexecutions     
projects/myproject/logs/cloudsql.googleapis.com%2Fmysql.err
projects/myproject/logs/cloudsql.googleapis.com%2Fpostgres.log
projects/myproject/logs/compute.googleapis.com%2Fhealthchecks
projects/myproject/logs/compute.googleapis.com%2Fshielded_vm_integrity
projects/myproject/logs/container-runtime
projects/myproject/logs/container.googleapis.com%2Fcluster-autoscaler-visibility
projects/myproject/logs/diagnostic-log
projects/myproject/logs/docker
projects/myproject/logs/events
(...)

• Pour lire les journaux de n’importe quel conteneur de journaux, utilisez :

gcloud logging read "LOG_FILTER"

• Nous pouvons éventuellement utiliser les options suivantes :
  • --order=ORDER: desc (par défaut) ou asc pour modifier l'ordre dans lequel les journaux sont affichés
  • --organization=ORGANIZATION_ID, --project=PROJECT_ID, --folder=FOLDER_ID: sélectionnez l'organisation, le projet ou le dossier GCP à partir duquel lire les journaux
  • --bucket=BUCKET, --location=LOCATION: sélectionnez le bucket et l'emplacement du bucket à partir duquel lire les journaux
  • --limit=LIMIT: limiter le nombre d'entrées renvoyées
• LOG_FILTER est une expression de filtre utilisée pour récupérer des entrées de journal spécifiques. Pour plus de détails, voir langage de requête de journalisation gcp
• Voici un exemple :

# Activity logs of a pod in specific time interval

$ gcloud logging read 'protoPayload.resourceName:mypod AND protoPayload.resourceNamespace:mynamespace AND logName:projects/mygcpproject/logs/cloudaudit.googleapis.com%2Factivity AND timestamp>="2024-05-14T06:05:54.238629139Z" AND timestamp<="2024-05-14T13:16:54.238629139Z"' --limit 1
---
insertId: c9bfcdbf-9be3-4401-8fc0-b9bbdaaca1dc
labels:
  authorization.k8s.io/decision: allow
  authorization.k8s.io/reason: 'RBAC: allowed by ClusterRoleBinding "system:controller:generic-garbage-collector"
    of ClusterRole "system:controller:generic-garbage-collector" to ServiceAccount
    "generic-garbage-collector/kube-system"'
logName: projects/mygcpproject/logs/cloudaudit.googleapis.com%2Factivity
operation:
  first: true
  id: c9bfcdbf-9be3-4401-8fc0-b9bbdaaca1dc
  last: true
  producer: k8s.io
protoPayload:
  '@type': type.googleapis.com/google.cloud.audit.AuditLog
  authenticationInfo:
    principalEmail: system:serviceaccount:kube-system:generic-garbage-collector
  authorizationInfo:
  - granted: true
    permission: com.victoriametrics.operator.v1beta1.vmservicescrapes.delete
    resource: operator.victoriametrics.com/v1beta1/namespaces/mynamespace/vmservicescrapes/mypod
  methodName: com.victoriametrics.operator.v1beta1.vmservicescrapes.delete
  requestMetadata:
    callerIp: 10.201.10.42
    callerSuppliedUserAgent: kube-controller-manager/v1.27.11 (linux/amd64) kubernetes/2cefead/system:serviceaccount:kube-system:generic-garbage-collector
  resourceName: operator.victoriametrics.com/v1beta1/namespaces/mynamespace/vmservicescrapes/mypod
  serviceName: k8s.io
  status:
    code: 0
receiveTimestamp: '2024-05-14T08:55:59.938400352Z'
resource:
  labels:
    cluster_name: mygkecluster
    location: europe-west1
    project_id: mygcpproject
  type: k8s_cluster
timestamp: '2024-05-14T08:55:58.827020Z'

• Voici les détails sur les autorisations requises pour la gestion des journaux :
  • Autorisations requises pour explorer les journaux
  • Rôles IAM pour la journalisation
• GCP dispose également d'une interface web d'exploration de journaux disponible via la Console cloud. Voici un lien pour un aperçu :
  • Explorateur de journaux GCP
• Toutes les entrées de journaux sont des instances de LogEntry. Voici la liste actuelle des champs d'une entrée de journal :
  • Champs d'une entrée du journal
• Pour afficher en continu (tails) les journaux à partir de la ligne de commande, jetez un œil à :
  • Suivi des journaux GCP avec gcloud
• Pour en savoir plus sur la lecture et l'écriture des journaux à l'aide de « gcloud », consultez :
  • Journalisation gcloud
• Voici un lien pour le format du champ « logName » : Format du champ logName
• Voici la documentation de la liste des journaux de plateforme disponibles (valeurs pour le champ « logName » des entrées de journal) et leurs descriptions + les types de ressources associés (valeurs pour le champ « resource.type » des entrées de journal) :
  • Liste des journaux plateforme
• Voici une cartographie des services GCP vers les types de ressources de journalisation : Services GCP pour le mappage des types de ressources de journalisation
• Autres liens de documentation utiles :
  • Structure de l'entrée du journal
  • Routage des journaux
  • Conservation des journaux
  • Tarification des journaux

Les journaux d'audit

Journaux d'audit GCP | Journaux d'audit GKE

• Les « journaux d'audit » représentent les journaux des activités des principaux utilisateurs (utilisateurs, comptes de service...) sur GCP, concernant les ressources et les accès et modifications des données des ressources
• Rôles requis pour l'affichage des journaux d'audit :
  • roles/logging.viewer: lire les journaux autres que les journaux d'audit « Accès aux données » qui sont stockés dans le bucket _Default .
  • roles/logging.privateLogViewer: accès à tous les journaux à l'intérieur des buckets _Required et _Default comprenant les journaux « Accès aux données »
• Types de journaux d'audit :
  • Journaux d'audit des activités d'administration: Appels d'API ou actions qui modifient les configurations de ressources ou les métadonnées. Toujours écrit. Ne ​​peut pas être désactivé. Le « sous-type » des journaux d'audit pour ce type de journaux est ADMIN_WRITE.
    • Exemples d'actions écrites sous forme de journal d'audit « Activité d'administration » : créer ou modifier une ressource de compartiment de stockage Cloud
  • Journaux d'audit d'accès aux données: Appels d'API ou actions qui lisent les configurations de ressources ou les métadonnées + appels d'API pilotés par l'utilisateur qui créent, modifient ou lisent. Désactivé par défaut. Doit être activé par service GCP à l'aide des « sous-types » de journaux d'audit suivants :
    • DATA_READ: enregistre uniquement les actions de lecture des données
    • DATA_WRITE: enregistre les actions de création et de modification des données
    • ADMIN_READ: enregistre les configurations de ressources ou les actions de lecture de métadonnées
    • Exemples d'actions écrites sous forme de journaux d'audit « Accès aux données » : lire les métadonnées d'une ressource de compartiment de stockage Cloud, créer, lire ou supprimer un objet de compartiment de stockage Cloud
    • Pour activer les journaux d'audit « Accès aux données », utilisez ceci.
  • Journaux d'audit des événements système: enregistre les entrées pour les actions Google Cloud (pas les actions directes des utilisateurs) qui modifient les configurations des ressources. Toujours écrit. Ne peut être désactivé.
  • Journaux d'audit de refus par politique: enregistre les entrées générées lorsqu'un service Google Cloud refuse l'accès à un utilisateur ou à un compte de service en raison d'une violation de la politique de sécurité. Écrit par défaut. Le projet est facturé pour le stockage de ces journaux. Les Filtres d'exclusion peuvent être utilisés pour empêcher que ces journaux soient stockés dans Cloud Logging (pour limiter par exemple les frais liés aux volumes de logs stockés)
• Voici les noms des journaux pour chaque type de journaux d'audit :
  • activités d'administration (activity) : projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Factivity
  • accès aux données (data access) : projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fdata_access
  • événement système (system event) : projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fsystem_event
  • refus par politique (policy denied) : projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fpolicy
• Autres liens de documentation utiles :
  • Types, sous-types et actions associées des journaux d'audit
  • Format des entrées des journaux d'audit (version simple)
  • Format des entrées des journaux d'audit (version détaillée)
  • Liste des services GCP écrivant des journaux d'audit
  • Stockage et routage des journaux d'audit
  • Conservation des journaux d'audit
  • Limites d'utilisation et quotas des journaux d'audit
  • Tarification des journaux d'audit
  • Affichage des journaux d'audit