Nasazení Codexu: kompletní workflow v Dockup

Nasazení Codexu by mělo končit důkazy, ne předpokladem. Praktickou výzvou není požádat Codex o spuštění příkazu pro nasazení, ale poskytnout agentovi rozhraní, které určí přesný cíl, počká na terminální stav, vrátí skutečné návratové kódy a zpřístupní podrobnosti o chybě bez použití prohlížeče.

Dockup je deployment layer pro tento workflow. Jeho CLI poskytuje Codexu strukturovaný JSON pro každý podporovaný příkaz a přibalený skill agenta učí, jak se autentizovat, vyhledávat služby, nasazovat, diagnostikovat a zastavit se před destruktivními operacemi.

Jak nainstalovat skill pro Codex CLI?

Nainstalujte CLI globálně a poté spusťte jediný instalační příkaz pro skill. Zapíše kanonický skill a vytvoří na něj odkazy v Claude Code i Codexu:

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

Kanonický skill se nachází v ~/.agents/skills/dockup/ a je symlinkovaný do ~/.codex/skills/. Je součástí dockup-cli, takže běžná aktualizace změní spustitelný soubor i jeho instrukce společně:

dockup update

Toto propojení verzí je důležité u rozsáhlého povrchu příkazů. Agent by nikdy neměl spouštět zapamatovaný flag jen proto, že se objevil ve starém promptu. Codex by měl používat přibalený skill a aktuální referenci Dockup CLI jako autoritativní zdroj příkazů.

Důvody tohoto návrhu najdete v článku skills agentů vs. MCP.

Jak se Codex autentizuje bez interaktivního terminálu?

Sandbox nebo CI job nemusí být schopen dokončit přihlášení pomocí prohlížeče. Nastavte token v prostředí procesu:

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

DOCKUP_TOKEN má přednost před lokálním konfiguračním souborem. Odpověď příkazu whoami uvádí, zda aktivní přihlašovací údaje pocházejí z prostředí, nebo z konfigurace. Codex tak může diagnostikovat běžný případ, kdy současně existuje zastaralý lokální token a CI token.

S tokenem zacházejte jako s infrastructure secret. Nevkládejte ho do AGENTS.md, SKILL.md, source control, příkladů příkazů commitovaných do repozitáře ani do závěrečného přepisu relace agenta. V CI použijte šifrované úložiště secretů dané platformy a zpřístupněte hodnotu pouze kroku nasazení. Kompletní non-interactive postup je popsán v článku CI/CD s DOCKUP_TOKEN.

Než Codexu udělíte přístup pro zápis, stanovte rozsah jeho oprávnění. Rozumný počáteční rozsah zahrnuje vyhledávání služeb, nasazování, čtení logů a kontrolu stavu. Mazání databází, ničení služeb, změny týmů a prořezávání konfigurace by měly zůstat podmíněné schválením.

Jak Codex najde nebo vytvoří správnou službu?

Vyhledávání proveďte jako první operaci. Nežádejte Codex, aby převedl „Payments API“ na odhadovaný slug:

dockup services --json

Každý výsledek obsahuje přesný target ve formátu project/service. Codex by měl tuto hodnotu zkopírovat do následujících příkazů a uvést ji ve svém souhrnu.

Pokud služba neexistuje, vytvořte ji z Gitu:

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

Příkaz vytvoří službu, nasadí ji, počká na vyřešení nasazení a zapíše odkaz .dockup do pracovního adresáře. Pokud je k dispozici Dockerfile, použije se; v opačném případě Nixpacks automaticky detekuje způsob buildu.

Když Codex ztratí stav relace nebo se workflow po přerušení sítě spouští znovu, měl by služby znovu vyhledat a před jakoukoli změnou zkontrolovat přesný target. Pokud target již existuje, pokračujte podle jeho stavu a historie nasazení namísto odeslání dalšího požadavku na vytvoření.

Kompletní sekvence od repozitáře je k dispozici v článku Z Git repozitáře do produkce.

Jak by měl Codex připravit konfiguraci před nasazením?

Požádejte Codex, aby před změnami zkontroloval aktuální metadata služby:

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

Odpověď s prostředím obsahuje klíče a značky isSecret, zatímco hodnoty secretů zůstávají skryté. Codex může běžné proměnné a secrety přidávat odděleně:

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 nevkládejte do dockup.yaml; manifest je vhodný pro konfiguraci v plain textu, kterou lze kontrolovat, nikoli pro přihlašovací údaje. Existující secret proměnné se v workflow config-as-code nepřepisují ani nemažou.

Když znáte port, na kterém služba naslouchá, a readiness check, nastavte je:

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

Readiness gate dává ověření produkce skutečný význam. Platforma provádí blue-green deployment a směruje provoz až poté, co nová verze splní podmínky gate.

Jak ověření produkce potvrdí terminální stav?

U existující služby použijte jediný příkaz:

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

Explicitní timeout odpovídá výchozí hodnotě 900 sekund a zviditelňuje záměr workflow. Návratový kód 0 znamená, že nasazení proběhlo úspěšně. Nenulový výsledek s deploy_failed znamená, že build nebo deployment skončil chybou. deploy_timeout znamená, že operace po skončení čekací doby stále nebyla v terminálním stavu.

Správná větvená logika Codexu vychází ze stavu procesu:

Výsledek	Akce Codexu
Exit 0, status:"success"	Pokračovat health checkem, kontrolou uptime a bezpečnosti
deploy_failed	Přečíst build logy a najít první chybu, podle které lze jednat
deploy_timeout	Oznámit nejistotu; zkontrolovat stav nebo opakovat s odůvodněným timeoutem
not_logged_in	Zastavit se a vyžádat platný token
needs_confirm	Zastavit se a požádat o schválení člověkem

Po úspěšném nasazení Codexu shromážděte pozorovatelné důkazy:

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

Kontroly uptime se spouštějí každou minutu a zahrnují statistiky doby odezvy, například p95. Výsledky bezpečnostních kontrol obsahují CVE image a kontroly konfigurace. Tyto signály neprokazují správnost business logiky, proto by Codex měl také spustit vlastní smoke testy repozitáře, pokud jsou k dispozici.

Jak by měl Codex diagnostikovat a obnovit neúspěšné vydání?

Chyby buildu a chyby za běhu vyžadují různé logy. Pokud nasazení nikdy nedosáhlo spuštění kontejneru, použijte nejnovější build output:

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

Runtime logy použijte, pokud se image sestavila, ale aplikace padá, naslouchá na nesprávném portu nebo selhává po spuštění:

dockup logs production/payments-api --json

Follow mode je užitečný během dlouhého buildu:

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

V režimu JSON je výstup follow mode ve formátu NDJSON, takže Codex může zpracovávat jednotlivé dávky ihned po jejich příchodu. Stream končí v terminálním stavu nasazení a zachovává skutečný návratový kód chyby.

Obnova začíná historií, ne odhadnutým cílem rollbacku:

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

Codex by měl identifikovat známé úspěšné nasazení, uvést zvolené ID a před jeho opětovným spuštěním zachovat důkazy o selhání. Nikdy by neměl zvolit „druhou položku“ bez ověření stavu a časových údajů.

Užitečný závěrečný report má sedm polí: target, větev nebo commit, ID nasazení, návratový kód, terminální stav, produkční URL a navazující akce. Díky tomuto formátu může nasazení Codexu zkontrolovat člověk nebo pozdější automatizační krok.

Kompaktní skript pro ověření

Tento shell pattern udržuje nasazení a diagnostiku v jednom transparentním řídicím toku:

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

Skript nevyhledává větu potvrzující úspěch pomocí grep. Důvěřuje návratovému kódu CLI, uchovává JSON s výsledkem nasazení a selže s chybou volající job, pokud produkce nedosáhla úspěšného stavu.

Udělejte retry pozorovatelným, ne skrytým

Relace agenta může být přerušena poté, co operace začala, ale ještě předtím, než se výsledek dostane do přepisu. Při dalším spuštění by Codex neměl slepě opakovat každou změnu. Měl by znovu vyhledat službu, zkontrolovat nejnovější nasazení a zjistit, zda předchozí operace dosáhla terminálního stavu.

Runbook pro nasazení Codexu by měl příkazy rozdělit na bezpečné pro opakování, bezpečné až po kontrole a podmíněné schválením. Čtecí operace lze bezpečně opakovat. Vytvoření služby vyžaduje nejprve vyhledávání. Nové nasazení je nová produkční událost a mělo by být jako takové zaznamenáno. Prořezávání a další destruktivní operace zůstávají rozhodnutím člověka.

Oddělte ověření platformy od ověření aplikace

Dockup může prokázat, že build skončil, kontejner je připravený a minutové sondy pozorují veřejně dostupnou službu. Codex by přesto měl spustit kontroly specifické pro aplikaci: veřejný health endpoint, autentizovaný testovací požadavek nebo smoke test z repozitáře, který nemění zákaznická data.

Konečný výsledek by měl uvádět obě vrstvy. „Nasazení na platformě proběhlo úspěšně“ a „aplikační smoke test prošel“ jsou různá tvrzení. Pokud je k dispozici pouze první z nich, Codex by to měl uvést, místo aby nejistotu zjednodušil na zelenou fajfku.

Před automatizací potvrďte dostupné příkazy

Opakovaně použitelná úloha Codexu by měla začínat kontrolou dockup skill status --json a otevřením aktuální reference CLI, pokud závisí na méně známé volbě. Zabráníte tak tomu, aby relace postupovala podle příkladu napsaného pro jiné vydání.

Kontrola je obzvlášť užitečná v ephemeral runnerech, kde se čerstvá globální instalace npm může lišit od instalace na vývojářském notebooku. Codex může stav skillu oznámit před prvním zápisem do produkce, takže záznam o nasazení bude reprodukovatelný.

Předání

Uchovejte důkazy.

Udržujte cíl viditelný

V závěrečném reportu uveďte přesný target služby.

Zachovejte rozhodnutí o zdroji

Zaznamenejte, zda Dockup použil Dockerfile z repozitáře, nebo Nixpacks. Tato informace pomůže další relaci Codexu zvolit správný build log a zabrání tomu, aby byla změna struktury zdrojových souborů zaměněna za incident platformy.

Zaznamenejte také, zda je zapnuté automatické nasazení při pushi. Manuální vydání agenta a vydání spuštěné pushem by se jinak mohla překrývat a vytvořit dvě produkční události v rámci stejného šetření.

Uveďte workflow do produkce

První nasazení Codexu proveďte vůči disposable nebo nízkorizikové službě a poté stejný ověřený contract příkazů povyšte do produkce.

npm install -g dockup-cli
dockup skill install

První příkaz nainstaluje CLI. Druhý nainstaluje odpovídající Dockup skill pro Claude Code a Codex. Začněte zdarma na app.dockup.ai.

Časté dotazy

Může Codex jedním příkazem nasadit nový Git repozitář?

Ano. dockup create může vytvořit službu, nasadit ji, počkat na terminální výsledek a propojit aktuální adresář, pokud se použije s --deploy, --wait a --link.

Jak se má Codex autentizovat k Dockupu?

Použijte DOCKUP_TOKEN v prostředí procesu a ověřte ho pomocí dockup whoami --json. Tím se v sandboxech a CI vyhnete interaktivnímu přihlášení v prohlížeči.

Co dokazuje, že nasazení Codexu proběhlo úspěšně?

Příkaz deploy musí po spuštění s --wait skončit s návratovým kódem 0 a jeho JSON musí uvádět úspěšný terminální stav. Poté proveďte kontroly status, uptime a aplikační smoke testy.

Může Codex číst produkční secrety z Dockupu?

Ne. Hodnoty secretů jsou ve výstupu skryté. Codex může secret nastavit nebo nahradit, ale při výpisu konfigurace uloženou hodnotu neobdrží.

Co má Codex udělat s needs_confirm?

Měl by se zastavit a vyžádat si výslovné schválení člověkem. Chyba znamená, že byl bez požadovaného potvrzení --yes proveden destruktivní příkaz.