[ Expérience DevOps ]

Concevez des pipelines bare metal prédictibles

Utilisez Bullionet comme couche d'exécution infra pour vos flux GitOps et CI/CD, du provisioning au rollout.

Retour à la plateforme développeur Utiliser bulli CLI

Workflow CI prêt à copier

bulli init
source <(bulli env --output sh)
terraform plan -var-file=prod-fr1.tfvars
terraform apply -auto-approve -var-file=prod-fr1.tfvars
bulli server list --output json

[ Pipeline réel ]

Montez un pipeline infra prêt pour la production en moins d'une heure

Partez d'une base concrète: arborescence repo, workflow CI, et vérifications post-déploiement.

Structurer le repo infra

Séparez les modules réutilisables et les environnements de production dans des dossiers dédiés.

Déclarer secrets et environnement CI

Ajoutez BULLI_TOKEN et les variables Terraform dans la CI, puis protégez la prod avec approbation.

Séparer plan et apply

Exécutez le plan sur pull request, puis appliquez uniquement sur main après revue.

Automatiser les checks post-déploiement

Exécutez un script de vérification pour valider inventaire, état des hôtes et santé du rollout.

Variables et garde-fous recommandés

•Secret CI: BULLI_TOKEN scopé uniquement sur les actions de provisioning.

•Environnement protégé: approbation production obligatoire avant apply.

•Script de vérification post-déploiement obligatoire avant statut vert.

Arborescence minimale

infra/
  modules/
    server-group/
      main.tf
      variables.tf
  envs/
    prod-fr/
      main.tf
      prod-fr1.tfvars
scripts/
  verify.sh
.github/
  workflows/
    infra-prod.yml

Workflow CI prêt à copier

name: infra-prod
on:
  pull_request:
    paths: ["infra/**"]
  push:
    branches: [main]
    paths: ["infra/**"]
  workflow_dispatch:

jobs:
  plan:
    runs-on: ubuntu-latest
    env:
      BULLI_TOKEN: $BULLI_TOKEN
    steps:
      - uses: actions/checkout@v4
      - uses: hashicorp/setup-terraform@v3
      - run: bulli init --token "$BULLI_TOKEN"
      - run: terraform -chdir=infra/envs/prod-fr init
      - run: terraform -chdir=infra/envs/prod-fr plan -out=tfplan -var-file=prod-fr1.tfvars

  apply:
    if: github.ref == 'refs/heads/main'
    needs: plan
    runs-on: ubuntu-latest
    environment: production
    env:
      BULLI_TOKEN: $BULLI_TOKEN
    steps:
      - uses: actions/checkout@v4
      - uses: hashicorp/setup-terraform@v3
      - run: bulli init --token "$BULLI_TOKEN"
      - run: terraform -chdir=infra/envs/prod-fr apply -auto-approve -var-file=prod-fr1.tfvars
      - run: ./scripts/verify.sh

Script de vérification post-déploiement

#!/usr/bin/env bash
set -euo pipefail

bulli server list --output json | jq '.[] | {hostname,status,location}'
bulli server get --hostname api-fr1-01
bulli server get --hostname api-fr1-02
bulli server get --hostname api-fr1-03

[ Modèle Git-friendly ]

Un seul flux Git du changement infra jusqu'au rollout production

Traitez l'infrastructure comme du code produit: branche, pull request, plan automatisé, validation humaine et apply protégé.

Exemple de workflow concret

# 1) Create branch for infra change
git checkout -b infra/prod-api-green-rollout

# 2) Update environment variables and rollout target
$EDITOR infra/envs/prod-fr/prod-fr1.tfvars
git add infra/envs/prod-fr/prod-fr1.tfvars
git commit -m "infra(prod-fr): add green API nodes for release 2026-02"
git push -u origin infra/prod-api-green-rollout

# 3) Open PR -> CI runs terraform plan (no production apply)
# 4) Review plan output + approve PR
# 5) Merge to main -> protected apply job starts with production approval

# 6) Post-deploy verification
./scripts/verify.sh

Livrer plus vite sans boucle ticket

Les équipes déploient les changements infra via pull requests, sans attendre des handoffs fragmentés.

Réduire le risque en production

Le plan est exécuté avant merge, l'apply est protégé, et les cibles rollback restent explicites à chaque étape.

Opérations auditables

Chaque changement garde sa branche, son commit, sa review et sa trace d'exécution pour conformité et post-mortem.

[ Procédures DevOps simples ]

Trois procédures pratiques que l'équipe peut lancer cette semaine

Chaque procédure garde un périmètre réduit, une validation explicite et un rollback possible.

Livrer un changement API en blue/green

Vous devez déployer une release API sans exposer immédiatement la prod.

•Provisionnez les nœuds green avec tags de release dans la même zone que les nœuds blue.

•Exécutez les checks santé (boot, SSH, endpoint applicatif) et relisez les résultats CI.

•Validez le cutover uniquement si les checks passent et que la cible de rollback reste disponible.

Résultat attendu: release déployée avec bascule contrôlée et rollback clair.

Remédier à un worker dégradé

Un worker est instable et doit être remplacé rapidement sans improvisation.

•Lisez les métadonnées du nœud source (plan, localisation, tags) et préparez le profil de remplacement.

•Provisionnez le remplaçant et validez sa readiness avant bascule trafic.

•Drainez l'ancien nœud, basculez le trafic, puis consignez le résumé d'incident.

Résultat attendu: nœud dégradé remplacé avec interruption de service minimale.

Planifier la capacité batch en semaine

Vous avez besoin de capacité batch en heures ouvrées avec un coût prévisible.

•Ciblez uniquement les nœuds taggés pour le planning semaine dans le scope autorisé.

•Appliquez power-on au début et power-off en fin de créneau avec checks d'état.

•Revoyez chaque jour les deltas capacité/coût et signalez les anomalies pour revue humaine.

Résultat attendu: disponibilité batch prévisible et dépense maîtrisée.

[ Blocs workflow ]

Tout ce qu'il faut pour les équipes delivery

Construisez des environnements reproductibles et déployez avec confiance sur tout le cycle de vie infra.

Provisioning compatible Terraform

Créez et modifiez l'infrastructure en déclaratif pour des environnements reproductibles.

Modèle opérationnel orienté Git

Promouvez les changements avec des étapes explicites et auditables.

Surface de commande scriptable

Intégrez les actions cycle de vie dans vos pipelines avec sorties machine-readables.

Cadence de rollout contrôlée

Appliquez des logiques de déploiement progressif et gardez la prod prévisible.

[ Kit de commandes ]

Commandes concrètes pour CI/CD et rollout

Utilisez ces commandes comme briques de base pour vos pipelines et changements contrôlés.

bulli init

Initialiser le contexte d'exécution

Préparez le contexte CLI avant les actions pipeline.

source <(bulli env --output sh)

Injecter les variables d'environnement

Chargez auth et contexte projet pour les jobs d'automatisation.

bulli server list --output json

Valider l'inventaire

Listez les serveurs et exploitez la sortie JSON dans vos checks CI.

bulli server reboot --hostname edge-worker-03

Reboot planifié

Déclenchez un redémarrage maîtrisé en fenêtre de rollout.

bulli server reinstall --hostname edge-worker-03 --os ubuntu-24.04

Réinstallation en récupération

Reconstruisez rapidement un nœud depuis une base OS propre.

[ Pattern pipeline ]

Provisionner, appliquer, vérifier, publier

Un enchaînement simple et robuste aligné avec l'opérationnel DevOps quotidien.

Exemple de pipeline infrastructure

# prod-fr1.tfvars
# plan = \"bm.performance\"
# location = \"paris\"
# hostname_prefix = \"api-fr1\"

terraform plan -var-file=prod-fr1.tfvars
terraform apply -auto-approve -var-file=prod-fr1.tfvars
bulli server list --output json
bulli server get --hostname api-fr1-01

[ Couche de sûreté ]

Opérer vite sans perdre le contrôle

Combinez accès scopés et checks opérationnels pour une automatisation sûre à grande échelle.

Accès d'automatisation scopés

Limitez les permissions des tokens selon l'environnement et l'usage.

Actions de rollout traçables

Gardez un historique auditable des changements de déploiement et d'exploitation.

Garde-fous pour IA et scripts

Automatisez agressivement tout en conservant des frontières opérationnelles nettes.