← Google Cloud pour les devs : gcloud et Cloud Logging

Google Cloud et la CLI gcloud

≈ 30 minutes · Jalon M1

Le gain du jour : savoir où vit une ressource Google Cloud, qui a le droit d’y toucher, et piloter tes projets depuis le terminal avec gcloud sans jamais te tromper d’environnement.

Google Cloud, c’est quoi ?

Google Cloud est un ensemble de services que Google loue à la demande : des machines, des bases de données, du stockage, des files de messages, et des outils d’observabilité comme Cloud Logging. Tu ne gères pas de serveurs physiques. Tu demandes une ressource, Google la fait tourner, et tu paies ce que tu consommes.

Trois questions reviennent tout le temps :

Où est rangée cette ressource ? (la hiérarchie)
Qui a le droit de la lire ou de la modifier ? (IAM)
Comment je la manipule depuis mon poste ? (la CLI gcloud)

On les prend dans cet ordre.

La hiérarchie des ressources

Tout ce que tu crées dans Google Cloud est rangé dans un arbre. On le construit en partant du bas.

Une ressource, c’est un objet concret : un service Cloud Run, un bucket, un sujet Pub/Sub. Chaque ressource appartient à un projet :

 📦 Projet "api-panier-dev"
   ├── ☁️ Cloud Run : api-panier
   └── 🪣 Bucket : factures-dev

Les projets peuvent être regroupés dans des dossiers, par équipe ou par environnement :

 📁 Dossier "Paiement"
   ├── 📦 Projet "api-panier-dev"
   │     ├── ☁️ Cloud Run : api-panier
   │     └── 🪣 Bucket : factures-dev
   └── 📦 Projet "api-panier-prod"

Au sommet, l’organisation représente l’entreprise entière, liée à son domaine (par exemple exemple.com) :

 🏢 Organisation exemple.com
   └── 📁 Dossier "Paiement"
         ├── 📦 Projet "api-panier-dev"
         │     ├── ☁️ Cloud Run : api-panier
         │     └── 🪣 Bucket : factures-dev
         └── 📦 Projet "api-panier-prod"

Les droits se transmettent vers le bas : un rôle donné sur le dossier « Paiement » s’applique à tous ses projets et à leurs ressources. Avec un compte Gmail personnel, tu n’as souvent que des projets. C’est normal.

Trois façons de nommer un projet

Identifiant	Exemple	Qui le choisit	Modifiable ?
Nom (project name)	`API Panier (dev)`	Toi, pour les humains	Oui
ID (project ID)	`api-panier-dev`	Toi, à la création, unique dans tout Google Cloud	Non, jamais
Numéro (project number)	`123456789012`	Google, automatiquement	Non

C’est l’ID que tu tapes dans gcloud. Le numéro apparaît dans certains messages d’erreur et dans les noms de comptes de service. Le nom ne sert qu’à l’affichage dans la console.

Le compte de facturation

Un projet ne paie pas tout seul. Il est lié à un compte de facturation (billing account), qui porte le moyen de paiement. Plusieurs projets peuvent partager le même compte. Sans compte lié, la plupart des services refusent de démarrer.

IAM : qui peut faire quoi

IAM (Identity and Access Management) répond à une seule question : est-ce que cette identité a le droit de faire cette action sur cette ressource ? Trois mots à connaître :

Principal : l’identité qui agit. Un utilisateur (user:alice@exemple.com), un groupe, ou un compte de service.
Rôle : un paquet de permissions. Par exemple roles/logging.viewer contient le droit de lire les logs.
Stratégie (policy) : la liste attachée à une ressource qui dit « tel principal a tel rôle ici ».

Il existe deux grandes familles de rôles :

Famille	Exemples	Usage
Rôles de base (basic)	`roles/owner`, `roles/editor`, `roles/viewer`	Très larges, couvrent presque tous les services. À éviter en production.
Rôles prédéfinis (predefined)	`roles/logging.viewer`, `roles/run.developer`	Ciblés sur un service et un usage. Le bon choix par défaut.

La règle d’or s’appelle le moindre privilège : donne le rôle le plus petit qui permet de faire le travail, sur la ressource la plus petite possible. Lire des logs ? roles/logging.viewer sur le projet, pas roles/editor.

Un compte de service (service account) est une identité pour un programme, pas pour une personne. Ton service Cloud Run tourne avec un compte de service, et c’est ce compte qui reçoit les rôles dont l’application a besoin. Son adresse ressemble à mon-app@api-panier-dev.iam.gserviceaccount.com.

La CLI gcloud

gcloud est l’outil en ligne de commande de Google Cloud. Tout ce que tu fais dans la console web, tu peux le faire (et le scripter) avec elle. Elle fait partie du Google Cloud CLI, à installer depuis la documentation officielle (paquet macOS, Linux, Windows, ou brew install --cask gcloud-cli sur Mac).

La première commande à lancer :

gcloud init

Elle t’ouvre le navigateur pour te connecter, te fait choisir un projet par défaut, et enregistre le tout dans une configuration nommée default. Pour vérifier :

gcloud config list      # compte et projet actifs
gcloud auth list        # comptes connectés, l'actif est marqué d'une *

Deux connexions différentes : le piège classique

Il y a deux commandes de connexion, et elles ne servent pas la même chose.

gcloud auth login

Elle connecte la CLI gcloud elle-même. Après ça, gcloud logging read ou gcloud run deploy agissent avec ton compte.

gcloud auth application-default login

Elle crée les Application Default Credentials (ADC) : un fichier d’identifiants stocké à un emplacement connu, que les bibliothèques clientes (le SDK Python google-cloud-logging, par exemple) vont chercher toutes seules quand ton code tourne en local.

On dessine le chemin en deux temps. D’abord, la CLI :

 👤 Toi ── gcloud auth login ──▶ 🔑 identifiants gcloud ──▶ 💻 commandes gcloud

Puis, à côté, ton code :

 👤 Toi ── gcloud auth login ──────────────────▶ 🔑 identifiants gcloud ──▶ 💻 commandes gcloud

 👤 Toi ── gcloud auth application-default login ▶ 🔑 fichier ADC ──▶ 🐍 ton script Python
                                                                       (bibliothèques clientes)

Les deux chemins ne se croisent pas. Être connecté dans gcloud ne connecte pas ton script, et l’inverse non plus.

Le symptôme typique

gcloud logging read marche parfaitement dans ton terminal, mais ton script Python plante avec une erreur du genre « Your default credentials were not found ». Ce n’est pas un bug de ton code : tu as fait gcloud auth login mais pas gcloud auth application-default login. En production, tu n’utilises ni l’un ni l’autre : l’application prend l’identité de son compte de service.

Changer de projet sans se tromper

Pour changer le projet par défaut de la configuration active :

gcloud config set project api-panier-dev
gcloud config get project       # vérifie

Pour une seule commande, sans rien changer à la configuration, le flag global --project suffit :

gcloud services list --enabled --project=api-panier-prod

Quand tu jongles entre dev, staging et prod, les configurations nommées évitent de retaper config set à chaque fois. Chacune garde son propre compte et son propre projet :

gcloud config configurations create dev       # crée et active "dev"
gcloud config set project api-panier-dev

gcloud config configurations create prod
gcloud config set project api-panier-prod

gcloud config configurations activate dev     # bascule vers dev
gcloud config configurations list             # l'active est marquée True

Activer une API

Dans un projet, chaque service doit être activé avant usage. Pour Cloud Logging :

gcloud services enable logging.googleapis.com

Sur la plupart des projets, Logging est déjà actif. La commande ne fait alors rien de mal : tu peux la relancer sans risque.

Lire la sortie : —format et —filter

Ces deux flags existent sur presque toutes les commandes de liste.

--format choisit la forme de la sortie :

gcloud projects list --format=json                       # pour un script ou jq
gcloud projects list --format="table(projectId,name)"    # pour un humain
gcloud projects list --format="value(projectId)"         # valeurs brutes, une par ligne

--filter garde seulement les éléments qui correspondent :

gcloud projects list --filter="projectId:api-panier*" --format="value(projectId)"
gcloud auth list --filter=status:ACTIVE --format="value(account)"

Trouver l’aide

Personne ne retient tous les flags. Deux réflexes :

gcloud config set --help        # aide complète d'une commande
gcloud help config set          # même chose, autre écriture

Sur un groupe (gcloud logging --help), --help liste ses sous-commandes.

Vérifie ta compréhension

Ton script Python qui lit les logs avec google-cloud-logging échoue : « default credentials were not found ». Pourtant gcloud logging read marche dans le même terminal. Que fais-tu ?

Une collègue doit seulement lire les logs du projet api-panier-dev. Quel rôle lui donner ?

À toi de jouer

Installe le Google Cloud CLI, lance gcloud init, puis vérifie avec gcloud config list et gcloud auth list.
Lance gcloud auth application-default login pour que tes scripts locaux puissent eux aussi appeler Google Cloud.
Crée deux configurations nommées (dev et une autre), et bascule de l’une à l’autre avec gcloud config configurations activate.
Affiche l’ID de tes projets, un par ligne, avec gcloud projects list —format=“value(projectId)”.
Vérifie que Cloud Logging est actif : gcloud services enable logging.googleapis.com.

Dans les leçons suivantes, on utilise ce gcloud bien configuré pour lire, filtrer et écrire des logs avec Cloud Logging, directement depuis le terminal.

🗂 Fiche de référence associée : Google Cloud et gcloud — antisèche.