[ DevOps Experience ]

Стройте предсказуемые bare metal delivery pipelines

Используйте Bullionet как execution layer для GitOps и CI/CD flows, от provisioning до rollout policy.

Назад к платформе разработчика Использовать bulli CLI

CI workflow (copy/paste)

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 ]

Соберите production-ready infra pipeline меньше чем за час

Используйте практичную базу: структура репозитория, CI workflow и post-deploy проверки.

Структурируйте infra-репозиторий

Разделите переиспользуемые модули и production-окружения по отдельным директориям.

Настройте CI secrets и окружение

Добавьте BULLI_TOKEN и Terraform variables в CI, а production защитите approval-шагом.

Разделите plan и apply

Запускайте plan на pull request, а apply только на main после ревью.

Автоматизируйте post-deploy checks

Запускайте verify-скрипт для проверки inventory, статуса хостов и здоровья rollout.

Рекомендуемые переменные и guardrails

•CI secret: BULLI_TOKEN только с правами на provisioning-действия.

•Protected environment: обязательный production approval перед apply.

•Обязательная post-deploy проверка перед green-статусом pipeline.

Минимальная структура репозитория

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

CI workflow (copy/paste)

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 проверки

#!/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-friendly модель ]

Единый Git-поток от infra-изменения до production rollout

Работайте с инфраструктурой как с продуктовым кодом: branch, pull request, автоматический plan, human approval и защищённый apply.

Конкретный пример workflow

# 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

Быстрее поставка без ticket-циклов

Команды доставляют infra-изменения через pull requests, а не через медленные и фрагментированные handoff.

Ниже риск в production

Plan выполняется до merge, apply защищён, а rollback-цели остаются явными на каждом этапе rollout.

Audit-ready операции

У каждого изменения есть branch, commit, review и execution trace для compliance и post-incident анализа.

[ Простые DevOps-процедуры ]

Три практичных процедуры, которые можно внедрить на этой неделе

В каждой процедуре: небольшой scope, явная валидация и рабочий rollback.

Выпустить API-изменение через blue/green

Нужно выкатить API-релиз без мгновенного риска для production.

•Поднимите green-ноды с release tags в той же локации, что и текущие blue-ноды.

•Прогоните health checks (boot, SSH, app endpoint) и проверьте результаты в CI.

•Подтверждайте cutover только после успешных checks и доступного rollback.

Ожидаемый результат: контролируемый релиз с прозрачным rollback-путём.

Заменить деградировавший worker

Одна worker-нода нестабильна и требует быстрой замены без импровизации.

•Считайте метаданные source-ноды (plan, location, tags) и подготовьте профиль replacement.

•Provision replacement-ноды и подтвердите readiness до переключения трафика.

•Сделайте drain старой ноды, переключите трафик и зафиксируйте incident summary.

Ожидаемый результат: деградировавшая нода заменена с минимальным влиянием на сервис.

Планировать batch-ёмкость по будням

Batch-ёмкость нужна только в рабочие часы, с предсказуемыми расходами.

•Таргетируйте только weekday-ноды в разрешённом project scope.

•Запускайте power-on/power-off по расписанию и проверяйте состояние после каждого шага.

•Ежедневно анализируйте capacity/cost deltas и отмечайте аномалии для human review.

Ожидаемый результат: предсказуемая batch-доступность и контролируемые затраты.

[ Блоки workflow ]

Всё необходимое для delivery-команд

Создавайте воспроизводимые окружения и уверенно доставляйте изменения по всему lifecycle инфраструктуры.

Terraform-совместимое provisioning

Создавайте и изменяйте инфраструктуру декларативно для воспроизводимых окружений.

Git-friendly operational model

Продвигайте изменения по окружениям через явные и проверяемые workflow steps.

Скриптуемая командная поверхность

Интегрируйте lifecycle actions в пайплайны с машиночитаемым выводом.

Контролируемая rollout cadence

Применяйте progressive deployment логику и держите production изменения предсказуемыми.

[ Command kit ]

Конкретные команды для CI/CD и rollout

Используйте эти команды как базовые блоки в release-пайплайнах и контролируемых изменениях.

bulli init

Инициализация execution context

Задайте CLI context перед pipeline-действиями.

source <(bulli env --output sh)

Загрузка environment variables

Подключите auth и project context для automation jobs.

bulli server list --output json

Проверка inventory

Получайте server list в JSON и валидируйте в CI checks.

bulli server reboot --hostname edge-worker-03

Плановый reboot

Запускайте контролируемый reboot в rollout-окнах.

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

Recovery reinstall

Быстро пересоберите ноду с чистой OS-базы.

[ Pipeline pattern ]

Provision, apply, verify, release

Простая и надёжная последовательность, соответствующая ежедневной DevOps-операционке.

Пример инфраструктурного 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

[ Слой безопасности ]

Работайте быстро, не теряя контроль

Используйте scoped access и operational checks для безопасной автоматизации в масштабе.

Scoped automation access

Ограничивайте права токенов по окружению и назначению.

Traceable rollout actions

Сохраняйте аудит deployment и operational изменений.

Guardrails для AI и скриптов

Автоматизируйте агрессивно, сохраняя чёткие operational boundaries.