Preskoči na sadržaj

Kako radi deploy verb (ECS mod)?

TL;DR

Native Python port (boto3) atlassian/aws-ecs-deploy reference pipe-a. Renderuje consumer-ov task-definition template sa novim image-om i zove AWS ECS direktno. Jednofazni (nema Infisical sync, nema tag_secret). --wait mapira na boto3 services_stable waiter. VendorAuthError se NE koristi — boto3 tipizovane ClientError-e se čuvaju u state kao register-failed:<code> / update-service-failed:<code>.

Kada se koristi

Servis ima deploy.mode: ecs u services.json. To znači:

  • consumerov repo ima ECS task-definition template
  • image se push-uje na Docker Hub / GHCR / sl.
  • deploy se radi preko AWS ECS API-ja direktno, ne preko Coolify

Šta radi, korak po korak

  1. Učitaj ci-state.json (koji servis, koji tag, koji env).
  2. Učitaj AWS credentials (env: AWS_* standard).
  3. Lazy import boto3 — ako nije instaliran na runneru, exit 2 sa jasnom porukom (vidi ci/aws/CLAUDE.md "Runner setup").
  4. Render task-definition template sa novim image poljem (koristeći services.<name>.deploy.ecs.task_definition_template).
  5. Register novu task-definition revision (boto3 register_task_definition).
  6. Update service da koristi novu revision (boto3 update_service).
  7. Ako --wait (default): čekaj services_stable waiter.
  8. Zapiši rezultat u ci-state.json:
  9. services.<name>.deploy.status (deployed | failed)
  10. services.<name>.deploy.task_definition_arn (na success)
  11. services.<name>.deploy.error (na failure: AWS error code)

boto3 auth handling (izuzetak od VendorAuthError)

ci/aws/api/api.py koristi boto3 klijente, ne raw urllib. boto3 auth failure-e tipizira kao ClientError sa kodovima kao AccessDeniedException, InvalidClientTokenId, ExpiredToken, itd.

Ovi se NE remapuju na VendorAuthError (exit 2). Umjesto toga, boto3 kod se čuva u ci-state.json tačno onako kako ga je AWS vratio (operator treba preciznu dijagnostiku, ne generički "auth failed").

{
  "services": {
    "api": {
      "deploy": {
        "status": "failed",
        "error": "register-failed:AccessDeniedException"
      }
    }
  }
}

Ovo je dokumentovani izuzetak u ci/_errors.py "AWS / ECS" — jedini vendor koji čuva boto3 kod umjesto da ga remapuje.

--wait i health check

  • --wait (default): čeka services_stable waiter. Servis se smatra deployed kad ECS potvrdi da je stable.
  • HEALTH_CHECK Make var: ime health check komande za custom verification (curl, itd.). Pored boto3 waiter-a.
  • NO_WAIT=true: preskoči waiter. Manje sigurno, brže.

Jednofazni vs Coolify (zašto nema Phase 1)

ECS deploy nema:

  • Infisical sync (ECS env vars idu preko task-definition, ne preko Coolify env)
  • tag_secret (nema Docker image coordinate sem u task-definition)

Sav env state ide kroz task-definition template render. Consumer odlučuje kako se secrets čuvaju (SSM Parameter Store, Secrets Manager, itd. — render-time interpolacija).

Failure modes

  • ClientError: AccessDeniedException → zapiši u state, ne aborta (soft default). Ako failure_policy: strict — aborta.
  • ClientError: InvalidParameterException → image/task-def mismatch; provjeri template.
  • services_stable waiter timeout → --wait se drži defaultno; NO_WAIT=true za skip.

Vidi i