|
Professor Seleznov
|
Оригинал статьи - Atlassian Data Center As A Torque Stack (тоже мой)
Отправная точка
Всё начиналось намеренно просто: публичные 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. Файл стека сделал порядок зависимостей явным:
- Сначала — хранилище;
- Затем — необходимые базы данных и Kubernetes Secrets;
- Далее — релизы приложений;
- В конце — агент 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/....
Два полезных момента отладки
- Предупреждения чартов: сгенерированные отчёты показали, что некоторые варнинги чартов допустимы только в этой лаборатории — потому что гейт verifier настроен на fail-on high и выше, а не потому, что все находки можно игнорировать в продакшене.
- Ложное срабатывание сканера секретов: одна сборка образа триггернула ложное срабатывание на упакованных бинарниках 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.
 -Источник
|
