<@UB2EH889X> the ECS deployment issue seems to be ...
# office-hoursd
Duffy Gillman
10/08/2025, 7:38 PM@Erik Osterman (Cloud Posse) the ECS deployment issue seems to be fairly universal to all code-dependent workloads in all cloud providers when working with Terraform. Azure, GCP, AWS.. I've fought with it in every provider for serverless functions, container orchestration, and "pushbutton" app hosting like Elastic Beanstalk. All of the provider resources expect a version of a deployable artifact, and from thenceforth Terraform state wants to keep on top of that version, risking catastrophic rollback if you've advanced version in CI/CD but not kept some version of truth up to date for the originating Terraform module.
đź’Ż 1
Duffy Gillman
10/08/2025, 7:43 PMadditional twist... I've run into the problem with ECS and with VM managed instance sets within GCP: by having a container definition AND a task definition (similarly in GCP, a VM image and an instance template), you have not one, but two versioned artifacts: one depending on another. Both are typically created in Terraform and need to be mindful of version changes that have come from CI/CD
Duffy Gillman
10/08/2025, 7:46 PMthe Real Solution™ (if I may be so bold) is for the cloud host APIs to support the existence of a workload defined, but not yet with a build artifact. This would allow (possibly) building configuration around the resource and deferring code deployment completely to CI/CD
e
Erik Osterman (Cloud Posse)
10/08/2025, 8:33 PMcc @Igor Rodionov
Erik Osterman (Cloud Posse)
10/08/2025, 8:34 PMthe Real Solution™ (if I may be so bold) is for the cloud host APIs to support the existence of a workload defined, but not yet with a build artifact.The closest thing that I've seen in AWS relating to this is the fact that a CloudFormation template can be pulled dynamically from a Git repo.
Erik Osterman (Cloud Posse)
10/08/2025, 8:35 PMOne consideration I've had is: what if we used CloudFormation for the ECS task deployment piece itself?
d
Duffy Gillman
10/08/2025, 8:55 PMOther than, "ick", it could be the solution. Though I'd argue it's equivalent to storing the .hcl in the Git repo and running it. I guess the advantage of CloudFormation is it may be easier to pass information needed by the task (VPC ID, Secret ARNs, etc) there than to pass the same to a GitHub Action workflow.
There are a bunch of ways to attack this. I think the general solutions are:
• single-source ECS service maintenance from one and only one system, or
• create a single source of truth that Terraform and CI/CD rely on for ECS service state
The single-source for the first option could very easily be CloudFormation. But it could also be TF in a code repo, or a python Lambda using
boto3