Развёртывание Codex: полный рабочий процесс в Dockup

Развёртывание Codex должно завершаться подтверждёнными результатами, а не предположениями. Практическая сложность заключается не в том, чтобы попросить Codex выполнить команду deploy, а в том, чтобы предоставить агенту интерфейс, который определяет точную цель, ожидает terminal state, возвращает реальные exit codes и показывает подробности сбоя без браузера.

Dockup — deployment layer для такого рабочего процесса. Его CLI возвращает Codex структурированный JSON для каждой поддерживаемой команды, а встроенный skill обучает агента аутентификации, поиску сервисов, развёртыванию, диагностике и остановке перед destructive operations.

Как установить skill для Codex CLI?

Установите CLI глобально, затем запустите единственный installer для skill. Он записывает canonical skill и создаёт ссылки на него в Claude Code и Codex:

npm install -g dockup-cli
dockup skill install
dockup skill status --json

Canonical skill находится в ~/.agents/skills/dockup/, а в ~/.codex/skills/ на него создаётся symlink. Skill поставляется внутри dockup-cli, поэтому обычное обновление одновременно изменяет executable и его инструкции:

dockup update

Такая связка версий особенно важна при большом количестве команд. Агент не должен выполнять запомненный flag только потому, что он встречался в старом prompt. Codex должен использовать поставляемый skill и актуальный справочник Dockup CLI как источник истины для команд.

Обоснование такого подхода к skills см. в статье agent skills vs MCP.

Как Codex проходит аутентификацию без интерактивного терминала?

Sandbox или CI job может не поддерживать вход через браузер. Укажите token в окружении процесса:

export DOCKUP_TOKEN="<TOKEN>"
dockup whoami --json

DOCKUP_TOKEN имеет приоритет над локальным config file. Ответ whoami показывает, откуда получены активные credentials — из окружения или config. Это помогает Codex диагностировать распространённую ситуацию, когда одновременно существуют устаревший локальный token и token из CI.

Считайте token infrastructure secret. Не добавляйте его в AGENTS.md, SKILL.md, source control, примеры команд, зафиксированные в repository, или итоговую расшифровку работы агента. В CI используйте зашифрованное хранилище secrets платформы и передавайте значение только шагу развёртывания. Полный non-interactive pattern описан в статье CI/CD с DOCKUP_TOKEN.

Прежде чем предоставлять Codex доступ на запись, определите границы его permissions. Разумный начальный scope включает поиск сервисов, развёртывание, чтение логов и проверки статуса. Удаление databases, уничтожение сервисов, изменение teams и pruning config должны оставаться операциями, требующими approval.

Как Codex находит или создаёт нужный сервис?

Сделайте discovery первой операцией. Не просите Codex преобразовывать «Payments API» в угаданный slug:

dockup services --json

Каждый результат содержит точное значение target в формате project/service. Codex должен копировать это значение в последующие команды и возвращать его в summary.

Если сервис не существует, создайте его из Git:

dockup create payments-api \
  --repo https://github.com/acme/payments-api \
  --project production \
  --branch main \
  --deploy \
  --wait \
  --link \
  --json

Команда создаёт сервис, развёртывает его, ожидает завершения deployment и записывает ссылку .dockup в рабочий каталог. При наличии используется Dockerfile; в противном случае Nixpacks автоматически определяет способ сборки.

Если Codex теряет состояние сессии или workflow запускается повторно после сетевого сбоя, он должен заново найти сервисы и проверить точный target, прежде чем что-либо изменять. Если target уже существует, продолжите работу с его статусом и историей deployments вместо отправки ещё одного запроса create.

Полная последовательность работы от repository описана в статье От Git repository до production.

Как Codex должен подготовить конфигурацию перед deployment?

Попросите Codex изучить текущие metadata сервиса перед их изменением:

dockup info production/payments-api --json
dockup env list -s production/payments-api --json

Ответ с окружением содержит keys и markers isSecret, а значения secrets остаются замаскированными. Codex может добавлять обычные variables и secrets отдельно:

dockup env set NODE_ENV=production \
  -s production/payments-api \
  --json

dockup env set STRIPE_SECRET_KEY="$STRIPE_SECRET_KEY" \
  --secret \
  -s production/payments-api \
  --json

Никогда не помещайте production secret в dockup.yaml: manifest подходит для конфигурации в открытом виде, которую можно просматривать и проверять, но не для credentials. Существующие secret variables не перезаписываются и не удаляются в workflow config-as-code.

Настройте listening port и readiness check сервиса, если они известны:

dockup set production/payments-api --port 3000 --json
dockup health production/payments-api \
  --path /health \
  --interval 5 \
  --retries 5 \
  --json

Readiness gate делает проверку production содержательной. Платформа выполняет blue-green deployment и направляет traffic только после того, как новая версия проходит gate.

Как production verification подтверждает terminal state?

Для существующего сервиса используйте одну команду:

dockup deploy production/payments-api \
  --wait \
  --timeout 900 \
  --json

Явно заданный timeout совпадает со значением по умолчанию — 900 секунд — и делает намерение workflow очевидным. Exit 0 означает успешное deployment. Ненулевой результат с deploy_failed означает, что build или deploy завершился ошибкой. deploy_timeout означает, что по окончании периода ожидания операция ещё не перешла в terminal state.

Правильная branching logic Codex основывается на статусе процесса:

Result	Codex action
Exit 0, status:"success"	Перейти к проверкам health, uptime и security
deploy_failed	Прочитать build logs и определить первую ошибку, требующую действий
deploy_timeout	Сообщить о неопределённости; проверить status или повторить операцию с обоснованным timeout
not_logged_in	Остановиться и запросить действительный token
needs_confirm	Остановиться и запросить approval человека

После успешного deployment Codex соберите наблюдаемые подтверждения:

dockup status production/payments-api --json
dockup uptime production/payments-api --hours 24 --json
dockup security production/payments-api --json

Проверки uptime выполняются каждую минуту и включают статистику времени ответа, например p95. Результаты security содержат CVEs образа и проверки конфигурации. Эти сигналы не доказывают корректность бизнес-логики, поэтому Codex также должен запускать собственные smoke tests repository, если они доступны.

Как Codex должен диагностировать и восстанавливать неудачный release?

Ошибки build и runtime требуют разных logs. Используйте последний build output, если deployment не дошёл до запускаемого container:

dockup logs production/payments-api --build --json

Используйте runtime logs, если image собрался, но приложение падает, слушает неправильный port или завершается после startup:

dockup logs production/payments-api --json

Follow mode полезен во время длительной сборки:

dockup logs production/payments-api --build -f --json

В JSON mode вывод follow представлен в формате NDJSON, поэтому Codex может обрабатывать каждый batch по мере его поступления. Stream завершается при достижении terminal deployment state и сохраняет реальный failure exit code.

Восстановление начинается с history, а не с угаданного target для rollback:

dockup deployments production/payments-api -n 20 --json
dockup rollback <deploymentId> production/payments-api --json

Codex должен определить заведомо успешный deployment, сообщить выбранный ID и сохранить evidence сбоя перед его повторным запуском. Нельзя выбирать «второй элемент» без проверки status и timestamps.

Полезный итоговый отчёт содержит семь полей: target, branch или commit, deployment ID, exit code, terminal status, production URL и follow-up actions. Такой формат позволяет человеку или следующему шагу automation проверить каждый deployment Codex.

Компактный скрипт проверки

Этот shell pattern объединяет deployment и диагностику в один прозрачный control flow:

if dockup deploy production/payments-api --wait --json > deploy-result.json; then
  dockup status production/payments-api --json
  dockup uptime production/payments-api --hours 24 --json
else
  dockup logs production/payments-api --build --json
  exit 1
fi

Скрипт не ищет в выводе фразу об успехе. Он доверяет exit code CLI, сохраняет deployment JSON и сообщает об ошибке вызывающей job, если production не достиг успешного состояния.

Делайте retries наблюдаемыми, а не незаметными

Сессия агента может прерваться после начала операции, но до того, как результат попадёт в transcript. Следующий запуск Codex не должен вслепую повторять каждую mutation. Ему следует заново найти сервис, проверить последний deployment и определить, перешла ли предыдущая операция в terminal state.

В runbook развёртывания Codex команды следует классифицировать как безопасные для повторения, безопасные только после проверки или требующие approval. Reads безопасно повторять. Для создания сервиса сначала нужен discovery. Новый deploy — это новое production event, которое следует зафиксировать именно как таковое. Pruning и другие destructive operations остаются решениями человека.

Разделяйте platform verification и application verification

Dockup может подтвердить, что build завершился, container стал ready, а probes на уровне минут наблюдают публичный сервис. Однако Codex всё равно должен запускать проверки, специфичные для приложения: public health endpoint, authenticated test request или smoke test из repository, который не изменяет данные клиентов.

В финальном результате следует указать оба уровня. «Platform deployment завершился успешно» и «application smoke test пройден» — разные утверждения. Если доступно только первое, Codex должен прямо сказать об этом, а не превращать неопределённость в зелёную галочку.

Проверяйте установленный command surface перед automation

Reusable task для Codex должен начинаться с проверки dockup skill status --json и открытия актуального справочника CLI, если он зависит от менее знакомой option. Это не позволит сессии следовать примеру, написанному для другого release.

Такая проверка особенно полезна в ephemeral runners, где свежая глобальная установка npm может отличаться от установки на laptop разработчика. Codex может сообщить состояние skill до выполнения первой production write operation, сделав deployment record воспроизводимым.

Финальная передача

Сохраняйте evidence.

Не скрывайте target

Возвращайте точный target сервиса в итоговом отчёте.

Фиксируйте решение об источнике

Записывайте, использовал ли Dockup Dockerfile repository или Nixpacks. Это помогает следующей сессии Codex выбрать правильный build log и не принять изменение структуры source за incident платформы.

Также фиксируйте, включён ли automatic deploy on push. Иначе manual agent release и release, запущенный push, могут пересечься и создать два production events в рамках одного расследования.

Переведите workflow в production

Сначала выполните первый deployment Codex для disposable или low-risk сервиса, а затем перенесите тот же проверенный contract команд в production.

npm install -g dockup-cli
dockup skill install

Первая команда устанавливает CLI. Вторая устанавливает соответствующий Dockup skill для Claude Code и Codex. Начать бесплатно можно на app.dockup.ai.

FAQ

Может ли Codex развернуть новый Git repository одной командой?

Да. dockup create может создать сервис, выполнить deployment, дождаться terminal result и связать текущий каталог при использовании с --deploy, --wait и --link.

Как Codex должен проходить аутентификацию в Dockup?

Используйте DOCKUP_TOKEN в окружении процесса и проверьте его с помощью dockup whoami --json. Это позволяет избежать интерактивного входа через браузер в sandboxes и CI.

Что доказывает успешность deployment Codex?

Команда deploy должна завершиться с exit 0 после запуска с --wait, а её JSON должен сообщить об успешном terminal status. Затем выполните проверки status, uptime и application smoke.

Может ли Codex прочитать production secrets из Dockup?

Нет. Значения secrets замаскированы в output. Codex может установить или заменить secret, но не получает сохранённое значение при просмотре configuration.

Что Codex должен делать с needs_confirm?

Он должен остановиться и запросить явное approval человека. Эта ошибка означает, что была предпринята destructive command без обязательного подтверждения --yes.