The order of the containers generated at initialization in ecs-task-def.json is random

[yutaro0602]

The order of the containers generated at initialization in ecs-task-def.json is random, and it's proving to be problematic.
As shown below, I am replacing the image definitions within the taskdef.json file that is generated by 'ecspresso init', and then deploying it.

'jq \'.containerDefinitions[0].image = "\'${BACKEND_FULL_IMAGE_PATH}\'"\' ecs-task-def.json > temp.json && mv temp.json ecs-task-def.json',
'jq \'.containerDefinitions[1].image = "\'${FRONTEND_FULL_IMAGE_PATH}\'"\' ecs-task-def.json > temp.json && mv temp.json ecs-task-def.json',

I am operating in the order of the array, but the order in which these containers are returned is somewhat irregular. It would be extremely helpful if Ecspresso could output the containers in alphabetical order.

[fujiwara]

@yutaro0602 Thank you! I think it desirable to ecspresso init result to be stable. So I'll fix to sort the elements in definition files that are created by init.

By the way, I did not suppose to modify definition files created by init by jq. Because ecspresso can read definition files as template, typical use case is modifying by the template.

[yutaro0602]

@fujiwara
I appreciate your willingness to assist.
You may be wondering why we're not using a template, so let me give you some background.

Currently, we are using ecspresso within the buildspecObject during the build time of CodePipeline. Furthermore, we're managing it with CDK.
When we initially considered deploying using CodeDeploy, the question arose on how to prepare taskdef.json, buildspec.yaml, and appspec.yaml for each environment.
That's when we discovered ecspresso, and particularly appreciated its ability to generate configuration files based on the current ECS setup, so we decided to use it.
When provisioning ECS infrastructure with CDK, environment-specific values are set, so our approach is to get those in the pipeline, swap out only the Docker images, and deploy.
We understood that we could use template syntax, but we had to parametrize too many items (target group, subnet, environment variables, log group, among many others), and felt that it was sufficient for deployment, so we opted to generate it with each deploy without preparing the original configuration file.
However, we recently realized the inconvenience of this approach from an operational perspective. As you may know, when using CodeDeploy as the deploymentController for ECS, task definitions cannot be updated via CDK.
If we neglect to write the default template language and acrobatically change the contents of the task definition like jq without preparing a configuration file, we must add that acrobatic operation when we want to add new items. However, by cleverly structuring the CDK stack, I'm considering the possibility of a method where resources including task definitions can be deleted quite easily as stateless stacks and regenerated.

From the above background, we're currently operating in such a way that we mirror the current ESC configuration without preparing the default configuration file each time, and only make necessary changes (replacing images). I believe ecspresso is a fantastic OSS. I'll be attending the jaws-ug container department on the 8th, and if there's a chance to chat then, I'd appreciate it.
I apologize for the lengthy message.