Torque: релизы на автопилоте

Оригинал статьи - Atlassian Data Center As A Torque Stack (тоже мой) ^[1]

Отправная точка ^[2]

Всё начиналось намеренно просто: публичные Helm-чарты Atlassian Data Center, пара хостов на Linux и задача доказать, что реальный мультиприложенческий стек можно доставить без отката к ручному ранбуку. Целевой стек был не игрушечным: Jira, Confluence, Bitbucket, Bamboo, Crowd, агент Bamboo, PostgreSQL для хранения данных и общее хранилище для продуктов, которым оно требуется.

Такой набор полезен тем, что ведёт себя как типичное корпоративное ПО: стейтфул-сервисы, дефолты чартов, долгое время старта, экраны первоначальной настройки, чувствительные данные, постоянные тома и несколько точек, где инструмент развёртывания должен «показать свою работу».

Первый проход: прямой деплой

Первым шагом я развернул k3s на двух хостах, подготовил общее хранилище на базе NFS, скачал чарты Atlassian из репозитория atlassian/data-center-helm-charts и применил каждый релиз через Torque. Этот шаг был важен: он позволил сохранить базовую конфигурацию предсказуемой и «скучной».

Прежде чем превратить настройку в стек, я хотел убедиться, что:

• чарты рендерятся без ошибок;

• сервисы поднимаются;

• NodePort'ы доступны;

• поды продуктов могут подключиться к своим базам данных.

Torque уже на этом этапе оказался полезен: путь apply дал согласованный цикл релизов и верифицируемый вывод вместо набора разовых Helm-команд.

Превращение в стек Torque

После успешного первого деплоя я конвертировал команды релиза в стек Torque. Файл стека сделал порядок зависимостей явным:

1. Сначала — хранилище;

2. Затем — необходимые базы данных и Kubernetes Secrets;

3. Далее — релизы приложений;

4. В конце — агент Bamboo.

Именно здесь Torque перестаёт быть просто обёрткой над Helm. Файл стека придаёт всей системе форму, которую можно ревьюить, воспроизводить, возобновлять и отлаживать. Если релиз на нижнем уровне зависает, оператору не нужно восстанавливать, какой файл values или namespace использовался — этот контекст уже есть в стеке.

Работа с секретами

Пароли баз данных в открытом виде в files values — это тот самый «быстрый костыль», который часто остаётся навсегда, если его не убрать на раннем этапе. Я добавил локального провайдера секретов Torque и изменил prereq-values, чтобы использовать ссылки вида secret://local/... для паролей БД и токена безопасности агента Bamboo.

Практический урок: разрешение секретов должно происходить на уровне передаваемых values, а не быть спрятанным в дефолтах чарта, которыми инструмент деплоя не управляет.

Перенос ссылок в явный файл values сделал поведение прозрачным. После этого я проверил сгенерированные Kubernetes Secrets, чтобы убедиться: кластер получил уже разрешённые значения, а не литеральные строки secret://.

Verifier как жёсткий гейт

С готовым стеком и провайдером секретов путь деплоя стал строже. Я использовал:

verifier --mode block --fail-on high

— сгенерировал доказательства для каждого релиза и потребовал их перед apply.

Сам процесс применения использовал:

torque apply --require-verified --drift-guard

Таким образом, развёртывание должно было соответствовать верифицированному плану, а не молча принимать изменённый рендер. Это превращает «я думаю, это безопасно» в «именно этот рендер прошёл вот эти проверки».

Параллельно я использовал Helmer для генерации HTML-планов под ревью. На практике именно этот этап отличает кейс по Torque от обычной заметки по установке. Результат — не просто «поды работают», а комплект из:

• файлов стека;

• отрендеренных планов;

• отчётов verifier;

• доказательств применения — всё это другой оператор может изучить позже.

Доказательства за пределами первоначального развёртывания

Новые функции proof развивают ту же идею дальше:

• torque apply simulate создаёт Live Apply Twin до того, как рискованное изменение коснётся кластера;

• после изменения torque guardian diff сравнивает симуляцию с живыми объектами Kubernetes, владельцами управляемых полей, событиями, состоянием aftercare и доказательствами границ секретов.

Если позже под продукта упадёт из-за невозможности pull'а образа, вебхук изменит поле, ConfigMap начнёт нести данные, похожие на секреты, или оператор вручную отредактирует живой объект — Guardian превратит расхождение в доказательство, а не в догадку.

Команды torque incident capture и torque incident replay делают сбой переносимым: состояние ресурсов, события, ограниченные логи, первопричина и заметки для PR можно изучать без доступа к исходному терминалу.

Самый новый слой — torque contract synthesize и torque contract test — конвертирует доказательства инцидентов и дрейфа в правила повторения. Для стека Atlassian это значит, что следующий деплой может доказать:

• отсутствие сбоев pull'а образа;

• отсутствие регрессий границ секретов;

• отсутствие необъяснимых владельцев управляемых полей;

• отсутствие сбоев aftercare — с помощью машиночитаемого контракта, а не памяти в Slack.

Примеры продвижения релиза с доказательствами

# Canary-стратегия
torque release promote ./reports/proof.graph.json 
  --strategy canary 
  --steps 5,25,50,100 
  --analysis-window 5m 
  --slo ./reports/slo.yaml 
  --rollback-on-fail 
  --key .torque/stack/keys/ed25519.json 
  --out-dir ./reports/promote-canary

# Blue-green с предпросмотром
torque release promote ./reports/proof.graph.json 
  --strategy blue-green 
  --preview 
  --smoke ./reports/smoke.json 
  --switch-traffic 
  --key .torque/stack/keys/ed25519.json 
  --out-dir ./reports/promote-blue-green

# Blue-green с сохранением состояния
torque release promote ./reports/proof.graph.json 
  --strategy blue-green 
  --preview --smoke ./reports/smoke.json --switch-traffic 
  --provider file --state-out ./reports/traffic-state.json 
  --execute --yes --format json

Кастомные образы в том же конвейере

Я также собрал кастомные образы для того же стека. Цель была не в форке продуктов Atlassian или «запекании» конфигурации в образы. Цель — доказать, что Torque может владеть шагом сборки образа как частью той же истории доставки.

Dockerfile'ы:

• фиксировали базовые образы Atlassian, PostgreSQL и NFS-провайдера по дайджесту;

• добавляли только небольшие операционные изменения там, где это полезно;

• проходили через torque build с включённым сканированием секретов.

Образ агента Bamboo — самый наглядный пример: он сохраняет базовый агент от upstream, но добавляет распространённые инструменты для диагностики и CI: curl, git, jq, openssh-client, tar, unzip.

Собранные OCI-лейауты были импортированы в containerd k3s на обоих узлах, а затем использованы в values стека как образы torque.local/atlassian/....

Два полезных момента отладки

1. Предупреждения чартов: сгенерированные отчёты показали, что некоторые варнинги чартов допустимы только в этой лаборатории — потому что гейт verifier настроен на fail-on high и выше, а не потому, что все находки можно игнорировать в продакшене.

2. Ложное срабатывание сканера секретов: одна сборка образа триггернула ложное срабатывание на упакованных бинарниках OpenSSH внутри образа Bitbucket. Это как раз тот случай, когда политику можно настраивать, но не отключать. Я добавил небольшой файл правил сканера, который сохранил строгость сканирования аргументов сборки и логов, но избежал ложного срабатывания на содержимом OCI.

Логи Torque как операционный граф

Полезный взгляд на логи — это не просто «покажи мне этот под». Это логи по:

• зависимостям стека;

• активному ReplicaSet;

• условию readiness;

• контексту событий.

Одно семейство команд обрабатывает:

• контекст с учётом зависимостей: --deps;

• нездоровые поды в namespace: --condition;

• события Kubernetes: --events;

• активные развёртывания: --deploy-mode active;

• доказательства передачи ответственности: --capture.

Это особенно сильно для агентов: они могут инспектировать контекст сбоя из графа стека, не угадывая сначала имена объектов Kubernetes.

Расширенные примеры логирования Torque:

# Логи с учётом зависимостей
torque logs --deps --stack atlassian-dc

# Только поды в состоянии CrashLoopBackOff
torque logs --condition CrashLoopBackOff -n atlassian

# События, связанные с развёртыванием
torque logs --events --deploy-mode active

# Захват доказательств для передачи
torque logs --capture --out ./evidence/incident-001.json

Итог: воспроизводимый путь для сложного стека

Экраны первоначальной настройки Atlassian и ввод лицензий никуда не делись, агенты Bamboo по-прежнему зависят от инициализации Bamboo. Torque не удаляет шаги жизненного цикла продуктов.

Что он делает: делает инфраструктурную сторону ревьюируемой:

• чарты рендерятся через один путь;

• секреты приходят от провайдера;

• verifier решает, можно ли продолжать релиз;

• drift-guard защищает apply;

• Helmer генерирует читаемые планы-доказательства;

• сборка образов встраивается в ту же операционную историю.

В этом практическая ценность: меньше магии, больше файлов, и деплой, который можно воспроизвести без зависимости от памяти терминала.

Агент-нативное исполнение

Именно поэтому Torque идеально подходит для работы с агентными системами. Codex, Claude, Gemini, CI или люди не должны писать DevOps-скрипты с нуля; они должны оперировать теми же рабочими процессами Torque через поверхность MCP или API.

Это даёт рабочему процессу:

• устойчивые джобы;

• возобновляемые шаги;

• аудиторский след;

• права доступа и аппрувы;

• доказательства от verifier;

• контекст логов — вместо не ревьюируемого транскрипта терминала.

Финальный захват показывает Codex, использующего Torque на том же развёртывании Atlassian.