[ DevOps Experience ]

Planbare Bare-Metal-Delivery-Pipelines aufbauen

Nutzen Sie Bullionet als Infrastruktur-Ausführungsebene für GitOps- und CI/CD-Flows, von Provisioning bis Rollout-Policy.

Zur Entwicklerplattform bulli CLI nutzen

Copy-ready CI-Workflow

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

[ Reale Pipeline ]

Eine produktionsreife Infra-Pipeline in unter einer Stunde aufsetzen

Starten Sie mit einer praktischen Basis: Repo-Struktur, CI-Workflow und Post-Deploy-Verifikation.

Infra-Repository strukturieren

Wiederverwendbare Module und Produktionsumgebungen in getrennten Verzeichnissen organisieren.

CI-Secrets und Umgebung definieren

BULLI_TOKEN und Terraform-Variablen in CI hinterlegen und Produktion mit Approval schützen.

Plan und Apply trennen

Plan auf Pull Requests ausführen, Apply nur auf main nach Review.

Post-Deploy-Checks automatisieren

Ein Verifikationsskript ausführen, um Inventar, Host-Status und Rollout-Gesundheit zu prüfen.

Empfohlene Variablen und Guardrails

•CI-Secret: BULLI_TOKEN nur für Provisioning-Aktionen freigeben.

•Geschützte Umgebung: Produktions-Approval vor Apply erzwingen.

•Post-Deploy-Verifikation vor grünem Pipeline-Status verpflichtend.

Minimale Repository-Struktur

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

Copy-ready CI-Workflow

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

Post-Deploy-Verifikationsskript

#!/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

[ Git-freundliches Modell ]

Ein Git-Flow vom Infra-Change bis zum Produktions-Rollout

Infrastruktur wie Produktcode behandeln: Branch, Pull Request, automatischer Plan, menschliche Freigabe und geschütztes Apply.

Konkretes Workflow-Beispiel

# 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

Schneller liefern ohne Ticket-Schleifen

Teams liefern Infrastrukturänderungen über Pull Requests statt über langsame, fragmentierte Übergaben.

Geringeres Produktionsrisiko

Plan läuft vor dem Merge, Apply ist geschützt, und Rollback-Ziele bleiben in jedem Schritt klar.

Audit-fähiger Betrieb

Jede Änderung hat Branch, Commit, Review und Ausführungsspur für Compliance und Incident-Nachbereitung.

[ Einfache DevOps-Verfahren ]

Drei praktische Verfahren für diese Woche

Jedes Verfahren hält den Scope klein, die Validierung klar und den Rollback möglich.

API-Release per Blue/green ausrollen

Ein API-Release soll ohne direktes Produktionsrisiko bereitgestellt werden.

•Green-Nodes mit Release-Tags im gleichen Standort wie Blue bereitstellen.

•Health-Checks (Boot, SSH, App-Endpoint) ausführen und CI-Ergebnisse prüfen.

•Cutover nur freigeben, wenn alle Checks bestehen und Rollback verfügbar bleibt.

Erwartetes Ergebnis: kontrollierter Release mit sauberem Rollback-Pfad.

Degradierten Worker ersetzen

Ein Worker ist instabil und muss schnell ohne Improvisation ersetzt werden.

•Metadaten der Quell-Node lesen (Plan, Standort, Tags) und Ersatzprofil vorbereiten.

•Ersatz-Node provisionieren und Readiness vor Traffic-Wechsel bestätigen.

•Alte Node drainen, Traffic wechseln und Incident-Zusammenfassung dokumentieren.

Erwartetes Ergebnis: instabile Node ersetzt bei minimaler Service-Störung.

Batch-Kapazität werktags planen

Batch-Kapazität wird nur zu Bürozeiten benötigt und soll kalkulierbar bleiben.

•Nur Nodes mit passenden Weekday-Tags im erlaubten Scope adressieren.

•Power-on/Power-off nach Zeitplan mit Status-Checks ausführen.

•Tägliche Kapazitäts- und Kostendeltas prüfen, Anomalien für Review markieren.

Erwartetes Ergebnis: planbare Batch-Verfügbarkeit bei kontrollierten Kosten.

[ Workflow-Bausteine ]

Alles für Delivery-Teams

Reproduzierbare Umgebungen erstellen und Änderungen über den gesamten Infrastruktur-Lifecycle kontrolliert ausliefern.

Terraform-kompatibles Provisioning

Infrastruktur deklarativ erstellen und verändern für reproduzierbare Umgebungen.

Git-freundliches Betriebsmodell

Änderungen mit expliziten, auditierbaren Workflow-Schritten durch Umgebungen führen.

Skriptfähige Kommandooberfläche

Lifecycle-Aktionen mit maschinenlesbarer Ausgabe in Pipelines integrieren.

Kontrollierte Rollout-Kadenz

Progressive Deployment-Logik anwenden und Produktion berechenbar halten.

[ Command-Kit ]

Konkrete Befehle für CI/CD und Rollout

Diese Befehle dienen als Bausteine für kontrollierte Deployments und Änderungen.

bulli init

Ausführungskontext initialisieren

CLI-Kontext vor Pipeline-Aktionen setzen.

source <(bulli env --output sh)

Umgebungsvariablen injizieren

Auth- und Projektkontext für Automationsjobs laden.

bulli server list --output json

Inventarzustand validieren

Serverliste als JSON in CI-Checks auswerten.

bulli server reboot --hostname edge-worker-03

Geplanten Reboot ausführen

Neustart kontrolliert im Rollout-Fenster triggern.

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

Recovery-Reinstall

Node schnell von sauberer OS-Basis neu aufbauen.

[ Pipeline-Pattern ]

Provisionieren, anwenden, verifizieren, releasen

Eine einfache und robuste Sequenz für den täglichen DevOps-Betrieb.

Beispiel Infrastruktur-Pipeline

# 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

[ Sicherheitslage ]

Schnell arbeiten, Kontrolle behalten

Scoped Access und operative Checks sorgen für sichere Automatisierung im großen Maßstab.

Scoped Automation Access

Token-Rechte nach Umgebung und Zweck begrenzen.

Nachvollziehbare Rollout-Aktionen

Deployment- und Betriebsänderungen auditierbar halten.

Guardrails für KI und Skripte

Stark automatisieren und trotzdem klare operative Grenzen bewahren.