Fix task def drift: Terraform owns revisions, deploy just restarts#50
Merged
Conversation
ecs-deploy was creating new task def revisions from the latest family revision, which lost Terraform's structural changes (readonlyRootFilesystem, user, volumes). Now: - ecs-deploy uses --force-new-deployment (no new revisions) - Remove ignore_changes = [task_definition] from ECS service module - Remove update-task-def.sh (no longer needed) Terraform owns the task definition structure. Docker build pushes :latest. Deploy just forces ECS to pull the new :latest image.
Terraform PlanNo changes — infrastructure is up to date. Plan output |
Alexanderamiri
added a commit
that referenced
this pull request
May 9, 2026
## Summary - **ecs-deploy.sh**: Replace register-task-definition + update-service with `--force-new-deployment`. No new revisions created — ECS just pulls the latest image. - **ecs-service module**: Remove `ignore_changes = [task_definition]` so Terraform can update the service when structural changes happen (security hardening, volumes, etc.) - **Remove update-task-def.sh**: No longer needed. ## Problem ecs-deploy was creating new task def revisions by copying the "latest" family revision and swapping the image tag. This lost Terraform's structural changes (readonlyRootFilesystem, user, /tmp volume) because the deploy revisions became the "latest" in the family, overwriting Terraform's work. Security Hub kept flagging ECS.5 because the running revision never had the fix. ## New flow 1. **Terraform** creates/updates the task definition (with security hardening, correct image = `:latest`) 2. **docker-build** pushes new image as `:latest` to ECR 3. **ecs-deploy** calls `--force-new-deployment` — ECS pulls the new `:latest` image using the existing TF-managed task def ## Test plan - [ ] Merge to main - [ ] Trigger platform-test-app CI - [ ] Verify running task def has `readonlyRootFilesystem: true`, `user: "1000"`, `/tmp` mount - [ ] Verify deploy step is faster (~1 min with 30s drain) - [ ] Verify Security Hub ECS.5 finding resolves
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
--force-new-deployment. No new revisions created — ECS just pulls the latest image.ignore_changes = [task_definition]so Terraform can update the service when structural changes happen (security hardening, volumes, etc.)Problem
ecs-deploy was creating new task def revisions by copying the "latest" family revision and swapping the image tag. This lost Terraform's structural changes (readonlyRootFilesystem, user, /tmp volume) because the deploy revisions became the "latest" in the family, overwriting Terraform's work. Security Hub kept flagging ECS.5 because the running revision never had the fix.
New flow
:latest):latestto ECR--force-new-deployment— ECS pulls the new:latestimage using the existing TF-managed task defTest plan
readonlyRootFilesystem: true,user: "1000",/tmpmount