Deployment Codex: flux Dockup de la un capăt la altul

Un deployment Codex ar trebui să se încheie cu dovezi, nu cu presupuneri. Provocarea practică nu este să-i ceri lui Codex să ruleze o comandă de deploy, ci să-i oferi agentului o interfață care identifică ținta exactă, așteaptă o stare terminală, returnează coduri de ieșire reale și oferă detalii despre erori fără browser.

Dockup este nivelul de deployment pentru acest workflow. CLI-ul său îi oferă lui Codex JSON structurat pentru fiecare comandă acceptată, iar skill-ul inclus îl învață pe agent cum să se autentifice, să descopere servicii, să facă deploy, să diagnosticheze problemele și să se oprească înainte de operațiuni distructive.

Cum instalezi skill-ul CLI pentru Codex?

Instalează CLI-ul global, apoi rulează installerul unic pentru skill. Acesta scrie skill-ul canonical și îl leagă atât în Claude Code, cât și în Codex:

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

Skill-ul canonical se află în ~/.agents/skills/dockup/ și este legat simbolic în ~/.codex/skills/. Este inclus în dockup-cli, astfel încât un update obișnuit modifică împreună executabilul și instrucțiunile acestuia:

dockup update

Această cuplare a versiunilor este importantă într-o interfață cu multe comenzi. Un agent nu ar trebui niciodată să execute un flag reținut din memorie doar pentru că a apărut într-un prompt mai vechi. Codex ar trebui să folosească skill-ul inclus în pachet și referința Dockup CLI actuală drept sursă de adevăr pentru comenzi.

Pentru motivația din spatele skill-urilor, consultă agent skills vs MCP.

Cum se autentifică Codex fără un terminal interactiv?

Este posibil ca un sandbox sau un job CI să nu poată finaliza autentificarea bazată pe browser. Setează un token în mediul procesului:

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

DOCKUP_TOKEN are prioritate față de fișierul de configurare local. Răspunsul whoami indică dacă credentialul activ provine din environment sau din configurație, ceea ce îl ajută pe Codex să diagnosticheze cazul frecvent în care coexistă un token local expirat și un token CI.

Tratează tokenul ca pe un secret de infrastructură. Nu îl include în AGENTS.md, SKILL.md, source control, exemple de comenzi salvate în repository sau transcriptul final al agentului. În CI, folosește secret store-ul criptat al platformei și expune valoarea doar pasului de deployment. Modelul complet non-interactiv este prezentat în CI/CD cu DOCKUP_TOKEN.

Înainte de a-i acorda lui Codex acces de scriere, stabilește limitele permisiunilor sale. Un scope inițial rezonabil include descoperirea serviciilor, deployment, citirea logurilor și verificările de status. Ștergerea bazelor de date, distrugerea serviciilor, modificările echipelor și eliminarea configurației ar trebui să necesite în continuare aprobare.

Cum găsește sau creează Codex serviciul corect?

Fă din discovery prima operațiune. Nu-i cere lui Codex să transforme „Payments API” într-un slug presupus:

dockup services --json

Fiecare rezultat include un target exact în formatul project/service. Codex ar trebui să copieze această valoare în comenzile ulterioare și să o returneze în sumarul său.

Când nu există niciun serviciu, creează unul din Git:

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

Comanda creează serviciul, face deploy, blochează execuția până când deploymentul se finalizează și scrie un link .dockup în directorul de lucru. Dacă există, este folosit un Dockerfile; în caz contrar, Nixpacks detectează automat configurația de build.

Când Codex pierde starea sesiunii sau un workflow este reluat după o întrerupere de rețea, ar trebui să redescopere serviciile și să verifice targetul exact înainte de a modifica ceva. Dacă targetul există deja, continuă de la statusul și istoricul deploymenturilor sale, în loc să emită o nouă cerere de creare.

Secvența completă, pornind de la repository, este disponibilă în De la repository Git la producție.

Cum ar trebui să pregătească Codex configurația înainte de deployment?

Cere-i lui Codex să inspecteze metadata actuală a serviciului înainte de a o modifica:

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

Răspunsul pentru environment include cheile și marcaje isSecret, în timp ce valorile secretelor rămân mascate. Codex poate adăuga separat variabile obișnuite și secrete:

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

Nu pune niciodată un secret de producție în dockup.yaml; manifestul este potrivit pentru configurații plain care pot fi revizuite, nu pentru credentiale. Variabilele secret existente nu sunt suprascrise sau eliminate de workflow-ul config-as-code.

Configurează portul pe care ascultă serviciul și readiness check-ul atunci când acestea sunt cunoscute:

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

Un readiness gate face relevantă verificarea în producție. Platforma efectuează un deployment blue-green și direcționează traficul doar după ce noua versiune trece de acest gate.

Cum confirmă verificarea în producție starea terminală?

Pentru un serviciu existent, folosește o singură comandă:

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

Timeout-ul explicit corespunde valorii implicite de 900 de secunde și face vizibilă intenția workflow-ului. Exit 0 înseamnă că deploymentul a reușit. Un rezultat non-zero cu deploy_failed înseamnă că build-ul sau deploymentul a eșuat. deploy_timeout înseamnă că operațiunea nu ajunsese încă într-o stare terminală la finalul perioadei de așteptare.

Logica corectă de branching pentru Codex se bazează pe statusul procesului:

Rezultat	Acțiunea Codex
Exit 0, status:"success"	Continuă cu verificările de health, uptime și security
deploy_failed	Citește build logs și identifică prima eroare care poate fi remediată
deploy_timeout	Raportează incertitudinea; inspectează statusul sau încearcă din nou cu un timeout justificat
not_logged_in	Oprește execuția și solicită un token valid
needs_confirm	Oprește execuția și solicită aprobarea unui om

După un deployment Codex reușit, colectează dovezi observabile:

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

Verificările de uptime rulează în fiecare minut și includ statistici privind timpul de răspuns, precum p95. Rezultatele de security includ CVE-uri ale imaginii și verificări de configurație. Aceste semnale nu dovedesc faptul că aplicația funcționează corect din punct de vedere business, așa că Codex ar trebui să ruleze și propriile smoke tests ale repository-ului, atunci când sunt disponibile.

Cum ar trebui Codex să diagnosticheze și să recupereze după un release eșuat?

Erorile de build și erorile de runtime necesită loguri diferite. Folosește cel mai recent output de build atunci când deploymentul nu a ajuns niciodată la un container care putea fi pornit:

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

Folosește runtime logs atunci când imaginea a fost construită, dar aplicația se închide, se leagă la portul greșit sau eșuează după pornire:

dockup logs production/payments-api --json

Modul follow este util în timpul unui build de durată:

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

În modul JSON, outputul follow este NDJSON, ceea ce îi permite lui Codex să proceseze fiecare batch pe măsură ce sosește. Streamul se încheie la o stare terminală a deploymentului și păstrează codul real de ieșire al erorii.

Recuperarea începe cu istoricul, nu cu o țintă de rollback presupusă:

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

Codex ar trebui să identifice un deployment cunoscut ca reușit, să indice ID-ul selectat și să păstreze dovezile erorii înainte de a-l rula din nou. Nu ar trebui niciodată să aleagă „al doilea element” fără să verifice statusul și timestamp-urile.

Un raport final util are șapte câmpuri: target, branch sau commit, ID-ul deploymentului, codul de ieșire, statusul terminal, URL-ul de producție și acțiunile ulterioare. Acest format face fiecare deployment Codex ușor de revizuit de către o persoană sau de un pas ulterior de automatizare.

Un script compact de verificare

Acest pattern de shell păstrează deploymentul și diagnosticul într-un singur flow de control transparent:

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

Scriptul nu caută cu grep o propoziție de succes. Se bazează pe codul de ieșire al CLI-ului, păstrează JSON-ul deploymentului și face jobul apelant să eșueze atunci când producția nu a ajuns la succes.

Fă retry-urile observabile, nu invizibile

Sesiunile agentului pot fi întrerupte după ce o operațiune a început, dar înainte ca rezultatul să ajungă în transcript. Următoarea rulare Codex nu ar trebui să repete orbește fiecare mutație. Ar trebui să redescopere serviciul, să inspecteze cel mai recent deployment și să stabilească dacă operațiunea anterioară a ajuns într-o stare terminală.

Un runbook de deployment Codex ar trebui să clasifice comenzile ca fiind sigure pentru repetare, sigure doar după inspecție sau condiționate de aprobare. Operațiunile de read pot fi repetate în siguranță. Crearea unui serviciu necesită mai întâi discovery. Un nou deploy este un nou eveniment de producție și ar trebui înregistrat ca atare. Eliminarea și celelalte operațiuni distructive rămân decizii umane.

Separă verificarea platformei de verificarea aplicației

Dockup poate demonstra că un build s-a finalizat, că un container a devenit ready și că probele executate la nivel de minut observă serviciul public. Codex ar trebui totuși să ruleze verificări specifice aplicației: un endpoint public de health, o cerere de test autentificată sau un smoke test furnizat de repository care nu modifică datele clienților.

Rezultatul final ar trebui să precizeze ambele niveluri. „Deploymentul platformei a reușit” și „smoke testul aplicației a trecut” sunt afirmații diferite. Când este disponibil doar primul rezultat, Codex ar trebui să spună acest lucru, nu să comprime incertitudinea într-un semn verde.

Confirmă interfața de comenzi instalată înainte de automatizare

O sarcină Codex reutilizabilă ar trebui să înceapă prin verificarea dockup skill status --json și deschiderea referinței CLI actuale atunci când depinde de o opțiune mai puțin familiară. Astfel, sesiunea nu va urma un exemplu scris pentru alt release.

Verificarea este deosebit de utilă în runner-ele efemere, unde o instalare npm globală nouă poate fi diferită de cea de pe laptopul unui developer. Codex poate raporta starea skill-ului înainte de a efectua primul write în producție, făcând înregistrarea deploymentului reproductibilă.

Predarea finală

Păstrează dovezile.

Păstrează targetul vizibil

Returnează targetul exact al serviciului în raportul final.

Păstrează decizia privind sursa

Notează dacă Dockup a folosit Dockerfile-ul repository-ului sau Nixpacks. Acest fapt ajută următoarea sesiune Codex să aleagă logul de build corect și împiedică confundarea unei schimbări în structura sursei cu un incident al platformei.

Notează și dacă deploymentul automat la push este activat. În caz contrar, un release manual al agentului și un release declanșat de un push se pot suprapune și pot crea două evenimente de producție în urma aceleiași investigații.

Pune workflow-ul în producție

Rulează primul deployment Codex pe un serviciu disposable sau cu risc redus, apoi promovează același contract de comenzi verificat în producție.

npm install -g dockup-cli
dockup skill install

Prima comandă instalează CLI-ul. A doua instalează skill-ul Dockup compatibil pentru Claude Code și Codex. Începe gratuit la app.dockup.ai.

Întrebări frecvente

Poate Codex să facă deploy unui repository Git nou cu o singură comandă?

Da. dockup create poate crea serviciul, poate face deploy, poate aștepta rezultatul terminal și poate lega directorul curent atunci când este folosit cu --deploy, --wait și --link.

Cum ar trebui Codex să se autentifice la Dockup?

Folosește DOCKUP_TOKEN în mediul procesului și verifică-l cu dockup whoami --json. Astfel eviți autentificarea interactivă prin browser în sandbox-uri și CI.

Ce dovedește că un deployment Codex a reușit?

Comanda deploy trebuie să se încheie cu exit 0 după rularea cu --wait, iar JSON-ul său trebuie să raporteze un status terminal de succes. Continuă cu verificări de status, uptime și smoke test-uri ale aplicației.

Poate Codex să citească secretele de producție din Dockup?

Nu. Valorile secretelor sunt mascate în output. Codex poate seta sau înlocui un secret, dar nu primește valoarea stocată atunci când listează configurația.

Ce ar trebui să facă Codex cu needs_confirm?

Ar trebui să se oprească și să solicite aprobarea explicită a unui om. Eroarea indică faptul că s-a încercat executarea unei comenzi distructive fără confirmarea obligatorie --yes.