DEV Community: La Formule Nuagique

Mettre à jour GKE sans sueurs froides : La stratégie Terraform Zero-Downtime

Benoît Garçon — Wed, 11 Feb 2026 10:00:00 +0000

Dans la vie d'un ingénieur Cloud, peu de notifications génèrent autant d'anxiété que : "GKE version 1.27 will reach end of life soon". La mise à jour de Kubernetes est souvent perçue comme une opération à cœur ouvert. Pourtant, avec une stratégie Terraform rigoureuse, c'est un non-événement.

Chez La Formule Nuagique, nous voyons trop souvent des clusters "Snowflake" mis à jour manuellement via la console Google Cloud. C'est une erreur critique en production. Une mise à jour GKE doit être déclarative, prévisible et codifiée.

Voici comment on architecture les montées de version GKE pour garantir la continuité de service, code Terraform à l'appui.

1. La règle d'or : Dissocier control plane et node pools

Sur GKE, la mise à jour se fait en deux temps : le Master (Control Plane) puis les Nodes (Workers). Terraform doit refléter cette réalité.

Une erreur classique est de tout vouloir mettre à jour en même temps. La bonne pratique consiste à piloter la version via des variables distinctes.

Le control plane

La mise à jour du master est gérée par Google. Elle ne cause pas de downtime applicatif, mais l'API server peut être indisponible quelques minutes (attention à vos pipelines CI/CD).

resource "google_container_cluster" "primary" {
  name     = "prod-cluster-01"
  location = "europe-west1"

  # On fixe la version mineure, mais on laisse Google gérer les patchs de sécu
  min_master_version = "1.29" 

  # ... configuration réseau ...
}

Le conseil de l'expert : Ne spécifiez pas la version complète (ex: 1.29.1-gke.1589000) dans min_master_version sauf nécessité absolue. Ciblez la mineure (1.29) pour bénéficier des auto-upgrades de sécurité critiques sans changer votre code tous les jours.

2. Les node pools : Là où le danger réside

C'est ici que votre trafic de production est traité. Si vous mettez à jour brutalement, les pods sont tués. Si vos nœuds redémarrent tous en même temps, c'est l'incident majeur.

Pour éviter cela, nous utilisons une stratégie de surge configurée directement dans Terraform.

L'approche max_surge et max_unavailable

L'objectif est de créer de nouveaux nœuds (en version N+1) avant de détruire les anciens (version N).

resource "google_container_node_pool" "primary_nodes" {
  name       = "pool-standard-v1"
  location   = "europe-west1"
  cluster    = google_container_cluster.primary.name

  # La version des noeuds suit celle du master, ou peut être gérée manuellement
  version = "1.29"

  upgrade_settings {
    # Combien de nœuds supplémentaires peut-on créer temporairement ?
    # Ici, on ajoute 1 nœud en plus pour absorber la charge pendant la migration.
    max_surge = 1

    # Combien de nœuds peuvent être indisponibles en même temps ?
    # 0 = On veut ABSOLUMENT maintenir la capacité actuelle.
    max_unavailable = 0
  }

  node_config {
    machine_type = "e2-standard-4"
    # ...
  }
}

L'analyse de Benoît Garçon : Avec max_unavailable = 0 et max_surge = 1, GKE va créer un nouveau nœud, attendre qu'il soit "Ready", déplacer les pods dessus (Drain), et seulement ensuite détruire l'ancien nœud. C'est plus lent, mais c'est l'assurance-vie de votre production.

3. Les fenêtres de maintenance

Ne laissez jamais Google décider quand la mise à jour s'applique. Vous ne voulez pas d'un upgrade le lundi matin à 9h00 lors du pic de charge.

Utilisez le bloc maintenance_policy dans votre ressource google_container_cluster :

resource "google_container_cluster" "primary" {
  # ...

  maintenance_policy {
    recurring_window {
      start_time = "2024-01-01T02:00:00Z" # 2h du matin UTC
      end_time   = "2024-01-01T06:00:00Z" # Jusqu'à 6h du matin
      recurrence = "FREQ=WEEKLY;BYDAY=SA,SU" # Uniquement le week-end
    }
  }
}

4. Le piège invisible : Les Pod Disruption Budgets

Même avec le meilleur code Terraform, votre montée de version peut rester bloquée indéfiniment. Pourquoi ? À cause des Pod Disruption Budgets.

Si vous avez une application avec 3 réplicas et un PDB qui exige minAvailable: 3, GKE ne pourra jamais drainer le nœud pour le mettre à jour.

La checklist de pré-upgrade de La Formule Nuagique :

Vérifier les APIs dépréciées : Utilisez l'outil kubent ou les "Deprecation Insights" dans la console GCP.
Audit des PDB : Assurez-vous qu'ils autorisent au moins 1 pod indisponible.
StatefulSets : Soyez extrêmement vigilant avec les bases de données hébergées dans Kubernetes, les volumes (PVC) peuvent être lents à se détacher/rattacher.

Conclusion : L'automatisation comme standard

La montée de version GKE ne doit pas être un projet héroïque, mais un processus standardisé. En codant ces stratégies dans Terraform, vous transformez un risque opérationnel en une simple Pull Request.

Besoin d'auditer la résilience de vos clusters Kubernetes ?

Benoît Garçon, via La Formule Nuagique, accompagne les équipes Tech dans la sécurisation de leurs infrastructures GCP et l'automatisation de leurs opérations Day-2.

Sécurisez et optimisez vos transferts de fichiers avec les signed URLs Cloud Storage

Benoît Garçon — Sun, 11 Jan 2026 22:30:17 +0000

En tant qu'architecte cloud, je vois encore trop souvent une anti-pattern tenace dans le développement d'applications web : le streaming de fichiers à travers le serveur backend.

Le scénario est classique : un utilisateur doit uploader une photo de profil ou télécharger une facture PDF. L'application reçoit le fichier sur le serveur API, le met en mémoire tampon, puis l'envoie vers Google Cloud Storage (GCS).

Pourquoi est-ce une mauvaise idée ?

Goulot d'étranglement : Votre serveur API (Compute Engine, Cloud Run ou GKE) consomme de la CPU et de la RAM pour du simple transit de données.
Latence : Vous ajoutez un saut supplémentaire (Client -> Serveur -> GCS).
Coûts : Vous payez pour la bande passante et le temps de calcul de votre serveur, alors que GCS est conçu pour ingérer des pétaoctets à moindre coût.

La solution architecturale élégante ? Les URL signées.

Dans cet article, nous allons voir comment déléguer le transfert de fichiers directement au client (le navigateur) de manière totalement sécurisée, en utilisant Python et le SDK GCP.

Qu'est-ce qu'une Signed URL ?

Une Signed URL est un lien temporaire qui donne une permission spécifique (lecture, écriture, suppression) sur un objet précis de votre bucket, pour une durée limitée.

Imaginez un valet de parking. Vous ne lui donnez pas les clés de votre maison (vos identifiants IAM Admin), mais un ticket temporaire qui lui permet juste de garer la voiture (uploader un fichier) et qui expire au bout de 5 minutes.

Demande : Le client (Frontend) demande au Backend l'autorisation d'uploader un fichier (ex: avatar.jpg).
Signature : Le Backend, via ses crédentiels IAM (Service Account), génère une URL signée cryptographiquement.
Envoi : Le Backend renvoie cette URL au client.
Action : Le client effectue un PUT ou un GET directement sur cette URL vers Google Cloud Storage.

Implémentation technique

Pour cet exemple, nous allons générer une URL permettant à un utilisateur d'uploader un fichier (méthode PUT).

Prérequis

Un bucket GCS privé (pas d'accès public allUsers).
Un Service Account avec le rôle roles/storage.objectCreator (pour l'upload) ou roles/storage.objectViewer (pour le download).

Le code (Backend Python)

Utilisons la méthode generate_signed_url du SDK Python.

from google.cloud import storage
import datetime

def generate_upload_url(bucket_name, blob_name, content_type):
    """
    Génère une URL signée v4 pour uploader un objet.
    """
    storage_client = storage.Client()
    bucket = storage_client.bucket(bucket_name)
    blob = bucket.blob(blob_name)

    url = blob.generate_signed_url(
        version="v4",
        # L'URL expire dans 15 minutes
        expiration=datetime.timedelta(minutes=15),
        # Autorise uniquement la méthode PUT
        method="PUT",
        # Sécurité critique : force le type de contenu
        content_type=content_type,
    )

    return url

# Exemple d'utilisation
# L'utilisateur veut uploader 'mon-image.png'
signed_url = generate_upload_url(
    "mon-bucket-app", 
    "uploads/user_123/mon-image.png", 
    "image/png"
)

print(f"URL d'upload générée : {signed_url}")

Le code (Frontend JavaScript)

Côté client, plus besoin d'authentification complexe. L'URL contient déjà le token nécessaire.

async function uploadFile(file) {
  // 1. Récupérer l'URL signée depuis votre API
  const response = await fetch('/api/get-upload-url', {
    method: 'POST',
    body: JSON.stringify({ name: file.name, type: file.type })
  });
  const { signedUrl } = await response.json();

  // 2. Uploader directement vers GCS
  const result = await fetch(signedUrl, {
    method: 'PUT',
    body: file,
    headers: {
      'Content-Type': file.type // Doit matcher celui défini lors de la signature !
    }
  });

  if (result.ok) {
    console.log('Upload réussi directement sur le Cloud Storage !');
  }
}

Les pièges à éviter

C'est ici que l'expérience fait la différence entre un code qui "marche" et une architecture de production.

1. La configuration CORS

C'est l'erreur numéro 1. Par défaut, votre bucket GCS refusera les requêtes venant de votre domaine (ex: mon-app.com). Vous devez configurer le CORS sur le bucket via la CLI gcloud ou Terraform.

Créez un fichier cors.json :

[
    {
      "origin": ["https://mon-app.com"],
      "method": ["PUT", "GET", "HEAD"],
      "responseHeader": ["Content-Type"],
      "maxAgeSeconds": 3600
    }
]

Appliquez-le :

gcloud storage buckets update gs://mon-bucket-app --cors-file=cors.json

2. Validez le Content-Type

Ne laissez jamais le champ content_type vide lors de la génération de la signature. Si vous ne le fixez pas, un utilisateur malveillant pourrait uploader un script exécutable (application/x-sh) à la place d'une image, ouvrant la porte à des failles de sécurité si ce fichier est ensuite servi à d'autres utilisateurs.

3. Gestion des noms de fichiers

Ne faites pas confiance aux noms de fichiers envoyés par les utilisateurs. Générez le nom de l'objet côté backend (par exemple avec un UUID) pour éviter les collisions et les caractères spéciaux non gérés.

Conclusion

L'utilisation des Signed URLs sur Google Cloud Storage est un "quick win" architectural. Vous déchargez votre infrastructure, améliorez l'expérience utilisateur grâce au réseau global de Google, et maintenez un niveau de sécurité granulaire.

C'est typiquement le genre d'optimisation Cloud Native qui permet de passer d'une application "bricolée" à une infrastructure capable de scaler.

Interconnexion multi-cloud GCP, AWS, Azure : Maîtriser le coût, la performance et la sécurité de vos flux

Benoît Garçon — Thu, 11 Dec 2025 17:32:17 +0000

L'ère du mono-cloud est révolue. Aujourd'hui, 82 % des entreprises adoptent une stratégie multi-cloud intentionnelle pour exploiter les services "Best-of-Breed" : l'IA de Google Cloud (GCP), la robustesse transactionnelle d'AWS, ou l'intégration Azure.

Cependant, le transfert de données entre ces environnements devient le goulot d'étranglement critique. L'approche historique par VPN sur l'Internet public est désormais obsolète, souffrant de latence imprévisible et de coûts de sortie (Egress) prohibitifs. Le marché a pivoté vers des solutions d'Interconnexion Cloud-to-Cloud dédiées.

Ce guide, basé sur notre analyse stratégique, vous fournit les clés pour choisir l'architecture d'interconnexion qui maximise la performance, garantit la sécurité (MACsec) et, surtout, optimise votre facture cloud (FinOps).

1. Performance : Adieu l'imprévisible, bonjour la latence déterministe

Le choix de votre méthode de connexion se résume à une question de performance garantie.

Le problème du VPN HA

Le Cloud VPN Haute Disponibilité (HA), bien que fiable (SLA 99,99 %), utilise l'Internet public. Les fluctuations du routage BGP et la congestion des nœuds d'échange Internet (IXP) introduisent une gigue (jitter) destructive pour les applications synchrones ou les bases de données distribuées. De plus, le débit est plafonné à environ 3 Gbps par tunnel en raison de la charge CPU de chiffrement IPsec.

La promesse de l'interconnexion privée

Les solutions dédiées comme Cross-Cloud Interconnect (CCI) de GCP ou Direct Connect d'AWS sont des autoroutes numériques :

Latence Ultra-Faible : Les benchmarks entre GCP (us-east4) et AWS (us-east-1) via interconnexion privée montrent une latence souvent inférieure à 2 ms, équivalente à la connexion entre deux zones de disponibilité internes.
Débit Garanti : Un circuit 10 Gbps ou 100 Gbps délivre son débit de façon constante (24/7), essentiel pour les fenêtres de sauvegarde nocturnes ou l'alimentation en données de modèles d'IA massifs.

2. Le facteur FinOps : Le point de rentabilité (Break-Even)

L'interconnexion privée est un investissement. Comprendre le point de bascule de rentabilité est essentiel pour le DAF et le CTO.

Coûts Fixes (Ports) vs. Coûts Variables (Egress)

L'interconnexion privée remplace un coût variable élevé (frais de sortie Internet) par un coût fixe (frais de port) et un coût variable réduit.

Type de Coût	Internet Public (VPN)	Interconnexion Privée (CCI/Direct Connect)
Coût Variable (Sortie/Egress)	Élevé (Ex: $0.08 - $0.12/GB sur GCP)	Très Réduit (Ex: ~ $0.02/GB sur GCP/AWS)
Coût Fixe (Port)	Faible (Frais minimes)	Élevé (Ex: ~ $5,900/mois pour 10G GCP-AWS)

Le seuil critique de 100 To

Notre analyse FinOps démontre que pour une connexion dédiée 10 Gbps entre GCP et AWS, le point de rentabilité se situe à environ 100 To de transfert mensuel.

Si Volume > 100 To/mois : La solution dédiée (CCI 10G/100G) est moins chère que le VPN sur Internet, tout en offrant une performance supérieure.
Si Volume < 50 To/mois : Privilégiez l'option Partner Interconnect (via Equinix ou Megaport). Leurs ports granulaires (dès 1 Gbps) offrent des frais fixes drastiquement plus bas, optimisant le ROI pour les volumes intermédiaires.

Piège à éviter : Les frais inter-régions. Si votre port Interconnect n'est pas géolocalisé au plus près de vos VMs, vous paierez des frais de transfert inter-région additionnels avant que les données n'atteignent le port physique.

3. Sécurité de Couche 2 : Le Bouclier MACsec

Pour les entreprises soumises à une conformité stricte (RGPD, secteur financier), la sécurité des données en transit est non négociable.

Le Cross-Cloud Interconnect (CCI) et la nouvelle offre AWS Interconnect supportent nativement le chiffrement MACsec (Media Access Control Security - IEEE 802.1AE).

MACsec vs. IPsec : Contrairement à IPsec (chiffrement de couche 3, logiciel, impact sur la performance), MACsec chiffre les trames Ethernet à la vitesse de la ligne (line-rate) sans dégradation de débit.
Protection Physique : MACsec protège contre l'interception physique (tapping) sur les fibres noires partagées, garantissant que les données sont chiffrées de la carte réseau du routeur de bordure GCP à celle d'AWS/Azure.

Recommandation : Le support de MACsec est un argument décisif pour choisir l'interconnexion native directe (CCI/Direct Connect/ExpressRoute Direct) pour toute charge de travail nécessitant une sécurité de couche 2.

4. Stratégie simplifiée : Choisir l'architecture adaptée

Le choix final dépend de votre cible cloud et de vos besoins en débit/agilité.

A. Connexion GCP vers AWS

La collaboration récente entre Google et AWS a simplifié l'architecture.

Solution	Débit/Capacité	Délai de Déploiement	Cas d'Usage Idéal
Partner Cross-Cloud Interconnect pour AWS	Granulaire (1 Gbps à 100 Gbps)	< 1 jour	Flexibilité (Retail, Débordement), volumes modérés (1-80 To). Recommandation standard pour un meilleur équilibre.
CCI Standard (Dédié) / AWS Interconnect	Fixe (10 Gbps ou 100 Gbps)	1 à 4 semaines	Volumes massifs et stables (IA/ML, Data Lake), exigences MACsec strictes.

B. Connexion GCP vers Azure

L'écosystème Azure est marqué par le coût élevé d'ExpressRoute Direct.

Option Recommandée : Modèle Fournisseur (ExpressRoute Partner) : Utilisez des partenaires comme Equinix Fabric ou Megaport Cloud Router (MCR). Cela permet d'acheter des circuits de 50 Mbps à 10 Gbps pour une fraction du coût d'ExpressRoute Direct, assurant agilité et économie (~$436/mois pour 1 Gbps, sans compter les frais partenaires).
Option ExpressRoute Direct : À n'envisager que si vous avez un besoin absolu de 100 Gbps ou des exigences de régulation très strictes. Le coût d'entrée ($50 000/mois pour 100 Gbps) est souvent prohibitif.

Conclusion et recommandations

Le passage au multi-cloud nécessite une infrastructure de réseau pensée comme un service financier et sécuritaire.

Priorité FinOps : Sortez d'Internet pour tout flux de données constant supérieur à 50 To/mois. L'économie sur les frais de sortie amortira le coût des ports dédiés.
Standardisation AWS : Standardisez sur Partner Cross-Cloud Interconnect pour AWS pour son déploiement rapide, sa gestion simplifiée et sa flexibilité bidirectionnelle.
Flexibilité Azure : Adoptez une approche hybride pour Azure en utilisant des Partenaires d'Interconnexion (Equinix/Megaport) pour éviter les frais excessifs d'ExpressRoute Direct.
Sécurité d'infrastructure : Activez MACsec systématiquement sur tous les liens physiques pour garantir l'intégrité et la confidentialité de vos données au niveau de la couche 2.

Guide pour l'installation de GKE on-prem sur VMware

Benoît Garçon — Tue, 11 Nov 2025 22:32:12 +0000

Dans l'univers du cloud hybride, Google Distributed Cloud (GDC), anciennement connu sous le nom d'Anthos, s'est imposé comme une solution de premier plan. Il promet d'étendre la puissance et l'agilité de Google Kubernetes Engine (GKE) directement dans votre data center. Pour de nombreuses entreprises, GDC sur VMware est la passerelle vers la modernisation applicative sans abandonner leurs investissements sur site.

Mais soyons honnêtes : le déploiement de GDC (ou GKE on-prem) n'est pas une simple formalité. C'est un exercice d'architecture qui exige une planification méticuleuse. En tant qu'experts Google Distributed Cloud, nous avons constaté que la majorité des échecs d'installation proviennent d'une phase de préparation insuffisante.

Ce guide n'est pas une simple copie de la documentation. Nous allons décortiquer le processus d'installation d'une configuration minimale, en mettant l'accent sur les pourquoi et les points de vigilance critiques que seul un expert GDC identifiera.

L'architecture GDC sur VMware : Les 3 piliers

Avant de taper la moindre commande, il est vital de comprendre les trois composants fondamentaux que nous allons construire.

Le poste de travail administrateur (Admin Workstation) : C'est une machine virtuelle (VM) dédiée dans votre vSphere qui servira de tour de contrôle. Elle héberge les outils CLI, comme gkeadm et gkectl, ainsi que les fichiers de configuration nécessaires pour créer et gérer vos clusters.
Le cluster d'administrateur (Admin Cluster) : C'est le cerveau de votre installation GDC on-prem. Il est lui-même un cluster Kubernetes qui gère le cycle de vie (création, mise à jour, suppression) de vos clusters d'utilisateur.
Le cluster d'utilisateur (User Cluster) : C'est ici que la magie opère. Ce cluster exécute vos charges de travail applicatives, exactement comme un cluster GKE standard dans le cloud.

Phase 1 : La planification, clé du succès avec Anthos

Ne sous-estimez jamais cette étape. Une installation de GKE on-prem réussie repose entièrement sur une planification rigoureuse de votre infrastructure existante.

Prérequis vSphere : Au-delà de la simple version

Vous avez besoin d'un environnement vSphere fonctionnel, avec vCenter Server et des hôtes ESXi. La documentation spécifie les versions minimales, typiquement 7.0u2+ ou 8.0+. Cependant, un expert regardera immédiatement la licence. Une licence vSphere Standard est suffisante pour une preuve de concept (POC) minimale. En revanche, une installation de production exige vSphere Enterprise Plus. Pourquoi ? Pour activer des fonctionnalités cruciales comme VMware DRS (Distributed Resource Scheduler) et les règles d'anti-affinité , qui garantissent la haute disponibilité de votre plan de contrôle GDC en répartissant les nœuds sur des hôtes physiques distincts.

L'autre point d'expertise concerne les permissions vCenter. N'utilisez jamais un compte administrateur global pour votre installation. Un expert GDC travaillera avec votre administrateur vSphere pour créer des rôles personnalisés avec les privilèges minimums requis, segmentés par objet vSphere (Datacenter, Cluster, Datastore, Réseau). C'est une question fondamentale de sécurité et de conformité.

Le point de bascule : La planification des adresses IP

C'est ici que 90% des déploiements échouent. GDC en mode "statique" (le plus courant pour une installation minimale avec l'équilibreur de charge MetalLB intégré ) exige une planification IP exhaustive. Vous ne pouvez pas inventer ces adresses au fur et à mesure. Vous devez définir et réserver avant de commencer :

Une adresse IP pour le poste de travail administrateur.
Trois adresses IP pour les nœuds du plan de contrôle du cluster d'administrateur.
Une adresse IP pour le nœud du plan de contrôle du cluster d'utilisateur.
Plusieurs adresses IP pour les nœuds de calcul (workers) du cluster d'utilisateur .
Une adresse IP virtuelle (VIP) pour le serveur d'API du cluster d'administrateur.
Une adresse IP virtuelle (VIP) pour le serveur d'API du cluster d'utilisateur.
Une adresse IP virtuelle (VIP) pour l'entrée Ingress du cluster d'utilisateur.
Une plage d'adresses IP virtuelles pour les services de type LoadBalancer.

De plus, vous devez définir vos plages CIDR pour les Pods et les Services de chaque cluster. Ces plages ne doivent absolument pas chevaucher vos réseaux existants (VMs, serveurs vCenter, DNS, etc.) pour éviter des cauchemars de routage .

Phase 2 : Configurer la connexion au cloud Google

Votre installation sur site doit communiquer avec Google Cloud pour télécharger les composants, s'enregistrer et être gérée.

Vous devez d'abord choisir un projet Google Cloud et y activer une série d'APIs essentielles. Les plus importantes sont gkeonprem.googleapis.com (l'API GKE On-Prem), gkehub.googleapis.com (pour enregistrer vos clusters dans un "Fleet") et anthos.googleapis.com.

Ensuite, vient la gestion des identités via les comptes de service (Service Accounts). C'est un point critique. Vous devez en créer manuellement deux:

Le compte de service d'accès aux composants (component-access-sa) : C'est lui qui a les droits (comme serviceusage.serviceUsageViewer) pour télécharger les binaires et images de GDC depuis Artifact Registry .
Le compte de service de journalisation d'audit (audit-logging-sa) : Il permet à vos clusters on-prem d'envoyer leurs journaux d'audit Kubernetes directement à Google Cloud Audit Logs.

Créez les clés JSON pour ces comptes, elles seront bientôt nécessaires. D'autres comptes de service, comme connect-register et logging-monitoring, seront créés automatiquement par l'outil d'installation gkeadm.

Phase 3 : Création du poste de travail administrateur

Le déploiement commence. Depuis votre machine locale (où gcloud est installé ), vous téléchargerez l'exécutable gkeadm.

La création du poste de travail se fait via deux fichiers de configuration. D'abord, credential.yaml, qui contient simplement vos identifiants vCenter. Ensuite, le fichier principal admin-ws-config.yaml. Ce YAML décrit à gkeadm votre environnement vSphere (datacenter, datastore, réseau) et les détails réseau de la VM du poste de travail (son IP statique, la passerelle, les serveurs DNS) .

Une fois ces fichiers remplis, vous lancez la commande ./gkeadm create admin-workstation. Cet outil va alors se connecter à vCenter, créer la VM, y installer les outils, et, comme mentionné, créer les comptes de service restants dans GCP.

Phase 4 : Déployer le cerveau, le cluster d'administrateur

Connectez-vous en SSH au poste de travail administrateur que vous venez de créer. Vous y trouverez des modèles de configuration, dont le crucial admin-cluster.yaml.

C'est le fichier de configuration le plus dense. Vous devez le remplir avec toutes les informations planifiées : les détails vCenter , les plages CIDR des Pods et Services , la configuration de l'équilibreur de charge MetalLB, les 3 adresses IP statiques pour les nœuds du plan de contrôle du cluster admin , la VIP de son serveur d'API , et les chemins vers les différents fichiers de clés JSON des comptes de service.

Avant la création, une étape indispensable est d'importer les images des OS (les modèles de VM) dans vSphere. Cela se fait avec gkectl prepare --config admin-cluster.yaml.

Enfin, lancez la création avec gkectl create admin --config admin-cluster.yaml. Ce processus est long. Il provisionne trois VM, y installe un cluster Kubernetes haute disponibilité, déploie les opérateurs GDC, et enregistre ce cluster auprès de Google Cloud. Une fois terminé, vous disposez d'un fichier kubeconfig local pour interagir avec votre nouveau cluster d'administrateur.

Étape suivante : Votre premier cluster utilisateur

Votre cluster d'administrateur est l'usine ; il est maintenant prêt à construire des clusters d'utilisateur. Le processus est similaire, en utilisant un fichier user-cluster.yaml ou, de manière plus moderne, en utilisant directement la gcloud CLI, car votre cluster admin est désormais géré par l'API GKE On-Prem. Une commande comme gcloud container vmware clusters create ... pilotera votre cluster d'administrateur on-prem pour qu'il déploie un nouveau cluster utilisateur.

Ce que nous avons couvert est l'installation "minimale". Le véritable travail d'un expert GDC / Anthos commence ici : configurer l'équilibrage de charge avancé (BGP avec MetalLB ou intégration F5), sécuriser les flux, mettre en place l'authentification OIDC, gérer les mises à niveau et assurer la surveillance à l'échelle de la production.

Si cette architecture et ce processus vous semblent complexes, c'est qu'ils le sont. Assurer la robustesse de votre fondation cloud hybride est notre métier. N'hésitez pas à contacter un expert pour sécuriser et accélérer votre parcours vers Google Distributed Cloud.

Simplifiez vos workflows DevOps avec Task, le "Makefile" moderne

Benoît Garçon — Sat, 11 Oct 2025 20:43:19 +0000

Aujourd'hui, on va parler d'un outil qui va changer votre façon de gérer vos workflows quotidiens : Task. Si le mot "Makefile" vous fait frissonner ou si vous en avez marre de jongler avec des scripts shell complexes et non portables, vous êtes au bon endroit. Task est là pour vous offrir une alternative moderne, simple et puissante.

Qu'est-ce que Task et pourquoi s'y intéresser ?

Imaginez un instant que vous puissiez définir des ensembles de commandes, des scripts et même des dépendances entre tâches, le tout dans un fichier YAML lisible et versionnable. C'est exactement ce que propose Task. Développé en Go, il se positionne comme une solution agnostique et multiplateforme pour automatiser vos tâches récurrentes en développement, en intégration continue, et bien sûr, en DevOps.

Pourquoi l'avoir adopté ?

Dans notre monde où l'infrastructure as code et l'automatisation règnent, Task s'intègre parfaitement. Que ce soit pour :

Builder des images Docker
Déployer des applications sur Kubernetes
Exécuter des tests unitaires ou d'intégration
Gérer des environnements de développement
Ou simplement organiser vos scripts de démarrage de services

Task vous offre une syntaxe claire et une exécution cohérente, peu importe la machine.

Installation : Votre premier pas vers l'automatisation

L'installation de Task est un jeu d'enfant, quelle que soit votre plateforme.

macOS/Linux (avec Homebrew) :

brew install go-task/tap/go-task

Windows (avec Chocolatey) :

choco install go-task

Ou téléchargez le binaire directement :
Rendez-vous sur taskfile.dev/docs/installation pour les binaires pré-compilés et d'autres méthodes d'installation.

Une fois installé, vérifiez-le avec :

task --version

Vous devriez voir la version de Task s'afficher, preuve que l'outil est prêt à rugir !

Votre premier `Taskfile.yml` : Le cœur de l'action

Toutes les tâches sont définies dans un fichier nommé Taskfile.yml (ou Taskfile.yaml), placé à la racine de votre projet. C'est là que la magie opère.

Créons un exemple simple. Dans votre répertoire de projet, créez un fichier Taskfile.yml avec le contenu suivant :

version: '3'

tasks:
  hello:
    desc: Dit bonjour au monde
    cmds:
      - echo "Bonjour, La Formule Nuagique !"
      - echo "Aujourd'hui, nous explorons Task."

  env-info:
    desc: Affiche quelques informations sur l'environnement
    cmds:
      - hostname
      - whoami
      - pwd

  build:
    desc: Simule une étape de build
    cmds:
      - echo "Lancement du build..."
      - sleep 2 # Simule un travail long
      - echo "Build terminé avec succès !"

Exécuter vos tâches

Pour exécuter une tâche, c'est très simple :

task hello

Vous devriez voir :

task: [hello] echo "Bonjour, La Formule Nuagique !"
Bonjour, La Formule Nuagique !
task: [hello] echo "Aujourd'hui, nous explorons Task."
Aujourd'hui, nous explorons Task.

Et pour l'info d'environnement :

task env-info

Lister toutes les tâches

Si vous avez de nombreuses tâches, vous pouvez toutes les lister avec leurs descriptions :

task --list
# Ou simplement
task -l

Ceci est incroyablement utile pour les collaborateurs qui découvrent un projet et ont besoin de savoir quelles sont les actions disponibles.

Fonctionnalités avancées pour le DevOps moderne

Task ne se contente pas d'exécuter des scripts. Il offre des fonctionnalités robustes qui en font un outil DevOps de choix.

1. Dépendances entre tâches

C'est là que Task devient vraiment puissant. Vous pouvez définir qu'une tâche doit s'exécuter après une ou plusieurs autres tâches.

version: '3'

tasks:
  clean:
    desc: Nettoie les artefacts de build
    cmds:
      - echo "Nettoyage des fichiers..."
      - sleep 1
      - rm -rf dist/ # Supprime un dossier de distribution fictif

  build:
    desc: Compile l'application
    cmds:
      - echo "Compilation de l'application..."
      - sleep 3
      - mkdir -p dist/
      - touch dist/app.bin

  deploy:
    desc: Déploie l'application
    deps:
      - clean # S'assure que le nettoyage est fait avant le déploiement
      - build # S'assure que l'application est compilée
    cmds:
      - echo "Déploiement de dist/app.bin vers le serveur..."
      - echo "Application déployée !"

Maintenant, si vous exécutez task deploy, Task s'assurera d'abord que clean puis build sont exécutés séquentiellement avant de lancer les commandes de deploy. C'est idéal pour créer des pipelines CI/CD locaux !

2. Variables et paramètres

Rendez vos tâches dynamiques avec des variables. Vous pouvez définir des variables globales, locales à une tâche, ou passer des arguments en ligne de commande.

version: '3'

vars:
  PROJECT_NAME: mon-app-nuagique

tasks:
  greet:
    desc: Salue un utilisateur ou le projet
    cmds:
      - echo "Bonjour, ${USER_NAME:-équipe} !"
      - echo "Bienvenue sur le projet ${PROJECT_NAME}."
    vars:
      USER_NAME: "{{.CLI_ARGS}}" # Permet de passer un nom en ligne de commande

  docker-build:
    desc: Construit l'image Docker
    cmds:
      - docker build -t la-formule-nuagique/${PROJECT_NAME}:{{.VERSION}} .
    vars:
      VERSION: '1.0.0' # Version par défaut si non spécifiée

Exemple d'utilisation :

task greet "Alice" # output: "Bonjour, Alice !" et le nom du projet
task docker-build -- VERSION=1.1.0 # Override la version

3. Gestion des erreurs et conditions

Task offre des moyens de gérer les échecs et d'exécuter des commandes conditionnellement, ce qui est crucial pour des scripts robustes.

version: '3'

tasks:
  check-docker:
    desc: Vérifie si Docker est en cours d'exécution
    cmds:
      - docker info > /dev/null 2>&1 || { echo "Docker n'est pas en cours d'exécution. Veuillez le démarrer." && exit 1; }
      - echo "Docker est opérationnel !"
    errors_to_stdout: true # Affiche les erreurs de la commande si elle échoue

  run-app:
    desc: Démarre l'application si Docker est prêt
    deps:
      - check-docker
    cmds:
      - echo "Lancement de l'application..."
      - docker run -d --name my-app my-image:latest
      - echo "Application démarrée !"

Dans cet exemple, check-docker s'assure que le démon Docker est actif. Si ce n'est pas le cas, un message d'erreur est affiché et la tâche se termine avec un code d'erreur, empêchant run-app de s'exécuter.

4. Exécution parallèle

Pour les tâches indépendantes, Task peut les exécuter en parallèle pour gagner du temps.

version: '3'

tasks:
  test-frontend:
    desc: Exécute les tests frontend
    cmds:
      - echo "Lancement des tests frontend..."
      - sleep 5

  test-backend:
    desc: Exécute les tests backend
    cmds:
      - echo "Lancement des tests backend..."
      - sleep 3

  full-tests:
    desc: Exécute tous les tests en parallèle
    cmds:
      - task: test-frontend
        silent: true # Rend la sortie plus propre
      - task: test-backend
        silent: true
    # Ou alternativement, en utilisant `deps` avec un flag parallèle
    # deps: [test-frontend, test-backend]
    # vars: { PARALLEL: true } # Non directement supporté comme ça, mais on peut le faire avec `cmd` et `&`

Pour exécuter test-frontend et test-backend simultanément, vous pouvez le faire en ligne de commande ou en les orchestrant avec un script shell dans une tâche:

task test-frontend & task test-backend

Cependant, l'approche la plus propre avec Task est de créer une tâche qui les lance :

version: '3'

tasks:
  test-frontend:
    desc: Exécute les tests frontend
    cmds:
      - echo "Lancement des tests frontend..."
      - sleep 5
      - echo "Tests frontend terminés."

  test-backend:
    desc: Exécute les tests backend
    cmds:
      - echo "Lancement des tests backend..."
      - sleep 3
      - echo "Tests backend terminés."

  run-all-tests-parallel:
    desc: Exécute les tests frontend et backend en parallèle
    cmds:
      - task: test-frontend &
      - task: test-backend &
      - wait # Attend la fin de tous les processus en arrière-plan

Exécutez task run-all-tests-parallel pour voir les tâches s'exécuter côte à côte.

Task vs. Makefile vs. scripts Shell

C'est une question légitime. Voici pourquoi Task se démarque :

Lisibilité et simplicité (vs. Makefile) : Le YAML est intrinsèquement plus facile à lire et à écrire que la syntaxe parfois archaïque et les subtilités des Makefiles. Pas de problèmes avec les tabulations vs. espaces !
Portabilité (vs. scripts Shell) : Les scripts shell (.sh, .bat) sont souvent liés à un système d'exploitation spécifique. Task, compilé en Go, garantit que vos Taskfile.yml fonctionnent de manière identique sur Linux, macOS et Windows, avec une seule installation.
Fonctionnalités intégrées : Dépendances, variables, descriptions, exécution parallèle, gestion d'erreurs... Task offre des fonctionnalités de "pipeline" sans avoir à écrire des logiques complexes dans vos scripts.
Discoverability : task --list est une fonctionnalité clé qui permet à quiconque de comprendre rapidement ce qu'un projet peut faire.

Bonnes pratiques avec Task pour la Formule Nuagique

Un Taskfile.yml par projet/module : Organisez vos tâches logiquement.
Descriptions claires (desc) : N'oubliez jamais la description de vos tâches. C'est la documentation embarquée de vos workflows.
Petit et modulaire : Gardez vos tâches courtes et faites en sorte qu'elles fassent une seule chose. Utilisez les dépendances pour chaîner des opérations complexes.
Variables pour la flexibilité : Utilisez des variables pour les chemins, les noms de conteneurs, les versions, etc.
Gestion des erreurs : Anticipez les échecs et incluez des vérifications ou des instructions claires en cas de problème.
Intégration CI/CD : Task est parfait pour être appelé dans vos pipelines Jenkins, GitLab CI, GitHub Actions, etc., assurant une cohérence entre votre environnement local et votre CI/CD.

Conclusion : adoptez Task et gagnez en efficacité !

Task est un outil simple à prendre en main, mais incroyablement puissant pour quiconque souhaite automatiser et standardiser ses workflows. Que vous soyez développeur, ingénieur DevOps ou architecte cloud, l'intégration de Task dans vos projets vous fera gagner un temps précieux et assurera une meilleure cohérence dans l'exécution de vos tâches.

Fini le temps des "ça marche sur ma machine" ou des scripts obscurs ! Avec Task, vos opérations sont claires, portables et faciles à gérer. Essayez-le dès aujourd'hui et transformez vos processus !

Google Cloud Storage : Le guide du débutant pour maîtriser vos fichiers

Benoît Garçon — Thu, 11 Sep 2025 11:00:00 +0000

Le terme "Cloud" peut souvent sembler intimidant, un univers abstrait rempli de jargon technique et de services complexes. Pourtant, au cœur de cette nébuleuse se trouvent des concepts fondamentalement simples et puissants. L'un des plus essentiels est le stockage d'objets. Il est temps de démystifier l'un des outils les plus robustes et accessibles dans ce domaine : Google Cloud Storage (GCS).

Imaginez GCS non pas comme une technologie obscure, mais comme un disque dur quasi infini, accessible de n'importe où dans le monde, ultra-sécurisé et d'une flexibilité remarquable. C'est un service conçu pour stocker ce que l'on appelle des "données non structurées", ce qui inclut pratiquement tout ce à quoi vous pouvez penser : les images et vidéos de votre site web, les sauvegardes (backups) de vos bases de données, les fichiers de logs de vos applications, ou même les immenses jeux de données pour l'intelligence artificielle.

Ce guide a pour but de vous accompagner, pas à pas, dans la découverte de GCS. Nous n'allons pas seulement survoler les fonctionnalités ; nous allons comprendre la logique qui les sous-tend. Nous nous concentrerons sur l'utilisation de l'outil en ligne de commande gcloud, un incontournable pour tout développeur qui souhaite automatiser ses tâches et travailler efficacement. En maîtrisant GCS, vous n'apprenez pas seulement à stocker des fichiers ; vous posez la première pierre pour construire des applications scalables, de l'hébergement de sites statiques à l'analyse de données à grande échelle (Big Data). En effet, GCS est une solution de stockage d'objets unifiée, ce qui signifie qu'il est conçu pour être le socle de stockage pour une multitude d'autres services Google Cloud, comme BigQuery pour l'analyse de données ou Vertex AI pour le machine learning. Apprendre GCS, c'est donc ouvrir la porte à tout l'écosystème de Google Cloud.

Les concepts clés

Avant de taper notre première commande, il est crucial de comprendre les deux briques de base qui constituent Google Cloud Storage. Tout comme un système de fichiers est composé de dossiers et de fichiers, GCS est structuré autour de "buckets" et d'"objets".

Les "buckets", vos conteneurs dans le cloud

Un "bucket" (qui se traduit par "seau" en anglais) est le conteneur fondamental dans GCS. C'est l'équivalent d'un dossier racine ou d'un disque dur principal où vous allez stocker vos données. Lorsque vous commencez à utiliser GCS, la première chose que vous ferez est de créer un bucket.

La caractéristique la plus importante, et souvent une source de confusion pour les débutants, est que le nom d'un bucket doit être globalement unique. Cela signifie que le nom que vous choisissez ne peut pas déjà être utilisé par un autre utilisateur de Google Cloud, où que ce soit dans le monde. La raison est simple : chaque bucket peut potentiellement être adressé via une URL standard sur Internet (par exemple, storage.googleapis.com/mon-nom-de-bucket-unique). Il fait donc partie d'un espace de noms mondial, un peu comme les noms de domaine de sites web.

Pour éviter les erreurs, les noms de buckets doivent respecter quelques règles simples :

Ils ne peuvent contenir que des lettres minuscules, des chiffres, des tirets (-), des underscores (_) et des points (.).
Ils doivent commencer et se terminer par une lettre ou un chiffre.
Leur longueur doit être comprise entre 3 et 63 caractères.

Cette contrainte de nommage unique n'est pas seulement une limitation technique ; elle a une implication directe sur la sécurité. Puisqu'un nom de bucket est public et découvrable, un tiers pourrait essayer de deviner des noms pour vérifier l'existence de projets ou d'informations. Cela mène à une règle d'or fondamentale : ne jamais inclure d'informations sensibles dans les noms de buckets ou d'objets. Par exemple, au lieu de nommer un bucket gs://rapports-secrets-clients-2024, il est infiniment préférable d'utiliser un nom non descriptif et difficile à deviner, comme gs://archive-data-alpha-7b3d. La sensibilité doit résider dans les données elles-mêmes et dans leurs permissions, pas dans leur nom.

Les "objects", vos fichiers et leurs métadonnées

Si un bucket est le dossier, un "objet" est simplement le fichier qu'il contient. Il peut s'agir de n'importe quel type de fichier (une image, un document PDF, une vidéo, un fichier binaire) et sa taille peut aller jusqu'à 5 To.

Chaque objet dans GCS est composé de deux éléments indissociables :

Les données : Le contenu brut du fichier lui-même.
Les métadonnées : Un ensemble d'informations qui décrivent l'objet. Cela inclut des métadonnées standard comme le nom de l'objet, sa taille, son type de contenu (par exemple, image/jpeg), et la date de sa dernière modification. Vous pouvez également ajouter vos propres métadonnées personnalisées pour étiqueter et organiser vos données.

En résumé, la structure est simple : vous créez des buckets pour organiser vos projets, et vous placez des objets (vos fichiers) à l'intérieur de ces buckets.

Partie 2 : Vos premiers pas avec `gcloud storage`

Maintenant que les concepts sont clairs, passons à la pratique. L'outil gcloud est une interface en ligne de commande (CLI) puissante qui vous permet d'interagir avec tous les services Google Cloud, y compris GCS. Le sous-ensemble de commandes dédié au stockage est gcloud storage. Il est important de noter que gcloud storage est l'outil moderne et unifié recommandé par Google, qui remplace progressivement l'ancien outil gsutil pour offrir une expérience plus cohérente.

La syntaxe de ces commandes a été conçue pour être intuitive pour quiconque a déjà utilisé un terminal Linux ou macOS. Les commandes de base comme cp (copier), ls (lister) et rm (supprimer) fonctionnent de manière très similaire, ce qui réduit considérablement la courbe d'apprentissage. Ce choix de conception n'est pas anodin ; il vise à rendre l'interaction avec le stockage cloud aussi naturelle que la gestion de fichiers sur votre propre machine.

Voici les opérations fondamentales que vous devez maîtriser.

Créer votre premier bucket

La première étape est de créer un conteneur pour vos fichiers. N'oubliez pas que le nom doit être unique au monde!

gcloud storage buckets create gs://

Par exemple : gcloud storage buckets create gs://mon-projet-media-8a9b7c. Le préfixe gs:// est la manière standard de désigner une ressource dans Google Cloud Storage.

Envoyer (uploader) votre premier fichier

Une fois le bucket créé, vous pouvez y copier un fichier depuis votre ordinateur local.

gcloud storage cp <FILE> gs://

Par exemple, pour envoyer un fichier nommé logo.png depuis votre répertoire courant : gcloud storage cp logo.png gs://mon-projet-media-8a9b7c/.

Lister le contenu d'un bucket

Pour voir les objets que contient votre bucket, utilisez la commande ls.

gcloud storage ls gs://

Cette commande affichera la liste de tous les objets à la racine de votre bucket.

Télécharger un fichier

Pour récupérer un fichier depuis votre bucket vers votre machine locale, utilisez la même commande cp, mais en inversant la source et la destination.

gcloud storage ls gs:// <PATH>

Par exemple, pour télécharger logo.png dans votre répertoire courant : gcloud storage cp gs://mon-projet-media-8a9b7c/logo.png ..

Supprimer un objet et un bucket

Enfin, pour nettoyer, vous pouvez supprimer un objet spécifique ou un bucket entier. Soyez prudent, car ces opérations sont généralement irréversibles, à moins que des mécanismes de protection comme la suppression réversible (soft delete) ou la gestion des versions ne soient activés.

Pour supprimer un objet :

gcloud storage rm gs://

Pour supprimer un bucket et tout son contenu (option récursive -r) :

gcloud storage rm -r gs://

Avec ces cinq commandes, vous détenez déjà les clés pour effectuer 90% des opérations courantes sur Google Cloud Storage.

Partie 3 : Optimiser les coûts

L'un des plus grands avantages du cloud est son modèle de paiement à l'usage (pay-as-you-go). Cependant, cela peut aussi être un piège si l'on ne comprend pas comment les coûts sont structurés. Pour GCS, le coût ne dépend pas seulement de la quantité de données que vous stockez (le "stockage au repos"), mais aussi de la fréquence à laquelle vous y accédez (les "opérations" et la "sortie réseau"). Google propose des outils pour gérer intelligemment ce compromis.

Les classes de stockage, à chaque donnée son usage

Toutes les données n'ont pas la même valeur ni la même fréquence d'accès. Un fichier image pour votre site web est consulté des milliers de fois par jour ("donnée chaude"), tandis qu'une archive légale peut ne jamais être consultée pendant des années ("donnée glacée"). GCS vous permet d'aligner le coût de stockage sur le profil d'accès de vos données grâce aux classes de stockage.

Standard : La classe Standard est idéale pour les données "chaudes", c'est-à-dire celles qui sont fréquemment consultées et modifiées. Cela inclut les sites web dynamiques, le streaming de contenu vidéo, les applications mobiles et les charges de travail analytiques actives. Bien que cette classe présente le coût de stockage le plus élevé, elle offre en contrepartie le coût d'accès le plus bas, ce qui la rend parfaite pour des données nécessitant une disponibilité immédiate et constante. Aucune durée minimale de stockage n'est imposée.

Nearline : Pour les données "tièdes", la classe Nearline est la plus appropriée. Il s'agit de données consultées de manière peu fréquente, comme des sauvegardes (backups) vérifiées mensuellement, des fichiers de logs ou du contenu multimédia rarement sollicité. Elle propose un coût de stockage bas en échange d'un coût d'accès moyen. Une durée minimale de stockage de 30 jours est requise pour cette classe.

Coldline : La classe Coldline est conçue pour les données "froides", telles que les archives consultées de manière occasionnelle (par exemple, trimestriellement) ou les données destinées à la reprise après sinistre. Elle se caractérise par un coût de stockage très bas, mais un coût d'accès élevé, la rendant économique pour les informations rarement nécessaires. La durée minimale de conservation pour cette classe est de 90 jours.

Archive : Enfin, la classe Archive est réservée aux données "glacées", qui sont rarement, voire jamais, consultées. Cela concerne typiquement les archives légales ou réglementaires qui doivent être conservées sur le long terme pour des raisons de conformité. Cette classe offre le coût de stockage le plus bas du marché, mais son coût d'accès est le plus élevé, ce qui la destine à une conservation à très long terme. Une durée minimale de stockage de 365 jours est appliquée.

La "durée minimale de stockage" est un concept clé : si vous supprimez un objet d'une classe autre que Standard avant cette durée, des frais de suppression anticipée s'appliqueront. Le choix d'une classe est donc un engagement sur la durée de vie prévue de la donnée.

Le Cycle de Vie des Objets - L'Automatisation au Service de vos Économies

Changer manuellement la classe de stockage de millions de fichiers serait une tâche titanesque. C'est là qu'intervient l'une des fonctionnalités les plus puissantes de GCS : la gestion du cycle de vie des objets (Object Lifecycle Management).

Cette fonctionnalité vous permet de définir des règles automatiques qui s'appliquent à tous les objets d'un bucket. C'est comme avoir un majordome personnel qui, sans que vous ayez à intervenir, range votre grenier pour vous faire économiser de l'argent. Vous pouvez créer des règles pour :

Changer la classe de stockage d'un objet après un certain temps.
Supprimer un objet après une période définie.

Prenons un exemple concret et courant : nous voulons que tous nos fichiers de logs (se terminant par .log) soient automatiquement déplacés vers la classe de stockage Coldline après 90 jours pour réduire les coûts. De plus, pour des raisons de conformité, nous voulons que ces logs soient définitivement supprimés après 7 ans (soit 2555 jours).

Pour cela, nous créons un fichier de configuration au format JSON, que nous pourrions nommer lifecycle.json :

{
  "lifecycle": {
    "rule": [
      {
        "action": { "type": "Delete" },
        "condition": { "age": 2555, "matchesSuffix": [".log"] }
      }
    ]
  }
}

Expliquons ce fichier :

rule : Définit une liste de règles.
Première règle :
- action : L'action à effectuer est SetStorageClass (changer la classe de stockage) pour la mettre à COLDLINE.
- condition : Cette action se déclenche quand l'âge (age) de l'objet atteint 90 jours ET si son nom se termine (matchesSuffix) par .log.
Deuxième règle :
- action : L'action est de type Delete (supprimer).
- condition : Elle se déclenche quand l'âge de l'objet atteint 2555 jours ET si son nom se termine par .log.

Une fois ce fichier créé, il suffit d'une seule commande gcloud pour l'appliquer à votre bucket :

gcloud storage buckets update gs://<PATH> --lifecycle-file=lifecycle.json

Cette approche n'est pas seulement une fonctionnalité technique ; elle incarne un principe fondamental de l'architecture cloud. La valeur de la plupart des données diminue avec le temps. Les règles de cycle de vie sont le mécanisme qui vous permet d'aligner de manière programmatique et automatique vos coûts de stockage sur la valeur métier de vos données, une stratégie essentielle pour tout architecte cloud.

Partie 4 : L'astuce de fin, partager un fichier de manière sécurisée et temporaire

Nous arrivons à l'astuce qui distingue souvent un débutant d'un utilisateur averti. Imaginez le scénario suivant : vous stockez des factures PDF pour les utilisateurs de votre application dans un bucket GCS. Ce bucket doit absolument rester privé ; personne sur Internet ne doit pouvoir lister son contenu. Comment permettez-vous à un utilisateur spécifique de télécharger sa propre facture, et uniquement la sienne, pour une durée limitée ?

La mauvaise approche serait de rendre le fichier public temporairement, ou de gérer des permissions complexes. La solution élégante et sécurisée s'appelle les URL signées (Signed URLs).

Une URL signée est une URL spéciale et unique qui contient une signature cryptographique. Cette signature accorde des permissions très spécifiques (par exemple, lire un objet précis) pour une durée limitée (par exemple, 5 minutes) à quiconque possède cette URL. Une fois le délai expiré, l'URL devient invalide.

Les avantages sont immenses :

Sécurité : Le bucket et ses objets restent privés. Vous n'ouvrez jamais l'accès publiquement.
Contrôle granulaire : Vous accordez un accès à un seul objet, pour une seule action (lecture, écriture, suppression), et pour une durée que vous définissez.
Simplicité : L'utilisateur final n'a pas besoin d'un compte Google ou de s'authentifier auprès de GCP. Il lui suffit de cliquer sur un lien.

Voici comment générer une URL signée avec gcloud.

Prérequis : Pour générer une signature, vous avez besoin d'une identité qui a la permission de le faire. Dans GCP, les identités pour les applications et les scripts s'appellent des "comptes de service". Vous devez en créer un et lui donner un rôle qui lui permet de lire les objets, par exemple Storage Object Viewer (roles/storage.objectViewer).
La commande : La méthode la plus moderne et sécurisée pour générer une URL signée est d'utiliser l'impersonation de compte de service. Votre compte utilisateur (avec lequel vous êtes authentifié dans gcloud) demande à gcloud de générer l'URL au nom du compte de service.

gcloud storage sign-url gs://<PATH> --impersonate-service-account=<ACCOUNT> --duration=10m

Décortiquons cette commande :

gs://[...]/[...] : Cible l'objet exact pour lequel vous voulez générer l'URL.
--impersonate-service-account : Spécifie l'email du compte de service qui a les permissions de lire l'objet. gcloud utilisera cette identité pour "signer" la requête.
--duration=10m : Définit la durée de validité de l'URL. Vous pouvez utiliser s pour les secondes, m pour les minutes, ou h pour les heures.

Le résultat de cette commande est une longue URL que vous pouvez donner à votre utilisateur.

Cette technique est plus qu'une simple astuce de sécurité ; c'est un puissant modèle d'architecture pour des applications cloud performantes. Un flux de travail naïf serait que l'utilisateur demande la facture à votre serveur, que votre serveur télécharge le fichier depuis GCS, puis le renvoie à l'utilisateur. Ce processus fait de votre serveur un goulot d'étranglement et consomme sa bande passante. Avec une URL signée, votre serveur ne fait que la partie légère : il vérifie les droits de l'utilisateur et génère l'URL. Ensuite, le transfert du fichier (la partie lourde) se fait directement entre le navigateur de l'utilisateur et l'infrastructure massive et ultra-performante de Google. Votre application devient ainsi plus rapide, moins chère à opérer et beaucoup plus scalable.

Conclusion

Si vous avez suivi ce guide jusqu'au bout, vous avez accompli un parcours significatif. Vous avez non seulement appris les concepts fondamentaux de Google Cloud Storage comme les buckets et les objets, mais vous avez aussi mis les mains dans le cambouis avec les commandes essentielles (create, cp, ls, rm).

Plus important encore, vous avez commencé à penser comme un architecte cloud. Vous savez désormais que toutes les données ne se valent pas et vous avez découvert comment utiliser stratégiquement les classes de stockage et les règles de cycle de vie pour aligner les coûts sur la valeur de vos données. Enfin, avec les URL signées, vous disposez d'une technique de niveau professionnel pour construire des applications sécurisées et performantes qui partagent des données de manière contrôlée.

Vous n'êtes plus un débutant complet. Vous possédez les connaissances fondamentales et une astuce puissante pour commencer à construire des solutions robustes et efficaces avec Google Cloud Storage. Le chemin ne s'arrête pas là. Vous pouvez maintenant explorer des fonctionnalités plus avancées comme la gestion des versions d'objets (Object Versioning) pour vous protéger contre les suppressions accidentelles, ou les notifications Pub/Sub pour déclencher des actions (comme le traitement d'une image) dès qu'un nouvel objet est uploadé. Le monde du stockage cloud est vaste, mais vous avez désormais une base solide pour l'explorer avec confiance.

Sources

IAP sur GKE : Google change les règles, êtes-vous prêt pour la migration ?

Benoît Garçon — Mon, 11 Aug 2025 17:01:05 +0000

Vous utilisez Identity-Aware Proxy (IAP) pour sécuriser l'accès à vos applications sur Google Kubernetes Engine (GKE) ? C'est une excellente pratique. IAP agit comme un garde du corps intelligent pour vos services, vérifiant l'identité de chaque utilisateur avant de lui laisser franchir la porte. C'est la solution idéale pour protéger une application interne ou un environnement de pré-production.

Cependant, une annonce de Google est peut-être passée sous votre radar : la méthode historique pour activer IAP sur GKE est en cours de dépréciation. Si vous avez configuré IAP il y a quelque temps, il est fort probable que vous soyez concerné. Pas de panique ! Ce changement est en réalité une bonne nouvelle, et ce guide est là pour vous accompagner dans une migration tout en douceur.

Pourquoi ce changement ? L'ancien monde face au nouveau

Pour comprendre l'intérêt de cette migration, revenons un instant sur la manière dont les choses fonctionnaient. Auparavant, pour activer IAP, il fallait se rendre dans la console Google Cloud, créer manuellement un client OAuth, puis copier-coller l'identifiant de ce client dans les annotations de votre ressource Ingress sur Kubernetes. Cette approche, bien que fonctionnelle, présentait quelques inconvénients. Elle mélangeait une configuration faite à la main dans la console avec des manifestes déclaratifs dans Kubernetes, ce qui n'est pas idéal pour l'automatisation et les pratiques GitOps.

La nouvelle méthode est bien plus élégante et s'intègre parfaitement à l'écosystème Kubernetes. Tout se passe désormais à l'intérieur de votre cluster. La configuration d'IAP est définie via une ressource Kubernetes dédiée appelée BackendConfig. C'est une approche "Kubernetes-native" : votre configuration IAP vit aux côtés de vos déploiements et de vos services, directement dans vos fichiers YAML. C'est plus propre, plus simple à suivre et entièrement automatisable.

Le plan de migration, étape par étape

Migrer vers la nouvelle méthode est un processus simple qui se déroule en quelques étapes logiques. L'objectif est de passer d'une configuration manuelle à une configuration déclarée dans votre cluster.

Première étape : Vérifiez si vous êtes concerné

La première chose à faire est de regarder la configuration de votre service Kubernetes. Plus précisément, inspectez les champs de votre ressource GCPBackendPolicy. Si vous ne voyez pas de champ iap.enabled: true, il y a de fortes chances que vous deviez migrer.

Deuxième étape : Définir votre GCPBackendPolicy

C'est le cœur de la nouvelle configuration. Vous allez créer un nouveau fichier YAML pour une ressource de type GCPBackendPolicy. Dans ce fichier, vous activerez IAP. Ce manifeste est très clair et se lit presque comme une phrase : "Active IAP pour ce backend".

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: policy
spec:
  targetRef:
    kind: Service
    name: nginx
  default:
    iap:
      enabled: true

Les avantages concrets de cette migration

Ce changement n'est pas qu'une simple mise à jour technique, il apporte de réels bénéfices. Votre configuration de sécurité est désormais entièrement gérée "en tant que code" (as code), ce qui facilite le suivi des versions, les audits et les déploiements automatisés. Il n'est plus nécessaire de gérer les brands IAP et on peut simplifier l'utilisation des clients. Enfin, toute votre configuration d'application, de son déploiement à sa sécurité, est centralisée au sein de vos manifestes Kubernetes, simplifiant la gestion globale de votre projet.

N'attendez pas le dernier moment

Google a fixé des dates butoirs pour cette dépréciation. Le 21 septembre 2025, l'ancienne API sera coupée. Même si la migration est simple, il est préférable de ne pas la remettre à plus tard pour éviter toute interruption de service. En adoptant dès maintenant cette nouvelle approche, vous modernisez votre infrastructure et vous vous alignez sur les meilleures pratiques de l'écosystème Kubernetes.

Si cette migration vous semble complexe, si vous n'êtes pas sûr d'être concerné ou si vous souhaitez simplement un audit de vos pratiques de sécurité sur GCP, n'hésitez pas à faire appel à un expert. En tant que consultant freelance, je peux vous aider à naviguer ces changements et à garantir que votre infrastructure reste sécurisée, performante et à la pointe de la technologie.

Proxy-only subnet sur GCP : Le guide pour bien démarrer

Benoît Garçon — Fri, 11 Jul 2025 09:20:37 +0000

Vous êtes sur le point de déployer votre nouvelle application sur Google Cloud, et pour exposer celle-ci au monde, vous avez choisi un répartiteur de charge moderne basé sur Envoy. Il peut s'agir d'un Global External HTTPS Load Balancer ou de ses cousins régionaux. Au moment de la configuration, une question vous est posée : la création d'un "proxy-only subnet". C'est une étape obligatoire, mais qui soulève souvent des interrogations. Ce sous-réseau n'est pas destiné à vos machines virtuelles, mais il s'agit d'un espace réseau réservé que Google Cloud utilisera pour allouer des adresses IP à ses proxys Envoy managés. Ces proxys sont le cœur de votre répartiteur de charge. Comprendre comment dimensionner et gérer ce sous-réseau est donc essentiel pour garantir la performance et la scalabilité de vos services.

Quelle taille pour mon subnet ?

La première décision à prendre concerne la taille de ce sous-réseau. La documentation de Google Cloud impose une taille minimale qui doit pouvoir fournir au moins 64 adresses IP, ce qui correspond à un masque de sous-réseau en /26. Cependant, se contenter du strict minimum est rarement une bonne idée en production. L'approche recommandée est bien plus confortable. Il est conseillé de démarrer avec un préfixe en /23, ce qui vous alloue 512 adresses IP. C'est un excellent point de départ qui offre une marge de manœuvre suffisante pour la plupart des applications, tout en restant raisonnable. Si votre réseau VPC commence à être à l'étroit en adresses privées RFC 1918, sachez qu'il est tout à fait possible d'utiliser une plage d'adresses non-RFC 1918 pour ce subnet spécifique, une astuce précieuse pour éviter les conflits.

Comment Google choisit le nombre de proxys ?

Le véritable intérêt de ce système est son élasticité. Le nombre de proxys n'est pas fixe. Google Cloud l'ajuste dynamiquement en fonction du trafic que votre application reçoit. Toutes les dix minutes, le service évalue la capacité nécessaire pour gérer la charge et ajuste le nombre de proxys en conséquence. Pour ce faire, il se base sur le plus grand des besoins calculés entre la bande passante et le volume de connexions ou de requêtes.

Imaginons que votre service diffuse des tutoriels vidéo. Chaque instance de proxy peut gérer jusqu'à 18 Mo par seconde de trafic. Si, pendant la période d'observation, votre application doit servir un total de 180 Mo par seconde, Google Cloud calculera qu'il a besoin de dix proxys pour satisfaire la demande en bande passante.

Maintenant, pensons à un site de commerce en ligne durant une vente flash. Le calcul se portera sur les connexions et les requêtes. Un proxy peut gérer environ 600 nouvelles connexions par seconde en HTTP, ou 150 en HTTPS à cause de la charge supplémentaire du chiffrement. Il peut aussi maintenir 3000 connexions actives simultanément. Si votre site reçoit une vague de 2000 nouvelles connexions HTTPS par seconde, le système saura qu'il doit provisionner plus de treize proxys juste pour absorber ce pic de nouvelles connexions. De la même manière, un proxy peut traiter jusqu'à 1400 requêtes par seconde, un chiffre important pour les API très sollicitées.

L'impact caché de la journalisation

Un détail crucial à ne pas négliger est l'impact de la journalisation, ou logging, sur les performances. Le chiffre de 1400 requêtes par seconde est valable lorsque la journalisation via Cloud Logging est désactivée. Si vous décidez d'activer la journalisation pour 100% de vos requêtes afin d'avoir une observabilité complète, la capacité de traitement d'un proxy chute de moitié, pour atteindre environ 700 requêtes par seconde. Cela signifie que pour un même trafic, vous aurez besoin de deux fois plus de proxys, ce qui a une incidence directe sur la facture. Heureusement, il est possible de configurer l'échantillonnage des journaux pour ne tracer qu'un pourcentage du trafic, trouvant ainsi le juste équilibre entre observabilité et maîtrise des coûts.

Quelques détails importants

Il est primordial de se rappeler que ces proxys sont alloués au niveau du VPC et de la région, et non par répartiteur de charge individuel. Vous devez donc créer un unique proxy-only subnet dans chaque région où vous déployez des répartiteurs de charge basés sur Envoy. Si vous avez trois load balancers différents dans la même région du même VPC, ils partageront tous le même pool de proxys hébergés dans ce subnet. Enfin, n'oubliez pas que chaque proxy provisionné pour répondre à vos besoins en trafic engendre un coût horaire supplémentaire. La compréhension de ces mécanismes de mise à l'échelle vous permet non seulement d'anticiper les performances, mais aussi d'estimer plus finement vos dépenses sur le cloud.

Conclusion

Le proxy-only subnet peut sembler n'être qu'un détail technique dans la configuration d'un load balancer sur GCP. Pourtant, le choix de sa taille initiale et la compréhension de son fonctionnement dynamique sont des éléments clés pour construire une architecture robuste et évolutive. En démarrant avec une taille confortable comme un /23 et en gardant à l'esprit les facteurs qui influencent le scaling automatique, vous vous assurez que votre infrastructure pourra encaisser les montées en charge sans sourciller. Vous avez maintenant toutes les cartes en main pour dimensionner ce composant essentiel avec confiance.

Sources

Documentation Google Cloud : Planning the size of your proxy-only subnet

Le chaînon manquant de la documentation GCP : cartographier la toile invisible des dépendances d'API

Benoît Garçon — Tue, 10 Jun 2025 23:58:53 +0000

Naviguer dans l'écosystème Google Cloud Platform peut parfois s'apparenter à l'exploration d'une métropole tentaculaire. Des centaines de services, chacun doté de sa propre puissance, offrent des possibilités quasi infinies. Mais comme dans toute grande ville, des réseaux souterrains et invisibles connectent chaque quartier. Dans GCP, ces réseaux sont les dépendances entre les services d'API, des liens cruciaux mais étonnamment absents des cartes officielles.

Constat

Quand on travaille avec Google Cloud Platform (GCP), on finit toujours par passer par la case gcloud services enable. Que ce soit pour Cloud Functions, BigQuery, ou l’incontournable IAM, chaque service repose sur un ensemble parfois obscur d’APIs qu’il faut activer dans un ordre souvent flou. Et pourtant, la documentation officielle ne fournit aucune carte des dépendances entre ces services. Impossible de savoir à l’avance si désactiver anthos.googleapis.com va faire tomber dix autres services — jusqu’à ce que cela vous arrive.

Le résultat obtenu

C'est face à cette opacité que l'idée a germé : pourquoi ne pas construire la carte nous-mêmes ? C'est ainsi qu'est née l'application web que j'ai développée, disponible sur gcp.garçon.fr. L'objectif était simple : offrir une vue claire, interactive et intuitive de la toile des dépendances entre les services de Google Cloud.

L'application se présente comme une page unique, sobre, inspirée du design de Google pour ne pas dépayser les habitués. Elle s'articule autour de trois composants essentiels. Au centre, un graphe dynamique représente l'ensemble des services sous forme de nœuds. Lorsqu'une dépendance existe, une arête les relie, matérialisant enfin ces connexions invisibles. Sur la droite, une liste exhaustive de tous les services permet une recherche et une identification rapide.

La véritable valeur ajoutée se révèle à l'interaction. En sélectionnant un service, que ce soit dans la liste ou directement sur le graphe, l'interface s'anime. Le graphe zoome sur le nœud choisi et met en évidence ses relations. Les dépendances que le service consomme (ce dont il a besoin pour fonctionner) s'affichent en rouge, tandis que les services qui, à l'inverse, dépendent de lui, se colorent en vert. Simultanément, le panneau de droite se transforme pour afficher un résumé détaillé, listant clairement ces deux catégories : "Depends On" et "Dependency Of". La complexité se démêle sous nos yeux.

L'application elle-même est bâtie sur des technologies web standards, s'appuyant sur la puissante bibliothèque JavaScript Vis.js pour la partie la plus complexe : le rendu et la physique du graphe. Le résultat est un outil léger, rapide et ne nécessitant aucune installation.

Cartographier les dépendances entre APIs GCP : là où la doc s'arrête, le code commence

Le défi principal n'était pas tant technique que informationnel. Il a fallu patiemment compiler et croiser les informations pour établir cette cartographie. La méthode repose sur un test systématique des APIs. On commence par créer un projet GCP vierge. Ensuite, on active toutes les APIs disponibles (oui, ça fait beaucoup de trafic réseau), puis on les désactive une par une. À chaque tentative de désactivation, si une erreur apparaît mentionnant qu’un service est « depended on by the following active service(s) », on enregistre la relation. En réactivant ensuite l’API désactivée, on revient à l’état initial pour recommencer avec la suivante. C’est fastidieux, long (très long), mais redoutablement efficace.

Les résultats sont ensuite collectés dans un simple fichier texte de type serviceA=>serviceB, signifiant que serviceB dépend de serviceA. Ce fichier brut a été transformé en graphe interactif sur le site. Il est possible de cliquer sur une API et de voir en temps réel quelles autres APIs en dépendent, ou inversement, lesquelles elle requiert pour fonctionner.

L’enjeu dépasse la simple curiosité. Dans une logique DevSecOps ou de gouvernance fine du cloud, il est essentiel de savoir ce que l’on expose, ce qui est actif, et surtout ce que l’on pourrait désactiver sans effet de bord. Google fournit bien des descriptions d’API, mais reste silencieux sur leurs dépendances techniques. Ce manque de transparence, sans doute volontaire pour des raisons d’évolution interne, peut poser problème dans des environnements contraints.

L'application n’a pas la prétention d’être exhaustive ni parfaite. Elle se base sur des expérimentations dans un contexte contrôlé, sur un seul projet vierge. Mais elle a déjà mis en lumière des dépendances inattendues — comme le fait que certains services de réseau ou de machine learning sont étroitement liés à des APIs que l’on aurait pensé optionnelles.

Au-delà de la simple curiosité intellectuelle, cet outil apporte une valeur tangible. Pour un architecte cloud, il permet d'anticiper les besoins et de concevoir des infrastructures plus robustes. Pour un développeur, il accélère le diagnostic des erreurs de configuration. Pour un responsable FinOps, il offre une meilleure visibilité sur les coûts indirects qu'un service peut engendrer en sollicitant d'autres API facturables.

Conclusion

En résumé, quand la documentation ne suffit plus, il faut expérimenter. Et si ce travail peut servir à d'autres, tant mieux. La cartographie est disponible publiquement, sans inscription ni tracking. C’est un outil de plus pour comprendre un peu mieux cette immense boîte noire qu’est parfois GCP. Cette application ne prétend pas remplacer la documentation officielle, mais plutôt la compléter là où elle est silencieuse. Elle est une invitation à explorer, à comprendre et à maîtriser la mécanique interne de Google Cloud. La complexité n'est pas une fatalité lorsqu'on dispose des bons outils pour la visualiser. Je vous invite à l'explorer sur gcp.garçon.fr et à voir par vous-même la structure cachée de la plateforme que nous utilisons chaque jour.

Introduction à OpenTofu pour les utilisateurs Terraform

Benoît Garçon — Sun, 11 May 2025 21:57:33 +0000

OpenTofu est un fork communautaire de Terraform, compatible en grande partie avec ce dernier, mais qui prend une orientation technique différente sur certains points clés. Pour les utilisateurs expérimentés de Terraform, la transition vers OpenTofu est quasi transparente tout en offrant des fonctionnalités avancées comme le chiffrement natif de l'état ou une évaluation anticipée des expressions.

Ce tutoriel illustre l'utilisation d'OpenTofu pour déployer une architecture répartie sur deux régions GCP avec deux machines virtuelles GCE faisant tourner NGINX, exposées via un Global Load Balancer. Le backend de stockage d'état utilisera GitLab comme source de vérité.

Installation d'OpenTofu

Installation Debian/Ubuntu :

curl --proto '=https' --tlsv1.2 -fsSL https://get.opentofu.org/install-opentofu.sh | bash -s -- --install-method deb

Pour vérifier la bonne installation de OpenTofu :

tofu version

Configuration du backend GitLab

GitLab permet de stocker l'état via un repository en tant que backend "HTTP" compatible.

Exemple terragrunt.hcl :

locals {
  config            = yamldecode(file("config.yaml"))
  gitlab_project_id = local.config.backend.gitlab.project_id
  gitlab_username   = local.config.backend.gitlab.username
  gitlab_token      = get_env("GITLAB_TOKEN", "")
  gitlab_path       = "blog"
  gitlab_url        = "https://gitlab.com/api/v4/projects/${local.gitlab_project_id}/terraform/state/${local.gitlab_path}"
}

generate "backend" {
  path      = "backend.tf"
  if_exists = "overwrite_terragrunt"
  contents  = <<EOF
terraform {
  backend "http" {
    address        = "${local.gitlab_url}"
    lock_address   = "${local.gitlab_url}/lock"
    unlock_address = "${local.gitlab_url}/lock"
    username       = "${local.gitlab_username}"
    password       = "${local.gitlab_token}"
    lock_method    = "POST"
    unlock_method  = "DELETE"
    retry_wait_min = 5
  }
}
EOF
}

generate "providers" {
  path      = "providers.tf"
  if_exists = "overwrite_terragrunt"
  contents  = <<EOF
provider "google" {
  project = "${local.config.cloud.project_id}"
  region  = "${local.config.cloud.region}"
}
EOF
}

inputs = {
  config = local.config
}

Ce module Terragrunt va charger un fichier config.yaml de ce type :

backend:
  gitlab:
    project_id: "<project_id>"
    username: "<username>"

cloud:
  project_id: <gcp_project_id>
  region: europe-west9
  workload:
    france:
      color: "#0000BB"
      machine: e2-micro
      region: europe-west9
      traffic: 0.80
    belgium:
      color: "#BB0000"
      machine: e2-micro
      region: europe-west1
      traffic: 0.20

Remplacez <project_id>, <username>, <gcp_project_id>, et les identifiants par les vôtres. Le projet doit être configuré pour permettre le remote backend via HTTP.

Pour pouvoir utiliser OpenTofu et le backend GitLab, il faut aussi exporter une variable d'environnement :

export GITLAB_TOKEN=<key>

Infrastructure cible

Deux instances GCE (dans europe-west9 et europe-west1) avec NGINX
Global Load Balancer HTTP(S)
Priorité pondérée sur les backends (ex : 80/20)

Exemple d’infrastructure (fichiers principaux)

`workload.tf`

resource "google_compute_instance" "nginx" {
  for_each = var.config.cloud.workload

  machine_type = each.value.machine
  name         = "nginx-${each.key}"
  zone         = "${each.value.region}-b"

  boot_disk {
    initialize_params {
      image = "debian-cloud/debian-12"
    }
  }

  network_interface {
    network = "default"
    access_config {}
  }

  tags = [ "public" ]

  metadata_startup_script = <<-EOF
    #!/bin/bash
    apt-get update
    apt-get install -y nginx
    echo " <!DOCTYPE html> <html lang="fr"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>${upper(each.key)}</title> <style> body { background-color: ${each.value.color}; color: white; display: flex; justify-content: center; align-items: center; height: 100vh; margin: 0; font-family: Arial, sans-serif; } h1 { font-size: 5rem; } </style> </head> <body> <h1>${upper(each.key)}</h1> </body> </html>" > /var/www/html/index.nginx-debian.html
    systemctl restart nginx
  EOF

  depends_on = [ google_project_service.apis ]
}

`load_balancing.tf`

resource "google_compute_instance_group" "group" {
  for_each = var.config.cloud.workload

  name        = "group-${each.key}"
  zone        = "${each.value.region}-b"
  instances   = [google_compute_instance.nginx[each.key].self_link]

  named_port {
    name = "http"
    port = 80
  }
}

resource "google_compute_health_check" "default" {
  name               = "http-health-check"
  check_interval_sec = 5
  timeout_sec        = 5

  http_health_check {
    port = 80
  }
}

resource "google_compute_backend_service" "default" {
  name                  = "nginx-backend"
  load_balancing_scheme = "EXTERNAL"
  port_name             = "http"
  protocol              = "HTTP"
  timeout_sec           = 10
  health_checks         = [google_compute_health_check.default.self_link]

  dynamic "backend" {
    for_each = var.config.cloud.workload
    content {
      group           = google_compute_instance_group.group[backend.key].self_link
      balancing_mode  = "UTILIZATION"
      capacity_scaler = backend.value.traffic
    }
  }
}

resource "google_compute_url_map" "default" {
  name            = "url-map"
  default_service = google_compute_backend_service.default.self_link
}

resource "google_compute_target_http_proxy" "default" {
  name        = "http-proxy"
  url_map     = google_compute_url_map.default.self_link
}

resource "google_compute_global_forwarding_rule" "default" {
  name                  = "http-forwarding-rule"
  target                = google_compute_target_http_proxy.default.self_link
  port_range            = "80"
  load_balancing_scheme = "EXTERNAL"
}

`network.tf`

resource "google_compute_firewall" "allow_http" {
  name    = "allow-http"
  network = "default"

  allow {
    protocol = "tcp"
    ports    = ["80"]
  }

  source_ranges = ["0.0.0.0/0"]
  target_tags   = ["public"]
}

`api.tf`

resource "google_project_service" "apis" {
  project = var.config.cloud.project_id
  service = "compute.googleapis.com"
}

`variables.tf`

variable "config" {
  type = any
}

Utilisation de Terragrunt avec OpenTofu

Terragrunt est pleinement compatible avec OpenTofu. Il suffit de remplacer la commande terraform par tofu dans votre via votre variable TERRAGRUNT_TFPATH :

export TERRAGRUNT_TFPATH=tofu

Conclusion

Ce projet démontre la maturité d'OpenTofu pour gérer des infrastructures complexes tout en restant compatible avec l'écosystème Terraform. Couplé à Terragrunt, il devient un outil de choix pour l'automatisation multi-environnement. L'intégration avec GitLab pour la gestion d'état et les pipelines CI renforce encore sa pertinence pour des workflows GitOps en production : il est tout aussi cpable que Terraform.

Grâce à une configuration modulaire, un backend distant sécurisé, et une exposition via un load balancer global, ce cas d’usage illustre comment industrialiser un déploiement cloud fiable avec des outils modernes, ouverts et maintenus par la communauté.

Références

OpenTofu documentation : https://opentofu.org/docs/
GitLab HTTP backend support : https://docs.gitlab.com/ee/user/infrastructure/terraform_backend.html
GCP Terraform provider : https://registry.terraform.io/providers/hashicorp/google/latest/docs
Terragrunt official site : https://terragrunt.gruntwork.io/
Exemple Load Balancer GCP avec Terraform : https://cloud.google.com/load-balancing/docs/https/ext-https-lb-tf

KubeCon Europe 2025 : entre hype et réalité

Benoît Garçon — Fri, 11 Apr 2025 11:41:46 +0000

La semaine dernière, j'ai eu le plaisir de participer à la KubeCon Europe 2025, qui s'est tenue à Londres du 1er au 4 avril. Cet événement est l'un des plus grands rassemblements de la communauté cloud native en Europe, réunissant développeurs, architectes, et passionnés autour des technologies open source.

Une ambiance dynamique

Dès mon arrivée, j'ai été impressionné par l'effervescence qui régnait au sein de l'ExCeL London. Avec 229 sessions programmées, allant des keynotes inspirantes aux ateliers techniques, en passant par des lightning talks percutants, il y en avait pour tous les goûts. Les co-located events, tels que l'ArgoCon, ont offert des perspectives sur leurs roadmaps spécifiques.

Des échanges engagés

Au-delà des conférences, ce sont les rencontres qui ont marqué mon expérience. Les discussions informelles lors des pauses café, les échanges sur les stands des sponsors, et les afterworks ont été autant d'occasions de partager des retours d'expérience, de découvrir de nouveaux outils, et de tisser des liens avec des professionnels venus des quatre coins du monde.

Une omniprésence de l'IA, parfois au détriment de la profondeur technique

Cependant, un aspect m'a quelque peu déçu : la présence omniprésente de l'intelligence artificielle. Bien que l'IA soit un sujet incontournable, j'ai eu le sentiment que de nombreuses présentations l'abordaient de manière superficielle, plus comme un argument marketing que comme une réelle avancée technique. Certains talks semblaient manquer de profondeur, privilégiant les effets d'annonce aux démonstrations concrètes.

Un événement à la croisée des chemins

En conclusion, la KubeCon Europe 2025 a été une expérience enrichissante, tant sur le plan professionnel que personnel. L'organisation impeccable, la diversité des sessions, et la richesse des échanges en font un rendez-vous incontournable pour tout professionnel du cloud native. Néanmoins, j'espère que les prochaines éditions sauront rééquilibrer le contenu, en mettant davantage l'accent sur la profondeur technique et les retours d'expérience concrets, afin de satisfaire les attentes des praticiens chevronnés.

Simplifiez votre infra avec les Stacks Terragrunt

Benoît Garçon — Tue, 11 Mar 2025 21:03:48 +0000

Terragrunt, l'outil de gestion de configurations pour Terraform, a récemment introduit une fonctionnalité majeure : les stacks. Cette nouveauté vise à simplifier et optimiser la gestion des infrastructures en réduisant la répétition et en améliorant l'organisation des configurations. Dans cet article, nous explorerons en détail cette fonctionnalité, en la rendant accessible aux débutants tout en fournissant des informations approfondies pour les experts.

Qu'est-ce qu'une Stack dans Terragrunt ?

Dans le contexte de Terragrunt, une stack est une collection d'unités gérées ensemble. Elle peut représenter un environnement complet, tel que dev, staging ou prod, ou un projet entier. Les stacks permettent de gérer la complexité liée à la gestion de multiples unités à travers différents environnements.

Pourquoi les Stacks ?

Avant l'introduction des stacks, les utilisateurs de Terragrunt devaient souvent gérer un grand nombre de fichiers terragrunt.hcl, ce qui entraînait une répétition et une complexité accrues. Les stacks offrent une abstraction au-dessus de ces fichiers, permettant de regrouper et de gérer plusieurs unités au sein d'une seule configuration. Cette approche réduit la redondance et facilite la maintenance des configurations.

Fonctionnalités clés des Stacks

Fichier `terragrunt.stack.hcl`

Le fichier terragrunt.stack.hcl est au cœur de cette nouvelle fonctionnalité. Il sert de raccourci pour définir une stack, similaire à la manière dont les unités peuvent être définies directement dans un dossier. Ce fichier permet de centraliser la configuration de plusieurs unités, simplifiant ainsi la gestion et la lisibilité.

Bloc `unit`

Au sein du fichier terragrunt.stack.hcl, le bloc unit est utilisé pour définir une unité de déploiement. Chaque unité représente un composant d'infrastructure distinct à déployer dans le cadre de la stack. Le bloc unit prend en charge plusieurs arguments, permettant une configuration détaillée et flexible de chaque composant.

Commande `terragrunt stack output`

Terragrunt introduit la commande terragrunt stack output, qui permet aux utilisateurs de récupérer et d'interagir avec les sorties de plusieurs unités au sein d'une stack. Cette fonctionnalité simplifie la gestion des sorties d'infrastructure en les consolidant en une vue unique.

Avantages des Stacks

Réduction de la répétition : En consolidant les configurations, les stacks diminuent la duplication de code, rendant les configurations plus propres et plus faciles à maintenir.
Gestion simplifiée des dépendances : Les stacks permettent de définir clairement les dépendances entre les unités, assurant que les composants d'infrastructure sont déployés dans le bon ordre.
Visualisation améliorée : Avec les stacks, il est plus facile de visualiser et de comprendre la structure et les relations au sein de l'infrastructure, ce qui facilite la planification et le dépannage.

Considérations actuelles

Bien que les stacks apportent de nombreux avantages, il est important de noter que cette fonctionnalité est encore en phase expérimentale. Pour qu'elle soit stabilisée, plusieurs aspects doivent être abordés, notamment :

Support des commandes stack : Ajouter la prise en charge des commandes stack run * pour étendre les opérations au niveau des stacks.
Support des sorties stack : Intégrer les commandes stack output pour améliorer l'interaction avec les sorties des stacks.
Support des valeurs de stack : Introduire la gestion des "valeurs" au niveau des stacks pour une configuration plus flexible.
Support des stacks récursives : Permettre la gestion de stacks imbriquées pour des architectures d'infrastructure plus complexes.
Tests d'intégration : Effectuer des tests approfondis pour assurer une gestion fluide des stacks dans divers scénarios opérationnels.
Compatibilité avec le parallélisme : Vérifier la compatibilité avec les indicateurs de parallélisme, en particulier pour les stacks avec des dépendances.

Exemple d'application

Voici un exemple de stack Terragrunt sur Google Cloud Platform (GCP). Cette stack va gérer :

Un VPC avec un sous-réseau
Une instance Compute Engine (VM)
Une base de données Cloud SQL

Structure du projet

On va organiser le projet en trois modules Terraform :

gcp-stack/
│── modules/
│   │── vpc/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   ├── outputs.tf
│   │── compute/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   ├── outputs.tf
│   │── database/
│       ├── main.tf
│       ├── variables.tf
│       ├── outputs.tf
│── terragrunt.stack.hcl
│── terragrunt.hcl

1. Définition de la stack (`terragrunt.stack.hcl`)

Dans Terragrunt, une stack est définie dans le fichier terragrunt.stack.hcl. Voici un exemple :

# Activer la fonctionnalité expérimentale des stacks
experiments = ["stacks"]

stack "gcp-infra" {
  description = "Infrastructure GCP avec VPC, VM et base de données"

  unit "vpc" {
    path = "./modules/vpc"
  }

  unit "compute" {
    path = "./modules/compute"
    dependencies = ["vpc"]
  }

  unit "database" {
    path = "./modules/database"
    dependencies = ["vpc"]
  }
}

Explications

La stack "gcp-infra" regroupe trois units : vpc, compute, database
Chaque unit représente un module Terraform
compute et database dépendent du vpc, donc ils ne seront déployés qu'après

2. Configuration Terragrunt (`terragrunt.hcl`)

Ce fichier permet d'éviter les répétitions et de centraliser certaines configurations :

terraform {
  source = "${path_relative_to_include()}"
}

remote_state {
  backend = "gcs"
  config = {
    bucket = "my-terraform-state-bucket"
    prefix = "${path_relative_to_include()}"
  }
}

inputs = {
  project_id  = "my-gcp-project"
  region      = "us-central1"
}

3. Module VPC (`modules/vpc/main.tf`)

Ce module crée un VPC avec un sous-réseau :

resource "google_compute_network" "vpc" {
  name                    = "my-vpc"
  auto_create_subnetworks = false
}

resource "google_compute_subnetwork" "subnet" {
  name          = "my-subnet"
  region        = var.region
  network       = google_compute_network.vpc.id
  ip_cidr_range = "10.0.0.0/24"
}

output "vpc_id" {
  value = google_compute_network.vpc.id
}

output "subnet_id" {
  value = google_compute_subnetwork.subnet.id
}

4. Module Compute Engine (`modules/compute/main.tf`)

Ce module déploie une VM qui utilise le VPC créé :

resource "google_compute_instance" "vm" {
  name         = "my-vm"
  machine_type = "e2-medium"
  zone         = "${var.region}-a"

  boot_disk {
    initialize_params {
      image = "debian-cloud/debian-11"
    }
  }

  network_interface {
    network    = var.vpc_id
    subnetwork = var.subnet_id
  }
}

output "vm_ip" {
  value = google_compute_instance.vm.network_interface[0].network_ip
}

5. Module Cloud SQL (`modules/database/main.tf`)

Ce module crée une base de données Cloud SQL :

resource "google_sql_database_instance" "db" {
  name             = "my-database"
  database_version = "MYSQL_8_0"
  region           = var.region

  settings {
    tier = "db-f1-micro"
    ip_configuration {
      private_network = var.vpc_id
    }
  }
}

output "db_instance" {
  value = google_sql_database_instance.db.connection_name
}

6. Déploiement de la stack

Avec Terragrunt, il est possible d'exécuter toutes les unités de la stack en une seule commande :

terragrunt run-all apply

Cette commande :

Déploie d'abord le VPC
Puis la VM et la base de données
Gère les dépendances automatiquement

Pour voir les outputs de toute la stack :

terragrunt stack output

Les stacks dans Terragrunt offrent une organisation claire et une gestion automatique des dépendances entre les modules. Sur GCP, elles permettent de déployer une infrastructure complète en une seule commande, tout en centralisant la configuration.

Conclusion

L'introduction des stacks dans Terragrunt représente une avancée significative pour la gestion des infrastructures en tant que code. En offrant une abstraction au-dessus des configurations existantes, les stacks simplifient la gestion, réduisent la répétition et améliorent la clarté des infrastructures complexes. Bien que la fonctionnalité soit encore en phase expérimentale, elle offre déjà des outils puissants pour les praticiens du cloud, qu'ils soient novices ou experts.

Pour ceux qui souhaitent explorer davantage cette fonctionnalité, il est recommandé de consulter la documentation officielle de Terragrunt et de participer aux discussions communautaires pour rester informés des évolutions futures.

DEV Community: La Formule Nuagique

Mettre à jour GKE sans sueurs froides : La stratégie Terraform Zero-Downtime

1. La règle d'or : Dissocier control plane et node pools

Le control plane

2. Les node pools : Là où le danger réside

L'approche max_surge et max_unavailable

3. Les fenêtres de maintenance

4. Le piège invisible : Les Pod Disruption Budgets

Conclusion : L'automatisation comme standard

Besoin d'auditer la résilience de vos clusters Kubernetes ?

Sécurisez et optimisez vos transferts de fichiers avec les signed URLs Cloud Storage

Qu'est-ce qu'une Signed URL ?

Implémentation technique

Prérequis

Le code (Backend Python)

Le code (Frontend JavaScript)

Les pièges à éviter

1. La configuration CORS

2. Validez le Content-Type

3. Gestion des noms de fichiers

Conclusion

Interconnexion multi-cloud GCP, AWS, Azure : Maîtriser le coût, la performance et la sécurité de vos flux

1. Performance : Adieu l'imprévisible, bonjour la latence déterministe

Le problème du VPN HA

La promesse de l'interconnexion privée

2. Le facteur FinOps : Le point de rentabilité (Break-Even)

Coûts Fixes (Ports) vs. Coûts Variables (Egress)

Le seuil critique de 100 To

3. Sécurité de Couche 2 : Le Bouclier MACsec

4. Stratégie simplifiée : Choisir l'architecture adaptée

A. Connexion GCP vers AWS

B. Connexion GCP vers Azure

Conclusion et recommandations

Guide pour l'installation de GKE on-prem sur VMware

L'architecture GDC sur VMware : Les 3 piliers

Phase 1 : La planification, clé du succès avec Anthos

Prérequis vSphere : Au-delà de la simple version

Le point de bascule : La planification des adresses IP

Phase 2 : Configurer la connexion au cloud Google

Phase 3 : Création du poste de travail administrateur

Phase 4 : Déployer le cerveau, le cluster d'administrateur

Étape suivante : Votre premier cluster utilisateur

Simplifiez vos workflows DevOps avec Task, le "Makefile" moderne

Qu'est-ce que Task et pourquoi s'y intéresser ?

Installation : Votre premier pas vers l'automatisation

Votre premier Taskfile.yml : Le cœur de l'action

Exécuter vos tâches

Lister toutes les tâches

Fonctionnalités avancées pour le DevOps moderne

1. Dépendances entre tâches

2. Variables et paramètres

3. Gestion des erreurs et conditions

4. Exécution parallèle

Task vs. Makefile vs. scripts Shell

Bonnes pratiques avec Task pour la Formule Nuagique

Conclusion : adoptez Task et gagnez en efficacité !

Google Cloud Storage : Le guide du débutant pour maîtriser vos fichiers

Les concepts clés

Les "buckets", vos conteneurs dans le cloud

Les "objects", vos fichiers et leurs métadonnées

Partie 2 : Vos premiers pas avec gcloud storage

Créer votre premier bucket

Envoyer (uploader) votre premier fichier

Lister le contenu d'un bucket

Télécharger un fichier

Supprimer un objet et un bucket

Partie 3 : Optimiser les coûts

Les classes de stockage, à chaque donnée son usage

Le Cycle de Vie des Objets - L'Automatisation au Service de vos Économies

Partie 4 : L'astuce de fin, partager un fichier de manière sécurisée et temporaire

Conclusion

Sources

IAP sur GKE : Google change les règles, êtes-vous prêt pour la migration ?

Pourquoi ce changement ? L'ancien monde face au nouveau

Le plan de migration, étape par étape

Première étape : Vérifiez si vous êtes concerné

Deuxième étape : Définir votre GCPBackendPolicy

Les avantages concrets de cette migration

N'attendez pas le dernier moment

Proxy-only subnet sur GCP : Le guide pour bien démarrer

Votre premier `Taskfile.yml` : Le cœur de l'action

Partie 2 : Vos premiers pas avec `gcloud storage`

`workload.tf`

`load_balancing.tf`

`network.tf`

`api.tf`

`variables.tf`

Fichier `terragrunt.stack.hcl`

Bloc `unit`

Commande `terragrunt stack output`

1. Définition de la stack (`terragrunt.stack.hcl`)

2. Configuration Terragrunt (`terragrunt.hcl`)

3. Module VPC (`modules/vpc/main.tf`)

4. Module Compute Engine (`modules/compute/main.tf`)

5. Module Cloud SQL (`modules/database/main.tf`)