Use actual ECS task definition file, drop name req

[Tom Shawver (TomFrost)]

Previously the task definition file required by this step was actually just an array of container definitions -- one of three main sections of a task definition. This commit reads the task definition file as a full ECS task definition, including keys for the family name and the optional 'volumes' section which previously couldn't be defined in this step at all. Since the family is now defined in this file, the need to specify the family as an argument in this step has been eliminated, and the argument has been removed.

[Nicolas Huray (nhuray)]

Hey I checked you PR and I would like to integrate it ASAP but I merged another PR since.

Could you rebase your branch please?

[Tiago Braga (tibraga)]

Hello,

When it will to merge with this fix?

Thanks!

[Tom Shawver (TomFrost)]

Hi there! Sorry, I no longer use this codebase (nor Wercker) and I am no longer part of the org under which I originally opened this PR. Others are welcome to take over my contribution, but I'm unable to maintain it.

With that said, however: The main point of this script is to automate the downscaling/upscaling of ECS service tasks to roll out a new task definition, however ECS has since been updated to handle this itself. When defining an ECS cluster, you can now specify the percentage of instances that must stay online as the new version cycles in, as well as the number of extra instances over the desired amount that can be launched during this process. This eliminates the need to automate a scale down/scale up, and the AWS CLI tool can read a full task json file and upload it as a new revision to an existing task. That reduces this entire script to two calls with the AWS CLI: One to upload the new task definition, and another to update the service to use the new revision.

Here's a sample of how I'm doing it now. I recommend creating a file named ecs_task.json.tpl that contains your ECS task json, but with placeholders in the format ${VARIABLE_NAME} for things that should need to be added dynamically, such as the tag name for the build you want to deploy. If you export environment variables named the same of those placeholders, you can use envsubst from the gettext library to replace your placeholders with the values of the env vars. The first line of this sample shows the command to do that. Note also that this depends on the json tool from NPM, installable with npm i -g json. You can replace it with any other cli json processor.

envsubst < ${ECS_TASK_TEMPLATE} > ${ECS_TASK_JSON}
RESULT=`aws --region ${AWS_REGION} ecs register-task-definition --cli-input-json file://${ECS_TASK_JSON} --output json`
TASK_ARN=`echo ${RESULT} | json taskDefinition.taskDefinitionArn`
aws --region ${AWS_REGION} ecs update-service --cluster ${ECS_CLUSTER} --service ${ECS_SERVICE} --task-definition ${TASK_ARN} --output json

Required env vars:
ECS_TASK_TEMPLATE - path to your ecs_task.json.tpl
ECS_TASK_JSON - path to write the processed ecs_task.json (can be as simple as /tmp/ecs.json)
AWS_REGION - The region, such as us-east-1, to deploy to
ECS_CLUSTER - The ECS cluster name to deploy into
ECS_SERVICE - The name of the service to update to the new task definition

All this assumes that your ecs_task.json has the appropriate fields to determine which task to upload to.