Codex-deployointi: Dockup-työnkulku alusta loppuun

Codex-deployoinnin pitäisi päättyä näyttöön onnistumisesta, ei oletukseen. Käytännön haaste ei ole deploy-komennon suorittamisen pyytäminen Codexilta, vaan sellaisen rajapinnan tarjoaminen agentille, joka tunnistaa täsmällisen kohteen, odottaa päätetilaa, palauttaa todelliset exit-koodit ja näyttää virheiden yksityiskohdat ilman selainta.

Dockup toimii tämän työnkulun deployment layer -kerroksena. Sen CLI tarjoaa Codexille rakenteista JSON-dataa jokaisesta tuetusta komennosta, ja sen mukana toimitettava skill opettaa agentille, miten tunnistaudutaan, etsitään palveluita, deployataan, diagnosoidaan ongelmia ja pysähdytään ennen tuhoisia operaatioita.

Miten Codex CLI -skill asennetaan?

Asenna CLI globaalisti ja suorita sen jälkeen skillin yksittäinen asennuskomento. Se kirjoittaa kanonisen skillin ja linkittää sen sekä Claude Codeen että Codexiin:

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

Kanoninen skill sijaitsee hakemistossa ~/.agents/skills/dockup/, ja se linkitetään hakemistoon ~/.codex/skills/. Skill toimitetaan osana dockup-cli-pakettia, joten tavallinen päivitys päivittää suoritettavan tiedoston ja sen ohjeet yhdessä:

dockup update

Tämä versioiden yhteensopivuus on tärkeää, kun komentopinta on laaja. Agentin ei pitäisi koskaan suorittaa muistamaansa flagia vain siksi, että se esiintyi vanhassa promptissa. Codexin pitäisi käyttää paketoitua skillia ja ajantasaista Dockup CLI -referenssiä komentojen auktoriteettina.

Skillien suunnitteluperiaatteista kerrotaan artikkelissa agent skills vs MCP.

Miten Codex tunnistautuu ilman interaktiivista päätettä?

Sandbox tai CI-työ voi olla estynyt suorittamasta selaimeen perustuvaa kirjautumista. Aseta token prosessin ympäristöön:

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

DOCKUP_TOKEN ohittaa paikallisen asetustiedoston. whoami-vastaus kertoo, tuliko aktiivinen tunnistetieto ympäristöstä vai asetustiedostosta. Tämä auttaa Codexia selvittämään yleisen tilanteen, jossa vanhentunut paikallinen token ja CI-token ovat käytössä samanaikaisesti.

Käsittele tokenia infrastruktuurin salaisuutena. Älä lisää sitä tiedostoihin AGENTS.md tai SKILL.md, versionhallintaan, repositorioon tallennettaviin komentoesimerkkeihin tai agentin lopulliseen transkriptiin. Käytä CI:ssä alustan salattua secrets storea ja välitä arvo vain deployment-vaiheelle. Täydellinen non-interactive-malli kuvataan artikkelissa CI/CD with DOCKUP_TOKEN.

Ennen kuin annat Codexille kirjoitusoikeudet, määritä sen käyttöoikeuksien rajat. Järkevä aloituslaajuus sisältää palveluiden etsinnän, deployoinnin, lokien lukemisen ja status-tarkistukset. Tietokantojen poiston, palveluiden tuhoamisen, tiimimuutokset ja konfiguraation siivouksen pitäisi edelleen vaatia hyväksynnän.

Miten Codex löytää tai luo oikean palvelun?

Tee etsinnästä ensimmäinen operaatio. Älä pyydä Codexia muuttamaan nimeä “Payments API” arvatuksi slugiksi:

dockup services --json

Jokainen tulos sisältää täsmällisen target-arvon muodossa project/service. Codexin pitäisi kopioida tämä arvo seuraaviin komentoihin ja palauttaa se yhteenvedossaan.

Kun palvelua ei ole olemassa, luo se Gitistä:

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

Komento luo palvelun, deployaa sen, odottaa deploymentin valmistumista ja kirjoittaa .dockup-linkin työskentelyhakemistoon. Jos Dockerfile on olemassa, sitä käytetään; muussa tapauksessa Nixpacks tunnistaa buildin automaattisesti.

Kun Codex menettää session tilan tai työnkulku suoritetaan uudelleen verkkokatkoksen jälkeen, sen pitäisi etsiä palvelut uudelleen ja tarkistaa täsmällinen target ennen muutosten tekemistä. Jos kohde on jo olemassa, jatka sen statuksesta ja deployment-historiasta sen sijaan, että lähettäisit uuden create-pyynnön.

Koko repository-first-jakso on kuvattu artikkelissa Git repository to production.

Miten Codexin pitäisi valmistella konfiguraatio ennen deployointia?

Pyydä Codexia tarkistamaan palvelun nykyiset metatiedot ennen niiden muuttamista:

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

Ympäristömuuttujien vastaus sisältää avaimet ja isSecret-merkinnät, mutta salaisten muuttujien arvot pysyvät piilotettuina. Codex voi lisätä tavalliset muuttujat ja salaisuudet erikseen:

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

Älä koskaan lisää production-salaisuutta tiedostoon dockup.yaml; manifesti sopii tarkistettavalle tavalliselle konfiguraatiolle, ei tunnistetiedoille. Olemassa olevia secret-muuttujia ei ylikirjoiteta eikä siivota config-as-code-työnkulussa.

Määritä palvelun kuunteluportti ja readiness check, kun niiden arvot ovat tiedossa:

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

Readiness gate tekee tuotantoympäristön varmennuksesta merkityksellisen. Alusta suorittaa blue-green-deploymentin ja ohjaa liikenteen vasta, kun uusi versio täyttää gate-ehdon.

Miten tuotantoympäristön varmennus vahvistaa päätetilan?

Olemassa olevalle palvelulle käytä yhtä komentoa:

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

Explicit timeout vastaa oletusarvoa, joka on 900 sekuntia, ja tekee työnkulun tarkoituksen näkyväksi. Exit 0 tarkoittaa, että deployment onnistui. Nollasta poikkeava tulos yhdessä tilan deploy_failed kanssa tarkoittaa, että build tai deploy epäonnistui. deploy_timeout tarkoittaa, että operaatio ei ollut vielä päätynyt, kun odotusaika päättyi.

Codexin oikean haarautumislogiikan tulee perustua prosessin statukseen:

Tulos	Codexin toiminto
Exit 0, status:"success"	Jatka health-, uptime- ja security-varmennuksiin
deploy_failed	Lue build-lokit ja tunnista ensimmäinen korjattavissa oleva virhe
deploy_timeout	Raportoi epävarmuus; tarkista status tai yritä uudelleen perustellulla timeout-arvolla
not_logged_in	Pysähdy ja pyydä kelvollista tokenia
needs_confirm	Pysähdy ja pyydä ihmisen hyväksyntä

Onnistuneen Codex-deployoinnin jälkeen kerää havaittavaa näyttöä:

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

Uptime-tarkistukset suoritetaan minuutin välein, ja ne sisältävät response time -tilastoja, kuten p95-arvon. Security-tulokset sisältävät imagen CVE-haavoittuvuudet ja konfiguraatiotarkistukset. Nämä signaalit eivät todista liiketoimintalogiikan toimivuutta, joten Codexin pitäisi suorittaa myös repositorion omat smoke-testit, jos sellaisia on saatavilla.

Miten Codexin pitäisi diagnosoida ja palautua epäonnistuneesta releasesta?

Build- ja runtime-virheet edellyttävät eri lokitietoja. Käytä uusinta build-outputia, kun deployment ei koskaan saavuttanut ajettavaa konttia:

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

Käytä runtime-lokeja, kun image buildattiin, mutta sovellus kaatuu, kuuntelee väärää porttia tai epäonnistuu käynnistymisen jälkeen:

dockup logs production/payments-api --json

Follow-tila on hyödyllinen pitkän buildin aikana:

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

JSON-tilassa follow-output on NDJSON-muodossa, joten Codex voi käsitellä jokaisen erän sen saapuessa. Stream päättyy deploymentin päätetilaan ja säilyttää todellisen virheen exit-koodin.

Palautuminen alkaa historiasta, ei arvatusta rollback-kohteesta:

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

Codexin pitäisi tunnistaa varmasti onnistunut deployment, ilmoittaa valittu ID ja säilyttää virhettä koskevat todisteet ennen sen uudelleenajoa. Sen ei koskaan pitäisi valita “toista kohdetta” tarkistamatta statusta ja aikaleimoja.

Hyödyllinen loppuraportti sisältää seitsemän kenttää: kohde, branch tai commit, deployment ID, exit-koodi, päätetila, tuotannon URL ja jatkotoimet. Tämä muoto tekee jokaisesta Codex-deployoinnista ihmisen tai myöhemmän automaatiovaiheen tarkistettavan.

Tiivis varmennusskripti

Tämä shell-malli pitää deployoinnin ja diagnostiikan samassa läpinäkyvässä kontrollivirrassa:

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

Skripti ei etsi onnistumislauseketta grepillä. Se luottaa CLI:n exit-koodiin, säilyttää deploymentin JSON-datan ja epäonnistuu, jos tuotanto ei saavuttanut onnistunutta tilaa.

Tee uudelleenyrityksistä havaittavia, älä näkymättömiä

Agent-sessiot voivat keskeytyä sen jälkeen, kun operaatio on alkanut, mutta ennen kuin tulos päätyy transkriptiin. Seuraavan Codex-ajon ei pitäisi toistaa kaikkia muutoksia sokeasti. Sen pitäisi etsiä palvelu uudelleen, tarkistaa viimeisin deployment ja selvittää, saavuttiko edellinen operaatio päätetilan.

Codex-deployoinnin runbookin pitäisi luokitella komennot sellaisiksi, jotka voi suorittaa turvallisesti uudelleen, jotka voi suorittaa uudelleen vasta tarkistuksen jälkeen tai jotka vaativat hyväksynnän. Lukukomennot voi suorittaa turvallisesti uudelleen. Palvelun luonti edellyttää ensin etsintää. Uusi deploy on uusi tuotantotapahtuma, ja se pitäisi kirjata sellaisena. Siivous ja muut tuhoisat toimet ovat edelleen ihmisen päätöksiä.

Erota alustan varmennus sovelluksen varmennuksesta

Dockup voi osoittaa, että build valmistui, kontti saavutti readiness-tilan ja minuutin välein suoritettavat probe-tarkistukset havaitsevat julkisen palvelun. Codexin pitäisi silti suorittaa sovelluskohtaiset tarkistukset: julkinen health endpoint, autentikoitu testipyyntö tai repositorion tarjoama smoke-testi, joka ei muuta asiakasdataa.

Lopputuloksessa pitäisi ilmoittaa molemmat tasot. ”Alustan deployment onnistui” ja ”sovelluksen smoke-testi läpäistiin” ovat eri väitteitä. Jos saatavilla on vain ensimmäinen tieto, Codexin pitäisi sanoa se sen sijaan, että se tiivistäisi epävarmuuden vihreäksi valintamerkiksi.

Varmista asennettu komentopinta ennen automaatiota

Uudelleenkäytettävän Codex-tehtävän pitäisi alkaa tarkistamalla dockup skill status --json ja avaamalla ajantasainen CLI-referenssi, kun tehtävä riippuu vähemmän tutusta optiosta. Näin estetään sessiota noudattamasta esimerkkiä, joka on kirjoitettu toiselle julkaisulle.

Tarkistus on erityisen hyödyllinen ephemeral runner -ympäristöissä, joissa uusi globaali npm-asennus voi poiketa kehittäjän kannettavalla tietokoneella olevasta versiosta. Codex voi raportoida skillin tilan ennen ensimmäistä tuotantoon kohdistuvaa kirjoitusoperaatiota, mikä tekee deployment-tietueesta toistettavan.

Lopullinen luovutus

Säilytä todisteet.

Pidä kohde näkyvissä

Palauta täsmällinen palvelukohde loppuraportissa.

Säilytä lähdettä koskeva päätös

Kirjaa, käyttikö Dockup repositorion Dockerfile-tiedostoa vai Nixpacksia. Tämä tieto auttaa seuraavaa Codex-sessiota valitsemaan oikean build-lokin ja estää lähdehakemiston muutoksen tulkitsemisen alustan häiriöksi.

Kirjaa myös, onko automaattinen deploy pushin yhteydessä käytössä. Muuten manuaalinen agent-release ja pushin käynnistämä release voivat mennä päällekkäin ja luoda samasta tutkinnasta kaksi tuotantotapahtumaa.

Vie työnkulku tuotantoon

Suorita ensimmäinen Codex-deployointi kertakäyttöiseen tai vähäriskiseen palveluun ja siirrä sama varmennettu komentokontrakti sen jälkeen tuotantoon.

npm install -g dockup-cli
dockup skill install

Ensimmäinen komento asentaa CLI:n. Toinen asentaa Claude Coden ja Codexin kanssa yhteensopivan Dockup-skillin. Aloita maksutta osoitteessa app.dockup.ai.

Usein kysytyt kysymykset

Voiko Codex deployata uuden Git-repositorion yhdellä komennolla?

Kyllä. dockup create voi luoda palvelun, deployata sen, odottaa päätetulosta ja linkittää nykyisen hakemiston, kun sitä käytetään optioiden --deploy, --wait ja --link kanssa.

Miten Codexin pitäisi tunnistautua Dockupiin?

Käytä prosessin ympäristössä muuttujaa DOCKUP_TOKEN ja varmista se komennolla dockup whoami --json. Tämä välttää interaktiivisen selainkirjautumisen sandbox- ja CI-ympäristöissä.

Mikä todistaa Codex-deployoinnin onnistuneen?

Deploy-komennon täytyy päättyä exit-koodiin 0, kun se on suoritettu option --wait kanssa, ja sen JSON-datan täytyy ilmoittaa onnistunut päätetila. Jatka tarkistuksilla status, uptime ja sovelluksen smoke-testit.

Voiko Codex lukea tuotannon salaisuuksia Dockupista?

Ei. Salaisten muuttujien arvot peitetään tulosteessa. Codex voi asettaa tai korvata salaisuuden, mutta se ei saa tallennettua arvoa näkyviin, kun konfiguraatiota listataan.

Mitä Codexin pitäisi tehdä needs_confirm-tilanteessa?

Sen pitäisi pysähtyä ja pyytää ihmiseltä nimenomainen hyväksyntä. Virhe tarkoittaa, että tuhoisaa komentoa yritettiin suorittaa ilman vaadittua --yes-vahvistusta.