Releases: fabfuel/ecs-deploy
Environment diffs, networking mode & placement constraints
This release adds two new flags to the deploy action:
New Feature: --diff / --no-diff
By default, ecs deploy prints a diff of all adjustments to your task definition. If you do not want to print the differences in e.g. the environment you can suppress the output with the new --no-diff flag.
Improvement: Environment diffs
Until now, when changing or adding an environment variable, the complete old and new environment was printed to the screen. From now on, ecs deploy only prints those environment variables and values, which have been changed. This prevents exposing sensitive data to the console. To completely suppress the diff, use the --no-diff flag, described above.
Fix: Support for networking mode and placement constraints
You can not change the networking mode or placement constraints via ecs deploy yet, but from now on, the settings for networking mode and placement constraints retain in the newly created task definition.
Capacity warnings & custom task definitions
This release adds two new parameters to the deploy action:
--ignore warnings
If your cluster is undersized or the service's deployment options are not optimally set, the cluster
might be incapable to run blue-green-deployments. In this case, you might see errors like these:
ERROR: (service my-service) was unable to place a task because no container instance met all of
its requirements. The closest matching (container-instance 123456-1234-1234-1234-1234567890) is
already using a port required by your task. For more information, see the Troubleshooting
section of the Amazon ECS Developer Guide.
There might also be warnings about insufficient memory or CPU.
To ignore these warnings, you can run the deployment with the flag --ignore-warnings
$ ecs deploy my-cluster my-service --ignore-warnings
In that case, the warning is printed, but the script continues and waits for a successful
deployment until it times out.
--task
To deploy any task definition (independent of which is currently used in the service), you can use the --task parameter. The value can be:
A fully qualified task ARN
$ ecs deploy my-cluster my-service --task arn:aws:ecs:eu-central-1:123456789012:task-definition/my-task:20
A task family name with revision
$ ecs deploy my-cluster my-service --task my-task:20
Or just a task family name. It this case, the most recent revision is used
$ ecs deploy my-cluster my-service --task my-task
Important
ecs will still create a new task definition, which then is used in the service.
This is done, to retain consistent behaviour and to ensure the ECS agent e.g. pulls all images.
But the newly created task definition will be based on the given task, not the currently used task.
Task Role Support
Version 1.1.0 adds support for ECS' task role capabilities and boto's --task-role-arn option.
It introduces a new CLI parameter -r or --role to set a task role ARN on demand.
New command: run task & New Relic setup via environment variables
- Run a one-off task, based on an existing task definition
- Set up New Relic credentials via environment variables:
Environment Management & New Relic deployment recording
Environment Management
Add or change environment variables with the new -e or --env parameter:
$ ecs deploy my-cluster my-service -e webserver SOME_VARIABLE SOME_VALUE
https://github.com/fabfuel/ecs-deploy#set-an-environment-variable
New Relic deployment recording
If providing an API key and Application ID via the new parameters --newrelic-apikey and --newrelic-appid ecs will record the deployment in New Relic.
Optionally you can overwrite the user who triggered the deployment via --userand add additional information about the changes via --comment.
ecs deploy my-cluster my-service -t 1.2.3 --newrelic-apikey 1234567980 --newrelic-appid 12345678 --comment "New Feature XY" --user foobar