I'm trying to fit together the last piece of an ECS deployment pipeline and I'm not sure how to go about it, and the bits I've found on how others have don't seem to fit with how I'm approaching the problem. So I'm wondering if I need to rethink the entire approach. I have an infrastructure repo that has Pulumi code for defining all sorts of things. This includes all the stuff required for the ECS cluster, including the container definitions themselves for an app. Right now it's using a statically-defined

image

. In the apps' repos, I have Github Actions rules that build the containers and push them to ECR. Now I need to close the gap between these two. My thought was that I'd trigger CodeDeploy from Actions (we're doing that for the old process I'm replacing) and that would handle the deployment. The problem is that the next time I run

pulumi up

, it'll re-deploy some old version of the app. Ideally I'd just leave that field out, but it is required by the SDK. The few things I've found about how other people do this is to run pulumi in the deploy pipeline and pass it the container version in an environment variable. I don't particularly want to run all of the infrastructure configuration stuff on a code deploy, though (and especially don't want changes to infra to potentially roll out while a developer is running what they think is a normal code deploy). But is that what I have to do?

The app repo should handle deploying to ECR in one Pulumi project. There should be another project, probably in the same repo, with references to that project's outputs (for ECR info), and the infrastructure project's output (for the cluster info). That project creates TaskDefinitions. Each time you

up

stacks in this project, you'll create a new version of the TaskDefinition, and ECS will handle deploying the image and draining old containers.

I already have the container build and push process working outside of pulumi; that should be ok as long as I can pass the resultant container information in to https://github.com/pulumi/actions , right?

You don't need to, no. You just need to create a new task definition version in ECS.

Right, so I guess to clarify more, if I want to define the task definition with all its various parameters in Pulumi, then the container version also needs to be Pulumi-ized. So I can't pick and choose and have Pulumi define things like the container memory limits but not the image version. Which I guess is fine.

The task definition version is a single JSON document. If you want to build parts of it in one system and parts in another, you can do that, but only by having one system ingest the other system's outputs (or contributing values).

Well, ideally I was thinking not of changing the definition, but rather having the definition include dynamism.

nginx:latest

is an example, where it's referring to a tag but that tag can change to whatever.

Ah. Major warning: don't ever do that.

Yeah, I actually want a specified version

Yes, do that. Build the version, release it to ECR, then when you're ready to deploy to dev, create a new dev TaskDefintion. A few hours later, you'll create a new staging TaskDefinition.

Correct in that it's accurate, but a pain in the ass, given that some of those are infrastructure concerns and the others are app concerns

I think your thinking is not aligned with devops. Changing the app version is not an app-only concern.

Well this is devolving to philosophical discussions on things we can't actually change, so I don't think that's useful to continue here. But thank you for your help - that's helped me see what my options are