Ecs-deploy

Version 1.5.0 add support for deployments of services which are running with scheduling strategy/service type: `DAEMON`.

A received task definition contains a new `compatibilities` parameter (used for Fargate), but it is not possible to use this task definition AS IS to register a new revision. The API does not accept the `compatibilities` parameter.

New Feature: Automated Rollback

If a deployment failed (due to e.g. a timeout or a task placement error) ecs-deploy now is able to automatically rollback the service to the previous task definition revision.
This can be achieved with the new flag `--rollback`. By default, a failed deployment is **not** rolled back. The default behavior will change in a future version.

New Feature: Keep old task definitions

By default, the old task definition gets deregistered in ECS after an successful deployment. This can be prevented by passing the new flag `--no-deregister`. The old task definition then will stay active within ECS.

Improvement: Print ecs-deploy version

The current version of ecs-deploy can not be printed via `ecs --version`. This might be useful for debugging.

Improvement: More explicit error handling

ecs-deploy now only handles ECS errors. All other errors are bypassed, which might simplify debugging issues with 3rd-party-dependencies.

This hotfix solves an issue with task definitions, which do not define a Task Role ARN.

For full change log, see: https://github.com/fabfuel/ecs-deploy/releases/tag/1.3.0

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.

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.