You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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!
The text was updated successfully, but these errors were encountered:
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 theimage_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
andimage_tag
in the Parameter Store, why not storedesired_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 forimage_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
fromlifecycle
and then implementing a data source based on the value fordesired_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!
The text was updated successfully, but these errors were encountered: