allowing desired_count via the SSM Parameter Store

[FlorinAndrei]

Is your request related to a problem? Please describe.

I need to migrate to Terraform a good amount of infrastructure created manually in the AWS Console. The existing ECS services currently do not have autoscaling enabled, and may not have it enabled in the foreseeable future, since the demand is steady and the scale is not huge.

What would work great in this case is an ECS Service module that does not ignore desired_count. Unfortunately, the current module always ignores this variable.

I am aware of the workaround via local-exec described here:

https://github.com/terraform-aws-modules/terraform-aws-ecs/blob/master/docs/README.md

It's not bad, but it seems... hackish, for lack of a better word.

In the same document, below the desired_count workaround, a method is described to construct a container definition by taking the image_tag value from the SSM Parameter Store. That's exactly what I need / want to do for the image tags, to implement deployments.

But here's the thing: if we store repository_name and image_tag in the Parameter Store, why not store desired_count there as well? That would still allow external entities to change the internal settings of the service, while avoiding conflicts with Terraform. Same logic as for image_tag.

What would be the minimal change to the code in this repo to allow storing desired_count in the Parameter Store and optionally using it in real life?

Would it be as simple as removing desired_count from lifecycle and then implementing a data source based on the value for desired_count stored in the Parameter Store?

Of course, the change should be compatible with the current behavior of the module, so I'm guessing a boolean variable would have to be created (called e.g. ignore_desired_count, by default true).

And autoscaling would have to be disabled for all this to work.

Suggestions are welcome. I am willing to give it a try and implement it correctly in a PR. Thanks!

[github-actions[bot]]

This issue has been automatically marked as stale because it has been open 30 days with no activity. Remove stale label or comment or this issue will be closed in 10 days

[github-actions[bot]]

This issue was automatically closed because of stale in 10 days

[github-actions[bot]]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.