Cloud Ops Chronicles

Le Workflow "AI-First" : Quand votre IDE ne démarre que pour valider l'IA

2026-05-14T00:00:00+02:00

L’ère du développeur-validateur
Le nouveau cycle de vie : de la Feature à la Release
Pourquoi Nix ? L’arme secrète du déterminisme
Les dessous de l’architecture : abattre les murs pour les workstations Serverless
Le nerf de la guerre : Pourquoi le Scale-to-Zero change tout pour le budget
Architecture du projet et pipeline de build
- Le conteneur de base
- La forge : L’Agent IA en action
Pour démarrer

Une Workstation VS Code reproductible sur Cloud Run, propulsée par Nix, conçue pour les boucles de collaboration Humain-IA — avec un coût de 0,00 $ au repos.

🔗 Source du projet : gitlab.com/matgou/workstation-nix

L’ère du développeur-validateur¶

Il y a encore peu de temps, nos environnements de développement vivaient sur nos machines, lourds et personnalisés à l’excès. Puis sont arrivés les IDE Cloud (GitHub Codespaces, Google Cloud Workstations), pensés pour une ère bien précise : celle de développeurs humains codant activement 8 heures par jour en utilisant la puissance de serveurs déportés.

Mais l’émergence de l’IA générative bouleverse aussi cette donne. Aujourd’hui, face à la génération de code, on a besoin de GPU : locaux (pas chers), distants (chers) et, en plus, deux visions s’affrontent et on verra bien laquelle perdurera :

L’école du “les IA seront bientôt 100% autonomes” : Le développeur ne maintient plus que des spécifications en Markdown, l’IA fait tout le reste, de bout en bout.
L’école du “L’IA prépare, l’humain valide” : L’IA abat le gros du travail, mais le développeur aura toujours un rôle de garant du code produit. Il sera amené à “mettre les mains dedans” pour tester, valider et ajuster.

Soyons pragmatiques : la première école relève encore (pour l’instant) de la science-fiction pour la majorité des projets complexes ou critiques en entreprise. Et je suis d’avis que nous avons pour l’instant toujours besoin de mettre les mains dans le cambouis pour auditer et valider le code généré. Cependant, je constate que nos outils n’ont pas suivi, l’adoption des EDI déportés est encore trop anecdotique. Et payer un environnement permanent alors que l’humain n’intervient plus qu’en pointillé n’a aucun sens économique — et même écologique.

Je vous propose ici une réflexion autour des nouveaux EDI déportés et souhaite montrer qu’ils sont accessibles à tous avec, comme exemple, la mise en place d’une Workstation-CloudRun. Ces derniers, bien que n’ayant pas été construits précisément pour ce monde de symbiose entre le développeur et l’agent IA, s’y adaptent pourtant parfaitement. Aujourd’hui chacun peut disposer d’un EDI surpuissant, avec des GPUs, sur mesure, disponible instantanément, qui ne vit que le temps exact où nous avons besoin de réviser le code (et pas pendant que l’IA travaille).

Le nouveau cycle de vie : de la Feature à la Release¶

Pour bien comprendre la nouvelle dynamique du développement piloté par les agents IA, il faut repenser notre pipeline de livraison. L’humain n’est plus à l’origine du code, il en devient le validateur final.

Voici une vision d’un workflow moderne :

Les spécifications d’un ticket ou d’une modification sont communiquées. (Je ne vais pas détailler ici comment écrire et faire valider de bonnes spécifications pour que l’IA puisse les traiter.)
L’IA travaille dans l’ombre : Un agent IA (Gemini, Claude, ou un pipeline CI autonome) échafaude un projet, écrit une feature ou résout un bug.
Le point de convergence : L’agent dépose tout ce code directement dans un grove — un bucket Google Cloud Storage (GCS) servant d’espace de travail partagé. J’ai emprunté le terme “grove” au framework Google Scion. (Coût : 0 $, le stockage objet étant quasi gratuit).
Le passage de relais (Hand-off) : L’IA vous notifie que le code est prêt à être validé ou complété par l’humain.
L’Humain prend la main : Vous cliquez sur une URL Cloud Run. En quelques secondes, une instance VS Code démarre dans la Workstation Nix. Le code généré par l’IA est déjà là, monté instantanément. Dans cette workstation, vous pouvez modifier, lancer, déboguer le code, ou même le vibecoder.
Scale to Zero : Une fois la PR validée, vous fermez l’onglet. L’instance Cloud Run s’éteint. Vous ne payez plus.

Voici comment se matérialise ce cycle, de la requête initiale jusqu’à la release :

flowchart LR
    A["🎯 Feature Request"] --> B{"🤖 Agent IA"}
    B ==>|"git clone + code"| C[("☁️ Grove (GCS)")]
    D["💻 Workstation Nix"] -->|"GCS FUSE mount"| C
    B --> |"spawn"| D
    E{"👨‍💻 Humain"} --> |"review, test, fix"| D
    E -->|"git merge"| F[("🚀 Git Release")]

    style A fill:#4285f4,color:#fff,stroke:none
    style B fill:#ea4335,color:#fff,stroke:none
    style C fill:#fbbc04,color:#333,stroke:none
    style D fill:#34a853,color:#fff,stroke:none
    style E fill:#ea4335,color:#fff,stroke:none
    style F fill:#4285f4,color:#fff,stroke:none

Le gros avantage d’un workflow comme celui-ci est entre autres le principe du Scale to Zero : c’est-à-dire que le coût total au repos : 0,00 $ — En effet, le grove (GCS) ne coûte que quelques centimes de stockage. La Workstation ne consomme des ressources que pendant la validation humaine.

Des IA qui manipulent du code, ça semble maintenant classique, mais VS Code dans Cloud Run, c’est un concept. Pour le rendre fonctionnel et reproductible, il faut parfois contourner certaines limites. Ce projet est un bon exemple de comment repousser les limites de cette technologie.

Pourquoi Nix ? L’arme secrète du déterminisme¶

Dans ce projet, il faut garantir que l’environnement dans lequel s’exécute le code est reproductible et qu’il disposera de tous les outils nécessaires aux suites de tests et au développement.

Un des défis est donc que l’environnement soit reproductible mais non figé (par exemple, si on compile un conteneur Docker, on embarque toutes les dépendances de manière statique mais aussi les failles de sécurité).

C’est ici que Nix entre en jeu en remplaçant l’approche impérative par une approche purement fonctionnelle. Chaque dépendance est managée as code et embarque son arbre de dépendances complet. “Le package.json/package-lock de la workstation” en quelque sorte.

Voici pourquoi Nix est devenu indispensable pour cette architecture : - Reproductibilité bit-à-bit : Le même fichier flake.lock (généré par l’IA ou le template) produit toujours exactement la même image. - Composition atomique : Ajouter un outil se résume à une ligne.

coreTools = with pkgs; [
  bashInteractive coreutils curl git jq neovim nix ripgrep
];

Chaque binaire — de bash à code-server — est tiré du Nix Store avec sa version exacte. Nix génère ensuite l’image Docker finale pour nous via pkgs.dockerTools.buildLayeredImage, sans même avoir besoin d’un daemon Docker complexe. - Pas d’artefacts à stocker : Seul le fichier de code flake.nix est à stocker. La beauté de la chose, c’est que si l’on change de machine, on repart avec la même configuration.

C’est exactement le choix qui a été fait par devenv.sh, un projet open source de Cachix qui standardise la définition d’environnements de développement au-dessus de Nix. Son principe : décrire son environnement dans un simple fichier devenv.nix avec une syntaxe déclarative — langages, paquets, services, scripts — et laisser Nix matérialiser le tout de façon reproductible. Activating Python, Rust ou PostgreSQL se résume à une ligne (languages.python.enable = true;), l’activation d’un environnement se fait en moins de 100 ms grâce au cache, et le tout reste décorable via des profils et des imports.

Notre Workstation-CloudRun s’intègre naturellement avec le standard devenv. Une fois connecté à l’IDE, le développeur peut simplement lancer devenv shell dans le terminal VS Code pour activer l’environnement déclaré dans le dépôt du projet hébergé sur le grove. Les outils, les versions, les services — tout est déjà défini as code par l’équipe ou par l’IA. Le développeur n’a rien à installer manuellement : l’environnement de développement est aussi éphémère et reproductible que la workstation elle-même.

Les dessous de l’architecture : abattre les murs pour les workstations Serverless¶

Sur le papier, faire tourner un IDE web comme VS Code sur Cloud Run semble facile. Nix propose un système de build permettant de créer des conteneurs. Mais dans la pratique (et particulièrement d’un point de vue DevSecOps), les plateformes Serverless ne sont pas du tout conçues pour héberger des environnements stateful avec des accès terminaux complexes.

Pour transformer cette vision en réalité, j’ai dû affronter et contourner quelques limites techniques majeures de l’écosystème cloud actuel. Je vous propose un petit retour d’expérience sur les problèmes rencontrés :

Mur n°1 — Le terminal qui refuse de s’ouvrir¶

Nous allons utiliser le terminal de VS Code pour interagir avec l’environnement. Mais manipuler un terminal oblige à interagir avec le noyau du système.

Le noyau gVisor par défaut (Gen1) de Cloud Run ne supporte pas les pseudo-terminaux (/dev/ptmx).

La solution : Passer au moteur d’exécution Cloud Run de seconde génération (--execution-environment gen2). Cela exécute le conteneur dans une véritable micro-VM Linux. Nous montons ensuite devpts manuellement au démarrage pour débloquer les terminaux VS Code.

Mur n°2 — Les WebSockets vs. la couche proxy¶

La commande gcloud run services proxy, qui permet d’accéder à un service Cloud Run via un tunnel local, ne supporte pas les connexions WebSocket. Or, VS Code (code-server) repose massivement sur les WebSockets pour le terminal et l’édition en temps réel. Résultat : des freezes aléatoires du terminal et des déconnexions en pleine session. Ce problème bloque de facto l’utilisation d’IAP (Identity-Aware Proxy) comme couche d’authentification, puisque le proxy en est le point d’entrée.

Une alternative aurait été de placer un Load Balancer avec IAP devant Cloud Run — solution propre mais qui introduit un coût fixe permanent (~18 $/mois pour la règle de forwarding), ce qui va à l’encontre de notre philosophie Scale-to-Zero à coût nul au repos.

La solution pragmatique : Exposer Cloud Run directement (avec son URL HTTPS native) et déléguer la sécurité au mécanisme natif --auth password de code-server, qui est pleinement compatible WebSocket. Le timeout de l’instance Cloud Run est également poussé à son maximum légal (3600 secondes) pour garantir une session ininterrompue, et le nombre maximum d’instances est verrouillé à 1 (--max-instances 1) pour garantir une session unique et maîtriser les coûts.

Mur n°3 — Le stockage partagé Humain / IA¶

À chaque scale-to-zero, le conteneur disparaît. Il nous fallait un espace persistant où l’IA peut déposer le code et où la workstation peut modifier et le récupérer. Puis le reprendre en cas de stop/start du conteneur. Le but étant de pouvoir travailler sur un projet, de l’abandonner et de le reprendre plus tard sans perdre son travail. Idéal pour les périodes d’essai.

La solution : GCS FUSE et le mirage des permissions POSIX : Un bucket Cloud Storage monté via GCS FUSE semblait la solution évidente. Cependant, un nouveau mur est apparu : GCS n’est pas un système de fichiers POSIX et ne gère pas nativement les changements de permissions (les fameux chmod et chown). Conséquence ? Des outils modernes comme devenv, npm ou git, qui tentent de sécuriser leurs fichiers temporaires ou environnements virtuels, plantaient lamentablement avec une erreur fatale : Operation not permitted.

Pour contourner cette limitation stricte sans sacrifier la persistance temps réel, nous avons “trompé” l’outil de montage FUSE en forçant une simulation totale des permissions pour notre utilisateur exclusif. Voici la configuration de montage Cloud Run optimisée pour l’IDE (quelques options de performances ont aussi été ajoutées) :

implicit-dirs
stat-cache-max-size-mb=32        # Alloue 32 Mo en RAM pour le cache des métadonnées
metadata-cache-ttl-secs=300      # Garde les métadonnées en cache pendant 5 minutes
enable-streaming-writes=true     # Écritures en streaming direct
client-protocol=http1            # (Performance) Forcer HTTP/1.1 pour éviter le Head-of-Line blocking HTTP/2
max-conns-per-host=100           # (Performance) Massifier les I/O parallèles
cache-dir=cr-volume:cache        # Indique à Cloud Run d'utiliser notre volume in-memory nommé "cache"
file-cache-max-size-mb=2048      # Alloue 2Go de RAM pour ce cache
uid=1000                         # Force l'appartenance à l'utilisateur VS Code
gid=1000
file-mode=0777                   # Simule une permissivité totale
dir-mode=0777

L’Asynchronisme et la gestion des petits fichiers : Créer un environnement virtuel (ex: python -m venv) implique la création de milliers de petits fichiers. Avec un montage réseau classique et le protocole HTTP/2 par défaut de GCS FUSE, toutes ces requêtes s’empilent de manière synchrone sur une seule connexion TCP. Nous forçons donc le protocole HTTP/1.1 (client-protocol=http1), ouvrons un pool de 100 connexions simultanées pour paralléliser massivement les écritures. De plus, nous conservons un cache local en RAM (cache-dir=cr-volume:cache) de 2 Go pour accélérer considérablement la lecture du code source existant.

Cependant, il faut être conscient des limites du Serverless : même avec cette parallélisation et ces caches agressifs, la latence réseau synchrone incompressible de Google Cloud Storage reste un goulot d’étranglement pour la création pure d’arborescences massives. Voici l’évolution des performances mesurées pour la création d’un environnement Python (devenv shell) sur notre architecture Cloud Run :

Configuration GCS FUSE	Temps de création du `venv`	Bilan
Standard (HTTP/2 par défaut)	~ 9 min 42 s	Inutilisable au quotidien
Optimisé (HTTP/1.1 + max-conns=100 + Caches RAM)	~ 8 min 44 s	Mieux, mais la latence synchrone bride le réseau
Optimisé + Déport `.devenv` en RAM (Symlink)	~ 45 secondes	Performances quasi locales !

L’ultime parade (implémentée via un wrapper transparent au sein même de l’image Nix) consiste à déporter le dossier d’état local .devenv dans la RAM (tmpfs) à l’aide d’un lien symbolique dynamique. Puisque le /nix/store est recréé à chaque démarrage de l’instance, le dossier d’état de l’environnement est par essence éphémère. En le générant en RAM, la création de milliers de fichiers devient atomique et immédiate. Le développeur conserve ainsi un environnement persistant pour son code via GCS FUSE (bénéficiant des options de cache pour la réactivité de lecture), tout en esquivant totalement la latence GCS pour la création de l’outillage lourd.

Grâce aux drapeaux uid, gid et mode, GCS FUSE considère de plus que l’utilisateur possède déjà tous les droits. Lorsqu’un outil demande un chmod, GCS FUSE renvoie un code de succès factice au lieu de crasher. Le développeur obtient ainsi un environnement de développement persistant, tout en évitant les crashs liés aux exigences POSIX.

Mur n°4 — Tourner en non-root avec Nix (Sécurité)¶

Faire tourner un IDE en root complet est une hérésie de sécurité. Mais Nix a besoin d’écrire dans /nix/store pour installer des paquets. La solution naïve — donner l’ownership du store entier à l’utilisateur coder (mode single-user) — est un anti-pattern de sécurité : l’utilisateur pourrait alors modifier n’importe quel binaire du système.

La solution : Utiliser le mode multi-user de Nix avec nix-daemon. Le conteneur démarre en root, lance le daemon Nix en arrière-plan (qui reste root et gère exclusivement le store), puis abandonne irrévocablement ses privilèges via gosu avant de lancer l’IDE sous l’UID 1000. Ainsi, le /nix/store reste en lecture seule pour l’utilisateur coder — il peut installer de nouveaux paquets via le daemon (qui vérifie et écrit pour lui), mais ne peut jamais altérer les binaires existants. C’est la même architecture que celle utilisée sur les machines NixOS de production.

Quelques petites optimisations supplémentaires qui concernent Nix : - Bypass du disque réseau : Nous forçons export TMPDIR=/tmp/cache pour orienter les builds vers notre volume in-memory ultra-rapide (RAM-disk de 4 Go monté spécialement pour l’occasion). - Mise au pas de Nix : Nous bloquons la parallélisation sauvage en forçant max-jobs = 4 et cores = 2 dans la configuration de Nix pour respecter les vCPU réellement alloués au conteneur.

Le nerf de la guerre : Pourquoi le Scale-to-Zero change tout pour le budget¶

Maintenant que nous avons réussi à packager Nix et VS Code dans un conteneur, nous pouvons l’utiliser avec une approche Cloud Run. Voici ce que ça change en termes de coûts.

L’approche Serverless brille particulièrement dans ce workflow hybride, car il permet de ne payer que ce qu’on consomme. Pour illustrer cela, prenons un scénario réaliste d’entreprise : un mois de travail standard (environ 160 heures) pour un développeur alternant entre validation IA et code manuel.

Dans un modèle cloud classique, votre environnement tourne (et vous facture) pendant ces 160 heures, que vous soyez en train de taper du code, en réunion, ou d’attendre qu’une IA finisse son travail. Regardons l’impact financier de notre approche face aux ténors du marché :

	Google Cloud Workstations	GitHub Codespaces (4-core)	Notre Cloud Run Workstation
Coût mensuel (160h)	~192 $	~61 $	~28 $
Coût d’attente (idle)	~171 $ (Control plane 24/7)	~3,50 $ (Stockage persistant)	0 $
Pénalité Asynchrone	L’instance tourne à vide	Le stockage est facturé	Seul le bucket GCS est facturé (< 1$)

Comment lire ce tableau ? La différence radicale (28$ contre 192$) s’explique par la suppression pure et simple du coût d’attente. Si l’IA prépare une grosse feature le lundi, mais que vous ne trouvez le temps de la réviser que le jeudi pendant 2 heures, Cloud Run ne vous aura coûté que 0,40 $ sur toute la semaine. Les autres solutions vous facturent des frais fixes en continu.

Architecture du projet et pipeline de build¶

Une des étapes du projet est la création d’un conteneur de base qui sera utilisé par Cloud Run et l’autre partie du projet consiste en la création d’un catalogue GitLab permettant de préparer le code pour la reprise par la workstation.

Le conteneur de base¶

Le projet est volontairement minimaliste — trois dossiers, zéro framework superflu :

workstation-nix/
├── base-oss/                  # 🏗️ Golden Image Nix
│   ├── flake.nix              #    Définition déclarative de l'image Docker
│   ├── flake.lock             #    Verrouillage des dépendances (reproductibilité)
│   └── .trivyignore           #    CVE acceptées (revue mensuelle)
├── terraform/                 # ☁️ Infrastructure as Code
│   ├── main.tf                #    APIs GCP, Artifact Registry, Secret Manager
│   ├── iam.tf                 #    Service Account & rôles (moindre privilège)
│   ├── variables.tf           #    Variables du projet
│   └── provider.tf            #    Configuration du provider GCP
├── cloudbuild.yaml            # 🔄 Pipeline CI/CD (Cloud Build)
└── Makefile                   # 🎯 Point d'entrée développeur (init/build/deploy)

base-oss/flake.nix est le cœur du projet : il définit de manière purement déclarative tous les outils embarqués dans la Golden Image (bash, git, code-server, nix…) et génère l’image Docker via pkgs.dockerTools.buildLayeredImage — sans Dockerfile, sans daemon Docker.

terraform/ provisionne l’infrastructure GCP nécessaire : activation des APIs, création de l’Artifact Registry pour stocker les images, du Secret Manager pour le mot de passe IDE, et du Service Account avec le principe du moindre privilège.

cloudbuild.yaml orchestre le pipeline CI/CD complet. Voici le flux de bout en bout, du git push à l’image déployable :

flowchart LR
    A["📦 git push"] --> B["🔨 Nix Build\n(nixos/nix)"]
    B -->|"image.tar.gz"| C["🐳 Docker Load\n& Tag"]
    C --> D["🔍 Trivy Scan\n(CRITICAL/HIGH)"]
    D -->|"✅ Pass"| E["📤 Push\nArtifact Registry"]
    D -->|"❌ Fail"| F["🚫 Build\nBloqué"]

    style A fill:#4285f4,color:#fff,stroke:none
    style B fill:#34a853,color:#fff,stroke:none
    style C fill:#4285f4,color:#fff,stroke:none
    style D fill:#fbbc04,color:#333,stroke:none
    style E fill:#34a853,color:#fff,stroke:none
    style F fill:#ea4335,color:#fff,stroke:none

Le pipeline se décompose en 4 étapes : 1. Nix Build — Le conteneur nixos/nix évalue flake.nix et produit une archive Docker layered (image.tar.gz). Aucune dépendance implicite : tout est dans le lockfile. 2. Docker Tag — L’image est chargée puis taguée avec latest et le short SHA du commit pour la traçabilité. 3. Trivy Scan — Scan de sécurité automatique. Si des CVE critiques non acceptées sont détectées, le build est bloqué (exit code 1). Seules les CVE documentées dans .trivyignore sont autorisées. 4. Push — L’image validée est poussée vers Artifact Registry, prête à être déployée sur Cloud Run.

Le tout s’exécute via un simple make build côté développeur — Cloud Build s’occupe du reste.

La forge : L’Agent IA en action¶

Une workstation à la demande prend tout son sens lorsque le travail préparatoire a été mâché par une intelligence artificielle. Pour faire le pont entre une “Issue” métier (le besoin) et l’environnement Cloud Run (la validation), nous avons besoin d’une forge automatisée.

Plutôt que d’exécuter un agent IA en local sur la machine du développeur, nous déléguons cette tâche à la CI/CD (ici GitLab CI), via un composant réutilisable (CI/CD Catalog). Voici comment fonctionne ce pipeline asynchrone :

Déclenchement (Trigger) : Ce job CI est conçu pour scruter les issues portant un label spécifique (ex: agent::run). Il peut être déclenché manuellement par un développeur (via l’interface GitLab) ou planifié de manière régulière via un CRON job (Scheduled Pipeline) qui va parcourir la liste d’attente de façon autonome (par exemple, toutes les nuits).
Exécution du Gemini CLI : Le job CI instancie un environnement léger contenant un outil en ligne de commande (gemini-cli) connecté à l’API Google Gemini. Ce CLI dispose d’outils (Function Calling / Tools) lui permettant de lire l’arborescence du projet, examiner le code existant et écrire de nouveaux fichiers.
Pre-coding de la feature : L’agent IA analyse la demande contenue dans le ticket. Il crée une nouvelle branche depuis main, échafaude le code (scaffolding), écrit les tests de base et implémente la fonctionnalité demandée.
Injection de l’environnement (devenv.nix) : C’est ici que la magie opère. L’IA sait de quels outils elle a besoin pour la feature (une nouvelle base Redis, l’ajout d’un compilateur Rust, un package Python spécifique, etc.). Elle va générer ou mettre à jour statiquement le fichier devenv.nix à la racine du projet.
Merge Request et Hand-off : Le code généré est poussé sur GitLab et une Merge Request est automatiquement ouverte. Le développeur reçoit une notification : le terrain est préparé.

Le passage de relais : Lorsque le développeur humain clique sur le lien pour démarrer sa Workstation Nix (Cloud Run), il bascule directement sur la branche de l’agent. La Workstation détecte automatiquement le fichier .vscode/extensions.json généré par l’IA et installe silencieusement les extensions recommandées en arrière-plan pendant le démarrage. Grâce au fichier devenv.nix fraîchement injecté, il lui suffit de taper devenv shell dans le terminal. Instantanément, toutes les dépendances requises par la nouvelle feature sont téléchargées et configurées via Nix, de manière parfaitement isolée et reproductible.

Le développeur n’a plus qu’à relire le code généré par l’IA, l’exécuter dans l’environnement préparé pour lui, ajuster les détails métier complexes et valider la Merge Request. Le cycle est bouclé.

Je ne vais pas détailler toute l’intégration de l’IA dans le projet, ce billet se concentrant plutôt sur l’idée de Workstation dans Cloud Run. Cependant, voici quelques indications sur le workflow que j’imagine.

Exemple d’intégration dans .gitlab-ci.yml :

Pour activer ce workflow dans n’importe quel projet, il suffit d’inclure le composant d’agent IA depuis le catalogue CI/CD GitLab :

include:
  - component: {{CI_SERVER_HOST}}/mon-orga/catalog/gemini-agent@1.0.0
    inputs:
      trigger_label: "agent::run"
      gemini_model: "gemini-2.5-pro"

Ce simple composant suffit à transformer votre GitLab CI en une véritable équipe de développement asynchrone, prête à préparer le terrain pour vos Workstations Nix.

Sous le capot : Le System Prompt de l’Agent

Pour que cet agent soit réellement autonome, voici un exemple de prompt système. Il définit clairement le rôle de l’agent, le concept de “Grove”, et insiste fortement sur la reproductibilité.

Voir le System Prompt de l'Agent Gemini

Tu es un Agent IA de Développement Autonome intégré dans une pipeline GitLab CI/CD. 
Ton rôle est de préparer le terrain pour les développeurs humains en pré-codant des fonctionnalités et en provisionnant des environnements de développement (Workstations) entièrement prêts à l'emploi.

Voici ta mission. Tu dois exécuter ces étapes de manière séquentielle et autonome :

1. RECHERCHE DES ISSUES :
   - Utilise l'API GitLab pour lister toutes les issues ouvertes du dépôt courant portant le label "{{trigger_label}}".
   - Si aucune issue n'est trouvée, termine ton exécution avec succès.

2. POUR CHAQUE ISSUE TROUVÉE, exécute le workflow suivant :

   A. ANALYSE ET PRÉPARATION :
      - Lis attentivement la description de l'issue pour comprendre le besoin technique.
      - Crée une nouvelle branche Git au nom explicite (ex: `feature/issue-<ID>-<nom-court>`).

   B. CRÉATION DU GROVE (ESPACE DE TRAVAIL) :
      - Provisionne un nouvel espace persistant (un "Grove") sur Google Cloud Storage (GCS) dédié à cette issue.
      - Initialise ce grove en y clonant le code source de la branche nouvellement créée.

   C. PRE-CODING & DEPENDANCES :
      - Implémente la fonctionnalité demandée ou corrige le bug.
      - Ajoute des tests unitaires basiques pour prouver le fonctionnement de ton code.
      - CRITIQUE : Analyse les dépendances nécessaires à ton code (Node.js, Python, PostgreSQL, etc.). Tu DOIS générer ou mettre à jour le fichier `devenv.nix` à la racine du projet pour y déclarer ces dépendances, afin que l'environnement soit reproductible pour l'humain.
      - CONFIGURATION IDE : Si le projet utilise Python, génère un fichier `.vscode/extensions.json` recommandant les extensions "ms-python.python" et "ms-python.vscode-pylance", ainsi qu'un fichier `.vscode/settings.json` configurant `python.defaultInterpreterPath` vers l'exécutable du virtualenv géré par devenv (c'est-à-dire `.devenv/state/venv/bin/python`).
      - Commite tes changements et pousse la branche sur GitLab. Ouvre une Merge Request (WIP/Draft).

   D. DEPLOIEMENT DE LA WORKSTATION :
      - Utilise les scripts du dépôt (ex: `make deploy`) pour déployer une instance Cloud Run Workstation éphémère.
      - Configure cette Workstation pour qu'elle monte le Grove GCS que tu as créé à l'étape B.
      - Récupère l'URL d'accès HTTPS générée par Cloud Run et le mot de passe.

   E. HAND-OFF (PASSAGE DE RELAIS) :
      - Publie un commentaire détaillé sur l'Issue GitLab initiale contenant :
        1. Le résumé de tes choix techniques.
        2. Le lien vers la Merge Request.
        3. Le lien d'accès direct vers la Workstation Cloud Run (avec la commande `devenv shell` suggérée).
        4. Les instructions de connexion.
      - Retire le label "{{trigger_label}}" et ajoute "ready-for-review".

RÈGLES STRICTES :
- Ne demande pas d'assistance humaine en cours de processus. Si tu rencontres une erreur, documente-la et passe à l'issue suivante.
- Le fichier `devenv.nix` est la source de vérité de l'infrastructure logicielle.

Pour démarrer¶

L’ensemble de ce socle d’infrastructure est open source. Trois commandes suffisent pour déployer votre propre environnement de révision “Scale-to-Zero” :

Une fois déployée, ouvrez l’URL affichée, entrez votre mot de passe, et vous voilà dans l’environnement de révision idéal — prêt à collaborer avec votre agent IA. Quand c’est fini, fermez simplement l’onglet. Zéro gaspillage, sécurité maximale.

🔗 Source du projet : gitlab.com/matgou/workstation-nix

The "AI-First" Workflow: When Your IDE Only Starts to Validate AI

2026-05-14T00:00:00+02:00

The Developer-Validator Era
The New Lifecycle: From Feature to Release
Why Nix? The Secret Weapon of Determinism
Under the Hood: Breaking Down Walls for Serverless Workstations
The Sinews of War: Why Scale-to-Zero Changes Everything for the Budget
Project Architecture and Build Pipeline
- The Base Container
- The Forge: The AI Agent in Action
To Get Started

🔗 Project source: gitlab.com/matgou/workstation-nix

A reproducible VS Code Workstation on Cloud Run, powered by Nix, designed for Human-AI collaboration loops — with a $0.00 idle cost.

The Developer-Validator Era¶

Not long ago, our development environments lived on our machines, heavy and overly customized. Then came Cloud IDEs (GitHub Codespaces, Google Cloud Workstations), designed for a very specific era: one where human developers code actively for 8 hours a day using the power of remote servers.

But the emergence of generative AI is also disrupting this paradigm. Today, for code generation, we need GPUs: local (cheap), remote (expensive) and, moreover, two visions clash and we will see which one prevails:

The “AIs will soon be 100% autonomous” school: The developer only maintains specifications in Markdown, the AI does the rest, end-to-end.
The “AI prepares, human validates” school: The AI does the bulk of the work, but the developer will always have a role as the guarantor of the produced code. They will have to “get their hands dirty” to test, validate, and adjust.

Let’s be pragmatic: the first school is still (for now) science fiction for the majority of complex or critical enterprise projects. And I am of the opinion that for now, we still need to get our hands dirty to audit and validate the generated code. However, I notice that our tools have not kept up; the adoption of remote IDEs is still too anecdotal. And paying for a permanent environment when the human only intervenes intermittently makes no economic sense — or even ecological sense.

I propose here a reflection on new remote IDEs and want to show that they are accessible to all with, as an example, the implementation of a CloudRun-Workstation. These, although not built precisely for this world of symbiosis between the developer and the AI agent, adapt perfectly to it. Today everyone can have a super-powerful IDE, with GPUs, custom-made, available instantly, which only lives the exact time we need to review the code (and not while the AI is working).

The New Lifecycle: From Feature to Release¶

To fully understand the new dynamic of AI-agent-driven development, we must rethink our delivery pipeline. The human is no longer the originator of the code, they become the final validator.

Here is a vision of a modern workflow:

The specifications of a ticket or a modification are communicated. (I won’t detail here how to write and validate good specifications for the AI to process.)
The AI works in the shadows: An AI agent (Gemini, Claude, or an autonomous CI pipeline) scaffolds a project, writes a feature, or fixes a bug.
The convergence point: The agent deposits all this code directly into a grove — a Google Cloud Storage (GCS) bucket serving as a shared workspace. I borrowed the term “grove” from the Google Scion framework. (Cost: $0, object storage being almost free).
The hand-off: The AI notifies you that the code is ready to be validated or completed by the human.
The Human takes over: You click on a Cloud Run URL. In seconds, a VS Code instance starts in the Nix Workstation. The AI-generated code is already there, mounted instantly. In this workstation, you can modify, run, debug the code, or even vibe-code it.
Scale to Zero: Once the PR is validated, you close the tab. The Cloud Run instance shuts down. You stop paying.

Here is how this cycle materializes, from the initial request to the release:

flowchart LR
    A["🎯 Feature Request"] --> B{"🤖 AI Agent"}
    B ==>|"git clone + code"| C[("☁️ Grove (GCS)")]
    D["💻 Nix Workstation"] -->|"GCS FUSE mount"| C
    B --> |"spawn"| D
    E{"👨‍💻 Human"} --> |"review, test, fix"| D
    E -->|"git merge"| F[("🚀 Git Release")]

    style A fill:#4285f4,color:#fff,stroke:none
    style B fill:#ea4335,color:#fff,stroke:none
    style C fill:#fbbc04,color:#333,stroke:none
    style D fill:#34a853,color:#fff,stroke:none
    style E fill:#ea4335,color:#fff,stroke:none
    style F fill:#4285f4,color:#fff,stroke:none

The big advantage of a workflow like this is, among other things, the Scale to Zero principle: that is to say, the total idle cost: $0.00 — Indeed, the grove (GCS) only costs a few cents in storage. The Workstation consumes resources only during human validation.

AIs manipulating code seems standard now, but VS Code in Cloud Run is a concept. To make it functional and reproducible, we sometimes have to bypass certain limits. This project is a good example of how to push the boundaries of this technology.

Why Nix? The Secret Weapon of Determinism¶

In this project, we must ensure that the environment in which the code runs is reproducible and that it will have all the tools necessary for test suites and development.

One of the challenges is therefore that the environment is reproducible but not frozen (for example, if we compile a Docker container, we embed all the dependencies statically but also the security flaws).

This is where Nix comes in by replacing the imperative approach with a purely functional approach. Each dependency is managed as code and embeds its complete dependency tree. “The package.json/package-lock of the workstation” in a way.

Here is why Nix has become indispensable for this architecture: - Bit-for-bit reproducibility: The exact same flake.lock file (generated by the AI or the template) always produces exactly the same image. - Atomic composition: Adding a tool comes down to one line.

coreTools = with pkgs; [
  bashInteractive coreutils curl git jq neovim nix ripgrep
];

Every binary — from bash to code-server — is pulled from the Nix Store with its exact version. Nix then generates the final Docker image for us via pkgs.dockerTools.buildLayeredImage, without even needing a complex Docker daemon. - No artifacts to store: Only the flake.nix code file needs to be stored. The beauty of it is that if you change machines, you start again with the same configuration.

This is exactly the choice made by devenv.sh, an open source project by Cachix that standardizes the definition of development environments on top of Nix. Its principle: describe your environment in a simple devenv.nix file with declarative syntax — languages, packages, services, scripts — and let Nix materialize everything reproducibly. Activating Python, Rust or PostgreSQL comes down to one line (languages.python.enable = true;), activating an environment takes less than 100 ms thanks to the cache, and everything remains decoratable via profiles and imports.

Our CloudRun-Workstation integrates naturally with the devenv standard. Once connected to the IDE, the developer can simply launch devenv shell in the VS Code terminal to activate the environment declared in the project repository hosted on the grove. The tools, versions, services — everything is already defined as code by the team or by the AI. The developer has nothing to install manually: the development environment is as ephemeral and reproducible as the workstation itself.

Under the Hood: Breaking Down Walls for Serverless Workstations¶

On paper, running a web IDE like VS Code on Cloud Run seems easy. Nix offers a build system to create containers. But in practice (and particularly from a DevSecOps point of view), Serverless platforms are not at all designed to host stateful environments with complex terminal accesses.

To turn this vision into reality, I had to confront and bypass some major technical limits of the current cloud ecosystem. Here is a quick retrospective on the problems encountered:

Wall #1 — The Terminal that Refuses to Open¶

We will use the VS Code terminal to interact with the environment. But manipulating a terminal requires interacting with the system kernel.

Cloud Run’s default gVisor kernel (Gen1) does not support pseudo-terminals (/dev/ptmx).

The Solution: Switch to the second-generation Cloud Run execution engine (--execution-environment gen2). This runs the container in a real Linux micro-VM. We then manually mount devpts at startup to unblock the VS Code terminals.

Wall #2 — WebSockets vs. the Proxy Layer¶

The gcloud run services proxy command, which allows accessing a Cloud Run service via a local tunnel, does not support WebSocket connections. However, VS Code (code-server) relies heavily on WebSockets for the terminal and real-time editing. Result: random terminal freezes and disconnections mid-session. This problem de facto blocks the use of IAP (Identity-Aware Proxy) as an authentication layer, since the proxy is the entry point.

An alternative would have been to place a Load Balancer with IAP in front of Cloud Run — a clean solution but one that introduces a permanent fixed cost (~$18/month for the forwarding rule), which goes against our Scale-to-Zero philosophy with zero idle cost.

The Pragmatic Solution: Expose Cloud Run directly (with its native HTTPS URL) and delegate security to code-server’s native --auth password mechanism, which is fully WebSocket compatible. The Cloud Run instance timeout is also pushed to its legal maximum (3600 seconds) to guarantee an uninterrupted session, and the maximum number of instances is locked to 1 (--max-instances 1) to guarantee a single session and control costs.

Wall #3 — Shared Human / AI Storage¶

At each scale-to-zero, the container disappears. We needed a persistent space where the AI can deposit the code and where the workstation can retrieve and modify it. Then pick it up in case of a stop/start of the container. The goal being to be able to work on a project, abandon it, and pick it up later without losing work. Ideal for testing periods.

The Solution: GCS FUSE and the Mirage of POSIX Permissions: A Cloud Storage bucket mounted via GCS FUSE seemed the obvious solution. However, a new wall appeared: GCS is not a POSIX file system and does not natively handle permission changes (the famous chmod and chown). Consequence? Modern tools like devenv, npm or git, which try to secure their temporary files or virtual environments, crashed miserably with a fatal error: Operation not permitted.

To bypass this strict limitation without sacrificing real-time persistence, we “tricked” the FUSE mounting tool by forcing a total simulation of permissions for our exclusive user. Here is the Cloud Run mount configuration optimized for the IDE (some performance options were also added):

implicit-dirs
stat-cache-max-size-mb=32        # Allocates 32 MB in RAM for metadata cache
metadata-cache-ttl-secs=300      # Keeps metadata in cache for 5 minutes
enable-streaming-writes=true     # Direct streaming writes
client-protocol=http1            # (Performance) Force HTTP/1.1 to avoid HTTP/2 Head-of-Line blocking
max-conns-per-host=100           # (Performance) Massify parallel I/O
cache-dir=cr-volume:cache        # Tells Cloud Run to use our in-memory volume named "cache"
file-cache-max-size-mb=2048      # Allocates 2GB of RAM for this cache
uid=1000                         # Forces ownership to the VS Code user
gid=1000
file-mode=0777                   # Simulates total permissiveness
dir-mode=0777

Asynchrony and the Management of Small Files: Creating a virtual environment (e.g., python -m venv) involves the creation of thousands of small files. With a classic network mount and the default HTTP/2 protocol of GCS FUSE, all these requests pile up synchronously on a single TCP connection. We therefore force the HTTP/1.1 protocol (client-protocol=http1), open a pool of 100 simultaneous connections to massively parallelize the writes. Moreover, we keep a local RAM cache (cache-dir=cr-volume:cache) of 2 GB to considerably accelerate the reading of the existing source code.

However, one must be aware of the limits of Serverless: even with this parallelization and these aggressive caches, the incompressible synchronous network latency of Google Cloud Storage remains a bottleneck for the pure creation of massive tree structures. Here is the evolution of the performances measured for the creation of a Python environment (devenv shell) on our Cloud Run architecture:

GCS FUSE Configuration	`venv` Creation Time	Assessment
Standard (Default HTTP/2)	~ 9 min 42 s	Unusable on a daily basis
Optimized (HTTP/1.1 + max-conns=100 + RAM Caches)	~ 8 min 44 s	Better, but synchronous latency throttles the network
Optimized + `.devenv` Relocation to RAM (Symlink)	~ 45 seconds	Near-local performance!

The ultimate workaround (implemented via a transparent wrapper within the Nix image itself) consists of relocating the local .devenv state folder into RAM (tmpfs) using a dynamic symbolic link. Since the /nix/store is recreated at each startup of the instance, the environment’s state folder is by essence ephemeral. By generating it in RAM, the creation of thousands of files becomes atomic and immediate. The developer thus keeps a persistent environment for their code via GCS FUSE (benefiting from the cache options for reading responsiveness), while totally avoiding GCS latency for the creation of heavy tooling.

Thanks to the uid, gid and mode flags, GCS FUSE also considers that the user already has all rights. When a tool requests a chmod, GCS FUSE returns a dummy success code instead of crashing. The developer thus obtains a persistent development environment, while avoiding crashes related to POSIX requirements.

Wall #4 — Running Non-Root with Nix (Security)¶

Running an IDE as full root is a security heresy. But Nix needs to write to /nix/store to install packages. The naive solution — giving ownership of the entire store to the coder user (single-user mode) — is an anti-pattern of security: the user could then modify any system binary.

The Solution: Use the Nix multi-user mode with nix-daemon. The container starts as root, launches the Nix daemon in the background (which remains root and exclusively manages the store), then irrevocably drops its privileges via gosu before launching the IDE under UID 1000. Thus, the /nix/store remains read-only for the coder user — they can install new packages via the daemon (which verifies and writes for them), but can never alter existing binaries. This is the same architecture used on production NixOS machines.

Some additional minor optimizations concerning Nix: - Network disk bypass: We force export TMPDIR=/tmp/cache to direct builds to our ultra-fast in-memory volume (4 GB RAM-disk mounted specially for the occasion). - Bringing Nix into line: We block wild parallelization by forcing max-jobs = 4 and cores = 2 in the Nix configuration to respect the vCPUs actually allocated to the container.

The Sinews of War: Why Scale-to-Zero Changes Everything for the Budget¶

Now that we have managed to package Nix and VS Code in a container, we can use it with a Cloud Run approach. Here is what changes in terms of costs.

The Serverless approach shines particularly in this hybrid workflow, because it allows paying only for what is consumed. To illustrate this, let’s take a realistic corporate scenario: a standard working month (about 160 hours) for a developer alternating between AI validation and manual coding.

In a classic cloud model, your environment runs (and bills you) during these 160 hours, whether you are typing code, in a meeting, or waiting for an AI to finish its work. Let’s look at the financial impact of our approach against the market leaders:

	Google Cloud Workstations	GitHub Codespaces (4-core)	Our Cloud Run Workstation
Monthly Cost (160h)	~$192	~$61	~$28
Idle Cost	~$171 (Control plane 24/7)	~$3.50 (Persistent storage)	$0
Asynchronous Penalty	The instance runs idle	Storage is billed	Only the GCS bucket is billed (< $1)

How to read this table? The radical difference ($28 vs $192) is explained by the pure and simple elimination of the idle cost. If the AI prepares a large feature on Monday, but you only find time to review it on Thursday for 2 hours, Cloud Run will have only cost you $0.40 over the whole week. The other solutions bill you fixed fees continuously.

Project Architecture and Build Pipeline¶

One of the project steps is the creation of a base container that will be used by Cloud Run and the other part of the project consists of creating a GitLab catalog allowing the code to be prepared for resumption by the workstation.

The Base Container¶

The project is intentionally minimalist — three folders, zero superfluous frameworks:

workstation-nix/
├── base-oss/                  # 🏗️ Golden Image Nix
│   ├── flake.nix              #    Declarative definition of the Docker image
│   ├── flake.lock             #    Dependency locking (reproducibility)
│   └── .trivyignore           #    Accepted CVEs (monthly review)
├── terraform/                 # ☁️ Infrastructure as Code
│   ├── main.tf                #    GCP APIs, Artifact Registry, Secret Manager
│   ├── iam.tf                 #    Service Account & roles (least privilege)
│   ├── variables.tf           #    Project variables
│   └── provider.tf            #    GCP provider configuration
├── cloudbuild.yaml            # 🔄 CI/CD Pipeline (Cloud Build)
└── Makefile                   # 🎯 Developer entry point (init/build/deploy)

base-oss/flake.nix is the heart of the project: it declaratively defines all the tools embedded in the Golden Image (bash, git, code-server, nix…) and generates the Docker image via pkgs.dockerTools.buildLayeredImage — without Dockerfile, without Docker daemon.

terraform/ provisions the necessary GCP infrastructure: API activation, creation of the Artifact Registry to store images, the Secret Manager for the IDE password, and the Service Account with the principle of least privilege.

cloudbuild.yaml orchestrates the complete CI/CD pipeline. Here is the end-to-end flow, from git push to the deployable image:

flowchart LR
    A["📦 git push"] --> B["🔨 Nix Build\n(nixos/nix)"]
    B -->|"image.tar.gz"| C["🐳 Docker Load\n& Tag"]
    C --> D["🔍 Trivy Scan\n(CRITICAL/HIGH)"]
    D -->|"✅ Pass"| E["📤 Push\nArtifact Registry"]
    D -->|"❌ Fail"| F["🚫 Build\nBlocked"]

    style A fill:#4285f4,color:#fff,stroke:none
    style B fill:#34a853,color:#fff,stroke:none
    style C fill:#4285f4,color:#fff,stroke:none
    style D fill:#fbbc04,color:#333,stroke:none
    style E fill:#34a853,color:#fff,stroke:none
    style F fill:#ea4335,color:#fff,stroke:none

The pipeline breaks down into 4 steps: 1. Nix Build — The nixos/nix container evaluates flake.nix and produces a layered Docker archive (image.tar.gz). No implicit dependencies: everything is in the lockfile. 2. Docker Tag — The image is loaded then tagged with latest and the short commit SHA for traceability. 3. Trivy Scan — Automatic security scan. If unaccepted critical CVEs are detected, the build is blocked (exit code 1). Only CVEs documented in .trivyignore are allowed. 4. Push — The validated image is pushed to Artifact Registry, ready to be deployed on Cloud Run.

Everything is executed via a simple make build on the developer side — Cloud Build takes care of the rest.

The Forge: The AI Agent in Action¶

An on-demand workstation takes on its full meaning when the preparatory work has been chewed up by an artificial intelligence. To bridge the gap between a business “Issue” (the need) and the Cloud Run environment (the validation), we need an automated forge.

Rather than running an AI agent locally on the developer’s machine, we delegate this task to the CI/CD (here GitLab CI), via a reusable component (CI/CD Catalog). Here is how this asynchronous pipeline works:

Trigger: This CI job is designed to scan for issues bearing a specific label (e.g., agent::run). It can be triggered manually by a developer (via the GitLab interface) or scheduled regularly via a CRON job (Scheduled Pipeline) that will autonomously go through the waiting list (for example, every night).
Gemini CLI Execution: The CI job instantiates a lightweight environment containing a command-line tool (gemini-cli) connected to the Google Gemini API. This CLI has tools (Function Calling / Tools) allowing it to read the project tree, examine existing code, and write new files.
Feature Pre-coding: The AI agent analyzes the request contained in the ticket. It creates a new branch from main, scaffolds the code, writes basic tests, and implements the requested functionality.
Environment Injection (devenv.nix): This is where the magic happens. The AI knows what tools it needs for the feature (a new Redis database, the addition of a Rust compiler, a specific Python package, etc.). It will generate or statically update the devenv.nix file at the root of the project to declare these dependencies, so that the environment is reproducible for the human.
Merge Request and Hand-off: The generated code is pushed to GitLab and a Merge Request is automatically opened. The developer receives a notification: the groundwork is laid.

The Hand-off: When the human developer clicks the link to start their Nix Workstation (Cloud Run), they switch directly to the agent’s branch. The Workstation automatically detects the .vscode/extensions.json file generated by the AI and silently installs the recommended extensions in the background during startup. Thanks to the freshly injected devenv.nix file, they just need to type devenv shell in the terminal. Instantly, all dependencies required by the new feature are downloaded and configured via Nix, in a perfectly isolated and reproducible manner.

The developer only has to read the code generated by the AI, execute it in the environment prepared for them, adjust complex business details, and validate the Merge Request. The cycle is complete.

I will not detail the entire integration of AI in the project, this post focusing more on the idea of Workstation in Cloud Run. However, here are some indications on the workflow I imagine.

Example Integration in .gitlab-ci.yml:

To activate this workflow in any project, simply include the AI agent component from the GitLab CI/CD catalog:

include:
  - component: {{CI_SERVER_HOST}}/my-org/catalog/gemini-agent@1.0.0
    inputs:
      trigger_label: "agent::run"
      gemini_model: "gemini-2.5-pro"

This simple component is enough to transform your GitLab CI into a true asynchronous development team, ready to lay the groundwork for your Nix Workstations.

Under the Hood: The Agent’s System Prompt

For this agent to be truly autonomous, here is an example of a system prompt. It clearly defines the role of the agent, the concept of “Grove”, and strongly insists on reproducibility.

View the Gemini Agent System Prompt

You are an Autonomous Development AI Agent integrated into a GitLab CI/CD pipeline.
Your role is to lay the groundwork for human developers by pre-coding features and provisioning fully ready-to-use development environments (Workstations).

Here is your mission. You must execute these steps sequentially and autonomously:

1. ISSUE SEARCH:
   - Use the GitLab API to list all open issues in the current repository bearing the label "{{trigger_label}}".
   - If no issues are found, successfully terminate your execution.

2. FOR EACH ISSUE FOUND, execute the following workflow:

   A. ANALYSIS AND PREPARATION:
      - Carefully read the issue description to understand the technical need.
      - Create a new Git branch with an explicit name (e.g., `feature/issue-<ID>-<short-name>`).

   B. GROVE CREATION (WORKSPACE):
      - Provision a new persistent space (a "Grove") on Google Cloud Storage (GCS) dedicated to this issue.
      - Initialize this grove by cloning the source code of the newly created branch into it.

   C. PRE-CODING & DEPENDENCIES:
      - Implement the requested functionality or fix the bug.
      - Add basic unit tests to prove the functioning of your code.
      - CRITICAL: Analyze the dependencies needed for your code (Node.js, Python, PostgreSQL, etc.). You MUST generate or update the `devenv.nix` file at the project root to declare these dependencies there, so that the environment is reproducible for the human.
      - IDE CONFIGURATION: If the project uses Python, generate a `.vscode/extensions.json` file recommending the "ms-python.python" and "ms-python.vscode-pylance" extensions, as well as a `.vscode/settings.json` file configuring `python.defaultInterpreterPath` to the executable of the virtualenv managed by devenv (i.e., `.devenv/state/venv/bin/python`).
      - Commit your changes and push the branch to GitLab. Open a Merge Request (WIP/Draft).

   D. WORKSTATION DEPLOYMENT:
      - Use the repository scripts (e.g., `make deploy`) to deploy an ephemeral Cloud Run Workstation instance.
      - Configure this Workstation to mount the GCS Grove you created in step B.
      - Retrieve the generated HTTPS access URL by Cloud Run and the password.

   E. HAND-OFF:
      - Post a detailed comment on the initial GitLab Issue containing:
        1. The summary of your technical choices.
        2. The link to the Merge Request.
        3. The direct access link to the Cloud Run Workstation (with the suggested `devenv shell` command).
        4. Connection instructions.
      - Remove the "{{trigger_label}}" label and add "ready-for-review".

STRICT RULES:
- Do not request human assistance during the process. If you encounter an error, document it and move on to the next issue.
- The `devenv.nix` file is the source of truth for the software infrastructure.

To Get Started¶

This entire infrastructure base is open source. Three commands are enough to deploy your own “Scale-to-Zero” review environment:

Once deployed, open the displayed URL, enter your password, and there you are in the ideal review environment — ready to collaborate with your AI agent. When it’s finished, simply close the tab. Zero waste, maximum security.

🔗 Project source: gitlab.com/matgou/workstation-nix

J'ai automatisé ma veille technologique avec un Podcast généré par IA (Gemini & Cloud Run)

2026-01-27T00:00:00+01:00

L’Architecture “Serverless”
- Le Code (Open Source)
Étape 1 : La Source de Données (BigQuery)
Étape 2 : Le Scénariste (Gemini 3 Pro)
Étape 3 : Le Studio Audio (Gemini 2.5 Flash TTS)
Étape 4 : Le Graphiste (Imagen 3)
Étape 5 : La Diffusion (FastAPI & RSS)
- Le Flux RSS Dynamique
Étape 6 : L’Infrastructure as Code (Terraform)
Étape 7 : Le Pipeline CI/CD (GitLab CI & Cloud Deploy)
Le Coût (FinOps)

Vous n’avez pas le temps de lire les centaines de release notes publiées par Google Cloud chaque semaine ? Moi non plus. C’est pour cela que j’ai créé le GCP News Podcast.

🎙️ Écoutez le résultat final ici : podcast.kapable.info

Ce projet n’est pas juste une démo, c’est un pipeline de production entièrement automatisé “Serverless” qui :

Récupère l’actualité technique brute.
Scénarise un dialogue entre deux experts virtuels (Marc et Sophie).
Génère l’audio avec un réalisme bluffant (intonations, rires, pauses).
Crée une couverture d’album unique pour chaque épisode.
Publie le tout sur le web et les plateformes de podcast (Spotify, etc.).

Voici comment j’ai construit ce système.

L’Architecture “Serverless”¶

Le système est conçu pour coûter près de zéro lorsqu’il ne tourne pas. Il s’appuie sur une architecture événementielle et des services managés.

Le Code (Open Source)¶

Tout le code est disponible sur GitLab : matgou/podcast-generator. Il est divisé en deux parties : * generator/ : Le script Python batch qui crée l’épisode. * frontend/ : L’interface web FastAPI pour écouter les épisodes.

Étape 1 : La Source de Données (BigQuery)¶

Contrairement à beaucoup de projets qui font du “scraping”, ici nous utilisons une source de vérité propre : le dataset public BigQuery de Google.

Le script exécute une simple requête SQL pour récupérer tout ce qui a changé depuis 7 jours.

QUERY = """
    SELECT description, published_at, product_name
    FROM `bigquery-public-data.google_cloud_release_notes.release_notes`
    WHERE published_at > DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY)
    ORDER BY published_at DESC
"""

Cela nous donne une liste brute de texte, souvent très aride et technique. C’est là que l’IA entre en jeu.

Étape 2 : Le Scénariste (Gemini 3 Pro)¶

Nous injectons ces notes brutes dans Gemini 3 Pro avec un prompt système très spécifique (le prompt_template.txt).

Le but n’est pas de résumer, mais de scénariser. * Marc est l’expert technique, précis et factuel. * Sophie est l’animatrice curieuse, qui pose les questions que l’auditeur se poserait.

L’une des fonctionnalités clés utilisées ici est le Grounding avec Google Search. Cela permet à Gemini de vérifier les faits et d’ajouter des liens vers la documentation officielle dans les métadonnées de l’épisode.

// Exemple de sortie structurée JSON attendue de Gemini
{
  "title": "Cloud Run s'accélère et BigQuery se sécurise",
  "summary": "Cette semaine, Marc et Sophie discutent des nouvelles instances...",
  "script": "Sophie: Bonjour à tous ! ... Marc: Exactement, et c'est majeur...",
  "image_prompt": "An abstract representation of a fast server race in a neon city..."
}

Étape 3 : Le Studio Audio (Gemini 2.5 Flash TTS)¶

C’est la partie la plus impressionnante. Nous n’utilisons pas l’ancien “Text-to-Speech” robotique. Nous utilisons le modèle Gemini 2.5 Flash TTS (encore en preview), capable de générer plusieurs locuteurs dans le même flux audio.

Le prompt définit les personnalités vocales : * Marc utilise la voix Fenrir. * Sophie utilise la voix Laomedeia.

Le script Python appelle directement l’API REST de Vertex AI pour générer l’audio.

# Extrait simplifié de l'appel API
payload = {
    "contents": [{"parts": [{"text": script_text}]}],
    "generationConfig": {
        "speechConfig": {
            "multiSpeakerVoiceConfig": {
                "speakerVoiceConfigs": [
                    {"speaker": "Marc", "voiceConfig": {"prebuiltVoiceConfig": { "voiceName": "Fenrir" }}},
                    {"speaker": "Sophie", "voiceConfig": {"prebuiltVoiceConfig": { "voiceName": "Laomedeia" }}}
                ]
            }
        }
    }
}

Étape 4 : Le Graphiste (Imagen 3)¶

Pour rendre le podcast visuel sur les plateformes, il nous faut une couverture. Gemini (le scénariste) a déjà généré un image_prompt basé sur le contenu de l’épisode.

Nous passons ce prompt à Imagen 3 via Vertex AI pour générer une image carrée (1:1), que nous redimensionnons et compressons pour respecter les standards d’Apple Podcasts (1400x1400, <512KB).

Étape 5 : La Diffusion (FastAPI & RSS)¶

Une fois tous les fichiers générés (MP3, JSON, JPG, YAML), ils sont stockés sur Google Cloud Storage.

Le Frontend (une app FastAPI sur Cloud Run) ne stocke rien. Il agit comme une interface de lecture sur le Bucket GCS.

Le Flux RSS Dynamique¶

Pour s’abonner sur Apple Podcast ou Spotify, il faut un flux RSS XML conforme. L’application génère ce flux à la volée (/feed.xml) en lisant les manifestes des épisodes présents dans le bucket.

Elle gère aussi : * La signature d’URL (Signed URLs) pour sécuriser l’accès aux fichiers audio. * Les headers HTTP HEAD nécessaires pour la validation par les agrégateurs de podcasts.

Étape 6 : L’Infrastructure as Code (Terraform)¶

Pour éviter de cliquer partout dans la console Google Cloud, toute l’infrastructure est définie en Terraform.

Cela permet de créer des environnements reproductibles (Preprod, Prod) et de gérer les permissions finement.

# Extrait de infra/production/main.tf
module "podcast_generator" {
  source = "../modules/podcast-generator"

  project_id           = var.project_id
  region               = var.region
  bucket_name          = "${var.project_id}-podcast-output"

  # Configuration du Job et du Service
  podcast_model        = "gemini-3.0-pro-preview"
  schedule_cron        = "0 9 * * 1" # Tous les lundis à 9h
}

Étape 7 : Le Pipeline CI/CD (GitLab CI & Cloud Deploy)¶

Le déploiement est entièrement automatisé via GitLab CI et Google Cloud Deploy.

GitLab CI : Construit les images Docker (Generator & Frontend) et les pousse sur Artifact Registry.
Cloud Deploy : Récupère ces images, génère les manifestes Kubernetes (YAML) via un script et déploie le tout sur Cloud Run.

Le pipeline gère la promotion du code de la pré-production vers la production sans intervention manuelle risquée.

Le Coût (FinOps)¶

C’est la meilleure partie. Comme l’architecture est “Scale to Zero”, je ne paie que lorsque le podcast est généré ou écouté.

Coût mensuel réel : ~0,20 €

Cloud Run (Job) : Quelques centimes pour les 2-3 minutes de génération par semaine.
Cloud Run (Service) : Gratuit (dans le Free Tier) car peu de trafic.
Vertex AI : Le plus gros poste, mais reste très faible pour une utilisation hebdomadaire.
Cloud Storage : Négligeable pour quelques fichiers MP3.

C’est une solution extrêmement économique pour un média entièrement automatisé.

Ce projet démontre la puissance de la GenAI Multimodale. En moins de 500 lignes de code Python, nous avons remplacé toute une chaîne de production médiatique (recherche, écriture, enregistrement, graphisme).

Le résultat est une veille technologique agréable à écouter, toujours à jour, et qui tourne toute seule chaque lundi matin pendant que je prends mon café. ☕

Liens utiles : * 🎧 Le Podcast * 🛠️ Code Source (GitLab)

I Automated My Tech Watch with an AI-Generated Podcast (Gemini & Cloud Run)

2026-01-27T00:00:00+01:00

The “Serverless” Architecture
- The Code (Open Source)
Step 1: The Data Source (BigQuery)
Step 2: The Screenwriter (Gemini 3 Pro)
Step 3: The Audio Studio (Gemini 2.5 Flash TTS)
Step 4: The Graphic Designer (Imagen 3)
Step 5: Distribution (FastAPI & RSS)
- The Dynamic RSS Feed
Step 6: Infrastructure as Code (Terraform)
Step 7: The CI/CD Pipeline (GitLab CI & Cloud Deploy)
The Cost (FinOps)
Conclusion

Don’t have time to read the hundreds of release notes published by Google Cloud every week? Neither do I. That’s why I created the GCP News Podcast.

🎙️ Listen to the final result here: podcast.kapable.info

This project isn’t just a demo, it’s a fully automated “Serverless” production pipeline that:

Retrieves raw technical news.
Scripts a dialogue between two virtual experts (Marc and Sophie).
Generates audio with stunning realism (intonations, laughter, pauses).
Creates unique album art for each episode.
Publishes everything to the web and podcast platforms (Spotify, etc.).

Here is how I built this system.

The “Serverless” Architecture¶

The system is designed to cost almost zero when it’s not running. It relies on an event-driven architecture and managed services.

The Code (Open Source)¶

All the code is available on GitLab: matgou/podcast-generator. It is divided into two parts: * generator/: The Python batch script that creates the episode. * frontend/: The FastAPI web interface to listen to episodes.

Step 1: The Data Source (BigQuery)¶

Unlike many projects that do “scraping”, here we use a clean source of truth: Google’s public BigQuery dataset.

The script executes a simple SQL query to retrieve everything that has changed in the last 7 days.

QUERY = """
    SELECT description, published_at, product_name
    FROM `bigquery-public-data.google_cloud_release_notes.release_notes`
    WHERE published_at > DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY)
    ORDER BY published_at DESC
"""

This gives us a raw list of text, often very dry and technical. That’s where AI comes in.

Step 2: The Screenwriter (Gemini 3 Pro)¶

We inject these raw notes into Gemini 3 Pro with a very specific system prompt (prompt_template.txt).

The goal is not to summarize, but to script. * Marc is the technical expert, precise and factual. * Sophie is the curious host, asking the questions the listener would ask.

One of the key features used here is Grounding with Google Search. This allows Gemini to verify facts and add links to official documentation in the episode metadata.

// Example of expected structured JSON output from Gemini
{
  "title": "Cloud Run speeds up and BigQuery gets safer",
  "summary": "This week, Marc and Sophie discuss the new instances...",
  "script": "Sophie: Hello everyone! ... Marc: Exactly, and it's major...",
  "image_prompt": "An abstract representation of a fast server race in a neon city..."
}

Step 3: The Audio Studio (Gemini 2.5 Flash TTS)¶

This is the most impressive part. We don’t use the old robotic “Text-to-Speech”. We use the Gemini 2.5 Flash TTS model (still in preview), capable of generating multiple speakers in the same audio stream.

The prompt defines the voice personalities: * Marc uses the Fenrir voice. * Sophie uses the Laomedeia voice.

The Python script directly calls the Vertex AI REST API to generate the audio.

# Simplified API call extract
payload = {
    "contents": [{"parts": [{"text": script_text}]}],
    "generationConfig": {
        "speechConfig": {
            "multiSpeakerVoiceConfig": {
                "speakerVoiceConfigs": [
                    {"speaker": "Marc", "voiceConfig": {"prebuiltVoiceConfig": { "voiceName": "Fenrir" }}},
                    {"speaker": "Sophie", "voiceConfig": {"prebuiltVoiceConfig": { "voiceName": "Laomedeia" }}}
                ]
            }
        }
    }
}

Step 4: The Graphic Designer (Imagen 3)¶

To make the podcast visual on platforms, we need a cover. Gemini (the screenwriter) has already generated an image_prompt based on the episode content.

We pass this prompt to Imagen 3 via Vertex AI to generate a square image (1:1), which we resize and compress to respect Apple Podcasts standards (1400x1400, <512KB).

Step 5: Distribution (FastAPI & RSS)¶

Once all files are generated (MP3, JSON, JPG, YAML), they are stored on Google Cloud Storage.

The Frontend (a FastAPI app on Cloud Run) stores nothing. It acts as a playback interface on the GCS Bucket.

The Dynamic RSS Feed¶

To subscribe on Apple Podcast or Spotify, a compliant XML RSS feed is required. The application generates this feed on the fly (/feed.xml) by reading the manifests of episodes present in the bucket.

It also handles: * URL signing (Signed URLs) to secure access to audio files. * HEAD HTTP headers necessary for validation by podcast aggregators.

Step 6: Infrastructure as Code (Terraform)¶

To avoid clicking everywhere in the Google Cloud console, the entire infrastructure is defined in Terraform.

This allows creating reproducible environments (Preprod, Prod) and managing permissions finely.

# Extract from infra/production/main.tf
module "podcast_generator" {
  source = "../modules/podcast-generator"

  project_id           = var.project_id
  region               = var.region
  bucket_name          = "${var.project_id}-podcast-output"

  # Job and Service Configuration
  podcast_model        = "gemini-3.0-pro-preview"
  schedule_cron        = "0 9 * * 1" # Every Monday at 9am
}

Step 7: The CI/CD Pipeline (GitLab CI & Cloud Deploy)¶

Deployment is fully automated via GitLab CI and Google Cloud Deploy.

GitLab CI: Builds Docker images (Generator & Frontend) and pushes them to Artifact Registry.
Cloud Deploy: Retrieves these images, generates Kubernetes manifests (YAML) via a script, and deploys everything to Cloud Run.

The pipeline handles code promotion from pre-production to production without risky manual intervention.

The Cost (FinOps)¶

This is the best part. Since the architecture is “Scale to Zero”, I only pay when the podcast is generated or listened to.

Actual monthly cost: ~€0.20

Cloud Run (Job): A few cents for the 2-3 minutes of generation per week.
Cloud Run (Service): Free (in the Free Tier) because low traffic.
Vertex AI: The biggest item, but remains very low for weekly use.
Cloud Storage: Negligible for a few MP3 files.

It’s an extremely economical solution for fully automated media.

Conclusion¶

This project demonstrates the power of Multimodal GenAI. In less than 500 lines of Python code, we replaced an entire media production chain (research, writing, recording, graphic design).

The result is a tech watch that is pleasant to listen to, always up to date, and runs by itself every Monday morning while I have my coffee. ☕

Useful links: * 🎧 The Podcast * 🛠️ Source Code (GitLab)

InkFlowAI : De la note manuscrite au compte-rendu structuré (Grâce à l'IA)

2026-01-20T00:00:00+01:00

Le Problème
La Solution : InkFlowAI
- Workflow Utilisateur
Architecture Technique (Sous le capot)
- Diagramme de Flux de Données
- Étapes Clés
Conclusion

Vous prenez des notes sur votre Kindle Scribe (ou toute autre tablette e-ink) et vous vous retrouvez avec des PDFs manuscrits difficiles à exploiter ? Voici comment InkFlowAI automatise la transformation de vos gribouillages en comptes-rendus professionnels, diagrammes inclus.

Le Problème¶

La prise de note manuscrite est fluide et naturelle, mais le partage et l’archivage sont pénibles. Retaper ses notes prend du temps. Rédiger des schémas sur ordinateur est laborieux.

La Solution : InkFlowAI¶

Un système Serverless et Réactif hébergé sur Google Cloud, qui agit comme un assistant personnel.

Workflow Utilisateur¶

Vous terminez votre réunion.
Vous cliquez sur “Partager par email” sur votre Kindle.
30 secondes plus tard, vous recevez un email en réponse contenant :
- Un résumé structuré (Markdown) de la réunion.
- La liste des actions et décisions.
- Vos schémas manuscrits convertis en diagrammes propres (Mermaid/PNG).

Architecture Technique (Sous le capot)¶

Nous avons récemment migré d’une architecture de polling (vérification périodique) vers une architecture événementielle (Push) pour une réactivité temps réel.

Diagramme de Flux de Données¶

Étapes Clés¶

Réception Réactive (Gmail + Pub/Sub) : Au lieu de demander toutes les minutes “J’ai du courrier ?”, notre service dort. Dès qu’un email arrive, Gmail notifie Cloud Pub/Sub, qui réveille instantanément notre container sur Cloud Run. Cela réduit les coûts et la latence.
Analyse Multimodale (Gemini Pro Generation) : Le cœur du système. Nous envoyons le PDF (images des pages manuscrites) directement à Gemini 3 Pro via Vertex AI. Le prompt système est conçu pour :
- Déchiffrer l’écriture manuscrite (OCR avancé).
- Comprendre le contexte (brainstorming, décision, TOD).
- Détecter les dessins et générer le code Mermaid.js correspondant.
Rendu de Diagrammes (“NanoBanana”) : Si vous avez dessiné un carré fléché vers un cercle, Gemini le traduit en code. InkFlowAI compile ce code en une image PNG nette, prête à être insérée dans le rapport final.
Stockage & Notification : Tout est archivé sur Cloud Storage (S3-compatible) pour la pérennité. Un email formaté est renvoyé à l’expéditeur.

Conclusion¶

InkFlowAI montre comment l’IA générative (multimodale) peut combler le fossé entre le monde analogique (papier/stylo) et le monde numérique (Jira/Wiki/Docs), en automatisant la partie la plus ennuyeuse du travail : la mise au propre.

Le code est Open Source et déployable sur votre propre projet GCP : https://gitlab.com/matgou/inkflowai

InkFlowAI: From Handwritten Notes to Structured Reports (Powered by AI)

2026-01-20T00:00:00+01:00

The Problem
The Solution: InkFlowAI
- User Workflow
Technical Architecture (Under the Hood)
- Data Flow Diagram
- Key Components
Conclusion

Do you take notes on your Kindle Scribe (or any e-ink tablet) only to end up with handwritten PDFs that sit in a digital graveyard? Here is how InkFlowAI automates the transformation of your scribbles into professional meeting minutes, diagrams included.

The Problem¶

Handwriting is fluid and natural for thinking, but terrible for sharing and archiving. Typing up notes takes time. Redrawing whiteboard sketches on a computer is tedious.

The Solution: InkFlowAI¶

A Serverless and Reactive system hosted on Google Cloud that acts as your personal secretary.

User Workflow¶

You finish your meeting.
You click “Share via Email” on your Kindle.
30 seconds later, you receive a reply email containing:
- A structured summary (Markdown) of the meeting.
- A list of action items and decisions.
- Your handdrawn sketches converted into clean technical diagrams (Mermaid/PNG).

Technical Architecture (Under the Hood)¶

We recently migrated from a polling architecture to an event-driven (Push) architecture for real-time responsiveness.

Data Flow Diagram¶

Key Components¶

Reactive Ingestion (Gmail + Pub/Sub): Instead of asking “Do I have mail?” every minute, our service sleeps. As soon as an email arrives, Gmail notifies Cloud Pub/Sub, which instantly wakes up our container on Cloud Run. This minimizes cost and latency.
Multimodal Analysis (Gemini Pro Generative AI): The core of the system. We send the raw PDF (images of handwritten pages) directly to Gemini 3 Pro via Vertex AI. The system prompt is engineered to:
- Decipher handwriting (Advanced OCR).
- Understand context (brainstorming, decisions, TODOs).
- Detect drawings and generate corresponding Mermaid.js code.
Diagram Rendering (“NanoBanana”): If you drew a box pointing to a circle, Gemini translates it into code. InkFlowAI compiles this code into a sharp PNG image, ready to be embedded in the final report.
Storage & Notification: Everything is archived on Cloud Storage (S3-compatible) for longevity. A formatted email is sent back to the sender.

Conclusion¶

InkFlowAI demonstrates how Generative AI (multimodal) can bridge the gap between the analog world (pen/paper) and the digital world (Jira/Wiki/Docs), automating the most boring part of work: cleaning up notes.

The code is Open Source and deployable on your own GCP project: https://gitlab.com/matgou/inkflowai

Votre propre Agent DevOps : L'avenir de l'observabilité

2025-05-28T00:00:00+02:00

Introduction
Démarrage rapide du développement d’agent ADK
Donner des outils à mon agent
- Et maintenant un vrai test
Intégration Kubernetes
- Construire un conteneur docker :
Dans kubernetes_admin/Dockerfile

Introduction¶

Google a récemment publié l’Agent Development Kit (ADK), un framework conçu pour simplifier le développement et le déploiement d’agents pilotés par l’IA. Ce framework est remarquablement convivial. Dans ce contexte, un agent est une API interactive qui exploite un grand modèle de langage (LLM), comme Gemini, et qui est renforcée par vos scripts personnalisés pour générer des réponses basées sur leur sortie.

Dans le monde DevSecOps, nous sommes déjà équipés d’une multitude d’outils et de scripts (CLI, API, et plus). Maintenant, imaginez équiper une IA de toutes ces capacités.

En tant qu’ingénieurs DevOps, nous nous retrouvons souvent à lire manuellement des journaux, à décrire des ressources pour trouver des statuts et à surveiller des événements. Et si chacun de nous avait un assistant dédié pour effectuer ces étapes de diagnostic initiales pour vous, en pointant directement vers les informations pertinentes ?

Cet article explore comment construire et utiliser un agent Kubernetes ADK (basé sur Python). Cet agent agira comme un outil de diagnostic, appelable via chat ou une API, pour rassembler rapidement des informations cruciales sur notre cluster et fournir des aperçus de diagnostic initiaux.

Testez-le ; personnellement, je suis convaincu : c’est l’avenir de l’observabilité.

Démarrage rapide du développement d’agent ADK¶

Commencer avec l’Agent Development Kit (ADK) est simple. Cette section vous guidera sur la façon de configurer et de créer un agent (très) basique.

Prérequis¶

Avant de commencer, assurez-vous d’avoir Python (y compris venv pour les environnements virtuels et pip pour l’installation de paquets) installé.
Vous aurez également besoin d’un projet Google Cloud Platform (GCP) configuré pour utiliser Vertex AI afin d’appeler le modèle Gemini.
Créez un dossier pour votre projet : bash mkdir kubernetes-admin && cd kubernetes-admin
Initialisez un environnement virtuel : bash python -m venv venv
Activez l’environnement virtuel :
- Sur macOS et Linux : bash source venv/bin/activate
- Sur Windows : bash .\venv\Scripts\activate
Installez poetry : pip install poetry

Structure de base¶

Créez les fichiers et répertoires suivants dans le répertoire kubernetes-admin que vous avez créé plus tôt :

- kubernetes_admin/
    |- agent.py # Contenant les instructions de l'agent : prompt initial et paramètres
    |- __init__.py # Un fichier init par défaut
    |- .env
    |- tools/ # Pour héberger les futures interfaces d'outils
        |- __init__.py # Un fichier init par défaut pour le paquet tools

Naviguez dans le répertoire interne kubernetes_admin (c’est là que résidera votre paquet Python) :

cd kubernetes_admin

Initialisez le projet Poetry dans ce répertoire kubernetes_admin :

poetry init

Suivez les invites. Vous pouvez accepter les valeurs par défaut pour la plupart, mais assurez-vous que le nom du paquet est `kubernetes_admin`.

Ajoutez la dépendance ADK à votre projet :

poetry add google-ai-agent

*(Note : Le nom du paquet est `google-ai-agent`, pas `google-adk`)*

Remplissez le fichier kubernetes_admin/__init__.py. Cela rend le module agent accessible.

# Dans kubernetes_admin/kubernetes_admin/__init__.py
from . import agent

Le fichier kubernetes_admin/tools/__init__.py peut rester vide pour le moment.

# Dans kubernetes_admin/kubernetes_admin/tools/
touch __init__.py

Créez un fichier .env vide dans le répertoire kubernetes_admin/kubernetes_admin/. Cela pourra être utilisé plus tard pour les configurations spécifiques à l’environnement si nécessaire.

# Dans kubernetes_admin/kubernetes_admin/
touch .env

Naviguez vers le répertoire racine du projet kubernetes-admin :

cd ..

Donner des instructions à l’agent¶

Le fichier agent.py (situé dans kubernetes-admin/kubernetes_admin/agent.py) est crucial dans l’Agent Development Kit (ADK). Il définit le prompt initial et les instructions de base pour l’agent IA. Plus tard, il sera étendu pour inclure les outils spécifiques que l’agent peut utiliser et la logique sur la façon dont il doit les utiliser.

Vous pouvez utiliser l’IA pour aider à générer le prompt initial et les instructions, ou les écrire vous-même.

Créez/éditez kubernetes-admin/kubernetes_admin/agent.py avec le contenu suivant :

# Dans kubernetes_admin/kubernetes_admin/agent.py
"""Kubernetes_Admin: Agent pour interagir avec et gérer un cluster Kubernetes."""

from google.adk.agents import LlmAgent

MODEL = "gemini-2.5-pro-preview-05-06"

KUBERNETES_ADMIN_INSTRUCTION = """
You are Kubernetes Admin, an AI assistant designed to help users manage and understand their Kubernetes (K8s) clusters.
Your primary goal is to help users by:
- Answering questions about their Kubernetes cluster.
- Retrieving information about resources like pods, nodes, services, deployments, namespaces, etc. using the available tools.
- Explaining Kubernetes concepts relevant to their queries.
- Assisting in understanding resource status and configurations.

Always strive to be clear, concise, and helpful in your responses.

Example interactions:
- User: "How many pods are running in the 'default' namespace?"
- You: (After using a tool to get pod count) "There are X pods currently running in the 'default' namespace."
- User: "What's the status of the pod named 'my-app-pod-123'?"
- You: (After using a tool to get pod status) "The pod 'my-app-pod-123' is currently in a 'Running' state."
"""

kubernetes_admin_agent = LlmAgent(
    name="kubernetes_admin_agent",
    model=MODEL,
    description=(
        "An AI agent that helps users explore and understand their Kubernetes cluster by answering questions and retrieving information about resources."
    ),
    instruction=KUBERNETES_ADMIN_INSTRUCTION,
    tools=[], # Passer l'instance FunctionTool
)

root_agent = kubernetes_admin_agent

Tester l’agent¶

Avant de lancer le test, vous devez configurer un environnement cloud :

export GOOGLE_GENAI_USE_VERTEXAI=true
export GOOGLE_CLOUD_PROJECT=<Complétez avec votre ID de projet GCP>
export GOOGLE_CLOUD_LOCATION=us-central1
export GOOGLE_CLOUD_STORAGE_BUCKET=${GOOGLE_CLOUD_PROJECT}-adk-bucket-$(openssl rand -hex 4) # générer un nom de bucket unique
gcloud auth application-default login
gcloud storage buckets create gs://$GOOGLE_CLOUD_STORAGE_BUCKET

Maintenant vous pouvez lancer le test avec la commande suivante :

adk run .

Si tout est ok, vous verrez l’invite suivante :

Log setup complete: /tmp/agents_log/agent.20250528_200909.log
To access latest log: tail -F /tmp/agents_log/agent.latest.log
Running agent kubernetes_admin_agent, type exit to exit.
[user]: hello
[kubernetes_admin_agent]: Hello! I'm Kubernetes Admin, your AI assistant for managing and understanding your Kubernetes cluster.

How can I help you today? For example, you can ask me about pods, nodes, services, or any other Kubernetes resources.
[user]: how many pod in my kubernetes clusters 
[kubernetes_admin_agent]: I can help you with that! To tell you how many pods are in your cluster, I need to check all namespaces.

Should I proceed to get the list of all pods across all namespaces in your cluster?

Donner des outils à mon agent¶

D’abord, écrivons une fonction Python pour interagir avec kubectl et l’envelopper comme un outil ADK.

Créez/éditez kubernetes-admin/kubernetes_admin/tools/kubectl_tool.py avec le contenu suivant :

# Dans kubernetes_admin/kubernetes_admin/tools/kubectl_tool.py<<EOF
"""Tool for executing kubectl get commands."""

import subprocess # For actual kubectl calls
from google.adk.tools import FunctionTool

def run_kubectl(verbs: str = "get", resource_type: str = "pods", resource_name: str = "", namespace: str = "default") -> str:
    """
    Runs a kubectl command with the specified verb, resource type, optional resource name, and namespace.
    Exemples:
        To get configuration of a specific pod use verbs: "describe", namespace: "all", resource_type: "pods", resource_name: "<custom pod name>"
        To get logs of a specific pod use verbs: "logs", namespace: "<namespace>", resource_type: "", resource_name: "<custom pod name>"
        To list pods in all namespace use verbs: "get", namespace: "all", resource_type: "pods", resource_name: ""

    Args:
        verbs: The kubectl verb to use (e.g., 'get', 'describe', 'logs', 'top').
        resource_type: The type of Kubernetes resource (e.g., 'pods', 'nodes', 'services', 'deployments').
        resource_name: Optional. The specific name of the resource. If None, lists all resources of the type.
        namespace: Optional. The Kubernetes namespace. Defaults to 'default'.

    Returns:
        A string containing the output of the kubectl command or an error message.
    """
    try:
        command = ["kubectl", verbs]
        if resource_name != "":
            command.append(f'{resource_type}/{resource_name}')
        else:
            command.append(f'{resource_type}')
        if namespace != "all":
            command.extend(["-n", namespace])
        else:
            command.extend(["--all-namespaces"])
        result = subprocess.run(command, capture_output=True, text=True, check=True, timeout=30)
        return result.stdout
    except FileNotFoundError:
        return "Error: kubectl command not found. Please ensure kubectl is installed and in your PATH."
    except subprocess.CalledProcessError as e:
        return f"Error executing kubectl command: {e.stderr}"
    except subprocess.TimeoutExpired:
        return "Error: kubectl command timed out."
    except Exception as e:
         return f"An unexpected error occurred: {str(e)}"

kubectl_tool = FunctionTool(
    func=run_kubectl)

Maintenant, mettons à jour kubernetes-admin/kubernetes_admin/agent.py pour inclure ce nouvel outil. Importez l’outil :

from .tools.kubectl_tool import kubectl_tool # Import the FunctionTool instance
...
...
kubernetes_admin_agent = LlmAgent(
    name="kubernetes_admin_agent",
    model=MODEL,
    description=(
        "An AI agent that helps users explore and understand their Kubernetes cluster by answering questions and retrieving information about resources."
    ),
    instruction=KUBERNETES_ADMIN_INSTRUCTION,
    tools=[kubectl_tool], # Pass the FunctionTool instance
)

Mettez à jour les instructions de l’agent dans KUBERNETES_ADMIN_INSTRUCTION dans kubernetes-admin/kubernetes_admin/agent.py pour informer le LLM du nouvel outil et comment l’utiliser :

KUBERNETES_ADMIN_INSTRUCTION = """
...
...
You have a tool named 'run_kubectl_command' to fetch information from the Kubernetes cluster by executing kubectl commands.
Tool 'run_kubectl_command' arguments:
- 'verbs': (string, required) The kubectl verb to use (e.g., 'get', 'describe', 'logs', 'top').
- 'resource_type': (string, required) The type of Kubernetes resource (e.g., 'pods', 'nodes', 'services', 'deployments', 'namespaces').
- 'resource_name': (string, optional) The specific name of the resource. If not provided, all resources of the given type in the namespace will be listed.
- 'namespace': (string, optional, defaults to 'default') The Kubernetes namespace to query.

When a user asks for information that requires querying the cluster (e.g., "list pods", "get node status", "describe service my-service", "get logs for pod xyz"), you MUST use the 'run_kubectl_command' tool.
Clearly state that you are using the tool, what you are querying for, and then present the information returned by the tool.
Determine the correct 'verbs' argument based on the user's request (e.g., "list" or "how many" implies 'get', "what's the status" implies 'get', "describe" implies 'describe', "show logs" implies 'logs').
"""

Et maintenant un vrai test¶

Maintenant, effectuons un vrai test pour voir si notre agent utilise kubectl comme prévu. (Assurez-vous d’avoir un fichier kubeconfig valide et d’être connecté à un cluster Kubernetes pour ce test.)

$ adk run .
...
[user]: how many pod in my cluster all namespaces
[kubernetes_admin_agent]: Okay, I can help you with that. I will use the `run_kubectl` tool to list all pods in all namespaces and then count them for you.
[kubernetes_admin_agent]: I have retrieved the list of all pods across all namespaces. There are a lot of them!
Based on the output, there are 119 pods in your cluster across all namespaces.

Intégration Kubernetes¶

Nous allons maintenant déployer notre agent dans un cluster Kubernetes, pour donner la possibilité à d’autres utilisateurs de l’utiliser.

Construire un conteneur docker :¶

Voici un Dockerfile pour construire une image de conteneur pour votre agent Python. Ce Dockerfile :
- Utilise une image de base Python slim.
- Installe kubectl (car l’outil de votre agent l’utilise) et Poetry.
- Configure un utilisateur non-root pour une meilleure sécurité.
- Installe les dépendances de votre projet en utilisant Poetry.
- Définit la commande par défaut pour exécuter votre agent ADK en utilisant son serveur HTTP intégré.
```Dockerfile

Dans kubernetes_admin/Dockerfile¶

FROM python:3.13-slim WORKDIR /app

RUN pip install poetry ENV PORT=8080 RUN apt update && apt install -y kubernetes-client/stable prometheus/stable && apt clean COPY . .

RUN adduser –disabled-password –gecos “” myuser && \ chown -R myuser:myuser /app

USER myuser

RUN poetry install

ENV PATH=”/home/myuser/.local/bin:$PATH” CMD poetry run uvicorn main:app –host 0.0.0.0 –port $PORT ```
(Configuration unique) Créez un dépôt Artifact Registry si vous ne l’avez pas déjà fait. bash # Remplacez REGION et GOOGLE_CLOUD_PROJECT avec vos détails. gcloud artifacts repositories create adk-repo --repository-format=docker \ --location=YOUR_REGION \ --description="ADK agent repository" \ --project=YOUR_GOOGLE_CLOUD_PROJECT
Construisez l’image Docker et poussez-la vers Artifact Registry. bash # Remplacez REGION et GOOGLE_CLOUD_PROJECT avec vos détails. gcloud builds submit --tag YOUR_REGION-docker.pkg.dev/YOUR_GOOGLE_CLOUD_PROJECT/adk-repo/k8s-admin-agent:latest \

Ajouter RBAC¶

Le manifeste suivant crée un ServiceAccount Kubernetes dans l’espace de noms kubernetes-admin-agent. Il définit également un ClusterRole avec des permissions en lecture seule (get, list, watch) sur tous les groupes d’API et ressources, puis utilise un ClusterRoleBinding pour accorder ces permissions au ServiceAccount créé.

kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
  name: kubernetes-admin-agent
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: kubernetes-admin-agent
rules:
- apiGroups:
  - "*"
  resources:
  - "*"
  verbs:
  - get
  - list
  - watch
---
apiVersion: rbac.authorization.k8s.io/v1
# This cluster role binding allows the kubernetes-admin-agent ServiceAccount to read all resources in any namespace.
kind: ClusterRoleBinding
metadata:
  name: kubernetes-admin-agent-global
subjects:
- kind: ServiceAccount
  name: kubernetes-admin-agent
  namespace: kubernetes-admin-agent
roleRef:
  kind: ClusterRole
  name: kubernetes-admin-agent
  apiGroup: rbac.authorization.k8s.io
EOF

Ajouter un secret pour les identifiants google¶

Pour permettre à votre agent fonctionnant dans Kubernetes de s’authentifier auprès des services Google Cloud (spécifiquement Vertex AI pour Gemini), vous devez créer un compte de service GCP, lui accorder les permissions nécessaires, générer une clé pour celui-ci, et stocker cette clé comme un secret Kubernetes.

Assurez-vous que votre variable d’environnement GOOGLE_CLOUD_PROJECT est correctement définie avant d’exécuter ces commandes.

# 1. Créer le compte de service
gcloud iam service-accounts create kubernetes-admin-agent

# 2. Accorder au compte de service le rôle "Vertex AI User" sur votre projet
gcloud projects add-iam-policy-binding ${GOOGLE_CLOUD_PROJECT} \
    --member="serviceAccount:kubernetes-admin-agent@${GOOGLE_CLOUD_PROJECT}.iam.gserviceaccount.com" \
    --role="roles/aiplatform.user"

# 3. Créer et télécharger une clé pour le compte de service
gcloud iam service-accounts keys create key.json \
    --iam-account="kubernetes-admin-agent@${GOOGLE_CLOUD_PROJECT}.iam.gserviceaccount.com"

# 4. Créer un espace de noms Kubernetes pour l'agent (si pas déjà créé)
kubectl create ns kubernetes-admin-agent
# 5. Créer un secret Kubernetes à partir du fichier de clé téléchargé
kubectl create secret generic google-cloud-key -n kubernetes-admin-agent --from-file=key.json=key.json

Déployer le service¶

Tests et expérimentations¶

Diagnostiquer OOMKill¶

Conclusion et prospective¶

Your Own Devops Agent: The future of observability

2025-05-28T00:00:00+02:00

Introduction
ADK agent developpement quick start
Giving tools to my agent
- And now real testing
Kubernetes integration
- Build a docker container :
In kubernetes_admin/Dockerfile

Introduction¶

Google has recently released the Agent Development Kit (ADK), a framework designed to simplify the development and deployment of AI-driven agents. This framework is remarkably user-friendly. In this context, an agent is an interactive API that leverages a Large Language Model (LLM), like Gemini, and is further empowered by your custom scripts to generate responses based on their output.

In the DevSecOps world, we’re already equipped with a multitude of tools and scripts (CLI, API, and more). Now, imagine equipping an AI with all of these capabilities.

As DevOps engineers, we often find ourselves manually reading logs, describing resources to find statuses, and watching events. What if each of us had a dedicated assistant to perform these initial diagnostic steps for you, directly pointing to relevant information?

This article explores how to build and utilize an ADK (Python-based) Kubernetes agent. This agent will act as a diagnostic tool, callable via chat or an API, to quickly gather crucial information about our cluster and provide initial diagnostic insights.

Test it; personally, I am convinced: this is the future of observability.

ADK agent developpement quick start¶

Getting started with the Agent Development Kit (ADK) is straightforward. This section will guide you through how to set up and create a (very) basic agent.

Prerequisites¶

Before you begin, ensure you have Python (including venv for virtual environments and pip for package installation) installed.
You will also need a Google Cloud Platform (GCP) project set up to use Vertex AI for calling the Gemini model.
Create a folder for your project: bash mkdir kubernetes-admin && cd kubernetes-admin
Initialize a virtual environment: bash python -m venv venv
Activate the virtual environment:
- On macOS and Linux: bash source venv/bin/activate
- On Windows: bash .\venv\Scripts\activate
Install poetry: pip install poetry

Basic structure¶

Create the following files and directories within the kubernetes-admin directory you created earlier:

- kubernetes_admin/
    |- agent.py # Containing agent instructions : initial prompt and parameters
    |- __init__.py # A default init file
    |- .env
    |- tools/ # To hosting futurer tools interfaces
        |- __init__.py # A default init file for the tools package

Navigate into the inner kubernetes_admin directory (this is where your Python package will reside):

cd kubernetes_admin

Initialize the Poetry project within this kubernetes_admin directory:

poetry init

Follow the prompts. You can accept defaults for most, but ensure the package name is `kubernetes_admin`.

Add the ADK dependency to your project:

poetry add google-ai-agent

*(Note: The package name is `google-ai-agent`, not `google-adk`)*

Populate the kubernetes_admin/__init__.py file. This makes the agent module accessible.

# In kubernetes_admin/kubernetes_admin/__init__.py
from . import agent" > __init__.py

The kubernetes_admin/tools/__init__.py file can remain empty for now.

# In kubernetes_admin/kubernetes_admin/tools/
touch __init__.py

Create an empty .env file in the kubernetes_admin/kubernetes_admin/ directory. This can be used later for environment-specific configurations if needed.

# In kubernetes_admin/kubernetes_admin/
touch .env

Navigate back to the root kubernetes-admin project directory:

cd ..

Giving Agent Instructions¶

The agent.py file (located at kubernetes-admin/kubernetes_admin/agent.py) is crucial in the Agent Development Kit (ADK). It defines the initial prompt and core instructions for the AI agent. Later, it will be expanded to include the specific tools the agent can use and the logic for how it should utilize them.

You can use AI to help generate the initial prompt and instructions, or write them yourself.

Create/edit kubernetes-admin/kubernetes_admin/agent.py with the following content:

# In kubernetes_admin/kubernetes_admin/agent.py
"""Kubernetes_Admin: Agent for interacting with and managing a Kubernetes cluster."""

from google.adk.agents import LlmAgent

MODEL = "gemini-2.5-pro-preview-05-06"

KUBERNETES_ADMIN_INSTRUCTION = """
You are Kubernetes Admin, an AI assistant designed to help users manage and understand their Kubernetes (K8s) clusters.
Your primary goal is to help users by:
- Answering questions about their Kubernetes cluster.
- Retrieving information about resources like pods, nodes, services, deployments, namespaces, etc. using the available tools.
- Explaining Kubernetes concepts relevant to their queries.
- Assisting in understanding resource status and configurations.

Always strive to be clear, concise, and helpful in your responses.

Example interactions:
- User: "How many pods are running in the 'default' namespace?"
- You: (After using a tool to get pod count) "There are X pods currently running in the 'default' namespace."
- User: "What's the status of the pod named 'my-app-pod-123'?"
- You: (After using a tool to get pod status) "The pod 'my-app-pod-123' is currently in a 'Running' state."
"""

kubernetes_admin_agent = LlmAgent(
    name="kubernetes_admin_agent",
    model=MODEL,
    description=(
        "An AI agent that helps users explore and understand their Kubernetes cluster by answering questions and retrieving information about resources."
    ),
    instruction=KUBERNETES_ADMIN_INSTRUCTION,
    tools=[], # Pass the FunctionTool instance
)

root_agent = kubernetes_admin_agent

Testing agent¶

Before running test, you must configure a cloud-environement :

export GOOGLE_GENAI_USE_VERTEXAI=true
export GOOGLE_CLOUD_PROJECT=<Complete with your GCP project ID>
export GOOGLE_CLOUD_LOCATION=us-central1
export GOOGLE_CLOUD_STORAGE_BUCKET=${GOOGLE_CLOUD_PROJECT}-adk-bucket-$(openssl rand -hex 4) # generate a unique bucket name
gcloud auth application-default login
gcloud storage buckets create gs://$GOOGLE_CLOUD_STORAGE_BUCKET

Now you can run test with the following command :

adk run .

If everything is ok, you will see the following prompt:

Log setup complete: /tmp/agents_log/agent.20250528_200909.log
To access latest log: tail -F /tmp/agents_log/agent.latest.log
Running agent kubernetes_admin_agent, type exit to exit.
[user]: hello
[kubernetes_admin_agent]: Hello! I'm Kubernetes Admin, your AI assistant for managing and understanding your Kubernetes cluster.

How can I help you today? For example, you can ask me about pods, nodes, services, or any other Kubernetes resources.
[user]: how many pod in my kubernetes clusters 
[kubernetes_admin_agent]: I can help you with that! To tell you how many pods are in your cluster, I need to check all namespaces.

Should I proceed to get the list of all pods across all namespaces in your cluster?

Giving tools to my agent¶

First, let’s write a Python function to interact with kubectl and wrap it as an ADK tool.

Create/edit kubernetes-admin/kubernetes_admin/tools/kubectl_tool.py with the following content:

# In kubernetes_admin/kubernetes_admin/tools/kubectl_tool.py<<EOF
"""Tool for executing kubectl get commands."""

import subprocess # For actual kubectl calls
from google.adk.tools import FunctionTool

def run_kubectl(verbs: str = "get", resource_type: str = "pods", resource_name: str = "", namespace: str = "default") -> str:
    """
    Runs a kubectl command with the specified verb, resource type, optional resource name, and namespace.
    Exemples:
        To get configuration of a specific pod use verbs: "describe", namespace: "all", resource_type: "pods", resource_name: "<custom pod name>"
        To get logs of a specific pod use verbs: "logs", namespace: "<namespace>", resource_type: "", resource_name: "<custom pod name>"
        To list pods in all namespace use verbs: "get", namespace: "all", resource_type: "pods", resource_name: ""

    Args:
        verbs: The kubectl verb to use (e.g., 'get', 'describe', 'logs', 'top').
        resource_type: The type of Kubernetes resource (e.g., 'pods', 'nodes', 'services', 'deployments').
        resource_name: Optional. The specific name of the resource. If None, lists all resources of the type.
        namespace: Optional. The Kubernetes namespace. Defaults to 'default'.

    Returns:
        A string containing the output of the kubectl command or an error message.
    """
    try:
        command = ["kubectl", verbs]
        if resource_name != "":
            command.append(f'{resource_type}/{resource_name}')
        else:
            command.append(f'{resource_type}')
        if namespace != "all":
            command.extend(["-n", namespace])
        else:
            command.extend(["--all-namespaces"])
        result = subprocess.run(command, capture_output=True, text=True, check=True, timeout=30)
        return result.stdout
    except FileNotFoundError:
        return "Error: kubectl command not found. Please ensure kubectl is installed and in your PATH."
    except subprocess.CalledProcessError as e:
        return f"Error executing kubectl command: {e.stderr}"
    except subprocess.TimeoutExpired:
        return "Error: kubectl command timed out."
    except Exception as e:
         return f"An unexpected error occurred: {str(e)}"

kubectl_tool = FunctionTool(
    func=run_kubectl)

Now, let’s update kubernetes-admin/kubernetes_admin/agent.py to include this new tool. Import the tool:

from .tools.kubectl_tool import kubectl_tool # Import the FunctionTool instance
...
...
kubernetes_admin_agent = LlmAgent(
    name="kubernetes_admin_agent",
    model=MODEL,
    description=(
        "An AI agent that helps users explore and understand their Kubernetes cluster by answering questions and retrieving information about resources."
    ),
    instruction=KUBERNETES_ADMIN_INSTRUCTION,
    tools=[kubectl_tool], # Pass the FunctionTool instance
)

Update the agent’s instructions within KUBERNETES_ADMIN_INSTRUCTION in kubernetes-admin/kubernetes_admin/agent.py to inform the LLM about the new tool and how to use it:

KUBERNETES_ADMIN_INSTRUCTION = """
...
...
You have a tool named 'run_kubectl_command' to fetch information from the Kubernetes cluster by executing kubectl commands.
Tool 'run_kubectl_command' arguments:
- 'verbs': (string, required) The kubectl verb to use (e.g., 'get', 'describe', 'logs', 'top').
- 'resource_type': (string, required) The type of Kubernetes resource (e.g., 'pods', 'nodes', 'services', 'deployments', 'namespaces').
- 'resource_name': (string, optional) The specific name of the resource. If not provided, all resources of the given type in the namespace will be listed.
- 'namespace': (string, optional, defaults to 'default') The Kubernetes namespace to query.

When a user asks for information that requires querying the cluster (e.g., "list pods", "get node status", "describe service my-service", "get logs for pod xyz"), you MUST use the 'run_kubectl_command' tool.
Clearly state that you are using the tool, what you are querying for, and then present the information returned by the tool.
Determine the correct 'verbs' argument based on the user's request (e.g., "list" or "how many" implies 'get', "what's the status" implies 'get', "describe" implies 'describe', "show logs" implies 'logs').
"""

And now real testing¶

Now, let’s perform a real test to see if our agent uses kubectl as expected. (Ensure you have a valid kubeconfig file and are connected to a Kubernetes cluster for this test.)

$ adk run .
...
[user]: how many pod in my cluster all namespaces
[kubernetes_admin_agent]: Okay, I can help you with that. I will use the `run_kubectl` tool to list all pods in all namespaces and then count them for you.
[kubernetes_admin_agent]: I have retrieved the list of all pods across all namespaces. There are a lot of them!
Based on the output, there are 119 pods in your cluster across all namespaces.

Kubernetes integration¶

We will now deploy our agent into a kubernetes cluster, to give possibility to other user to use it.

Build a docker container :¶

Here’s a Dockerfile to build a container image for your Python agent. This Dockerfile:
- Uses a slim Python base image.
- Installs kubectl (as your agent’s tool uses it) and Poetry.
- Sets up a non-root user for better security.
- Installs your project dependencies using Poetry.
- Sets the default command to run your ADK agent using its built-in HTTP server.
```Dockerfile

In kubernetes_admin/Dockerfile¶

FROM python:3.13-slim WORKDIR /app

RUN pip install poetry ENV PORT=8080 RUN apt update && apt install -y kubernetes-client/stable prometheus/stable && apt clean COPY . .

RUN adduser –disabled-password –gecos “” myuser && \ chown -R myuser:myuser /app

USER myuser

RUN poetry install

ENV PATH=”/home/myuser/.local/bin:$PATH” CMD poetry run uvicorn main:app –host 0.0.0.0 –port $PORT ```
(One-time setup) Create an Artifact Registry repository if you haven’t already. bash # Replace REGION and GOOGLE_CLOUD_PROJECT with your details. gcloud artifacts repositories create adk-repo --repository-format=docker \ --location=YOUR_REGION \ --description="ADK agent repository" \ --project=YOUR_GOOGLE_CLOUD_PROJECT
Build the Docker image and push it to Artifact Registry. bash # Replace REGION and GOOGLE_CLOUD_PROJECT with your details. gcloud builds submit --tag YOUR_REGION-docker.pkg.dev/YOUR_GOOGLE_CLOUD_PROJECT/adk-repo/k8s-admin-agent:latest \

Add RBAC¶

The following manifest creates a Kubernetes ServiceAccount in the kubernetes-admin-agent namespace. It also defines a ClusterRole with read-only permissions (get, list, watch) across all API groups and resources, and then uses a ClusterRoleBinding to grant these permissions to the created ServiceAccount.

kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
  name: kubernetes-admin-agent
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: kubernetes-admin-agent
rules:
- apiGroups:
  - "*"
  resources:
  - "*"
  verbs:
  - get
  - list
  - watch
---
apiVersion: rbac.authorization.k8s.io/v1
# This cluster role binding allows the kubernetes-admin-agent ServiceAccount to read all resources in any namespace.
kind: ClusterRoleBinding
metadata:
  name: kubernetes-admin-agent-global
subjects:
- kind: ServiceAccount
  name: kubernetes-admin-agent
  namespace: kubernetes-admin-agent
roleRef:
  kind: ClusterRole
  name: kubernetes-admin-agent
  apiGroup: rbac.authorization.k8s.io
EOF

Add secret for google credentials¶

To allow your agent running in Kubernetes to authenticate with Google Cloud services (specifically Vertex AI for Gemini), you need to create a GCP service account, grant it the necessary permissions, generate a key for it, and store this key as a Kubernetes secret.

Make sure your GOOGLE_CLOUD_PROJECT environment variable is set correctly before running these commands.

# 1. Create the service account
gcloud iam service-accounts create kubernetes-admin-agent

# 2. Grant the service account the "Vertex AI User" role on your project
gcloud projects add-iam-policy-binding ${GOOGLE_CLOUD_PROJECT} \
    --member="serviceAccount:kubernetes-admin-agent@${GOOGLE_CLOUD_PROJECT}.iam.gserviceaccount.com" \
    --role="roles/aiplatform.user"

# 3. Create and download a key for the service account
gcloud iam service-accounts keys create key.json \
    --iam-account="kubernetes-admin-agent@${GOOGLE_CLOUD_PROJECT}.iam.gserviceaccount.com"

# 4. Create a Kubernetes namespace for the agent (if not already created)
kubectl create ns kubernetes-admin-agent
# 5. Create a Kubernetes secret from the downloaded key file
kubectl create secret generic google-cloud-key -n kubernetes-admin-agent --from-file=key.json=key.json

Deploy service¶

Testing and experimentings¶

Diagnose OOMKill¶

Conclusion and prospective¶

Pourquoi vous avez besoin de certificats dans SSH ?

2024-07-25T00:00:00+02:00

Introduction
Les périls des clés privées : pourquoi le partage ou une mauvaise gestion est risqué
Cas d’utilisation : accès SRE et développeur SSH avec Hashicorp Vault
Générer et distribuer un certificat SSH
Comment les développeurs peuvent se connecter avec des certificats signés SSH
- Étape 1 : Demander un certificat : En tant que développeur, je souhaite signer mes clés ssh
- Étape 2 : Connexion SSH : En tant que développeur, je souhaite me connecter sur mes instances via ssh
Conclusion
Liens :

Introduction¶

Lorsque vous travaillez dans le cloud, sécuriser l’accès aux serveurs Linux de production est essentiel car votre charge de travail est confrontée à Internet. Les grandes entreprises jonglent avec les besoins critiques : maintenir un contrôle strict, appliquer un accès granulaire et garantir le plus haut niveau de sécurité.

Les clés SSH traditionnelles, bien qu’elles constituent la pierre angulaire de l’accès à distance, peuvent présenter des défis dans ces domaines. Cet article de blog explique pourquoi les certificats SSH, en combinant la puissance de Vault, offrent une alternative intéressante aux clés SSH traditionnelles.

Nous aborderons les aspects cruciaux de la gestion de l’accès aux environnements de production :

Contrôle centralisé et informations d’identification expirantes : les certificats SSH, émis et gérés par une autorité de certification (CA) centrale, fournissent un point de contrôle unique pour l’accès. Contrairement aux clés SSH statiques, les certificats peuvent avoir une durée de vie définie, garantissant que les informations d’identification compromises sont automatiquement révoquées après expiration.
Banishing Root Login : Les dangers inhérents à la connexion root sont déjà bien documentés. Les certificats SSH vous permettent d’appliquer un accès non root, en promouvant un principe de moindre privilège et en minimisant les dommages potentiels.
Visibilité granulaire et contrôle d’accès : les certificats offrent un niveau granulaire de contrôle d’accès. Vous pouvez définir non seulement qui peut accéder à un serveur, mais aussi quelles commandes ils peuvent exécuter et dans quelles conditions (permit-pty, port-forwarding, …). Ce niveau de détail fournit une piste d’audit claire et minimise la surface d’attaque.

En mettant en œuvre des certificats SSH, les entreprises peuvent gagner un avantage significatif dans la sécurisation de leurs environnements de production.

Les périls des clés privées : pourquoi le partage ou une mauvaise gestion est risqué¶

Il existe plusieurs raisons pour lesquelles les utilisateurs/Administrateurs peuvent conserver leurs clés privées SSH sur leur ordinateur.

C’est indéniablement pratique. Avoir votre clé privée à portée de main permet un accès rapide et facile aux serveurs sans avoir besoin de saisir un mot de passe à chaque fois. Cela peut représenter un gain de temps considérable, en particulier pour ceux qui se connectent fréquemment à plusieurs serveurs.
Certains utilisateurs comprennent mal les implications en matière de sécurité. Ils pourraient croire que tant que leur ordinateur est sécurisé (mots de passe forts, pare-feu, etc.), la clé privée qui y est stockée est également sécurisée.

Mais:

Si votre clé privée tombe entre de mauvaises mains, les attaquants obtiennent un accès complet à n’importe quel serveur auquel vous pouvez accéder avec cette clé. Cela pourrait leur permettre de voler des données, d’installer des logiciels malveillants ou de perturber des opérations critiques.
si vous perdez votre clé privée, vous serez exclu des serveurs auxquels vous devez accéder. Cela peut entraîner des temps d’arrêt et des perturbations importants.

La mise en œuvre et la gestion des certificats SSH, en particulier pour ceux qui ne les connaissent pas, peuvent sembler une étape supplémentaire complexe par rapport à la simplicité d’utilisation d’une clé privée. Cependant, l’utilisation d’outils de fournisseurs cloud tels que AWS SSM Connect ou GCP oslogin peut être une solution. Mais l’utilisation de certificats SSH offre l’avantage d’être nativement compatible multi-cloud, offrant une approche unifiée dans différents environnements cloud.

💡💡💡 ** Nous avons donc besoin d’un outil pour nous aider ** 💡💡💡

Cas d’utilisation : accès SRE et développeur SSH avec Hashicorp Vault¶

Une équipe de développement a besoin d’accéder à un serveur de production à des fins de dépannage et de débogage. L’équipe SRE est responsable de la gestion de l’accès et de la sécurité du serveur.

Générer et distribuer un certificat SSH¶

Prérequis:¶

Une instance Vault
Une compréhension de base des concepts de Vault tels que les “secrets engines”, “policies”, et “roles”.

Activez le “SSH Secrets Engine”:¶

Avant de plonger dans la configuration, il est essentiel de comprendre ce que fait le moteur de secrets SSH. Il fournit un moyen sécurisé de gérer les informations d’identification SSH, offrant des fonctionnalités telles que :

Génération d’informations d’identification SSH dynamiques
Authentification basée sur un certificat
Contrôle d’accès basé sur les rôles
Intégration avec d’autres fonctionnalités de Vault

Pour activer le moteur de secrets SSH, vous utiliserez la CLI Vault. Voici la commande :

vault secrets enable -path=ssh ssh

Cette commande monte le moteur de secrets SSH sur le chemin /ssh. Vous pouvez personnaliser le chemin si nécessaire.

Créer une autorité de certification pour le coffre-fort hashicorp¶

Nous disposons de deux méthodes pour établir une autorité de certification (CA) : l’interface de ligne de commande (CLI) et Terraform.

Pour générer une CA via bash :

vault write ssh/config/ca generate_signing_key=true

Soit pour générer une CA via terraform :

resource "vault_mount" "ssh_signer" {
  path        = "ssh-client-signer"
  type        = "ssh"
  description = "Sign ssh public keys"
}

resource "vault_ssh_secret_backend_ca" "user" {
  backend              = vault_mount.ssh_signer.path
  generate_signing_key = true
}
output "pub_key" {
  value = vault_ssh_secret_backend_ca.user.public_key
}

Ajout d’une autorisation de rôles pour les développeurs dans Hashicorp Vault¶

Pour gérer efficacement l’accès des développeurs aux certificats SSH dans Hashicorp Vault, nous devons configurer les autorisations SSH pour signer les demandes des développeurs.

Avec terraform

resource "vault_ssh_secret_backend_role" "user" {
  name                    = "mgoulin"
  backend                 = vault_mount.ssh_signer.path
  key_type                = "ca"
  allow_user_certificates = true
  default_extensions = {
    "permit-agent-forwarding" = ""
    "permit-pty"              = ""
    "permit-port-forwarding"  = ""
  }
  ttl = "1h"
}

Étape 0 : Injection de l’autorité de certification dans les serveurs AWS, Azure et GCP¶

L’injection de clés publiques SSH dans des instances cloud est une pratique courante pour permettre un accès SSH sécurisé. Voici comment procéder en tant que SRE sur AWS, Azure et GCP.

AWS¶

Ajoutez la clé publique à un objet paire de clés dans le service EC2 à l’aide de la commande aws ec2 import-key-pair.

echo "cert-authority $(vault read -field public_key ssh-client-signer/config/ca)" > /tmp/authorized_keys.txt
aws ec2 import-key-pair --key-name "dev-key" --public-key-material fileb:///tmp/authorized_keys.txt

GCP¶

Ajoutez la clé publique aux métadonnées de l’instance à l’aide de la commande gcloud compute project-info add-metadata.

export USERNAME=dev
echo "$USERNAME:cert-authority $(terraform output -r pub_key)" > /tmp/authorized_keys.txt
cloud compute project-info add-metadata --metadata-from-file=ssh-keys=authorized_keys.txt

Azure¶

Ajoutez la clé publique aux métadonnées de l’instance à l’aide de la commande az sshkey.

echo "cert-authority $(vault read -field public_key ssh-client-signer/config/ca)" > /tmp/authorized_keys.txt
az sshkey create --name "dev-key" --public-key "@/tmp/authorized_keys.txt" --resource-group "myResourceGroup"

Custom OnPrem Instances¶

Ajoutez la clé publique à l’instance en tant que root en ajoutant la ligne suivante au fichier /home/$USERNAME/authorized_keys.

export USERNAME=dev
echo "cert-authority $(vault read -field public_key ssh-client-signer/config/ca)" >> /home/$USERNAME/authorized_keys

Comment les développeurs peuvent se connecter avec des certificats signés SSH¶

Traditionnellement, les connexions SSH reposaient sur des paires de clés publiques et privées pour l’authentification. Bien qu’efficace, cette méthode présente des défis en termes de gestion des clés, de révocation et de contrôle d’accès. Avec Certificate-Authority et HashicorpVautl, les certificats lient l’identité d’un utilisateur à sa clé publique, permettant une authentification plus forte et un contrôle d’accès granulaire.

Avec les certificats SSH, les développeurs peuvent se connecter en toute sécurité aux serveurs distants sans avoir besoin de gérer directement les clés privées. Le processus implique :

Étape 1 : Demander un certificat : En tant que développeur, je souhaite signer mes clés ssh¶

Les développeurs demandent un certificat SSH à une autorité centralisée, souvent via un portail en libre-service ou en appelant l’API Vault.

Cela peut être fait avec la commande vault suivante. Lors de la requête, les développeurs fournissent leur clé publique, généralement stockée sous id_rsa.pub.

vault write -field=signed_key ssh/sign/dev \ 
    public_key=@$HOME/.ssh/id_rsa.pub > signed-cert.pub

Étape 2 : Connexion SSH : En tant que développeur, je souhaite me connecter sur mes instances via ssh¶

Les développeurs utilisent le certificat signé précédemment émis : signed-cert.pub, souvent appelé certificat client, pour s’authentifier auprès du serveur cible. Ce certificat, généralement au format PEM, contient la clé publique du développeur signée par l’autorité de certification (CA) de confiance, qui dans ce cas est Vault.

Lors de la connexion au serveur, le client SSH présente le certificat signé. Le serveur vérifie ensuite l’authenticité et la validité du certificat par rapport à la clé publique de l’autorité de certification. En cas de succès, la connexion est établie et le développeur accède au serveur.

ssh -i ./signed-cert.pub -v -i ~/.ssh/id_rsa dev@<target_server>

Conclusion¶

En adoptant les certificats SSH et en tirant parti d’un outil de gestion de l’autorité de certification centralisée tel que Hashicorp Vault, les organisations peuvent améliorer considérablement leur posture de sécurité SSH. Cette approche offre une solution robuste aux défis posés par la gestion traditionnelle des clés SSH, offrant un contrôle granulaire, une auditabilité améliorée et une gestion rationalisée des accès.

En passant aux certificats SSH, les organisations peuvent atténuer les risques associés aux clés compromises, faciliter la rotation des clés et appliquer des politiques d’accès strictes. Cela conduit finalement à une infrastructure SSH plus sécurisée et efficace.

Même si la mise en œuvre de certificats SSH nécessite une planification et une configuration minutieuses, les avantages à long terme en termes de sécurité et de facilité de gestion dépassent de loin l’investissement initial.

En suivant les directives décrites dans cet article, les organisations peuvent déployer avec succès des certificats SSH et récolter les fruits d’un environnement SSH plus sécurisé et contrôlé.

Liens :¶

Why You Need SSH Certificates

2024-07-25T00:00:00+02:00

Introduction
The Perils of Private Keys: Why Sharing or Poor Management is Risky
Use Case: SRE and Developer SSH Access with Hashicorp Vault
Generating and distributing SSH Certificate
How developers can connect with ssh signed certificates
- Step 1: Requesting a Certificate: As a developper I want to sign my ssh keys
- Step 2: SSH Connection: As a developper I want to connect on my instances via ssh
Conclusion
Links :

Introduction¶

When you work in the cloud, securing access to production Linux servers is essential as your workload are internet faced. Large companies juggle the critical needs of maintaining tight control, enforcing granular access, and ensuring the highest level of security.

Traditional SSH keys, while a cornerstone of remote access, can introduce challenges in these areas. This blog post explores why, SSH certificates in combining the power of Vault offer a compelling alternative to traditional SSH keys.

We’ll delve into the crucial aspects of managing access to production environments:

Centralized Control and Expiring Credentials: SSH certificates, issued and managed by a central Certificate Authority (CA), provide a single point of control for access. Unlike static SSH keys, certificates can have defined lifespans, ensuring compromised credentials are automatically revoked after expiration.
Banishing Root Login: The inherent dangers of root login are well documented. SSH certificates empower you to enforce non-root access, promoting a principle of least privilege and minimizing potential damage.
Granular Visibility and Access Control: Certificates offer a granular level of access control. You can define not only who can access a server, but also what commands they can execute and under what conditions (permit-pty, port-forwarding, …). This level of detail provides a clear audit trail and minimizes the attack surface.

By implementing SSH certificates, Compagnies can gain a significant edge in securing their production environments.

There are a few reasons why people or administrators might keep their SSH private keys on their computers.

It’s undeniably convenient. Having your private key readily available allows for quick and easy access to servers without needing to enter a password every time. This can be a major time-saver, especially for those who connect to multiple servers frequently.
Some users misunderstand the security implications. They might believe that as long as their computer is secure (strong passwords, firewalls etc.) then the private key stored on it is safe as well.

But:

If your private key falls into the wrong hands, attackers gain full access to any server you can access with that key. This could allow them to steal data, install malware, or disrupt critical operations.
if you lose your private key, you’ll be locked out of the servers you need to access. This can cause significant downtime and disruption.

Implementing and managing SSH certificates, especially for those unfamiliar with them, might seem like a complex additional step compared to the simplicity of using a private key. However, while using cloud provider tools like AWS SSM Connect or GCP oslogin can be a solution. But using SSH certificates offer the advantage of being natively multi-cloud compatible, providing a unified approach across different cloud environments.

💡💡💡 ** So we need a tools to help us ** 💡💡💡

Use Case: SRE and Developer SSH Access with Hashicorp Vault¶

A development team needs access to a production server for troubleshooting and debugging purposes. The SRE team is responsible for managing server access and security.

Generating and distributing SSH Certificate¶

Prerequisites:¶

A running Vault instance
A basic understanding of Vault concepts like secrets engines, policies, and roles.

Enable the SSH Secrets Engine:¶

Before diving into the configuration, it’s essential to understand what the SSH secrets engine does. It provides a secure way to manage SSH credentials, offering features like:

Dynamic SSH credentials generation
Certificate-based authentication
Role-based access control
Integration with other Vault features

To enable the SSH secrets engine, you’ll use the Vault CLI. Here’s the command:

vault secrets enable -path=ssh ssh

This command mounts the SSH secrets engine at the path /ssh. You can customize the path if needed.

Create Certificate-Authority for hashicorp vault¶

We have two methods for establishing a Certificate Authority (CA): the Command-Line Interface (CLI) and Terraform.

To generate a CA via bash :

vault write ssh/config/ca generate_signing_key=true

Or to generate a CA via terraform :

resource "vault_mount" "ssh_signer" {
  path        = "ssh-client-signer"
  type        = "ssh"
  description = "Sign ssh public keys"
}

resource "vault_ssh_secret_backend_ca" "user" {
  backend              = vault_mount.ssh_signer.path
  generate_signing_key = true
}
output "pub_key" {
  value = vault_ssh_secret_backend_ca.user.public_key
}

Adding Roles Authorization for Developers in Hashicorp Vault¶

To effectively manage developer access to SSH certificates within Hashicorp Vault, we need to configure SSH authorizations for signing developper requests.

With terraform

resource "vault_ssh_secret_backend_role" "user" {
  name                    = "mgoulin"
  backend                 = vault_mount.ssh_signer.path
  key_type                = "ca"
  allow_user_certificates = true
  default_extensions = {
    "permit-agent-forwarding" = ""
    "permit-pty"              = ""
    "permit-port-forwarding"  = ""
  }
  ttl = "1h"
}

Step 0: Injecting Certificate Authority into AWS, Azure, and GCP Servers¶

Injecting SSH public keys into cloud instances is a common practice to enable secure SSH access. Here’s how to do as SRE it on AWS, Azure, and GCP.

AWS¶

Add the public key to a key-pair object in EC2 service using the aws ec2 import-key-pair command.

echo "cert-authority $(vault read -field public_key ssh-client-signer/config/ca)" > /tmp/authorized_keys.txt
aws ec2 import-key-pair --key-name "dev-key" --public-key-material fileb:///tmp/authorized_keys.txt

GCP¶

Add the public key to the instance metadata using the gcloud compute project-info add-metadata command.

export USERNAME=dev
echo "$USERNAME:cert-authority $(terraform output -r pub_key)" > /tmp/authorized_keys.txt
cloud compute project-info add-metadata --metadata-from-file=ssh-keys=authorized_keys.txt

Azure¶

Add the public key to the instance metadata using the az sshkey command.

echo "cert-authority $(vault read -field public_key ssh-client-signer/config/ca)" > /tmp/authorized_keys.txt
az sshkey create --name "dev-key" --public-key "@/tmp/authorized_keys.txt" --resource-group "myResourceGroup"

Custom OnPrem Instances¶

Add the public key to the instance as root by adding the following line to /home/$USERNAME/authorized_keys file.

export USERNAME=dev
echo "cert-authority $(vault read -field public_key ssh-client-signer/config/ca)" >> /home/$USERNAME/authorized_keys

How developers can connect with ssh signed certificates¶

Traditionally, SSH connections relied on public and private key pairs for authentication. While effective, this method presents challenges in terms of key management, revocation, and access control. With Certificate-Authority and HashicorpVautl, certificates bind a user’s identity to their public key, enabling stronger authentication and granular access control.

With SSH certificates, developers can connect to remote servers securely without the need to manage private keys directly. The process involves:

Step 1: Requesting a Certificate: As a developper I want to sign my ssh keys¶

Developers request an SSH certificate from a centralized authority, often through a self-service portal or calling Vault API.

It can be done with the following vault command. During the request, developers provide their public key, typically stored as id_rsa.pub.

vault write -field=signed_key ssh/sign/dev \ 
    public_key=@$HOME/.ssh/id_rsa.pub > signed-cert.pub

Step 2: SSH Connection: As a developper I want to connect on my instances via ssh¶

Developers utilize the previously issued signed certificate : signed-cert.pub, often referred to as a client certificate, to authenticate with the target server. This certificate, typically in PEM format, contains the developer’s public key signed by the trusted Certificate Authority (CA), which in this case is Vault.

When connecting to the server, the SSH client presents the signed certificate. The server then verifies the certificate’s authenticity and validity against the CA’s public key. If successful, the connection is established, and the developer gains access to the server.

ssh -i ./signed-cert.pub -v -i ~/.ssh/id_rsa dev@<target_server>

Conclusion¶

By adopting SSH certificates and leveraging a centralized certificate authority management tool such as Hashicorp Vault, organizations can significantly enhance their SSH security posture. This approach offers a robust solution to the challenges posed by traditional SSH key management, providing granular control, improved auditability, and streamlined access management.

By transitioning to SSH certificates, organizations can mitigate risks associated with compromised keys, facilitate key rotation, and enforce strong access policies. This ultimately leads to a more secure and efficient SSH infrastructure.

While implementing SSH certificates requires careful planning and configuration, the long-term benefits in terms of security and manageability far outweigh the initial investment.

By following the guidelines outlined in this article, organizations can successfully deploy SSH certificates and reap the rewards of a more secure and controlled SSH environment.

Links :¶

Sécurisez vos secret avec HashiCorp Vault : avec le PaaS GCP

2024-07-22T00:00:00+02:00

Introduction
Prérequis
Étape 1 : Créer un service de compte
Étape 2 : Confirgurer une Clé KMS
Étape 3 : Configurer un bucket de stockage
Étape 4 : Générer un fichier de configuration pour le container
Étape 5 : Configurer le lancement de notre container
Étape 6 : Initialiser le Vault
Conclusion

Introduction¶

HashiCorp Vault est un outil de gestion des secrets populaire qui permet de centraliser et de sécuriser les secrets sensibles tels que les mots de passe, les jetons d’API, les certificats et toute sorte de données confidentielles. C’est donc un outil d’exploitation qui devient très rapidement indispensable. À titre personnel, j’en ai en particulier besoin pour mon article sur la gestion des clés SSH.

Cependant même si l’éditeur de la solution le conseil de l’installer sur une plateforme IaaS (un cluster de machine), pour des raisons de coût je pense qu’on peut obtenir un très bon compromis sur une installation de type PaaS. * IaaS apporterait la possibilité d’isoler au maximum les secrets du reste de l’infrastructure et comme beaucoup d’autres infrastructures sont dépendantes de ce service, cela permet aussi de la relancer en premier en cas de gros crash. * PaaS lui évite les contraintes de gestion des mises à jour des serveurs, les pannes matérielles et offre une tarification à l’utilisation qui est très intéressante pour de petites infrastructures.

Il n’y a cependant pas beaucoup de documentation selon moi sur l’utilisation de Hashicorp Vault sur du PaaS. Voici ici une aide sur comment déployer la solution Hashicorp sur une infrastructure PaaS :

CloudRun pour l’hébergement du compute et le lancement de container à la demande. Vous êtes facturé en fonction du temps d’exécution de vos conteneurs, de la mémoire qu’ils utilisent et du nombre de requêtes qu’ils traitent. Lorsqu’il n’y a pas de requêtes vers vos containers, ceux-ci sont coupés et vous n’êtes pas facturé.
GCS pour le stockage des secrets et la base de données. Vous êtes facturé en fonction de la quantité de données stockées dans vos buckets (négligeable, ici, car nous n’allons pas avoir des secrets de plusieurs Go) et le trafic entrant et sortant de vos buckets, y compris les requêtes API, les téléchargements et les téléchargements. Il existe des frais distincts pour le trafic standard et le trafic par API.
KMS pour le chiffrement des données sur le bucket (ce qu’on appelle “Seal” dans le language Vault). Vous êtes facturé pour chaque opération de chiffrement ou de déchiffrement effectuée à l’aide d’une clé KMS. Il existe différents tarifs pour les opérations de chiffrement symétrique et asymétrique.

En résumé, utiliser ces services permet de n’être facturé qu’as l’utilisation. Lectures de mot de passe au gestionnaire de secrets, décodage de flux, entraînera une facturation, mais si l’infrastructure “dort” elle ne coûtera rien.

Le schéma ci-dessous resume comment le service peut fonctionner sur du PaaS :

Voici maintenant comment installer HashiCorp Vault sur Cloud Run en utilisant un backend de stockage Cloud Storage (GCS) et un chiffrement Cloud Key Management Service (KMS) sur GCP.

Prérequis¶

Avant de commencer, vous devez avoir les éléments suivants :

Un compte GCP avec les permissions appropriées
Gcloud SDK installé et configuré (inclus dans la CLI de la cloud-console GCP)
Terraform (inclus dans la CLI de la cloud-console GCP)

Étape 1 : Créer un service de compte¶

Pour que notre application puisse interagir avec les APIs dans GCP (accès aux objets du bucket, KMS, …). Il sera utilisé par notre service CloudRUN et nous lui donnerons les droits en respectant scrupuleusement le principe des moindres-privilèges.

# service_account.tf

# Create a new service account
resource "google_service_account" "vault_sa" {
  account_id = "vault-${var.environment}-kapable-info-sa"
}

Étape 2 : Confirgurer une Clé KMS¶

On initialise maintenant une clé KMS qui sera elle utilisé par hashicorp pour chiffrer les secrets avant de les déposer dans le bucket. Cette clé appelé “seal”, dans le verbiage Vault est une sécurité permettant de ne pas avoir “en clair” les données dans le bucket.

L’utilisation d’un service comme KMS pour ce chiffrement permet de ne pas avoir a “imprimer”/”stocker” des “unseal-key”, ces chaines de caractères demandés au lancement de Vault pour décoder les données présente dans Vault.

Voici le code terraform permettant de générer une tel clé dans GCP et de la rendre accessible a notre service-account préalablement généré.

# kms.tf

# Generate random string for each ressource name
resource "random_id" "vault_kms" {
  byte_length = 8
}

# A keyring to store our keys
resource "google_kms_key_ring" "vault" {
  name     = "${var.environment}-vault-${random_id.vault_kms.hex}"
  location = "europe-west1"
  project  = var.project
}

# The crypto-key ressources
resource "google_kms_crypto_key" "vault-key" {
  name     = "${var.environment}-vault-${random_id.vault_kms.hex}"
  key_ring = google_kms_key_ring.vault.id

  version_template {
    algorithm        = "GOOGLE_SYMMETRIC_ENCRYPTION"
    protection_level = "SOFTWARE"
  }
  # If we lost this key, then we won't be able to read our data
  lifecycle {
    prevent_destroy = true
  }
}

# Allow our application service account to use this key
data "google_iam_policy" "seal" {
  binding {
    role = "roles/cloudkms.cryptoKeyEncrypterDecrypter"
    members = [
      "serviceAccount:${google_service_account.vault_sa.email}",
    ]
  }
}
# Atach policy to our key
resource "google_kms_key_ring_iam_policy" "seal" {
  key_ring_id = google_kms_key_ring.vault.id
  policy_data = data.google_iam_policy.seal.policy_data
}

Étape 3 : Configurer un bucket de stockage¶

Voici mon code standard pour la création d’un bucket de stockage

# bucket.tf

# Define vars
locals {
  buckets = {
    vault = { name = "vault" }
  }
}

# Generate random string for each ressource name
resource "random_id" "vault_bucket" {
  byte_length = 8
}

# Create buckets
resource "google_storage_bucket" "buckets" {
  for_each      = local.buckets
  name          = "${var.environment}-data-${each.key}-${random_id.vault_bucket.hex}"
  location      = "europe-west1"
  force_destroy = true

  public_access_prevention = "enforced"
}

# Allow our application service account to use this bucket
data "google_iam_policy" "data" {
  binding {
    role = "roles/storage.admin"
    members = [
      "serviceAccount:${google_service_account.vault_sa.email}",
    ]
  }
}

# Atach policy to our key
resource "google_storage_bucket_iam_policy" "policy" {
  for_each    = local.buckets
  bucket      = google_storage_bucket.buckets[each.key].name
  policy_data = data.google_iam_policy.data.policy_data
}

Étape 4 : Générer un fichier de configuration pour le container¶

Voici le fichier de configuration qui sera utilisé par le service Vault :

# vault-server.hcl

default_max_request_duration = "90s"
disable_clustering           = false
disable_mlock                = true
ui                           = true

log_file = "/dev/stdout"

listener "tcp" {
  address = "[::]:8200"
  cluster_address = "[::]:8201"
  tls_disable = "true"
}

# Utilisation du KMS Vault
seal "gcpckms" {
  key_ring   = "${key_ring}"
  crypto_key = "${crypto_key}"
  region     = "${region}"
}

# Utilisation du stockage GCS
storage "gcs" {
  ha_enabled = "true"
}

On injecte ensuite le fichier ci-dessus dans le service GCP Secret Manager :

# config.tf

# Generate random string for each ressource name
resource "random_id" "config" {
  byte_length = 8
}

# Secret to store config file
resource "google_secret_manager_secret" "vault_config" {
  secret_id = "${var.environment}-vault-config-${random_id.vault-config.hex}"

  labels = {
    app         = "vault"
    environment = var.environment
  }

  replication {
    user_managed {
      replicas {
        location = "europe-west1"
      }
    }
  }
}

# Inject config into our secret and complete config-file with KMS values
resource "google_secret_manager_secret_version" "vault_config" {
  secret = google_secret_manager_secret.vault_config.id

  secret_data = templatefile("${path.module}/vault-server.hcl", {
    key_ring   = google_kms_key_ring.vault.name
    crypto_key = google_kms_crypto_key.vault-key.name
    region     = google_kms_key_ring.vault.location
  })
}

# Atach policy to our secret
data "google_iam_policy" "vault_config" {
  binding {
    role = "roles/secretmanager.secretAccessor"
    members = [
      "serviceAccount:${google_service_account.vault_sa.email}",
    ]
  }
}
resource "google_secret_manager_secret_iam_policy" "vault_config" {
  project     = var.project
  secret_id   = google_secret_manager_secret.vault_config.id
  policy_data = data.google_iam_policy.vault_config.policy_data
}

Étape 5 : Configurer le lancement de notre container¶

Maintenant il est possible d’enfin lancer notre container pour cela on utilise un module perso et on prend soin de surcharger l’entrypoint du container. En effet par défaut le container utilise un mode “dev” pour se lancer.

module "vault_service" {
  source         = "../modules/http-container"
  project        = var.project
  fqdn           = var.environment != "prod" ? "vault-${var.environment}.kapable.info" : "vault.kapable.info"
  docker_image   = "hashicorp/vault"
  allways_on     = false
  container_port = 8200
  cpus           = 2
  memory         = 2000
  command        = ["/bin/vault"]
  args           = ["server", "-config", "/etc/vault/config.hcl"]
  container_env = {
    SKIP_SETCAP           = 1
    GOOGLE_PROJECT        = var.project
    GOOGLE_STORAGE_BUCKET = google_storage_bucket.buckets["vault"].name
    VAULT_LOG_LEVEL       = "info"
    SKIP_CHOWN            = 1
    VAULT_ADDR            = "http://127.0.0.1"
    VAULT_API_ADDR        = "http://127.0.0.1"
 }
  volumes = {
    config = {
      secret_id      = google_secret_manager_secret.vault_config.id
      secret_version = google_secret_manager_secret_version.vault_config.version
      secret_file    = "config.hcl"
      mount_path     = "/etc/vault"
    }
   }
  depends_on = [google_kms_key_ring_iam_policy.seal]
}

Étape 6 : Initialiser le Vault¶

Créez un répertoire pour stocker vos fichiers de configuration Vault.
Téléchargez le binaire Vault depuis https://developer.hashicorp.com/vault/install.
Déplacez le binaire Vault dans le répertoire que vous avez créé à l’étape 1.
Initialisez Vault en exécutant la commande suivante : ̀`` vault operator init -key-shares=1 -key-threshold=1 ``` Suivez les instructions à l’écran pour enregistrer les clés de déverrouillage et le jeton racine.

Conclusion¶

Ce guide vous a montré comment déployer et configurer Hashicorp Vault sur Cloud Run en utilisant un backend de stockage Cloud Storage (GCS) et un chiffrement Cloud Key Management Service (KMS) sur GCP.

Avantages de cette approche :

Simplicité: Déploiement et gestion simplifiés via Cloud Run et Terraform.
Évolution: Échelle automatique en fonction de la demande.
Sécurité: Chiffrement des secrets avec KMS et isolation des conteneurs.
Coût: Paiement à la consommation pour une optimisation des coûts.

Points importants à retenir:

Assurez-vous de suivre scrupuleusement les instructions de sécurité pour protéger vos secrets.
Utilisez des politiques IAM strictes pour limiter l’accès à vos ressources GCP.
Surveillez l’utilisation de vos ressources et ajustez la configuration de votre infrastructure en fonction de vos besoins.

En conclusion, l’hébergement de Hashicorp Vault sur Cloud Run avec un backend de stockage GCS et un chiffrement KMS sur GCP offre une solution simple, évolutive et sécurisée pour la gestion des secrets de vos applications.

Securely Manage Secrets with HashiCorp Vault on Cloud Run: A GCP Guide

2024-07-22T00:00:00+02:00

Introduction
Architecture
Prerequisites
Step 1: Create a Service Account
Step 2: Configure KMS (Key Management Service)
Step 3: Configure a Storage Backend
Step 4: Generate a Configuration File for the Container
Step 5: Configure Container Deployment
Step 6: Initialize Vault
Conclusion

Introduction¶

HashiCorp Vault is a powerful tool for managing application secrets, providing a centralized platform to store, control, and secure sensitive information. It offers a comprehensive suite of features to safeguard your critical secrets, including:

Secret Storage and Management: Vault securely stores a wide range of secrets, including passwords, API keys, certificates, and authentication tokens.
Granular Access Control: Implement fine-grained access controls to manage who can access specific secrets, ensuring that only authorized users and applications have access.
Robust Encryption: Vault encrypts secrets using strong encryption algorithms and utilizes system-managed encryption keys to guarantee data security.
Auditing and Logging: Vault maintains a comprehensive audit log of all secret access and modifications, enabling you to monitor and audit activities effectively.

Vault: A Pillar for Enhanced Security and Control

Vault has become an indispensable tool for organizations seeking to strengthen their security posture and protect sensitive data. Its centralized approach to secrets management simplifies the process of securing and controlling access to critical information, mitigating the risk of unauthorized access and data breaches.

Simplifying Vault Deployment and Management with GCP

While Vault offers immense value, deploying and managing a Vault instance can be a complex and time-consuming endeavor. This is where GCP PaaS simplify the process.

By leveraging the power of Google Cloud Platform (GCP), you can further enhance the security and scalability of your Vault deployment. GCP’s robust cloud infrastructure and suite of security services provide an ideal foundation for hosting and managing Vault:

Cloud Run is a fully managed serverless platform for deploying and running containerized applications. It provides an ideal environment for hosting Vault.
Google Cloud Storage (GCS): Utilize GCS as a secure and scalable backend storage solution for Vault data. GCS’s durability and high availability ensure that your secrets remain protected and accessible.
Cloud Key Management Service (KMS): Employ KMS to manage and control cryptographic keys used for encrypting Vault data. KMS’s centralized key management capabilities safeguard your encryption keys and simplify key rotation processes.

Leveraging Cloud Run for a Secure and Scalable Vault Solution

By combining the strengths of HashiCorp Vault and Cloud Run, organizations can achieve a powerful and scalable solution for managing application secrets. Cloud Run eliminates the complexities of infrastructure management, allowing you to focus on the core functionalities of Vault.

With Cloud Run, you can:

Deploy Vault quickly and easily: Utilize Cloud Run’s simplified deployment process to get Vault up and running in no time.
Scale Vault automatically: Cloud Run automatically scales Vault instances based on demand, ensuring it can handle fluctuating workloads efficiently.
Optimize costs: Benefit from Cloud Run’s pay-per-use model, paying only for the resources consumed by Vault.

A Comprehensive Solution for Secure Secrets Management

By combining the strengths of HashiCorp Vault, GCS, KMS, and Cloud Run on GCP, organizations can achieve a comprehensive and secure solution for managing application secrets:

Centralized Secret Storage: Vault provides a centralized repository for storing and managing all types of secrets.
Robust Encryption: KMS ensures that secrets are encrypted with strong encryption keys and stored securely in GCS.
Fine-grained Access Control: Vault enforces granular access controls to restrict access to secrets based on user identities and application permissions.

Embrace a Secure and Streamlined Approach to Secrets Management

By adopting HashiCorp Vault on Cloud Run, you can streamline secrets management, enhance application security, and gain peace of mind knowing that your sensitive data is protected. Cloud Run’s serverless architecture and pay-per-use model further simplify the process, making it an ideal choice for organizations seeking a cost-effective and scalable solution.

Architecture¶

Prerequisites¶

To embark on this journey of securing your application secrets with HashiCorp Vault on Cloud Run, ensure you have the following prerequisites in place:

Google Cloud Platform (GCP) Account: A GCP account is essential to access and utilize GCP’s services, including Cloud Run, GCS, and KMS.
GCP Project: A GCP project serves as the container for your GCP resources, including the Vault deployment. Ensure you have a designated project for this purpose.
gcloud Command-Line Tool: The gcloud command-line tool is a powerful interface for interacting with GCP services from your local machine. Install and configure gcloud to proceed.
vault Command-Line Tool: The vault command-line tool is the primary interface for interacting with HashiCorp Vault. Install and configure vault to manage your Vault instance.

Step 1: Create a Service Account¶

To enable Vault to interact with GCP APIs, we’ll create a service account. A service account is a special type of account used by applications or compute workloads, rather than a person. It allows applications to perform authorized actions on GCP resources, such as creating or deleting instances, or accessing Cloud Storage buckets.

# service_account.tf
resource "google_service_account" "vault_sa" {
  account_id   = "vault-${var.environment}-kpabl-info-sa"
}

Step 2: Configure KMS (Key Management Service)¶

In this step, we’ll set up a Key Management Service (KMS) to encrypt our secrets. KMS is a crucial component for ensuring the security of your secrets. It provides a centralized and secure way to manage cryptographic keys. Vault will encrypt and decrypting secrets and confidential information before it’s stored in GCS.

Also we need to create a : * KMS key ring * KMS cryptographic key

Refer to the official documentation for detailed instructions.

# kms.tf

# Create a KMS
resource "google_kms_crypto_key" "vault_kms" {
  crypto_key_id = "vault-${var.environment}-kpabl-info-key"
  purpose       = "ENCRYPT_DECRYPT"
  version_template {
    algorithm = "GOOGLE_SYMMETRIC_ENCRYPTION"
    protection_level = "SOFTWARE"
  }
  # If we lose this key, then we won't be able to read our data
  lifecycle {
    prevent_destroy = true
  }
}

# Create a Keyring
resource "google_kms_key_ring" "vault_keyring" {
  location = "europe-west1"
  project  = var.project
  name     = "vault-${var.environment}-kpabl-info-keyring"
}

# Associate the Keyring with a KMS
resource "google_kms_crypto_key" "vault_kms_keyring" {
  crypto_key_id = google_kms_crypto_key.vault_kms.crypto_key_id
  key_ring_id  = google_kms_key_ring.vault_keyring.key_ring_id
}

Step 3: Configure a Storage Backend¶

In this step, we’ll configure a storage backend using Google Cloud Storage (GCS) to securely store your Vault secrets. GCS provides a scalable, durable, and highly available object storage solution, making it an ideal choice for storing sensitive information like secrets.

# backend.tf

# Create a Bucket
resource "google_storage_bucket" "vault_bucket" {
  name     = "vault-${var.environment}-kpabl-info-bucket"
  location = "europe-west1"
  force_destroy = true
  project  = var.project
  storage_class = "STANDARD"
}

# Give the service account access to the bucket
resource "google_storage_bucket_iam_member" "vault_bucket_sa" {
  bucket = google_storage_bucket.vault_bucket.name
  role   = "roles/storage.admin"
  member = "serviceAccount:${google_service_account.vault_sa.email}"
}

Once you’ve created a GCS bucket, we’ll need to configure Vault to use it as the storage backend. This will involve setting up the necessary Vault configuration and policies to enable secure storage of secrets in your GCS bucket.

Step 4: Generate a Configuration File for the Container¶

With all the essential components in place, we’ll now generate a configuration file that will guide the containerized Vault application. This file will define the parameters and settings required for Vault to operate effectively within our GCP environment.

# vault-server.hcl

default_max_request_duration = "90s"
disable_clustering           = false
disable_mlock                = true
ui                           = true

log_file = "/dev/stdout"

listener "tcp" {
  address = "[::]:8200"
  cluster_address = "[::]:8201"
  tls_disable = "true"
}

seal "gcpckms" {
  key_ring   = "${key_ring}"
  crypto_key = "${crypto_key}"
  region     = "${region}"
}

storage "gcs" {
  ha_enabled = "true"
}

To further enhance security, we’ll leverage Google Cloud Secret Manager (SM) to store and manage the sensitive Vault configuration file. SM provides a centralized and secure vault for storing sensitive information like configuration data, ensuring that your Vault configuration remains protected and accessible only to authorized entities.

# config.tf

# Generate random string for each ressource name
resource "random_id" "config" {
  byte_length = 8
}

# Secret to store config file
resource "google_secret_manager_secret" "vault_config" {
  secret_id = "${var.environment}-vault-config-${random_id.vault-config.hex}"

  labels = {
    app         = "vault"
    environment = var.environment
  }

  replication {
    user_managed {
      replicas {
        location = "europe-west1"
      }
    }
  }
}

# Inject config into our secret and complete config-file with KMS values
resource "google_secret_manager_secret_version" "vault_config" {
  secret = google_secret_manager_secret.vault_config.id

  secret_data = templatefile("${path.module}/vault-server.hcl", {
    key_ring   = google_kms_key_ring.vault.name
    crypto_key = google_kms_crypto_key.vault-key.name
    region     = google_kms_key_ring.vault.location
  })
}

# Atach policy to our secret
data "google_iam_policy" "vault_config" {
  binding {
    role = "roles/secretmanager.secretAccessor"
    members = [
      "serviceAccount:${google_service_account.vault_sa.email}",
    ]
  }
}
resource "google_secret_manager_secret_iam_policy" "vault_config" {
  project     = var.project
  secret_id   = google_secret_manager_secret.vault_config.id
  policy_data = data.google_iam_policy.vault_config.policy_data
}

Step 5: Configure Container Deployment¶

Now that we have all the components in place, it’s time to deploy the containerized Vault application using Cloud Run. However, we’ll make some adjustments to ensure Vault runs in a secure mode rather than the default “dev” mode. By default, the official Vault Docker image runs in “dev” mode, which is not suitable for production environments. To operate Vault in a secure manner, we need to override the default entrypoint.

module "vault_service" {
  source         = "../modules/http-container"
  project        = var.project
  fqdn           = var.environment != "prod" ? "vault-${var.environment}.kapable.info" : "vault.kapable.info"
  docker_image   = "hashicorp/vault"
  allways_on     = false
  container_port = 8200
  cpus           = 2
  memory         = 2000
  command        = ["/bin/vault"]
  args           = ["server", "-config", "/etc/vault/config.hcl"]
  container_env = {
    SKIP_SETCAP           = 1
    GOOGLE_PROJECT        = var.project
    GOOGLE_STORAGE_BUCKET = google_storage_bucket.buckets["vault"].name
    VAULT_LOG_LEVEL       = "info"
    SKIP_CHOWN            = 1
    VAULT_ADDR            = "http://127.0.0.1"
    VAULT_API_ADDR        = "http://127.0.0.1"
 }
  volumes = {
    config = {
      secret_id      = google_secret_manager_secret.vault_config.id
      secret_version = google_secret_manager_secret_version.vault_config.version
      secret_file    = "config.hcl"
      mount_path     = "/etc/vault"
    }
   }
  depends_on = [google_kms_key_ring_iam_policy.seal]
}

Step 6: Initialize Vault¶

With Vault successfully deployed and configured, it’s time to initialize it to enable secret management capabilities. This involves creating a storage directory, downloading the Vault binary, and executing the initialization command.

Create a Storage Directory: Create a directory to store your Vault configuration files. For example, create a directory named vault-config in your home directory:
Initialize Vault: Navigate to the directory containing the Vault binary and execute the initialization command:
Follow On-screen Instructions: The initialization process will generate five key shares and a root token. Carefully record and store these key shares and the root token in a secure location. You will need these to unseal and recover Vault if necessary.

vault operator init

Conclusion¶

This comprehensive guide has walked you through the process of deploying and configuring Hashicorp Vault on Cloud Run, leveraging a Cloud Storage (GCS) storage backend and Cloud Key Management Service (KMS) encryption on GCP. By following these steps, you have successfully established a secure and scalable solution for managing your secrets in the GCP environment.

Key Benefits of this Approach:

Simplicity: Streamlined deployment and management through Cloud Run and Terraform.
Scalability: Automatic scaling based on demand, ensuring your infrastructure can handle fluctuating workloads.
Security: Robust security measures, including encryption of secrets with KMS and container isolation, safeguard your sensitive data.
Cost-Effectiveness: Pay-as-you-go model optimizes resource utilization and minimizes unnecessary expenses.

Essential Considerations:

Adhere to Security Guidelines: Strictly follow security best practices to protect your secrets from unauthorized access and potential breaches.
Implement IAM Policies: Enforce stringent IAM policies to restrict access to your GCP resources, ensuring only authorized users can manage your infrastructure.
Monitor Resource Usage: Continuously monitor resource utilization and adjust your infrastructure configuration as needed to meet evolving demands.

By hosting Hashicorp Vault on Cloud Run with a GCS storage backend and KMS encryption on GCP, you have gained a robust, scalable, and secure solution for managing your application secrets. This approach offers a streamlined deployment process, cost-effective operation, and enhanced security, making it an ideal choice for organizations seeking efficient and reliable secret management in the cloud.

Trust in GCP’s KMS Service and Confidentiality:

It is important to note that this model relies on trust in GCP’s KMS service and its commitment to confidentiality. By choosing to encrypt your secrets with KMS, you are entrusting GCP with the protection of your sensitive data. Therefore, it is crucial to carefully evaluate GCP’s security practices and ensure that they align with your organization’s risk tolerance and compliance requirements.

This model is suitable for organizations that have a high level of trust in GCP’s security practices and are comfortable with entrusting their secrets to a third-party service.

La quête du Graal Devops : Concilier scaling à zéro et disponibilité immédiate

2024-06-02T00:00:00+02:00

Comprendre le Problème
La Solution : Autoscaling piloté par les Événements
- Fonctionnement du Système
Mise en place de la plateforme
Event drivent Ansible
Mise en oeuvre de EDA dans le cluster
Test du scaling à zéro
Conclusion

Dans le monde impitoyable du cloud, chaque ressource inutilisée représente un coût inutile. Le scaling à zéro des pods Kubernetes, bien que séduisant pour optimiser les coûts, se traduit souvent par une expérience utilisateur dégradée avec des applications indisponibles. Comment alors concilier économies et réactivité ?

Oubliez les compromis, et adoptez une approche pilotée par les événements, en combinant la puissance d’Event Driven Ansible à la finesse d’outils tels qu’Istio, Prometheus et Alertmanager. Imaginez un système capable de :

Détecter instantanément les premiers appels HTTP vers vos applications.
Déclencher automatiquement le lancement de vos pods Kubernetes pour répondre à la demande.
Orchestrer la mise à l’échelle de vos ressources de manière dynamique et transparente.
Réduire vos coûts d’infrastructure en stoppant les pods inactifs.

Plus besoin d’attendre le redémarrage de vos applications, la disponibilité est quasi-immédiate, et vos utilisateurs ne se rendent compte de rien !

Dans cet article, nous allons explorer en détail comment mettre en place cette solution élégante et efficace. Vous découvrirez :

Les mécanismes de détection d’événements basés sur le trafic HTTP.
La configuration d’alertes intelligentes pour déclencher l’autoscaling.
La mise en œuvre de playbooks Ansible pour automatiser le scaling de vos déploiements.

Préparez-vous à dire adieu aux compromis et à entrer dans l’ère du scaling à zéro intelligent !

Comprendre le Problème¶

Considérons un environnement de développement ou de test. Un “opérateur” pourrait allumer l’environnement avant son utilisation et l’éteindre (scaling à zéro) après. Cependant, l’approche DevOps vise à automatiser ces processus pour éliminer les interventions manuelles.

Le défi réside dans la recherche d’une solution automatique pour gérer le scaling de manière dynamique, en s’adaptant aux fluctuations de la demande. Nous voulons que l’environnement soit disponible immédiatement lorsqu’il est nécessaire, sans que les utilisateurs ne subissent de délai d’attente.

La Solution : Autoscaling piloté par les Événements¶

L’autoscaling basé sur les événements est la clé pour concilier économies de ressources et disponibilité immédiate. L’idée est de surveiller le trafic HTTP vers les pods Kubernetes et de déclencher automatiquement le scaling (augmenter le nombre de pods) lorsque les demandes ne trouvent pas de destinations.

Fonctionnement du Système¶

Détection des Événements: Istio, un outil de gestion de trafic, surveille le trafic HTTP vers vos pods Kubernetes.
Collecte de Données: Prometheus, un système de monitoring, collecte les données de trafic provenant d’Istio.
Génération d’Alertes: Alertmanager analyse les données de Prometheus et déclenche des alertes lorsque le trafic HTTP dépasse un seuil défini.
Action Automatique: Les alertes d’Alertmanager déclenchent des playbooks Ansible via Event Driven Ansible, qui lancent automatiquement les pods Kubernetes.
Arrêt Automatique: Lorsqu’il n’y a plus de trafic HTTP pendant une période définie, Alertmanager déclenche un autre playbook Ansible qui arrête les pods.

Mise en place de la plateforme¶

Installation de kubernetes+istio¶

Nous utiliserons Google Kubernetes Engine (GKE) avec Node-Autoscaling, qui s’occupe automatiquement de la mise à l’échelle des nœuds. Cela permet d’optimiser les ressources facturables en fonction du nombre de pods en cours d’exécution.

gcloud compute networks create scaleto0-vpc --project $PROJECT_ID
gcloud container clusters create scaleto0-demo \
    --enable-autoscaling \
    --num-nodes 1 \
    --min-nodes 1 \
    --max-nodes 3 \
    --network scaleto0-vpc \
    --project $PROJECT_ID \
    --release-channel=regular \
    --zone=${REGION}-b
gcloud container clusters get-credentials scaleto0-demo \
  --zone=${REGION}-b \
  --project=$PROJECT_ID

Ensuite, nous installerons Istio pour la gestion du trafic :

curl -L https://istio.io/downloadIstio | sh -
cd istio-<<VERSION>>
./bin/istioctl install --set profile=demo -y

Vérifiez l’installation d’Istio :

# Vérifier l'état des pods
kubectl get pods -n istio-system

# Vérifier l'état des services et s'assurer qu'un LB externe est créé pour istio-ingressgateway
kubectl get svc -n istio-system

Installation du monitoring : Prometheus / Alertmanager¶

Dans cet article nous réaliserons l’installation d’un système de surveillance minimaliste pour Istio, en se concentrant uniquement sur la surveillance d’Istio lui-même, sans surveiller les serveurs, les CPU ou la RAM. Nous utiliserons un chart Helm pour une installation simplifiée et maintiendrons la cohérence avec le reste de l’article en utilisant l’espace de noms istio-system.

helm upgrade -i -n istio-system prometheus prometheus-community/prometheus -f - << EOF
---
# prometheus_values.yaml
rbac:
  create: true
configmapReload:
  prometheus:
    enabled: false
server:
  namespaces:
    - istio-system
  resources:
    limits:
      cpu: 100m
      memory: 512Mi
    requests:
      cpu: 100m
      memory: 512Mi
  global:
    scrape_interval: 1s
    scrape_timeout: 1s
    evaluation_interval: 2s
serverFiles:
  prometheus.yml:
    rule_files:
      - /etc/config/recording_rules.yml
      - /etc/config/alerting_rules.yml
    scrape_configs:
      - job_name: 'istiod'
        kubernetes_sd_configs:
          - role: pod
        relabel_configs:
          - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
            action: keep
            regex: true
          - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape_slow]
            action: drop
            regex: true
          - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scheme]
            action: replace
            regex: (https?)
            target_label: __scheme__
          - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_path]
            action: replace
            target_label: __metrics_path__
            regex: (.+)
          - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_port, __meta_kubernetes_pod_ip]
            action: replace
            regex: (\\d+);(([A-Fa-f0-9]{1,4}::?){1,7}[A-Fa-f0-9]{1,4})
            replacement: '[\$2]:\$1'
            target_label: __address__
          - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_port, __meta_kubernetes_pod_ip]
            action: replace
            regex: (\\d+);((([0-9]+?)(\\.|$)){4})
            replacement: \$2:\$1
            target_label: __address__
          - action: labelmap
            regex: __meta_kubernetes_pod_annotation_prometheus_io_param_(.+)
            replacement: __param_$1
          - action: labelmap
            regex: __meta_kubernetes_pod_label_(.+)
          - source_labels: [__meta_kubernetes_namespace]
            action: replace
            target_label: namespace
          - source_labels: [__meta_kubernetes_pod_name]
            action: replace
            target_label: pod
          - source_labels: [__meta_kubernetes_pod_phase]
            regex: Pending|Succeeded|Failed|Completed
            action: drop
          - source_labels: [__meta_kubernetes_pod_node_name]
            action: replace
            target_label: node
alertmanager:
  enabled: true

kube-state-metrics:
  enabled: false

prometheus-node-exporter:
  enabled: false

prometheus-pushgateway:
  enabled: false
EOF

kubectl create clusterrole prometheus-server --verb=get,list,watch --resource=pods,endpoints,services,nodes,namespaces                                       
kubectl create clusterrolebinding prometheus-server --clusterrole=prometheus-server --serviceaccount=istio-system:prometheus-server

Pour tester le système de monitoring, nous pouvons utiliser la commande suivante afin de rediriger http://localhost:9090 vers le pod Prometheus :

kubectl --namespace istio-system port-forward $(kubectl get pods --namespace istio-system -l "app.kubernetes.io/name=prometheus,app.kubernetes.io/instance=prometheus" -o jsonpath="{.items[0].metadata.name}") 9090

Ouvrez ensuite un navigateur web à l’adresse : http://localhost:9090

Installation d’une application¶

Pour simuler une application dans notre démo, nous allons utiliser “whoami” qui se contente de renvoyer la requête HTTP qu’il reçoit. Si cela fonctionne avec “whoami”, on pourra appliquer le meme principe sur tous les déploiements du cluster Kubernetes.

Créons un fichier YAML pour le déploiement, comme suit :

Ce code YAML décrit la configuration d’un déploiement Kubernetes pour une application nommée “whoami”.

Déploiement “whoami”: Définit un déploiement avec le nom “whoami” qui utilise l’image Docker “traefik/whoami:latest”. Il indique que le déploiement devrait avoir 1 “replica” (scaling à 1).
Service “whoami”: Définit un service Kubernetes nommé “whoami” qui se connecte à des pods avec l’étiquette “app: whoami”. Expose le port 80 du service, qui se redirige vers le port 80 du conteneur.

kubectl create ns whoami
kubectl label namespace whoami istio-injection=enabled
kubectl apply -n whoami -f - <<EOF
# whoami_deployment.yaml
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: whoami
  annotations:
    "sidecar.istio.io/proxyCPU": "500m"
    "sidecar.istio.io/proxyMemory": "512Mi"
spec:
  selector:
    matchLabels:
      app: whoami
  replicas: 1
  template:
    metadata:
      labels:
        app: whoami
    spec:
      containers:
      - name: master
        image: traefik/whoami:latest
        resources:
          requests:
            cpu: 500m
            memory: 512Mi
          limits:
            cpu: 500m
            memory: 512Mi
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: whoami
  labels:
    app: whoami
spec:
  ports:
  - port: 80
    targetPort: 80
  selector:
    app: whoami
EOF

Et exposons ce service via Istio :

kubectl apply -n whoami -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: whoami-gateway
spec:
  # The selector matches the ingress gateway pod labels.
  # If you installed Istio using Helm following the standard documentation, this would be "istio=ingress"
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: whoami
spec:
  hosts:
  - "*"
  gateways:
  - whoami-gateway
  http:
  - match:
    - uri:
        prefix: /
    route:
    - destination:
        port:
          number: 80
        host: whoami
    retries:
      attempts: 15
      perTryTimeout: 2s
EOF

Test de l’application

INGRESS_HOST=$(kubectl get svc -n istio-system istio-ingressgateway -o jsonpath="{.status.loadBalancer.ingress[0].ip}" )
curl -s -I -HHost:whoami.scaleto0.demo "http://$INGRESS_HOST/"
HTTP/1.1 200 OK
date: Thu, 30 May 2024 20:21:32 GMT
content-length: 570
content-type: text/plain; charset=utf-8
x-envoy-upstream-service-time: 1073
server: istio-envoy

Downscaling de l’application

kubectl -n whoami scale deployment whoami --replicas=0

L’appliation une fois coupé (down) ne devrait plus fonctionner : Indisponnibilité de l’application

curl -s -I -HHost:whoami.scaleto0.demo "http://$INGRESS_HOST:$INGRESS_PORT/"

HTTP/1.1 503 Service Unavailable
content-length: 19
content-type: text/plain
date: Thu, 30 May 2024 20:22:56 GMT
server: istio-envoy

Event drivent Ansible¶

En suivant la documentation de Redhat, nous allons construire une image de conteneur pour servir notre rulebook. Voici le fichier Dockerfile qui crée un conteneur pour lancer la commande “ansible-rulebook”.

cat > Dockerfile << EOF
FROM debian:latest

RUN apt-get update && \
    apt-get --assume-yes install openjdk-17-jdk python3-pip python3-psycopg && \
    pip3 install ansible ansible-rulebook ansible-runner kubernetes --break-system-packages

RUN mkdir /app && \
    useradd -u 1001 -ms /bin/bash ansible && \
    chown ansible:root /app

WORKDIR /app
USER ansible

RUN ansible-galaxy collection install ansible.eda

ENTRYPOINT ["ansible-rulebook", "-r", "/app/rules.yaml", "-i", "/app/inventory.yml", "-S", "/app"]
EOF

Nous pouvons construire et enregistrer notre image dans artifact-registry de Google :

# Creation du repository
gcloud artifacts repositories create scaleto0-demo-repo --repository-format=docker \
    --location=$REGION --description="Docker scaleto0 Demo repository"

# Creation de l'image
gcloud builds submit --region=$REGION --tag $REGION-docker.pkg.dev/$PROJECT_ID/scaleto0-demo-repo/rulebook-scaleto0-demo:v1

Ce conteneur sera déployé dans Kubernetes. Nous allons surcharger le fichier /app/rules.yaml pour y inclure nos règles et playbooks, notamment pour le scaling.

Mise en oeuvre de EDA dans le cluster¶

Construction d’un playbook pour le scaling¶

Ansible, un langage puissant pour la manipulation de composants d’infrastructure, nous permetant de créer un “playbook” qui permettra de scaller le déploiement Kubernetes.

cat > scale-deployment.yaml << EOF
---
- hosts: localhost
  connection: local
  gather_facts: false
  tasks:
  - name: Scale deployment up
    kubernetes.core.k8s_scale:
      api_version: v1
      kind: Deployment
      name: "{{ deployment_name }}"
      namespace: "{{ namespace }}"
      replicas: "{{ num_replicas }}"
      wait_timeout: 60
EOF

Nous pouvons tester le playbook avec la commande ci-dessous :

ansible-playbook -e '{"deployment_name":"whoami", "namespace":"whoami", "num_replicas": "1"}' scale-deployment.yaml

Ensuite, créons un fichier rules.yaml pour définir l’interface entre le monitoring et le playbook de scaling.

cat > rules.yaml << EOF
- name: Scale deployment up
  hosts: localhost
  gather_facts: false
  sources:
    - name: webhook
      ansible.eda.webhook:
        port: 5000
  rules:
    - name: whoami
      condition: true
      actions:
      - run_playbook:
          name: scale-deployment.yaml
          extra_vars:
            deployment_name: whoami
            namespace: whoami
            num_replicas: 1
EOF
cat > inventory.yml << EOF
ungrouped:
  hosts:
    localhost:
      ansible_connection: local
EOF

Injecter le playbook dans Kubernetes :

kubectl create ns ansible-rulebook
kubectl create -n ansible-rulebook configmap ansible-rulebook-config --from-file=.

Démarrer le conteneur:

kubectl -n ansible-rulebook apply -f - << EOF
# ansible-rulebook_deployment.yaml
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ansible-rulebook
spec:
  selector:
    matchLabels:
      app: ansible-rulebook
  replicas: 1
  template:
    metadata:
      labels:
        app: ansible-rulebook
    spec:
      containers:
      - name: master
        image: $REGION-docker.pkg.dev/$PROJECT_ID/scaleto0-demo-repo/rulebook-scaleto0-demo:v1
        resources:
          requests:
            cpu: 100m
            memory: 128Mi
          limits:
            cpu: 500m
            memory: 512Mi
        ports:
        - containerPort: 5000
        volumeMounts:
        - name: config
          mountPath: /app
      volumes:
      - name: config
        configMap:
          name: ansible-rulebook-config
---
apiVersion: v1
kind: Service
metadata:
  name: ansible-rulebook
  labels:
    app: ansible-rulebook
spec:
  ports:
  - port: 5000
    targetPort: 5000
  selector:
    app: ansible-rulebook
EOF

Accorder des droits à ansible-rulebook pour interagir avec Kubernetes :

kubectl apply -f - << EOF
# ansible-rulebook_clusterrole.yaml
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  creationTimestamp: "2024-05-31T19:01:36Z"
  name: deployment-scaler
rules:
- apiGroups:
  - apps
  resources:
  - deployments/scale
  - deployments
  verbs:
  - get
  - list
  - patch
  - update
EOF

Enfin, mapper le rôle ansible-rulebook au déploiement :

kubectl create clusterrolebinding deployment-scaler --clusterrole=deployment-scaler --serviceaccount=ansible-rulebook:default

Intégration avec la supervision¶

Il faut connecter Alertmanager à Ansible rulebook. Pour ce faire, mettons à jour la configuration d’Alertmanager pour qu’elle envoie ses alertes vers le rulebook.

kubectl patch -n istio-system configmap prometheus-alertmanager --type merge -p "
data:
  alertmanager.yml: |
    global: {}
    receivers:
    - name: default-receiver
      webhook_configs:
      - url: http://ansible-rulebook.ansible-rulebook.svc.cluster.local:5000/endpoint
    route:
      group_interval: 5s
      group_wait: 10s
      receiver: default-receiver
      repeat_interval: 5m
    templates:
    - /etc/alertmanager/*.tmpl
"

Relancer les pods de monitoring pour prendre en compte le nouveau configmap :

kubectl -n istio-system rollout restart statefulset/prometheus-alertmanager

Création de l’alerte de supervision¶

Créons une alerte de supervision qui détectera les erreurs 503 dans Prometheus et déclenchera le “rulebook” Ansible.

Étant donné que Prometheus est installé avec Helm, nous mettrons à jour la configuration statique pour injecter l’alerte. Dans un environnement de production, les alertes seraient injectées via l’opérateur et les CRD “PrometheusRules”.

kubectl patch -n istio-system configmap prometheus-server --type merge -p "
data:
  alerting_rules.yml: |
    groups:
      - name: DeploymentDown
        rules:
          - alert: DeploymentDown
            expr: sum by (destination_service_name) (rate(istio_requests_total{response_code=\"503\"}[3s])) > 0
            for: 2s
            labels:
              severity: page
            annotations:
              description: 'No upstream on {{ \$labels.destination_service_name }}'
              summary: '{{ \$labels.destination_service_name }} down'
"

Relancer les pods de monitoring pour prendre en compte le nouveau configmap :

kubectl -n istio-system rollout restart deployment/prometheus-server

Après avoir généré quelques appels vers l’application sans pods, nous devrions retrouver l’alerte dans Prometheus :

Test du scaling à zéro¶

1. Test de base:

Scénario: Démarrez l’application “whoami” avec un seul pod et observez que l’application est accessible.
Accédez au service “whoami” via un navigateur ou curl : Verifier que le résultat est correct et garder la fenetre ouverte pour visualiser le status de l’application.

INGRESS_HOST=$(kubectl get svc -n istio-system istio-ingressgateway -o jsonpath="{.status.loadBalancer.ingress[0].ip}" )
watch curl -s -I -HHost:whoami.scaleto0.demo "http://$INGRESS_HOST/"

* Assurez-vous que vous obtenez une réponse HTTP 200 et que le contenu renvoyé correspond à l’application “whoami”. * Vérifiez que le pod “whoami” est en cours d’exécution dans le cluster Kubernetes.

$ kubectl -n whoami get pod
NAME                      READY   STATUS    RESTARTS   AGE
whoami-5d696b585d-twv98   2/2     Running   0          4m58s

2. Test du scaling à zéro:

Scénario: Mettez l’application “whoami” à zéro pods et déclenchez des requêtes HTTP vers l’application.
Validation:
Utilisez la commande kubectl -n whoami scale deployment whoami --replicas=0 pour réduire le nombre de pods à zéro.
Effectuez plusieurs requêtes HTTP vers l’application “whoami” (via un navigateur ou curl).
Assurez-vous que les requêtes retournent une réponse HTTP 503 (service indisponible).
Vérifiez que le monitoring Prometheus détecte l’absence de pod et génère une alerte.
Vérifiez que l’alerte “DeploymentDown” est générée par Alertmanager et envoyée au webhook d’Ansible.
Vérifiez que le playbook Ansible “scale-deployment.yaml” est exécuté et qu’un nouveau pod “whoami” est crée

kubectl -n ansible-rulebook logs deployment/ansible-rulebook

De mon côté j’ai observé que le service répond en 25seconde après une coupure.

Conclusion¶

L’autoscaling basé sur les événements offre un équilibre parfait entre l’optimisation des ressources et la disponibilité immédiate des applications. En combinant Event Driven Ansible et des outils tels qu’Istio, Prometheus et Alertmanager, vous pouvez mettre en place un système robuste et efficace pour garantir une performance optimale et des coûts réduits.

Principaux avantages de cette approche¶

Disponibilité immédiate : Les pods sont lancés automatiquement lors des premiers appels HTTP, garantissant une réponse rapide aux demandes.
Optimisation des ressources : Les pods sont arrêtés automatiquement lorsqu’ils ne sont plus utilisés, ce qui réduit les coûts de ressources.
Efficacité et fiabilité : Le système fonctionne de manière automatique et fiable, sans intervention humaine.
Évolutivité : La solution peut être facilement adaptée aux besoins évolutifs des applications.

Questions pour réflexion¶

Avez-vous déjà mis en place des solutions similaires pour le scaling à zéro dans vos environnements Kubernetes ?
Comment pouvez-vous adapter cette solution à vos besoins spécifiques et l’intégrer dans votre pipeline DevOps ?

Ressources supplémentaires¶

https://chimbu.medium.com/installing-istio-not-anthos-service-mesh-on-gke-autopilot-2b78f1bbe90a
https://developers.redhat.com/articles/2024/04/12/event-driven-ansible-rulebook-automation#ansible_rulebook_cli_setup
https://github.com/istio/istio/issues/10543#issuecomment-921179277
https://medium.com/@letsretry/retry-between-region-using-ingress-controller-ingress-level-retry-e8c000580bfe

The Quest for the Devops Grail: Reconciling Zero Scaling and Immediate Availability

2024-06-02T00:00:00+02:00

Understanding the Problem
The Solution: Event-Driven Autoscaling
- How the System Works
Setting up the Platform
Event Driven Ansible
Implementing EDA in the Cluster
Testing Zero Scaling
Conclusion

In the ruthless world of the cloud, every unused resource represents an unnecessary cost. Zero scaling of Kubernetes pods, while attractive for optimizing costs, often results in a degraded user experience with unavailable applications. How then can you reconcile savings and responsiveness?

Forget about compromises, and adopt an event-driven approach, combining the power of Event Driven Ansible with the finesse of tools like Istio, Prometheus, and Alertmanager. Imagine a system capable of:

Instantly detecting the first HTTP calls to your applications.
Automatically triggering the launch of your Kubernetes pods to meet demand.
Orchestrating the scaling of your resources dynamically and transparently.
Reducing your infrastructure costs by stopping inactive pods.

No more waiting for your applications to restart, availability is almost immediate, and your users don’t notice a thing!

In this article, we will explore in detail how to implement this elegant and efficient solution. You will discover:

The mechanisms of event detection based on HTTP traffic.
The configuration of intelligent alerts to trigger autoscaling.
The implementation of Ansible playbooks to automate the scaling of your deployments.

Get ready to say goodbye to compromises and enter the era of intelligent zero scaling!

Understanding the Problem¶

Consider a development or test environment. An “operator” could turn on the environment before using it and turn it off (zero scaling) afterwards. However, the DevOps approach aims to automate these processes to eliminate manual interventions.

The challenge lies in finding an automatic solution to manage scaling dynamically, adapting to fluctuations in demand. We want the environment to be immediately available when needed, without users experiencing any wait time.

The Solution: Event-Driven Autoscaling¶

Event-based autoscaling is the key to reconciling resource savings and immediate availability. The idea is to monitor HTTP traffic to Kubernetes pods and automatically trigger scaling (increase the number of pods) when requests do not find destinations.

How the System Works¶

Event Detection: Istio, a traffic management tool, monitors HTTP traffic to your Kubernetes pods.
Data Collection: Prometheus, a monitoring system, collects traffic data from Istio.
Alert Generation: Alertmanager analyzes Prometheus data and triggers alerts when HTTP traffic exceeds a defined threshold.
Automatic Action: Alertmanager alerts trigger Ansible playbooks via Event Driven Ansible, which automatically launch Kubernetes pods.
Automatic Shutdown: When there is no more HTTP traffic for a defined period, Alertmanager triggers another Ansible playbook that stops the pods.

Setting up the Platform¶

Installing kubernetes+istio¶

We will use Google Kubernetes Engine (GKE) with Node-Autoscaling, which automatically handles node scaling. This helps optimize billable resources based on the number of pods running.

gcloud compute networks create scaleto0-vpc --project $PROJECT_ID
gcloud container clusters create scaleto0-demo \
--enable-autoscaling \
--num-nodes 1 \
--min-nodes 1 \
--max-nodes 3 \
--network scaleto0-vpc \
--project $PROJECT_ID \
--release-channel=regular \
--zone=${REGION}-b
gcloud container clusters get-credentials scaleto0-demo \
--zone=${REGION}-b \
--project=$PROJECT_ID

Next, we will install Istio for traffic management:

curl -L https://istio.io/downloadIstio | sh -
cd istio-<<VERSION>>
./bin/istioctl install --set profile=demo -y

Verify the Istio installation:

# Check the status of pods
kubectl get pods -n istio-system

# Check the status of services and make sure an external LB is created for istio-ingressgateway
kubectl get svc -n istio-system

Installing monitoring: Prometheus / Alertmanager¶

In this article we will perform the installation of a minimalist monitoring system for Istio, focusing only on monitoring Istio itself, without monitoring servers, CPU or RAM. We will use a Helm chart for simplified installation and maintain consistency with the rest of the article by using the istio-system namespace.

helm upgrade -i -n istio-system prometheus prometheus-community/prometheus -f - << EOF
---
# prometheus_values.yaml
rbac:
create: true
configmapReload:
prometheus:
enabled: false
server:
namespaces:
- istio-system
resources:
limits:
cpu: 100m
memory: 512Mi
requests:
cpu: 100m
memory: 512Mi
global:
scrape_interval: 1s
scrape_timeout: 1s
evaluation_interval: 2s
serverFiles:
prometheus.yml:
rule_files:
- /etc/config/recording_rules.yml
- /etc/config/alerting_rules.yml
scrape_configs:
- job_name: 'istiod'
kubernetes_sd_configs:
- role: pod
relabel_configs:
- source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
action: keep
regex: true
- source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape_slow]
action: drop
regex: true
- source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scheme]
action: replace
regex: (https?)
target_label: __scheme__
- source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_path]
action: replace
target_label: __metrics_path__
regex: (.+)
- source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_port, __meta_kubernetes_pod_ip]
action: replace
regex: (\\d+);(([A-Fa-f0-9]{1,4}::?){1,7}[A-Fa-f0-9]{1,4})
replacement: '[\$2]:\$1'
target_label: __address__
- source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_port, __meta_kubernetes_pod_ip]
action: replace
regex: (\\d+);((([0-9]+?)(\\.|$)){4})
replacement: \$2:\$1
target_label: __address__
- action: labelmap
regex: __meta_kubernetes_pod_annotation_prometheus_io_param_(.+)
replacement: __param_$1
- action: labelmap
regex: __meta_kubernetes_pod_label_(.+)
- source_labels: [__meta_kubernetes_namespace]
action: replace
target_label: namespace
- source_labels: [__meta_kubernetes_pod_name]
action: replace
target_label: pod
- source_labels: [__meta_kubernetes_pod_phase]
regex: Pending|Succeeded|Failed|Completed
action: drop
- source_labels: [__meta_kubernetes_pod_node_name]
action: replace
target_label: node
alertmanager:
enabled: true

kube-state-metrics:
enabled: false

prometheus-node-exporter:
enabled: false

prometheus-pushgateway:
enabled: false
EOF

kubectl create clusterrole prometheus-server --verb=get,list,watch --resource=pods,endpoints,services,nodes,namespaces
kubectl create clusterrolebinding prometheus-server --clusterrole=prometheus-server --serviceaccount=istio-system:prometheus-server

To test the monitoring system, we can use the following command to redirect http://localhost:9090 to the Prometheus pod:

kubectl --namespace istio-system port-forward $(kubectl get pods --namespace istio-system -l "app.kubernetes.io/name=prometheus,app.kubernetes.io/instance=prometheus" -o jsonpath="{.items[0].metadata.name}") 9090

Then open a web browser at the address: http://localhost:9090

Installing an Application¶

To simulate an application in our demo, we will use “whoami” which simply returns the HTTP request it receives. If it works with “whoami”, we can apply the same principle to all deployments on the Kubernetes cluster.

Let’s create a YAML file for the deployment, as follows:

This YAML code describes the configuration of a Kubernetes deployment for an application named “whoami”.

Deployment “whoami”: Defines a deployment with the name “whoami” that uses the Docker image “traefik/whoami:latest”. It indicates that the deployment should have 1 “replica” (scaling to 1).
Service “whoami”: Defines a Kubernetes service named “whoami” that connects to pods with the label “app: whoami”. Exposes port 80 of the service, which redirects to port 80 of the container.

kubectl create ns whoami
kubectl label namespace whoami istio-injection=enabled
kubectl apply -n whoami -f - <<EOF
# whoami_deployment.yaml
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: whoami
annotations:
"sidecar.istio.io/proxyCPU": "500m"
"sidecar.istio.io/proxyMemory": "512Mi"
spec:
selector:
matchLabels:
app: whoami
replicas: 1
template:
metadata:
labels:
app: whoami
spec:
containers:
- name: master
image: traefik/whoami:latest
resources:
requests:
cpu: 500m
memory: 512Mi
limits:
cpu: 500m
memory: 512Mi
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: whoami
labels:
app: whoami
spec:
ports:
- port: 80
targetPort: 80
selector:
app: whoami
EOF

And expose this service via Istio:

kubectl apply -n whoami -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: whoami-gateway
spec:
# The selector matches the ingress gateway pod labels.
# If you installed Istio using Helm following the standard documentation, this would be "istio=ingress"
selector:
istio: ingressgateway
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: whoami
spec:
hosts:
- "*"
gateways:
- whoami-gateway
http:
- match:
- uri:
prefix: /
route:
- destination:
port:
number: 80
host: whoami
retries:
attempts: 15
perTryTimeout: 2s
EOF

Testing the application

INGRESS_HOST=$(kubectl get svc -n istio-system istio-ingressgateway -o jsonpath="{.status.loadBalancer.ingress[0].ip}" )
curl -s -I -HHost:whoami.scaleto0.demo "http://$INGRESS_HOST/"
HTTP/1.1 200 OK
date: Thu, 30 May 2024 20:21:32 GMT
content-length: 570
content-type: text/plain; charset=utf-8
x-envoy-upstream-service-time: 1073
server: istio-envoy

Downscaling the application

kubectl -n whoami scale deployment whoami --replicas=0

Once the application is cut off (down), it should no longer work: Application unavailability

curl -s -I -HHost:whoami.scaleto0.demo "http://$INGRESS_HOST:$INGRESS_PORT/"

HTTP/1.1 503 Service Unavailable
content-length: 19
content-type: text/plain
date: Thu, 30 May 2024 20:22:56 GMT
server: istio-envoy

Event Driven Ansible¶

Following Redhat documentation, we will build a container image to serve our rulebook. Here is the Dockerfile that creates a container to run the “ansible-rulebook” command.

cat > Dockerfile << EOF
FROM debian:latest

RUN apt-get update && \
apt-get --assume-yes install openjdk-17-jdk python3-pip python3-psycopg && \
pip3 install ansible ansible-rulebook ansible-runner kubernetes --break-system-packages

RUN mkdir /app && \
useradd -u 1001 -ms /bin/bash ansible && \
chown ansible:root /app

WORKDIR /app
USER ansible

RUN ansible-galaxy collection install ansible.eda

ENTRYPOINT ["ansible-rulebook", "-r", "/app/rules.yaml", "-i", "/app/inventory.yml", "-S", "/app"]
EOF

We can build and save our image in Google’s artifact-registry:

# Creating the repository
gcloud artifacts repositories create scaleto0-demo-repo --repository-format=docker \
--location=$REGION --description="Docker scaleto0 Demo repository"

# Creating the image
gcloud builds submit --region=$REGION --tag $REGION-docker.pkg.dev/$PROJECT_ID/scaleto0-demo-repo/rulebook-scaleto0-demo:v1

This container will be deployed in Kubernetes. We will overload the /app/rules.yaml file to include our rules and playbooks, including those for scaling.

Implementing EDA in the Cluster¶

Building a playbook for scaling¶

Ansible, a powerful language for manipulating infrastructure components, allows us to create a “playbook” that will allow us to scale the Kubernetes deployment.

cat > scale-deployment.yaml << EOF
---
- hosts: localhost
connection: local
gather_facts: false
tasks:
- name: Scale deployment up
kubernetes.core.k8s_scale:
api_version: v1
kind: Deployment
name: "{{ deployment_name }}"
namespace: "{{ namespace }}"
replicas: "{{ num_replicas }}"
wait_timeout: 60
EOF

We can test the playbook with the command below:

ansible-playbook -e '{"deployment_name":"whoami", "namespace":"whoami", "num_replicas": "1"}' scale-deployment.yaml

Next, let’s create a rules.yaml file to define the interface between monitoring and the scaling playbook.

cat > rules.yaml << EOF
- name: Scale deployment up
hosts: localhost
gather_facts: false
sources:
- name: webhook
ansible.eda.webhook:
port: 5000
rules:
- name: whoami
condition: true
actions:
- run_playbook:
name: scale-deployment.yaml
extra_vars:
deployment_name: whoami
namespace: whoami
num_replicas: 1
EOF
cat > inventory.yml << EOF
ungrouped:
hosts:
localhost:
ansible_connection: local
EOF

Injecting the playbook into Kubernetes:

kubectl create ns ansible-rulebook
kubectl create -n ansible-rulebook configmap ansible-rulebook-config --from-file=.

Starting the container:

kubectl -n ansible-rulebook apply -f - << EOF
# ansible-rulebook_deployment.yaml
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: ansible-rulebook
spec:
selector:
matchLabels:
app: ansible-rulebook
replicas: 1
template:
metadata:
labels:
app: ansible-rulebook
spec:
containers:
- name: master
image: $REGION-docker.pkg.dev/$PROJECT_ID/scaleto0-demo-repo/rulebook-scaleto0-demo:v1
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 500m
memory: 512Mi
ports:
- containerPort: 5000
volumeMounts:
- name: config
mountPath: /app
volumes:
- name: config
configMap:
name: ansible-rulebook-config
---
apiVersion: v1
kind: Service
metadata:
name: ansible-rulebook
labels:
app: ansible-rulebook
spec:
ports:
- port: 5000
targetPort: 5000
selector:
app: ansible-rulebook
EOF

Granting rights to ansible-rulebook to interact with Kubernetes:

kubectl apply -f - << EOF
# ansible-rulebook_clusterrole.yaml
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
creationTimestamp: "2024-05-31T19:01:36Z"
name: deployment-scaler
rules:
- apiGroups:
- apps
resources:
- deployments/scale
- deployments
verbs:
- get
- list
- patch
- update
EOF

Finally, mapping the ansible-rulebook role to the deployment:

kubectl create clusterrolebinding deployment-scaler --clusterrole=deployment-scaler --serviceaccount=ansible-rulebook:default

Integration with Supervision¶

Alertmanager needs to be connected to Ansible rulebook. To do this, let’s update the Alertmanager configuration to have it send its alerts to the rulebook.

kubectl patch -n istio-system configmap prometheus-alertmanager --type merge -p "
data:
alertmanager.yml: |
global: {}
receivers:
- name: default-receiver
webhook_configs:
- url: http://ansible-rulebook.ansible-rulebook.svc.cluster.local:5000/endpoint
route:
group_interval: 5s
group_wait: 10s
receiver: default-receiver
repeat_interval: 5m
templates:
- /etc/alertmanager/*.tmpl
"

Restart the monitoring pods to take into account the new configmap:

kubectl -n istio-system rollout restart statefulset/prometheus-alertmanager

Creating the Supervision Alert¶

Let’s create a supervision alert that will detect 503 errors in Prometheus and trigger the Ansible “rulebook”.

Since Prometheus is installed with Helm, we will update the static configuration to inject the alert. In a production environment, alerts would be injected via the operator and “PrometheusRules” CRDs.

kubectl patch -n istio-system configmap prometheus-server --type merge -p "
data:
alerting_rules.yml: |
groups:
- name: DeploymentDown
rules:
- alert: DeploymentDown
expr: sum by (destination_service_name) (rate(istio_requests_total{response_code=\"503\"}[3s])) > 0
for: 2s
labels:
severity: page
annotations:
description: 'No upstream on {{ \$labels.destination_service_name }}'
summary: '{{ \$labels.destination_service_name }} down'
"

Restart the monitoring pods to take into account the new configmap:

kubectl -n istio-system rollout restart deployment/prometheus-server

After generating a few calls to the application without pods, we should find the alert in Prometheus:

Testing Zero Scaling¶

1. Basic test:

Scenario: Start the “whoami” application with a single pod and observe that the application is accessible.
Access the “whoami” service via a browser or curl: Verify that the result is correct and keep the window open to view the status of the application.

INGRESS_HOST=$(kubectl get svc -n istio-system istio-ingressgateway -o jsonpath="{.status.loadBalancer.ingress[0].ip}" )
watch curl -s -I -HHost:whoami.scaleto0.demo "http://$INGRESS_HOST/"

* Make sure you get an HTTP 200 response and that the content returned corresponds to the “whoami” application. * Verify that the “whoami” pod is running in the Kubernetes cluster.

$ kubectl -n whoami get pod
NAME READY STATUS RESTARTS AGE
whoami-5d696b585d-twv98 2/2 Running 0 4m58s

2. Testing zero scaling:

Scenario: Set the “whoami” application to zero pods and trigger HTTP requests to the application.
Validation:
Use the kubectl -n whoami scale deployment whoami --replicas=0 command to reduce the number of pods to zero.
Make several HTTP requests to the “whoami” application (via a browser or curl).
Make sure the requests return an HTTP 503 (service unavailable) response.
Verify that Prometheus monitoring detects the absence of a pod and generates an alert.
Verify that the “DeploymentDown” alert is generated by Alertmanager and sent to the Ansible webhook.
Verify that the Ansible playbook “scale-deployment.yaml” is executed and a new “whoami” pod is created

kubectl -n ansible-rulebook logs deployment/ansible-rulebook

From my side I observed that the service responds in 25 seconds after a cut-off.

Conclusion¶

Event-based autoscaling provides a perfect balance between resource optimization and the immediate availability of applications. By combining Event Driven Ansible with tools like Istio, Prometheus, and Alertmanager, you can implement a robust and efficient system to ensure optimal performance and reduced costs.

Key Benefits of This Approach¶

Immediate availability: Pods are launched automatically on the first HTTP calls, ensuring a quick response to requests.
Resource optimization: Pods are automatically shut down when they are no longer in use, reducing resource costs.
Efficiency and reliability: The system works automatically and reliably, without human intervention.
Scalability: The solution can be easily adapted to the evolving needs of applications.

Questions for Reflection¶

Have you already implemented similar solutions for zero scaling in your Kubernetes environments?
How can you adapt this solution to your specific needs and integrate it into your DevOps pipeline?

Additional Resources¶

https://chimbu.medium.com/installing-istio-not-anthos-service-mesh-on-gke-autopilot-2b78f1bbe90a
https://developers.redhat.com/articles/2024/04/12/event-driven-ansible-rulebook-automation#ansible_rulebook_cli_setup
https://github.com/istio/istio/issues/10543#issuecomment-921179277
https://medium.com/@letsretry/retry-between-region-using-ingress-controller-ingress-level-retry-e8c000580bfe

Génération de texte pour les Merges-Requests automatique avec un LLM

2024-05-29T00:00:00+02:00

1. Configuration de Vertex AI
2. Construction d’un script et intégration dans une image docker
3. Intégration dans GitLab CI
Conclusion

Notre métier consiste à installer des applications en respéctant l’état de l’art. Lorsque l’installation de l’application se fait via la mise à jour de code Gitlab, la documentation de ce code est primordiale. Toute mise à jour du code d’infrastructure est documenté dans une demande Gitlab de merge-request.

Aujourd’hui, je vous propose d’automatiser une des tâches de documentation: la rédaction de descriptions pour les merge-requests. J’ai pu remarquer qu’au début des projets, on se force à écrire de la documentation et des descriptions de changements clair et complet. Cependant, avec la pression ou les changements qui sont à effectuer rapidement, avec le temps, il arrive qu’on se retrouve à rédiger des notes trop brèves, non-exhaustives, ou ne reflétant pas l’intégralité des changements effectués dans le code.

Du coup, nos MR ressemblent à ça et c’est assez vide.

Alors que la documentation et ces descriptions sont très importantes pour :

les échanges avec l’équipe (Review, double checks, …)
l’audibilité des changements (savoir qui a changé quoi)
La gestion de la documentation du projet

Heureusement, avec Vertex AI et GitLab CI, on peut automatiser cette tâche !

Dans cet article, nous allons explorer comment utiliser Vertex AI pour générer automatiquement du texte de merge-request à partir des changements effectués dans une branche GitLab.

1. Configuration de Vertex AI¶

Tout d’abord, il faut configurer l’API Vertex AI capable de générer du texte à partir de données textuelles. Dans cet article, j’ai utilisé le modèle “gemini-1.5-flash-001”.

Il faut bien sûr activer l’api Vertex AI en suivant la documentation. On peut ensuite utiliser VertexAI via la console Google Cloud pour construire le meilleur prompt Après quelques textes voici le prompt que j’ai mis en place :

As a senior DevOps engineer reviewing a merge request for a Terraform module.  Please provide a comprehensive description of the changes in french, focusing on the following:
* **What is the overall purpose of the changes?**
* **What specific resources are affected?**
* **What are the main changes made to those resources?**
* **Are there any security or performance implications of the changes?**
* **Are there any potential risks or considerations?

On peut tester le prompt dans VertexAI, comme ci-dessous en glissant-déposser un fichier “git-diff”.

2. Construction d’un script et intégration dans une image docker¶

Pour commencer, on va créer un script python capable :

Interroger Gitlab pour obtenir le “gitdiff” changement Le soumettre à VertexAI Mettre a jour la MR Gitlab avec le résultat de VertexAI Voici le script : generate-mr-text.py

import base64
import vertexai
from vertexai.generative_models import GenerativeModel, Part, FinishReason
import vertexai.preview.generative_models as generative_models
import gitlab
import os, json
import argparse;

GCP_PROJECT_ID = os.getenv("GCP_PROJECT_ID", "sandbox-mgoulin")
GCP_LOCATION = os.getenv("GCP_LOCATION", "us-central1")
GCP_MODEL = os.getenv("GCP_MODEL", "gemini-1.5-flash-preview-0514")

GITLAB_HOST=os.getenv("GITLAB_HOST","https://gitlab.com")
GITLAB_TOKEN=os.getenv("GITLAB_TOKEN", False)
GITLAB_SSL_SKIP_VERIFY=os.getenv("GITLAB_SSL_SKIP_VERIFY",False)

LLM_PROMPT = """As a senior DevOps engineer reviewing a merge request for a Terraform module.  Please provide a comprehensive description of the changes in french, focusing on the following:
* **What is the overall purpose of the changes?**
* **What specific resources are affected?**
* **What are the main changes made to those resources?**
* **Are there any security or performance implications of the changes?**
* **Are there any potential risks or considerations?**"""

def generate(diff):
  vertexai.init(project=GCP_PROJECT_ID, location=GCP_LOCATION)
  model = GenerativeModel(
    GCP_MODEL,
  )
  responses = model.generate_content(
      [LLM_PROMPT, diff],
      generation_config=generation_config,
      safety_settings=safety_settings,
      stream=True,
  )

  rep = ""
  for response in responses:
    rep += response.text
  return rep

generation_config = {
    "max_output_tokens": 8192,
    "temperature": 1,
    "top_p": 0.95,
}

safety_settings = {
    generative_models.HarmCategory.HARM_CATEGORY_HATE_SPEECH: generative_models.HarmBlockThreshold.BLOCK_MEDIUM_AND_ABOVE,
    generative_models.HarmCategory.HARM_CATEGORY_DANGEROUS_CONTENT: generative_models.HarmBlockThreshold.BLOCK_MEDIUM_AND_ABOVE,
    generative_models.HarmCategory.HARM_CATEGORY_SEXUALLY_EXPLICIT: generative_models.HarmBlockThreshold.BLOCK_MEDIUM_AND_ABOVE,
    generative_models.HarmCategory.HARM_CATEGORY_HARASSMENT: generative_models.HarmBlockThreshold.BLOCK_MEDIUM_AND_ABOVE,
}

def find_mr(project, mr_id):
    gl = gitlab.Gitlab(url=GITLAB_HOST, private_token=GITLAB_TOKEN, ssl_verify=not(GITLAB_SSL_SKIP_VERIFY))
    prj = gl.projects.get(project)
    return prj.mergerequests.get(mr_id)

parser = argparse.ArgumentParser(
                    prog='generate-mr-text.py',
                    description='Use Gemini to update a merge request with a description',
                    )

parser.add_argument('-p', '--gitlab_project', required=True)
parser.add_argument('-m', '--gitlab_mr_id', required=True, type=int)
project = parser.parse_args().gitlab_project
mr_id = parser.parse_args().gitlab_mr_id

mr = find_mr(project, mr_id)
changes = mr.changes()
#print(json.dumps(changes, indent=4))
#diff=find_diff()
text=generate(json.dumps(changes, indent=4))
mr.description=mr.description.split("=== Start block generated by generate-mr-text.py ===")[0]+"""

=== Start block generated by generate-mr-text.py ===
"""+text
mr.save()

On peut intégrer rapidement ce script via Dockerfile et pip, pour cela, on a besoin de créer deux fichiers permettant d’installer le script dans un container docker.

Fichier requirements.txt

python-gitlab
google-cloud-aiplatform

Fichier : Dockerfile

FROM registry.access.redhat.com/ubi8/python-38

# Add application sources with correct permissions for OpenShift
USER 0
ADD . .
RUN chown -R 1001:0 ./
USER 1001

# Install the dependencies
RUN pip install -U "pip>=19.3.1" && \
    pip install -r requirements.txt

La commande docker build . permettra de construire le container et pour rester cohérent dans nos outils et rester dans le monde GCP, je propose de l’héberger dans Artifact registry

Pour résumé voici les commandes :

cloud artifacts repositories create --project sandbox-mgoulin --repository-format=DOCKER --location europe-west9 generate-mr-text
docker build . -t europe-west9-docker.pkg.dev/sandbox-mgoulin/generate-mr-text/generate-mr-text:latest
docker push europe-west9-docker.pkg.dev/sandbox-mgoulin/generate-mr-text/generate-mr-text:latest

Le container s’utilisera donc simplement de la façon suivante (d’autre variable d’environnement peuvent être ajouté dans le script).

docker run \
-e GCP_PROJECT_ID=... \
-e GITLAB_TOKEN=... \
-e GOOGLE_APPLICATION_CREDENTIALS=... \
europe-west9-docker.pkg.dev/sandbox-mgoulin/generate-mr-text/generate-mr-text:latest \
python generate-mr-text.py -p  -m

3. Intégration dans GitLab CI¶

Une fois le modèle Vertex AI configuré, le script crée, il faut l’intégrer dans le pipeline GitLab CI. Cela se fait en ajoutant une nouvelle étape dans le fichier : gitlab-ci.yml.

Voici un exemple de code :

merge_request_text:
stage: generate
image: europe-west9-docker.pkg.dev/sandbox-mgoulin/generate-mr-text/generate-mr-text:latest 
script:
- |
python generate-mr-text.py -p $CI_PROJECT_ID -m $vCI_MERGE_REQUEST_IID

Fonctionnement du pipeline :

Lorsque vous ouvrez une merge-request, le pipeline GitLab CI s’exécute.
L’étape merge_request_text lance le script écrit à l’étape 2.
Le modèle génère un texte de merge-request, qui peut ensuite être utilisé pour créer la description de la merge-request.

Conclusion¶

Après la mise en place de ce job en pipeline nos Merge-Requests ont clairement changés. Voici un exemple pour illustrer la monté de version de nextcloud.

## Revue de la demande de fusion du module Terraform Nextcloud

**Objet des changements:**

Cette demande de fusion vise à mettre à niveau le module Terraform pour Nextcloud vers la version 28. Cela implique une série de modifications pour assurer la compatibilité et la stabilité du service Nextcloud.

**Ressources affectées:**

Les changements affectent principalement les ressources suivantes :

* **Dockerfile:** La base de l'image Docker est mise à jour vers PHP 8.2 et la version de Nextcloud est modifiée en 28.
* **Fichier htaccess:** Un nouveau fichier `.htaccess` est ajouté, contenant des directives de configuration spécifiques à Nextcloud, notamment la gestion des en-têtes de sécurité, des directives de cache pour les ressources statiques et des règles de réécriture d'URL pour le bon fonctionnement de Nextcloud. 
* **Fichier nextcloud.tf:** L'image Docker utilisée pour le conteneur Nextcloud est mise à jour pour refléter la nouvelle version.

**Principales modifications:**

* **Mise à niveau de la version de Nextcloud:** L'image Docker est mise à jour vers la version 28, incluant les dernières fonctionnalités et corrections de sécurité. 
* **Configuration du fichier `.htaccess`:** Un nouveau fichier `.htaccess` est ajouté pour garantir la configuration optimale de Nextcloud et l'application des meilleures pratiques de sécurité. 

**Implications en matière de sécurité et de performance:**

* **Sécurité:** La mise à jour de Nextcloud vers la version 28 inclut des correctifs de sécurité importants. La configuration du fichier `.htaccess` contribue également à améliorer la sécurité en appliquant des en-têtes de sécurité essentiels. 
* **Performance:** La nouvelle image Docker basée sur PHP 8.2 pourrait entraîner des améliorations de performance, en particulier pour les applications gourmandes en ressources.

**Risques et considérations:**

* **Compatibilité:** Il est important de tester minutieusement la mise à jour pour s'assurer que toutes les applications et les configurations existantes sont compatibles avec la version 28 de Nextcloud.
* **Configurations spécifiques:** Des configurations spécifiques ou des extensions personnalisées pourraient nécessiter des ajustements supplémentaires.
* **Intégration:** Assurez-vous que la mise à jour de Nextcloud n'impacte pas négativement d'autres services ou composants du système. 
* **Sauvegardes:** Il est crucial de créer des sauvegardes complètes de la base de données Nextcloud et des fichiers de données avant d'effectuer la mise à jour.

**Conclusion:**

Cette demande de fusion vise à améliorer la sécurité et la stabilité du service Nextcloud en effectuant une mise à niveau vers la version 28. Il est essentiel de procéder à des tests complets avant de la valider en production pour garantir une transition en douceur et minimiser les risques.

Avantages de l’automatisation:

Gain de temps: Plus besoin de rédiger manuellement les descriptions de merge-request.
Cohérence: Le texte généré est toujours cohérent et suit un format standard.
Précision: Le modèle Vertex AI peut identifier des informations importantes qui pourraient être oubliées.
Meilleure communication: Des descriptions claires et précises facilitent la communication entre les membres de l’équipe.

En utilisant Vertex AI et GitLab CI, vous pouvez automatiser la génération de texte de merge-request et améliorer votre workflow de développement. Ce gain de temps et d’efficacité vous permettra de vous concentrer sur des tâches plus stratégiques.

N’hésitez pas à tester cette solution et à l’adapter à vos besoins !

Generation of text from Merge-Requests automatically in LLM

2024-05-29T00:00:00+02:00

Add application sources with correct permissions for OpenShift
Install the dependencies
Run the dockerfile
Build the dockerfile
The command docker build -t generate-mr-text . will generate the docker image. Then, you can run the docker image and specify the project and the merge request id as follows:
The command docker build -t generate-mr-text . will generate the docker image. Then, you can run the docker image and specify the project and the merge request id as follows:
The command docker build -t generate-mr-text . will generate the docker image. Then, you can run the docker image and specify the project and the merge request id as follows:
The command docker build -t generate-mr-text . will generate the docker image. Then, you can run the docker image and specify the project and the merge request id as follows:
The command docker build -t generate-mr-text . will generate the docker image. Then, you can run the docker image and specify the project and the merge request id as follows:
The command docker build -t generate-mr-text . will generate the docker image. Then, you can run the docker image and specify the project and the merge request id as follows:
The command docker build -t generate-mr-text . will generate the docker image. Then, you can run the docker image and specify the project and the merge request id as follows:
The command docker build -t generate-mr-text . will generate the docker image. Then, you can run the docker image and specify the project and the merge request id as follows:
The command docker build -t generate-mr-text . will generate the docker image. Then, you can run the docker image and specify the project and the merge request id as follows:
The command docker build -t generate-mr-text . will generate the docker image. Then, you can run the docker image and specify the project and the merge request id as follows:
The command docker build -t generate-mr-text . will generate the docker image. Then, you can run the docker image and specify the project and the merge request id as follows:
The command docker build -t generate-mr-text . will generate the docker image. Then, you can run the docker image and specify the project and the merge request id as follows:
The command docker build -t generate-mr-text . will generate the docker image. Then, you can run the docker image and specify the project and the merge request id as follows:
The command docker build -t generate-mr-text . will generate the docker image. Then, you can run the docker image and specify the project and the merge request id as follows:
The command docker build -t generate-mr-text . will generate the docker image. Then, you can run the docker image and specify the project and the merge request id as follows:
The command docker build -t generate-mr-text . will generate the docker image. Then, you can run the docker image and specify the project and the merge request id as follows:
The command docker build -t generate-mr-text . will generate the docker image. Then, you can run the docker image and specify the project and the merge request id as follows:

Note: This is an example, the implementation of the application may not be completely accurate. The purpose is to show you the general approach and the code may need to be adjusted to your specific needs.

Foreword:

The following guide aims to provide a comprehensive understanding of the process and code for generating a descriptive text from a Merge-Request. The objective is to automate this task, relieving developers from the need to manually write lengthy descriptions.

Prerequisites:

Before embarking on this endeavor, ensure you have the following prerequisites:

A good understanding of the basic concept of merge-requests and its role in GitLab.
A working knowledge of Python.
A solid foundation in using GitLab’s API.

Context:

In the world of software development, merge-requests are crucial for integrating code changes into a main branch. However, composing comprehensive descriptions for each merge-request can be time-consuming and sometimes tedious.

Objective:

The objective is to create a Python script that automatically generates a descriptive text for each merge-request based on the changes included. This text can include:

A summary of the changes introduced.
A link to the relevant commit.
Any relevant context or background information.

Implementation:

The script utilizes the GitLab API to retrieve information about the merge-request and its associated commits. This information is then processed and formatted into a comprehensive description.

The Python code is presented below, along with explanations of each section.

import base64
import vertexai
from vertexai.generative_models import GenerativeModel, Part, FinishReason

from vertexai.preview.generative_models import generative_models as generative_models

import gitlab
import os, json
import argparse;

GCP_PROJECT_ID = os.getenv("GCP_PROJECT_ID", "sandbox-mgoulin")
GCP_LOCATION = os.getenv("GCP_LOCATION", "us-central1")
GCP_MODEL = os.getenv("GCP_MODEL", "gemin-1.5-flash-preview-0514")

GITLAB_HOST = os.getenv("GITLAB_HOST", "https://gitlab.com")
GITLAB_TOKEN = os.getenv("GITLAB_TOKEN", False)
GITLAB_SSL_VERIFY = os.getenv("GITLAB_SSL_VERIFY", False)

LLM_PROMPT = """As a senior Devops engineer reviewing a merge request for a Terraform module. Please provide a comprehensive description of the changes in french, focusing on the following:
* **What is the overall purpose of the changes?**
* **What specific resources are affected?**
* **What are the main changes made to those resources?**
* **Are there any security or performance implications of the changes?**
* **Are there any potential risks or considerations?**
"""

def generate(diff):
    vertexai.init(project=GCP_PROJECT_ID, location=GCP_LOCATION)
    model = GenerativeModel(
        GCP_MODEL,
    )
    responses = model.generate_content(
        [LLM_PROMPT, diff],
        generation_config=generation_config,
        safety_settings=safety_settings,
        stream=True,
    )

    resp = ""
    for response in responses:
        resp += response.text
    return resp

generation_config = {
    "max_output_tokens": 8192,
    "temperature": 1,
    "top_p": 0.95,
}

safety_settings = {
    generative_models.HarmCategory.HARM_CATEGORY_HATE_SPEECH: generative_models.HarmBlockThreshold.BLOCK_MEDIUM_AND_ABOVE,
    generative_models.HarmCategory.HARM_CATEGORY_DANGER_OR_VIOLENCE: generative_models.HarmBlockThreshold.BLOCK_MEDIUM_AND_ABOVE,
    generative_models.HarmCategory.HARM_CATEGORY_SEXUAL_CONTENT: generative_models.HarmBlockThreshold.BLOCK_MEDIUM_AND_ABOVE,
    generative_models.HarmCategory.HARM_CATEGORY_HARASSMENT: generative_models.HarmBlockThreshold.BLOCK_MEDIUM_AND_ABOVE,
}

def find_mr(project, mr_id):
    gl = gitlab.Gitlab(url=GITLAB_HOST, private_token=GITLAB_TOKEN, ssl_verify=GITLAB_SSL_VERIFY)
    proj = gl.projects.get(project)
    return proj.mergerequests.get(mr_id)

parser = argparse.ArgumentParser(
    prog='generate-mr-text.py',
    description='Use Gemini to update a merge request with a description',
)

parser.add_argument('-p', '--gitlab_project', required=True)
parser.add_argument('-m', '--gitlab_mr_id', required=True, type=int)

project = parser.parse_args().gitlab_project
mr_id = parser.parse_args().gitlab_mr_id
mr = find_mr(project, mr_id)
changes = mr.changes()
#print(json.dumps(changes, indent=4))
#diff = find_diff()
text = generate(json.dumps(changes, indent=4))
mr.description = mr.description.split("=== START BLOCK GENERATED BY generate-mr-text.py ===") [0] + "=== START BLOCK GENERATED BY generate-mr-text.py ===\n" + text + "\n=== END BLOCK GENERATED BY generate-mr-text.py ==="
mr.save()

In this script:

Import necessary modules
Get Environment variables: this step retrieves the necessary information for connecting to GitLab and Vertex AI
Define the prompt: This sets up the instructions for the language model.
Define the generate function: This function uses the Vertex AI client library to connect to the Gemini model and generate text based on the provided input.
Define the find_mr function: This function retrieves the Merge-Request from GitLab using the specified project and merge-request ID.
Define the argument parser: This section creates a user-friendly interface for passing project and merge-request ID as arguments.
Retrieve the Merge-Request: The script uses the argument parser to get the project and merge-request ID and retrieves the relevant Merge-Request from GitLab.
Generate the description: The changes are fetched, processed, and used to generate a description.
Update the Merge-Request: The generated description is then added to the merge-request description field in GitLab.

How to use the script:

Set up the environment variables: Replace the placeholders in the script with your actual values.
Install the required libraries: Ensure that you have installed all the necessary libraries using pip install -r requirements.txt.
Run the script: Execute the script using a command similar to python generate-mr-text.py -p <gitlab_project> -m <gitlab_mr_id>.

Next Steps:

This is just a basic example of what can be achieved with this approach. There are many other ways to enhance this script, such as:

Integrating the script into a CI/CD pipeline to automate the description generation process completely.
Customizing the prompt to generate more detailed descriptions.
Adding error handling to make the script more robust.

Conclusion:

By leveraging the power of the Vertex AI Gemini model, this script simplifies the process of generating descriptive text for merge-requests. This automation streamlines the development workflow and ensures that all merge-requests are well-documented.

Add application sources with correct permissions for OpenShift¶

USER 0 ADD . . RUN chown -R 1001:0 ./* USER 1001

Install the dependencies¶

RUN pip install -r requirements.txt && \ pip install -r requirements-dev.txt

Run the dockerfile¶

RUN pip install –upgrade pip && \ pip install -r requirements.txt && \ pip install -r requirements-dev.txt

Build the dockerfile¶

RUN pip install –upgrade pip && \ pip install -r requirements.txt && \ pip install -r requirements-dev.txt

**The command `docker build -t generate-mr-text .`  will generate the docker image. Then, you can run the docker image and specify the project and the merge request id as follows:**

```bash
docker run -it  generate-mr-text -p <gitlab_project> -m <gitlab_mr_id>

**The command docker run -it generate-mr-text -p <gitlab_project> -m <gitlab_mr_id> will run the container and generate a description for the specified merge-request. **

Note: You need to replace <gitlab_project> and <gitlab_mr_id> with your project and merge-request id.

The docker image will be built with the following steps:

ADD . .: Copy all files from the current directory to the Docker image.
RUN chown -R 1001:0 ./*: Change the ownership of all files in the image to user 1001.
USER 1001: Switch to user 1001.
RUN pip install -r requirements.txt && pip install -r requirements-dev.txt: Install the Python dependencies.
RUN pip install –upgrade pip && pip install -r requirements.txt && pip install -r requirements-dev.txt: Update pip and install the Python dependencies.

The docker image will be built and tagged with the name generate-mr-text. You can then run the container using the docker run command.

The command `docker build -t generate-mr-text .` will generate the docker image. Then, you can run the docker image and specify the project and the merge request id as follows:¶

docker run -it  generate-mr-text -p <gitlab_project> -m <gitlab_mr_id>

**The command docker run -it generate-mr-text -p <gitlab_project> -m <gitlab_mr_id> will run the container and generate a description for the specified merge-request. **

Note: You need to replace <gitlab_project> and <gitlab_mr_id> with your project and merge-request id.

The docker image will be built with the following steps:

ADD . .: Copy all files from the current directory to the Docker image.
RUN chown -R 1001:0 ./*: Change the ownership of all files in the image to user 1001.
USER 1001: Switch to user 1001.
RUN pip install -r requirements.txt && pip install -r requirements-dev.txt: Install the Python dependencies.
RUN pip install –upgrade pip && pip install -r requirements.txt && pip install -r requirements-dev.txt: Update pip and install the Python dependencies.

The docker image will be built and tagged with the name generate-mr-text. You can then run the container using the docker run command.

The command `docker build -t generate-mr-text .` will generate the docker image. Then, you can run the docker image and specify the project and the merge request id as follows:¶

docker run -it  generate-mr-text -p <gitlab_project> -m <gitlab_mr_id>

**The command docker run -it generate-mr-text -p <gitlab_project> -m <gitlab_mr_id> will run the container and generate a description for the specified merge-request. **

Note: You need to replace <gitlab_project> and <gitlab_mr_id> with your project and merge-request id.

The docker image will be built with the following steps:

ADD . .: Copy all files from the current directory to the Docker image.
RUN chown -R 1001:0 ./*: Change the ownership of all files in the image to user 1001.
USER 1001: Switch to user 1001.
RUN pip install -r requirements.txt && pip install -r requirements-dev.txt: Install the Python dependencies.
RUN pip install –upgrade pip && pip install -r requirements.txt && pip install -r requirements-dev.txt: Update pip and install the Python dependencies.

The docker image will be built and tagged with the name generate-mr-text. You can then run the container using the docker run command.

The command `docker build -t generate-mr-text .` will generate the docker image. Then, you can run the docker image and specify the project and the merge request id as follows:¶

docker run -it  generate-mr-text -p <gitlab_project> -m <gitlab_mr_id>

**The command docker run -it generate-mr-text -p <gitlab_project> -m <gitlab_mr_id> will run the container and generate a description for the specified merge-request. **

Note: You need to replace <gitlab_project> and <gitlab_mr_id> with your project and merge-request id.

The docker image will be built with the following steps:

ADD . .: Copy all files from the current directory to the Docker image.
RUN chown -R 1001:0 ./*: Change the ownership of all files in the image to user 1001.
USER 1001: Switch to user 1001.
RUN pip install -r requirements.txt && pip install -r requirements-dev.txt: Install the Python dependencies.
RUN pip install –upgrade pip && pip install -r requirements.txt && pip install -r requirements-dev.txt: Update pip and install the Python dependencies.

The docker image will be built and tagged with the name generate-mr-text. You can then run the container using the docker run command.

The command `docker build -t generate-mr-text .` will generate the docker image. Then, you can run the docker image and specify the project and the merge request id as follows:¶

docker run -it  generate-mr-text -p <gitlab_project> -m <gitlab_mr_id>

**The command docker run -it generate-mr-text -p <gitlab_project> -m <gitlab_mr_id> will run the container and generate a description for the specified merge-request. **

Note: You need to replace <gitlab_project> and <gitlab_mr_id> with your project and merge-request id.

The docker image will be built with the following steps:

ADD . .: Copy all files from the current directory to the Docker image.
RUN chown -R 1001:0 ./*: Change the ownership of all files in the image to user 1001.
USER 1001: Switch to user 1001.
RUN pip install -r requirements.txt && pip install -r requirements-dev.txt: Install the Python dependencies.
RUN pip install –upgrade pip && pip install -r requirements.txt && pip install -r requirements-dev.txt: Update pip and install the Python dependencies.

The docker image will be built and tagged with the name generate-mr-text. You can then run the container using the docker run command.

The command `docker build -t generate-mr-text .` will generate the docker image. Then, you can run the docker image and specify the project and the merge request id as follows:¶

docker run -it  generate-mr-text -p <gitlab_project> -m <gitlab_mr_id>

**The command docker run -it generate-mr-text -p <gitlab_project> -m <gitlab_mr_id> will run the container and generate a description for the specified merge-request. **

Note: You need to replace <gitlab_project> and <gitlab_mr_id> with your project and merge-request id.

The docker image will be built with the following steps:

ADD . .: Copy all files from the current directory to the Docker image.
RUN chown -R 1001:0 ./*: Change the ownership of all files in the image to user 1001.
USER 1001: Switch to user 1001.
RUN pip install -r requirements.txt && pip install -r requirements-dev.txt: Install the Python dependencies.
RUN pip install –upgrade pip && pip install -r requirements.txt && pip install -r requirements-dev.txt: Update pip and install the Python dependencies.

The docker image will be built and tagged with the name generate-mr-text. You can then run the container using the docker run command.

The command `docker build -t generate-mr-text .` will generate the docker image. Then, you can run the docker image and specify the project and the merge request id as follows:¶

docker run -it  generate-mr-text -p <gitlab_project> -m <gitlab_mr_id>

**The command docker run -it generate-mr-text -p <gitlab_project> -m <gitlab_mr_id> will run the container and generate a description for the specified merge-request. **

Note: You need to replace <gitlab_project> and <gitlab_mr_id> with your project and merge-request id.

The docker image will be built with the following steps:

ADD . .: Copy all files from the current directory to the Docker image.
RUN chown -R 1001:0 ./*: Change the ownership of all files in the image to user 1001.
USER 1001: Switch to user 1001.
RUN pip install -r requirements.txt && pip install -r requirements-dev.txt: Install the Python dependencies.
RUN pip install –upgrade pip && pip install -r requirements.txt && pip install -r requirements-dev.txt: Update pip and install the Python dependencies.

The docker image will be built and tagged with the name generate-mr-text. You can then run the container using the docker run command.

The command `docker build -t generate-mr-text .` will generate the docker image. Then, you can run the docker image and specify the project and the merge request id as follows:¶

docker run -it  generate-mr-text -p <gitlab_project> -m <gitlab_mr_id>

**The command docker run -it generate-mr-text -p <gitlab_project> -m <gitlab_mr_id> will run the container and generate a description for the specified merge-request. **

Note: You need to replace <gitlab_project> and <gitlab_mr_id> with your project and merge-request id.

The docker image will be built with the following steps:

ADD . .: Copy all files from the current directory to the Docker image.
RUN chown -R 1001:0 ./*: Change the ownership of all files in the image to user 1001.
USER 1001: Switch to user 1001.
RUN pip install -r requirements.txt && pip install -r requirements-dev.txt: Install the Python dependencies.
RUN pip install –upgrade pip && pip install -r requirements.txt && pip install -r requirements-dev.txt: Update pip and install the Python dependencies.

The docker image will be built and tagged with the name generate-mr-text. You can then run the container using the docker run command.

The command `docker build -t generate-mr-text .` will generate the docker image. Then, you can run the docker image and specify the project and the merge request id as follows:¶

docker run -it  generate-mr-text -p <gitlab_project> -m <gitlab_mr_id>

**The command docker run -it generate-mr-text -p <gitlab_project> -m <gitlab_mr_id> will run the container and generate a description for the specified merge-request. **

Note: You need to replace <gitlab_project> and <gitlab_mr_id> with your project and merge-request id.

The docker image will be built with the following steps:

ADD . .: Copy all files from the current directory to the Docker image.
RUN chown -R 1001:0 ./*: Change the ownership of all files in the image to user 1001.
USER 1001: Switch to user 1001.
RUN pip install -r requirements.txt && pip install -r requirements-dev.txt: Install the Python dependencies.
RUN pip install –upgrade pip && pip install -r requirements.txt && pip install -r requirements-dev.txt: Update pip and install the Python dependencies.

The docker image will be built and tagged with the name generate-mr-text. You can then run the container using the docker run command.

The command `docker build -t generate-mr-text .` will generate the docker image. Then, you can run the docker image and specify the project and the merge request id as follows:¶

docker run -it  generate-mr-text -p <gitlab_project> -m <gitlab_mr_id>

**The command docker run -it generate-mr-text -p <gitlab_project> -m <gitlab_mr_id> will run the container and generate a description for the specified merge-request. **

Note: You need to replace <gitlab_project> and <gitlab_mr_id> with your project and merge-request id.

The docker image will be built with the following steps:

ADD . .: Copy all files from the current directory to the Docker image.
RUN chown -R 1001:0 ./*: Change the ownership of all files in the image to user 1001.
USER 1001: Switch to user 1001.
RUN pip install -r requirements.txt && pip install -r requirements-dev.txt: Install the Python dependencies.
RUN pip install –upgrade pip && pip install -r requirements.txt && pip install -r requirements-dev.txt: Update pip and install the Python dependencies.

The docker image will be built and tagged with the name generate-mr-text. You can then run the container using the docker run command.

The command `docker build -t generate-mr-text .` will generate the docker image. Then, you can run the docker image and specify the project and the merge request id as follows:¶

docker run -it  generate-mr-text -p <gitlab_project> -m <gitlab_mr_id>

**The command docker run -it generate-mr-text -p <gitlab_project> -m <gitlab_mr_id> will run the container and generate a description for the specified merge-request. **

Note: You need to replace <gitlab_project> and <gitlab_mr_id> with your project and merge-request id.

The docker image will be built with the following steps:

ADD . .: Copy all files from the current directory to the Docker image.
RUN chown -R 1001:0 ./*: Change the ownership of all files in the image to user 1001.
USER 1001: Switch to user 1001.
RUN pip install -r requirements.txt && pip install -r requirements-dev.txt: Install the Python dependencies.
RUN pip install –upgrade pip && pip install -r requirements.txt && pip install -r requirements-dev.txt: Update pip and install the Python dependencies.

The docker image will be built and tagged with the name generate-mr-text. You can then run the container using the docker run command.

The command `docker build -t generate-mr-text .` will generate the docker image. Then, you can run the docker image and specify the project and the merge request id as follows:¶

docker run -it  generate-mr-text -p <gitlab_project> -m <gitlab_mr_id>

**The command docker run -it generate-mr-text -p <gitlab_project> -m <gitlab_mr_id> will run the container and generate a description for the specified merge-request. **

Note: You need to replace <gitlab_project> and <gitlab_mr_id> with your project and merge-request id.

The docker image will be built with the following steps:

ADD . .: Copy all files from the current directory to the Docker image.
RUN chown -R 1001:0 ./*: Change the ownership of all files in the image to user 1001.
USER 1001: Switch to user 1001.
RUN pip install -r requirements.txt && pip install -r requirements-dev.txt: Install the Python dependencies.
RUN pip install –upgrade pip && pip install -r requirements.txt && pip install -r requirements-dev.txt: Update pip and install the Python dependencies.

The docker image will be built and tagged with the name generate-mr-text. You can then run the container using the docker run command.

The command `docker build -t generate-mr-text .` will generate the docker image. Then, you can run the docker image and specify the project and the merge request id as follows:¶

docker run -it  generate-mr-text -p <gitlab_project> -m <gitlab_mr_id>

**The command docker run -it generate-mr-text -p <gitlab_project> -m <gitlab_mr_id> will run the container and generate a description for the specified merge-request. **

Note: You need to replace <gitlab_project> and <gitlab_mr_id> with your project and merge-request id.

The docker image will be built with the following steps:

ADD . .: Copy all files from the current directory to the Docker image.
RUN chown -R 1001:0 ./*: Change the ownership of all files in the image to user 1001.
USER 1001: Switch to user 1001.
RUN pip install -r requirements.txt && pip install -r requirements-dev.txt: Install the Python dependencies.
RUN pip install –upgrade pip && pip install -r requirements.txt && pip install -r requirements-dev.txt: Update pip and install the Python dependencies.

The docker image will be built and tagged with the name generate-mr-text. You can then run the container using the docker run command.

The command `docker build -t generate-mr-text .` will generate the docker image. Then, you can run the docker image and specify the project and the merge request id as follows:¶

docker run -it  generate-mr-text -p <gitlab_project> -m <gitlab_mr_id>

**The command docker run -it generate-mr-text -p <gitlab_project> -m <gitlab_mr_id> will run the container and generate a description for the specified merge-request. **

Note: You need to replace <gitlab_project> and <gitlab_mr_id> with your project and merge-request id.

The docker image will be built with the following steps:

ADD . .: Copy all files from the current directory to the Docker image.
RUN chown -R 1001:0 ./*: Change the ownership of all files in the image to user 1001.
USER 1001: Switch to user 1001.
RUN pip install -r requirements.txt && pip install -r requirements-dev.txt: Install the Python dependencies.
RUN pip install –upgrade pip && pip install -r requirements.txt && pip install -r requirements-dev.txt: Update pip and install the Python dependencies.

The docker image will be built and tagged with the name generate-mr-text. You can then run the container using the docker run command.

The command `docker build -t generate-mr-text .` will generate the docker image. Then, you can run the docker image and specify the project and the merge request id as follows:¶

docker run -it  generate-mr-text -p <gitlab_project> -m <gitlab_mr_id>

**The command docker run -it generate-mr-text -p <gitlab_project> -m <gitlab_mr_id> will run the container and generate a description for the specified merge-request. **

Note: You need to replace <gitlab_project> and <gitlab_mr_id> with your project and merge-request id.

The docker image will be built with the following steps:

ADD . .: Copy all files from the current directory to the Docker image.
RUN chown -R 1001:0 ./*: Change the ownership of all files in the image to user 1001.
USER 1001: Switch to user 1001.
RUN pip install -r requirements.txt && pip install -r requirements-dev.txt: Install the Python dependencies.
RUN pip install –upgrade pip && pip install -r requirements.txt && pip install -r requirements-dev.txt: Update pip and install the Python dependencies.

The docker image will be built and tagged with the name generate-mr-text. You can then run the container using the docker run command.

The command `docker build -t generate-mr-text .` will generate the docker image. Then, you can run the docker image and specify the project and the merge request id as follows:¶

docker run -it  generate-mr-text -p <gitlab_project> -m <gitlab_mr_id>

**The command docker run -it generate-mr-text -p <gitlab_project> -m <gitlab_mr_id> will run the container and generate a description for the specified merge-request. **

Note: You need to replace <gitlab_project> and <gitlab_mr_id> with your project and merge-request id.

The docker image will be built with the following steps:

ADD . .: Copy all files from the current directory to the Docker image.
RUN chown -R 1001:0 ./*: Change the ownership of all files in the image to user 1001.
USER 1001: Switch to user 1001.
RUN pip install -r requirements.txt && pip install -r requirements-dev.txt: Install the Python dependencies.
RUN pip install –upgrade pip && pip install -r requirements.txt && pip install -r requirements-dev.txt: Update pip and install the Python dependencies.

The docker image will be built and tagged with the name generate-mr-text. You can then run the container using the docker run command.

The command `docker build -t generate-mr-text .` will generate the docker image. Then, you can run the docker image and specify the project and the merge request id as follows:¶

docker run -it  generate-mr-text -p <gitlab_project> -m <gitlab_mr_id>

**The command docker run -it generate-mr-text -p <gitlab_project> -m <gitlab_mr_id> will run the container and generate a description for the specified merge-request. **

Note: You need to replace <gitlab_project> and <gitlab_mr_id> with your project and merge-request id.

The docker image will be built with the following steps:

ADD . .: Copy all files from the current directory to the Docker image.
RUN chown -R 1001:0 ./*: Change the ownership of all files in the image to user 1001.
USER 1001: Switch to user 1001.
RUN pip install -r requirements.txt && pip install -r requirements-dev.txt: Install the Python dependencies.
RUN pip install –upgrade pip && pip install -r requirements.txt && pip install -r requirements-dev.txt: Update pip and install the Python dependencies.

The docker image will be built and tagged with the name generate-mr-text. You can then run the container using the docker run command.

The command `docker build -t generate-mr-text .` will generate the docker image. Then, you can run the docker image and specify the project and the merge request id as follows:¶

docker run -it  generate-mr-text -p <gitlab_project> -m <gitlab_mr_id>

**The command docker run -it generate-mr-text -p <gitlab_project> -m <gitlab_mr_id> will run the container and generate a description for the specified merge-request. **

Note: You need to replace <gitlab_project> and <gitlab_mr_id> with your project and merge-request id.

The docker image will be built with the following steps:

ADD . .: Copy all files from the current directory to the Docker image.
RUN chown -R 1001:0 ./*: Change the ownership of all files in the image to user 1001.
USER 1001: Switch to user 1001.
RUN pip install -r requirements.txt && pip install -r requirements-dev.txt: Install the Python dependencies.
RUN pip install –upgrade pip && pip install -r requirements.txt && pip install -r requirements-dev.txt: Update pip and install the Python dependencies.

The docker image will be built and tagged with the name generate-mr-text. You can then run the container using the docker run command.

¶

Initialisation d'un blog avec Pelican sur GitLab Pages!

2024-05-28T00:00:00+02:00

Introduction
Un blog as Code
Création du dépôt Git
- Les fichiers
- Ajout d’un themes
Ajout de domaines pour les pages
Contribuer

Introduction¶

Un des défis quand on cherche à partager du contenu, c’est de le faire simplement et avec efficience.

Je suis à la recherche d’un moyen d’écrire des articles autour du Devops et de publier ces articles sur un blog. L’idée est simplement de décrire comment on pratique l’installation d’applications et l’automatisation des tâches dans une DSI.

J’ai donc essayé diverses méthodes pour créer un blog :

Blogger de Google en SaaS, mais la mise en forme du code et du texte n’est pas simple
Wordpress dans des containers, mais il y a beaucoup de paramètres à configurer avant l’utilisation.
Et enfin Pelican sur GitLab Pages, a découvrir

Voici un petit exemple de ce que ça peut donner sur blogger. Mais j’ai eu beaucoup de mal à réaliser la mise en forme :

Dans cet article, je vous propose de décrire l’installation de Pelican et l’utilisation pour développer.

Un blog as Code¶

Gérer le contenu de mon blog comme du code permettra de fusionner la puissance d’un gestionnaire de version comme Git (et les pipelines qui compileront le contenu) avec l’efficience d’un site web statique (html).

Workflow efficace : Git permet de gérer les modifications du contenu du blog et de les partager avec d’autres contributeurs, tandis que Pelican génère automatiquement les pages web statiques à partir du contenu.
Développement agile : Les branches Git permettent de tester de nouvelles fonctionnalités ou de corriger des bugs sans affecter le contenu principal du blog.
Hébergement flexible : Git permet d’héberger le blog sur des plateformes comme Gitlab Pages, tandis que Pelican génère des pages web statiques compatibles avec ces plateformes.

Création du dépôt Git¶

Gitlab propose des modèles de projet déjà prévu pour Pelican. Il suffit de créer un nouveau projet Gitlab et de sélectionner le modèle : Pages/Pelican.

Ce template va initialiser le dépôt git et tout le code nécessaire pour utiliser Pelican.

Cette action a créé l’arborescence du dépôt comme décrite ci-dessous, il faudra maintenant cloner sur la station de travail le code pour l’éditer en local.

git clone https://gitlab.com/<USERNAME>/<REPO_NAME>.git

Les fichiers¶

Voici un petit descritifs des fichiers initialisés :

/
- content/       # Fichier de contenu du site web: articles markdown, images, ...
- pelicanconf.py # Fichier de configuration de pelican
...

Sous gitlab voici ce que ca donne :

Ajout d’un themes¶

Après quelques recherches, j’ai choisi d’utiliser le thème pelican-hyde suffisamment épuré et élégant pour mon besoin.

Pour l’installer, on télécharge le thème, on l’ajoute au dépôt git :

curl -L -O https://github.com/jvanz/pelican-hyde/archive/refs/heads/master.zip
unzip master.zip
git add pelican-hyde-master
rm -r master.zip
echo "THEME = 'themes-hyde'" >> pelicanconf.py
git add pelicanconf.py


git commit -m "Add pelican-hyde-master themes"
git push origin master:feat/add-pelican-hyde-master

On ira ensuite sur Git pour créer la merge-request et la merger sur la branche master

Ajout de domaines pour les pages¶

On peut ajouter dans gitlab-pages des mapping de domaines. Cela permet de servir nos pages statiques sur nos domaines sans utiliser une URL trop compliqué.

De mon côté, j’ai configuré le domaine comme ci-dessous :

Contribuer¶

Et voilà, il suffit maintenant de rédiger des articles au format markdown et de les pousser dans Git. On peut très bien utiliser les relectures et contributions (PullRequest) pour bénéficier de toute la puissance de Git.

Initialization of a Blog Using Pelican and GitLab Pages!

2024-05-28T00:00:00+02:00

Introduction
Using code
Contribution to the GitLab Git
List of features
Add Content to Git
Theming
Adding themes
Adding features
Automation
Adding domains
Adding custom content
Conclusion

Introduction¶

We will see in this quick guide how to create a blog using Pelican, which will be hosted on GitLab Pages, offering free hosting and a simple way to deploy a static site.

First, we will need to choose a place to store the blog:

Blogger from Google is free, with a simple interface, and easy to use. You will be able to store content in the form of text and code.
Wordpress offers more options for content creators. This option is also very easy to configure. It is free for personal use.
And finally, Pelican for GitLab Pages, a more advanced option.

We will opt for Pelican for GitLab Pages, a more comprehensive solution.

Using code¶

Let’s start by creating the blog, we will need to install Pelican and create a blog using it.

pip install pelican
pelican-quickstart

This will ask you several questions, like the title, author, description, etc. We will answer them to customize the initial blog setup.

Once this is done, we will be able to generate the site using Pelican:

make html

This will generate the HTML files of the blog in the output folder.

Contribution to the GitLab Git¶

GitLab Pages lets you host a static site from a repository. To do this, we will need to create a GitLab repository and upload the content.

The easiest way is to add the output folder as a new branch of the repository.

git init
git add .
git commit -m "Initial commit"
git branch -M main
git remote add origin git@gitlab.com:<USERNAME>/<REPO_NAME>.git
git push -u origin main

You can then go to the GitLab repository and configure GitLab Pages. It will automatically detect the presence of the index.html file and serve your website.

List of features¶

We will find different features in Pelican:

- content/            # The directory where your content lives
- pelicanconf.py        # Configuration file for Pelican
- publishconf.py      # Configuration file for Pelican (publication settings)
- makefile             # Makefile for generating output
- themes/             # Directory for themes
- output/             # Directory for the output HTML
- content/             # The directory where your content lives

The most important files are:

pelicanconf.py for configuring the blog’s settings, including the theme, title, author, and more.
publishconf.py for configuring the blog’s settings for publication on GitLab Pages.

Add Content to Git¶

GitLab Pages allows you to easily host a static site from a repository. You can use any branch in your repository to host a site. For example, the content of the main branch is used for the https://<USERNAME>.gitlab.io/<REPO_NAME> URL. If you want to create a site on the gh-pages branch, its content will be used for the https://<USERNAME>.gitlab.io/<REPO_NAME>/gh-pages URL.

Theming¶

Pelican is an easy way to host a static site on GitLab Pages. It’s a popular solution for a variety of blog configurations, but it’s not limited to these. You can even install a new theme:

pelican-themes

This command will list all available themes. To use one of them, you simply need to copy the theme folder to the themes directory and modify the pelicanconf.py file to point to the theme.

Adding themes¶

Once you’ve set up the basic Pelican configuration, you can start adding content to your blog. This content is stored in the content/ directory in Markdown files. For example, you can create a new file named content/posts/my-first-post.md.

The structure of the file is quite simple, it just includes the post’s title and the content, which can be formatted using Markdown. You can use this structure for all of your posts.

Adding features¶

You can add many features to your blog, such as:

Comments: You can use a comment system like Disqus to add comments to your blog posts.
Analytics: You can use Google Analytics to track traffic to your blog.
Social media: You can add social media buttons to your blog to allow readers to share your content.

Once you have added all the features you need, you can generate the site and deploy it to GitLab Pages.

Automation¶

It can be repetitive to generate and deploy the site. This can be done automatically with make. There are many automation solutions to do this, like Github actions or Gitlab CI/CD.

Adding domains¶

You can use a custom domain name to host your blog. This can be done by modifying the GitLab Pages settings.

Adding custom content¶

You can add custom content to your blog, such as a portfolio section, a contact page, or an about page. Pelican makes it easy to create new pages.

Conclusion¶

Pelican is a powerful tool for creating static blogs. GitLab Pages provides a simple and free way to host them. By combining these two tools, you can create a beautiful and functional blog in a few hours. You can easily customize it using themes and features.