Nasadenie Codex: komplexný workflow v Dockup

Nasadenie Codex by sa malo skončiť dôkazmi, nie domnienkou. Praktická výzva nespočíva v tom, aby ste požiadali Codex o spustenie príkazu na nasadenie, ale v tom, aby ste agentovi poskytli rozhranie, ktoré identifikuje presný cieľ, počká na konečný stav, vracia skutočné exit codes a sprístupňuje podrobnosti o zlyhaní bez použitia prehliadača.

Dockup je deployment layer pre tento workflow. Jeho CLI poskytuje Codexu štruktúrovaný JSON pri každom podporovanom príkaze a pribalený skill učí agenta autentifikovať sa, vyhľadávať služby, nasadzovať, diagnostikovať a zastaviť sa pred deštruktívnymi operáciami.

Ako nainštalovať skill Codex CLI?

Nainštalujte CLI globálne a potom spustite jediný inštalátor skillu. Zapíše kanonický skill a prepojí ho s Claude Code aj Codex:

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

Kanonický skill sa nachádza v ~/.agents/skills/dockup/ a symbolicky sa prepája do ~/.codex/skills/. Je súčasťou balíka dockup-cli, takže bežná aktualizácia zmení executable aj jeho inštrukcie naraz:

dockup update

Toto prepojenie verzií je dôležité pri rozsiahlej množine príkazov. Agent by nikdy nemal spúšťať zapamätaný flag len preto, že sa objavil v starom prompte. Codex by mal používať pribalený skill a aktuálnu referenciu Dockup CLI ako zdroj autority pre príkazy.

Dôvody tohto návrhu skillov nájdete v článku agent skills vs MCP.

Ako sa Codex autentifikuje bez interaktívneho terminálu?

Sandbox alebo CI job nemusí byť schopný dokončiť prihlasovanie cez prehliadač. Nastavte token v prostredí procesu:

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

DOCKUP_TOKEN má prednosť pred lokálnym konfiguračným súborom. Odpoveď whoami uvádza, či aktívne poverenie pochádza z prostredia alebo z konfigurácie, čo Codexu pomáha diagnostikovať bežný prípad, keď spolu existuje zastaraný lokálny token a CI token.

S tokenom zaobchádzajte ako s infrastructure secret. Nevkladajte ho do AGENTS.md, SKILL.md, source control, príkladov príkazov commitnutých do repozitára ani do finálneho transcriptu agenta. V CI používajte šifrované úložisko secrets danej platformy a hodnotu sprístupnite iba kroku nasadenia. Kompletný neinteraktívny postup nájdete v článku CI/CD s DOCKUP_TOKEN.

Pred udelením write access Codexu určte rozsah jeho oprávnení. Rozumný počiatočný rozsah zahŕňa vyhľadávanie služieb, nasadenie, čítanie logov a kontroly statusu. Mazanie databáz, deštrukcia služieb, zmeny tímu a odstraňovanie konfigurácie by mali naďalej vyžadovať schválenie.

Ako Codex nájde alebo vytvorí správnu službu?

Vyhľadávanie musí byť prvou operáciou. Nežiadajte Codex, aby z textu „Payments API“ odhadoval slug:

dockup services --json

Každý výsledok obsahuje presný target vo formáte project/service. Codex by mal túto hodnotu skopírovať do nasledujúcich príkazov a uviesť ju v súhrne.

Ak služba neexistuje, vytvorte ju z Git:

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

Príkaz vytvorí službu, nasadí ju, počká, kým sa deployment dokončí, a do pracovného adresára zapíše odkaz .dockup. Ak je k dispozícii Dockerfile, použije sa; v opačnom prípade Nixpacks automaticky rozpozná spôsob buildu.

Ak Codex stratí stav session alebo sa workflow spúšťa znova po prerušení siete, mal by služby opätovne vyhľadať a pred akoukoľvek mutáciou skontrolovať presný target. Ak target už existuje, pokračujte podľa jeho statusu a histórie deploymentov namiesto odoslania ďalšej požiadavky na vytvorenie.

Kompletnú sekvenciu od repozitára po produkciu nájdete v článku Git repository to production.

Ako má Codex pripraviť konfiguráciu pred nasadením?

Požiadajte Codex, aby pred zmenou konfigurácie skontroloval aktuálne metadata služby:

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

Odpoveď s prostredím obsahuje kľúče a označenia isSecret, pričom hodnoty secretov zostávajú zamaskované. Codex môže bežné premenné a secrety pridať oddelene:

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

Produkčný secret nikdy nevkladajte do dockup.yaml; manifest je vhodný na kontrolovateľnú bežnú konfiguráciu, nie na credentials. Existujúce secret premenné sa v rámci workflow config-as-code neprepíšu ani neodstránia.

Keď sú známe, nakonfigurujte port, na ktorom služba počúva, a readiness check:

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

Readiness gate dáva overeniu produkcie zmysel. Platforma vykonáva blue-green deployment a smeruje traffic až vtedy, keď nová verzia splní túto podmienku.

Ako overenie produkcie potvrdí konečný stav?

Pri existujúcej službe použite jeden príkaz:

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

Explicitný timeout zodpovedá predvolenej hodnote 900 sekúnd a robí zámer workflow viditeľným. Exit 0 znamená, že deployment bol úspešný. Výsledok s nenulovým kódom a hodnotou deploy_failed znamená, že build alebo deploy zlyhal. deploy_timeout znamená, že operácia po uplynutí čakacej doby ešte nebola v konečnom stave.

Správna branching logika Codexu vychádza zo statusu procesu:

Výsledok	Akcia Codexu
Exit 0, status:"success"	Pokračovať na overenie health, uptime a security
deploy_failed	Prečítať build logy a identifikovať prvú konkrétnu chybu
deploy_timeout	Nahlásiť neistotu; skontrolovať status alebo zopakovať operáciu s odôvodneným timeoutom
not_logged_in	Zastaviť a vyžiadať platný token
needs_confirm	Zastaviť a požiadať o schválenie človekom

Po úspešnom nasadení Codexu zhromaždite pozorovateľné dôkazy:

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

Uptime checks sa spúšťajú každú minútu a obsahujú štatistiky response time, napríklad p95. Výsledky security obsahujú CVEs v image a kontroly konfigurácie. Tieto signály nedokazujú správnosť business logiky, preto by mal Codex spustiť aj vlastné smoke tests repozitára, ak sú k dispozícii.

Ako má Codex diagnostikovať a obnoviť neúspešný release?

Build errors a runtime errors vyžadujú odlišné logy. Ak deployment nikdy nedosiahol stav spustiteľného kontajnera, použite najnovší build output:

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

Runtime logy použite vtedy, keď sa image úspešne zostavil, ale aplikácia padá, počúva na nesprávnom porte alebo zlyháva po štarte:

dockup logs production/payments-api --json

Follow mode je užitočný počas dlhého buildu:

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

V JSON mode má follow output formát NDJSON, takže Codex môže spracovať každú dávku hneď po jej doručení. Stream sa skončí pri konečnom stave deploymentu a zachová skutočný exit code zlyhania.

Obnova sa začína históriou, nie uhádnutým cieľom rollbacku:

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

Codex by mal identifikovať známy úspešný deployment, uviesť zvolené ID a pred jeho opätovným spustením zachovať dôkazy o zlyhaní. Nikdy by nemal vybrať „druhú položku“ bez overenia statusu a časových údajov.

Užitočný finálny report má sedem polí: target, branch alebo commit, ID deploymentu, exit code, konečný status, produkčnú URL a nasledujúce kroky. Vďaka tomuto formátu môže každé nasadenie Codexu skontrolovať človek alebo neskorší automation step.

Kompaktný overovací script

Tento shell pattern udržiava deployment a diagnostiku v jednom transparentnom 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

Script nevyhľadáva vetu o úspechu pomocou grep. Spolieha sa na exit code CLI, uchováva JSON deploymentu a zlyhá v calling jobe, keď produkcia nedosiahla úspešný stav.

Urobte retries pozorovateľnými, nie skrytými

Sessions agentov môžu byť prerušené po spustení operácie, ale ešte pred doručením výsledku do transcriptu. Ďalšie spustenie Codexu by nemalo slepo opakovať každú mutáciu. Malo by znovu vyhľadať službu, skontrolovať najnovší deployment a zistiť, či predchádzajúca operácia dosiahla konečný stav.

Runbook nasadenia Codex by mal príkazy rozdeliť na bezpečné na opakovanie, bezpečné až po kontrole a vyžadujúce schválenie. Read operácie je bezpečné opakovať. Vytvorenie služby si najskôr vyžaduje discovery. Nový deploy je nová produkčná udalosť a mal by sa tak aj zaznamenať. Pruning a ďalšie deštruktívne operácie zostávajú rozhodnutiami človeka.

Oddeľte overenie platformy od overenia aplikácie

Dockup dokáže potvrdiť, že build bol dokončený, kontajner je pripravený a probes na úrovni minút pozorujú verejne dostupnú službu. Codex by mal napriek tomu spustiť kontroly špecifické pre aplikáciu: verejný health endpoint, autentifikovanú testovaciu požiadavku alebo smoke test z repozitára, ktorý nemení zákaznícke dáta.

Finálny výsledok by mal uvádzať obe vrstvy. „Deployment platformy bol úspešný“ a „aplikačný smoke test prešiel“ sú odlišné tvrdenia. Ak je k dispozícii iba prvé z nich, Codex by to mal uviesť namiesto toho, aby neistotu skryl za zelenú značku.

Pred automatizáciou potvrďte dostupné príkazy

Reusable task pre Codex by sa mal začať kontrolou dockup skill status --json a otvorením aktuálnej referencie CLI, ak závisí od menej známej možnosti. Predídete tak tomu, aby session postupovala podľa príkladu určeného pre inú verziu.

Kontrola je obzvlášť užitočná v ephemeral runneroch, kde sa čerstvá globálna inštalácia npm môže líšiť od laptopu vývojára. Codex môže stav skillu nahlásiť ešte pred prvým write do produkcie, čím bude záznam o nasadení reprodukovateľný.

Finálne odovzdanie

Uchovajte dôkazy.

Zachovajte viditeľný target

Vo finálnom reporte uveďte presný target služby.

Zachovajte rozhodnutie o zdroji

Zaznamenajte, či Dockup použil Dockerfile z repozitára alebo Nixpacks. Táto informácia pomôže ďalšej session Codexu vybrať správny build log a zabráni tomu, aby sa zmena štruktúry zdroja považovala za incident platformy.

Zaznamenajte tiež, či je povolený automatický deploy po pushi. Manuálny release agenta a release spustený pushom by sa inak mohli prekrývať a vytvoriť dve produkčné udalosti v rámci jedného vyšetrovania.

Uveďte workflow do produkcie

Prvé nasadenie Codexu vykonajte voči disposable alebo nízkorizikovej službe a až potom preneste rovnaký overený contract príkazov do produkcie.

npm install -g dockup-cli
dockup skill install

Prvý príkaz nainštaluje CLI. Druhý nainštaluje zodpovedajúci Dockup skill pre Claude Code a Codex. Začnite bezplatne na app.dockup.ai.

Často kladené otázky

Môže Codex nasadiť nový Git repozitár jedným príkazom?

Áno. dockup create môže vytvoriť službu, nasadiť ju, počkať na konečný výsledok a prepojiť aktuálny adresár, ak sa použije s --deploy, --wait a --link.

Ako sa má Codex autentifikovať do Dockup?

Použite DOCKUP_TOKEN v prostredí procesu a overte ho pomocou dockup whoami --json. Vyhnete sa tak interaktívnemu prihlasovaniu cez prehliadač v sandboxoch a CI.

Čo dokazuje úspešné nasadenie Codexu?

Príkaz deploy musí po spustení s --wait skončiť s exit 0 a jeho JSON musí uvádzať úspešný konečný status. Následne spustite status, uptime a aplikačné smoke checks.

Môže Codex čítať produkčné secrety z Dockup?

Nie. Hodnoty secretov sú vo výstupe zamaskované. Codex môže secret nastaviť alebo nahradiť, ale pri výpise konfigurácie nedostane uloženú hodnotu.

Čo má Codex urobiť s needs_confirm?

Mal by sa zastaviť a vyžiadať si explicitné schválenie človekom. Chyba znamená, že sa niekto pokúsil spustiť deštruktívny príkaz bez požadovaného potvrdenia --yes.