Cloud GCP Guide

GCP Guide

Workflow

1. Structurer la hiérarchie des ressources

Organization
└── Folder (prod / staging / dev)
    └── Project (une app ou un domaine)
        └── Resources (Cloud Run, BigQuery, etc.)

• Crée un projet distinct par environnement ; jamais partager des projets entre prod et non-prod.
• Attribue un budget + alerte à chaque projet dès la création.

gcloud projects create my-app-prod --folder=FOLDER_ID
gcloud billing projects link my-app-prod --billing-account=BILLING_ID
gcloud alpha billing budgets create \
  --billing-account=BILLING_ID \
  --display-name="my-app-prod budget" \
  --budget-amount=500USD \
  --threshold-rule=percent=0.8

2. IAM — moindre privilège dès le départ

• Un service account par workload, jamais la clé par défaut Compute.
• Préfère Workload Identity Federation (pas de clé JSON) pour les pipelines CI/CD.
• Rôles custom > rôles primitifs (Owner/Editor/Viewer).

# Créer un SA dédié
gcloud iam service-accounts create sa-cloud-run-api \
  --display-name="API Cloud Run"

# Binding minimal
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="serviceAccount:sa-cloud-run-api@PROJECT_ID.iam.gserviceaccount.com" \
  --role="roles/run.invoker"

3. Choisir le bon service de calcul

# Déployer sur Cloud Run depuis une image Artifact Registry
gcloud run deploy my-api \
  --image=europe-west1-docker.pkg.dev/PROJECT_ID/repo/my-api:latest \
  --region=europe-west1 \
  --platform=managed \
  --service-account=sa-cloud-run-api@PROJECT_ID.iam.gserviceaccount.com \
  --min-instances=0 \
  --max-instances=20 \
  --concurrency=80 \
  --no-allow-unauthenticated

4. Choisir le bon stockage de données

BigQuery — optimisations essentielles :

-- Toujours créer les tables partitionnées
CREATE TABLE `project.dataset.events`
PARTITION BY DATE(created_at)
CLUSTER BY user_id, event_type
OPTIONS (require_partition_filter = true)
AS SELECT * FROM staging.events WHERE FALSE;

-- Lire seulement les partitions nécessaires
SELECT user_id, COUNT(*) as cnt
FROM `project.dataset.events`
WHERE DATE(created_at) BETWEEN '2026-01-01' AND '2026-01-31'
GROUP BY user_id;

5. Réseau et sécurité

# VPC dédié avec sous-réseaux régionaux
gcloud compute networks create vpc-prod --subnet-mode=custom
gcloud compute networks subnets create subnet-west1 \
  --network=vpc-prod \
  --region=europe-west1 \
  --range=10.0.1.0/24 \
  --enable-private-ip-google-access

# Firewall — deny-all ingress par défaut, allow uniquement ce qui est nécessaire
gcloud compute firewall-rules create allow-internal \
  --network=vpc-prod \
  --action=ALLOW \
  --rules=tcp:8080 \
  --source-ranges=10.0.0.0/8

• Active VPC Service Controls pour confiner BigQuery / GCS dans un périmètre.
• Chiffrement CMEK obligatoire pour les données sensibles (clés dans Cloud KMS).
• Active Cloud Armor devant les Load Balancers exposés à Internet.

6. Pipeline de données événementiels

Source → Pub/Sub → Dataflow → BigQuery / Firestore
                 ↘ Cloud Run (webhook consumer)

# Créer un topic Pub/Sub et un abonnement avec dead-letter
gcloud pubsub topics create events-topic
gcloud pubsub topics create events-dead-letter
gcloud pubsub subscriptions create events-sub \
  --topic=events-topic \
  --dead-letter-topic=events-dead-letter \
  --max-delivery-attempts=5 \
  --ack-deadline=60

Utilise Dataflow (Apache Beam managé) pour les transformations à fort volume ; Cloud Composer (Airflow) pour l'orchestration batch planifiée.

7. Infrastructure as Code avec Terraform

# provider.tf
terraform {
  required_providers {
    google = { source = "hashicorp/google", version = "~> 5.0" }
  }
  backend "gcs" {
    bucket = "tfstate-my-app-prod"
    prefix = "terraform/state"
  }
}

# Cloud Run minimal
resource "google_cloud_run_v2_service" "api" {
  name     = "my-api"
  location = "europe-west1"
  template {
    service_account = google_service_account.run_sa.email
    containers {
      image = "europe-west1-docker.pkg.dev/${var.project_id}/repo/my-api:latest"
      resources { limits = { cpu = "1", memory = "512Mi" } }
    }
  }
}

• Un workspace Terraform par environnement (ou modules + tfvars).
• Stocke le state dans GCS avec versioning activé.

8. Observabilité

# Voir les logs Cloud Run en temps réel
gcloud logging read \
  'resource.type="cloud_run_revision" AND resource.labels.service_name="my-api"' \
  --project=PROJECT_ID \
  --freshness=1h \
  --format="table(timestamp,jsonPayload.message)"

# Créer une alerte sur erreurs 5xx
gcloud monitoring policies create --policy-from-file=alert-5xx.yaml

• Utilise Cloud Trace + Error Reporting dès le dev (zero-cost en dessous des quotas).
• Exporte les logs vers BigQuery pour des analyses long terme à moindre coût.

Critères de décision rapides

• Cloud Run vs GKE : préfère Cloud Run si pas de dépendance Kubernetes-native (DaemonSet, CRD, GPU) ; GKE sinon.
• Firestore vs Cloud SQL : Firestore si schéma flexible et accès mobile/web direct ; Cloud SQL si SQL strict et transactions complexes.
• Région : europe-west1 (Belgique) ou europe-west9 (Paris) pour la conformité RGPD Europe.

Anti-patterns et pièges

• Pas de partitionnement BigQuery → factures qui explosent ; toujours partitionner sur une colonne date.
• Clés JSON de service account committées → rotation immédiate + audit ; utiliser Workload Identity à la place.
• min-instances=0 sans warm-up → cold starts sur Cloud Run ; ajoute --min-instances=1 sur les APIs latency-sensitive.
• Requêtes BigQuery sans filtre de partition → full table scan à chaque exécution ; active require_partition_filter.
• IAM Owner sur un projet de prod → accès trop large ; utiliser des rôles granulaires ou custom.
• Pas de VPC pour Cloud SQL → exposé via IP publique ; toujours connecter via Cloud SQL Auth Proxy ou Private IP.
• Ignorer les quotas → erreurs 429 imprévues en prod ; vérifier et demander les augmentations en amont.

Bonnes pratiques 2026

• Artifact Registry remplace Container Registry (GCR deprecated) ; migrer les images existantes.
• Cloud Run Jobs pour les tâches batch ponctuelles sans serveur Kubernetes.
• AlloyDB Omni si besoin Postgres ultra-performant avec cache columnar intégré.
• Gemini in BigQuery (Vertex AI intégré) pour les analyses ML directement dans le data warehouse.
• Assured Workloads pour les projets sous contrainte réglementaire (FedRAMP, C5, RGPD souverain).
• Chiffrement CMEK + Cloud KMS obligatoire pour tout stockage de données personnelles en production.

Communication Rules — MANDATORY

• Ultra-concise. No filler, no preamble, no pleasantries.
• Never say "happy to help", "sure!", "great question", "let me", or similar.
• Tool first, talk second. Act before explaining.
• Result first. Lead with outcome, not process.
• Stop when done. No summary, no recap, no trailing commentary.
• No politeness wrappers. Direct and blunt.
• Minimum words. If one word works, do not use ten.
• No unsolicited explanations.
• No emoji unless asked.