Files
acdl/modules/l1/ecs-service
Jon Chery 90be5839ab feat(P26): 3 platform pipelines + release job with semver/tag updates
Phase 26 — platform-pipelines-and-release-automation:

- platform-test.yml: PR pipeline (lint + unit-test + integration-test +
  schema-validation) replacing ci.yml for PRs; integration-test runs
  run_platform.sh --check-only for every contracts/*.yaml
- primitives-plan.yml: PR pipeline with matrix over all 9 L1 primitives
  (s3, vpc, ecs-cluster, ecs-service, iam-role, alb, ecr, cloudfront, waf)
- patterns-plan.yml: PR pipeline with matrix over all 2 L2 modules
  (static-assets, microservice)
- release.yml: push-to-main pipeline computing next semver tag (PATCH for
  regular phases, MINOR for milestone completions), updating floating
  MAJOR.MINOR + MAJOR tags, and creating GitHub releases
- run_primitive_plan.sh: plan-only/check-only runner for a single L1
  primitive (adapter compile + structure validation offline)
- run_pattern_plan.sh: plan-only/check-only runner for a single L2 pattern
  (environment check + contract validate + resolve + adapter + structure
  validation offline)
- contracts/microservice.yaml: sample consumer contract for the
  microservice L2 module (schema-compliant scalar inputs)
- instance.json for 8 L1 primitives (vpc, ecs-cluster, ecs-service,
  iam-role, alb, ecr, cloudfront, waf) so the primitives-plan matrix can
  run the adapter offline; s3 already had one
- tests/test_release_logic.py: unit test for semver computation
  (PATCH bump, MINOR bump on milestone, floating tag format)
- tests/test_pipeline_contract.py: 19 new tests validating the 4 platform
  workflows exist and conform (stages, matrices, triggers, permissions)

DEVIATION: The microservice pattern (run_pattern_plan.sh --check-only
microservice + run_platform.sh --check-only contracts/microservice.yaml)
fails at the adapter stage due to a pre-existing resolver ref-id mismatch
for multi-resource L1s (resolver emits ref:vpc.subnet_ids but the expanded
resource id is vpc-subnet). This predates Phase 26 and is out of scope for
pipeline automation; the static-assets pattern passes end-to-end. The
microservice contract is schema-valid and resolves correctly (11
resources); only the adapter compilation of multi-resource L1 refs fails.

VERIFICATION:
- bash scripts/run_ci.sh: PASS (lint + test + check-only)
- python3 -m pytest tests/ -v: 266 passed
- bash scripts/run_primitive_plan.sh --check-only s3: PASS
- bash scripts/run_pattern_plan.sh --check-only static-assets: PASS
- All 9 primitives pass run_primitive_plan.sh --check-only
- All instance.json validate against stack.schema.json

---ci---
project: acdl
phase: 26
milestone: v1.7
status: execute
---/ci---
2026-07-22 20:13:36 +00:00
..

ecs-service — ECS Fargate service (task definition + service)

Module kind: primitive | Version: 1.0.0

An ECS Fargate service with its task definition. Runs a container image on Fargate, optionally behind an ALB target group. This is a multi-resource module: it creates a task definition and a service that runs it.

Resources

Resource Type Purpose
task_definition aws_ecs_task_definition Fargate task definition with container image, CPU, memory, port, env
service aws_ecs_service Fargate service running the task definition in a cluster + subnets

Inputs

Name Type Required Default Description
image string yes ECR image URL for the task container
port number yes Container port the service listens on
cpu number no 256 Task CPU units (Fargate)
memory number no 512 Task memory in MiB (Fargate)
env string no Environment variables as a JSON map string
cluster_arn arn yes ECS cluster ARN (from ecs-cluster)
subnets string yes Comma-separated subnet ids (from vpc)
security_group string yes Security group id for the service ENIs
lb_target_group_arn arn no Optional ALB target group ARN (from alb)
region string yes AWS region the service is created in

Outputs

Name Type Description
service_arn arn The ECS service ARN
task_def_arn arn The ECS task definition ARN

Usage

{
  "id": "service",
  "type": "aws:ecs:task_definition",
  "module": "ecs-service@1.0.0",
  "inputs": {
    "image": "581513795199.dkr.ecr.us-east-1.amazonaws.com/acdl-microservice:latest",
    "port": 8080,
    "cpu": 256,
    "memory": 512,
    "cluster_arn": "ref:cluster.cluster_arn",
    "subnets": "ref:vpc.subnet_ids",
    "security_group": "ref:roles.role_arn",
    "region": "us-east-1"
  }
}

The image, port, and env inputs are compiled into a container_definitions JSON block by the adapter. The service is placed in the cluster with the given subnets and security group, and optionally wired to the ALB target group if lb_target_group_arn is provided.

Compliance extension points

  • CloudWatch Logs — add logConfiguration to the container definition with a log group + retention policy (SOX, SOC2 CC7.2, HIPAA §164.312(b), DORA ICT incident logging).
  • Task execution role separation — add a separate aws_iam_role for execution vs. the task role (SOC2 CC6.3 segregation of duties at runtime).
  • Secrets injection — add secrets block referencing AWS Secrets Manager / SSM Parameter Store with KMS encryption (SOC2 CC6.1, HIPAA §164.312(a)(2)(iv)).
  • Execute command — add enable_execute_command with KMS encryption for session audit (SOC2 CC7.2).
  • Deployment circuit breaker — add deployment_circuit_breaker block for resilience (SOC2 CC9.1, DORA operational resilience).
  • Health check — add a health_check block to the target group (currently missing despite the contract schema having a healthcheck field).

Versioning

1.0.0 — interface MAJOR, behavior MINOR, lifecycle PATCH. MAJOR bumps require a new registry entry (immutable publication); old entries enter a 12-month deprecation window.