If you manage different environments of your system in multiple different AWS accounts, you can now easily assume a deployment role in the target account in which your ECS cluster is running. You only need to provide --account with the AWS account id and --assume-role with the name of the role you want to assume in the target account. ecs-deploy automatically assumes this role and deploys inside your target account:

Example

    $ ecs deploy my-cluster my-service --account 1234567890 --assume-role ecsDeployRole

• new options to set task-wide CPU and memory limits (--task-cpu and --task-memory)
• CI via GitHub Actions
• re-enable automatic publication of Docker images

New Features

Set Docker Labels

You can not set Docker labels to your containers via: $ ecs deploy my-cluster my-service -d webserver somelabel somevalue

Set CPU and Memory reservation

via: --cpu and --memory

Set essential and privileged flags

via: --privileged <container_name> True|False or --essential <container_name> True|False

Set logging configuration

via e.g. --log <container_name> awslogs awslogs-group <log_group_name>

Set port mapping

via: --port <container_name> <container_port> <host_port> and overwrite existing via --exclusive-ports

Set volumes and mount points

via: --volume <volume_name> /host/path Please see README for more details

Set healthchecks

via: --health-check webserver "curl -f http://localhost/alive/" 30 5 3 0

Environment via .s3 files on S3

You can now use environment files stored on S3 to set the container environment variables via: --s3-env-file container arn:aws:s3:::/bucket_name/object_name

Other changes & improvements

• migrate CI/CD from travis-ci.org to travis-ci.com
• run tests in Python 3.7, 3.8, 3.9
• upgrade Docker environment to Python 3.8

New Features

Pass environment variables via .env file(s)

Instead of passing all environment variables for your containers separately, you can now pass the path to one or more .env files:

ecs deploy my-cluster my-service --env-file nginx env/nginx.env

Thanks a lot @thormikkel2 for your contribution

Define New Relic revision explicitly

By default, ecs-deploy uses the provided tag for tracking releases in New Relic. Optionally you can now provide an explicit --newrelic-revision to define the tracked revision/version yourself.

ecs deploy my-cluster my-service -t 1.2.3 --newrelic-revision "v1.2.3 (20201030)"

Thanks a lot @blytheaw for your contribution

• Add argument platform-version
• Bump required versions of botocore and boto3 to support e.g. Fragte EFS mounts

New major updates in this version:

Slack Notifications

Just by providing a Slack integration URL, ecs-deploy will now automatically notify you about deployments. You will receive a message when the deployment starts as well as when the deployment finished either successfully or failed. The Slack URL can be provided either by the new option --slack-url or as environment variable SLACK_URL. With the new option --slack-service-match (env var SLACK_SERVICE_MATCH) you can control, which services you want to be notified about (e.g. if you only want to notify production deployments).

Diff

If you manage your task definitions in a separate tool or workflow, it can be very helpful to see the differences between two specific revisions of a task defition. This now easily can be achieved with the new command ecs diff. All you need to provide is the task family name as well as two different revision numbers:

ecs diff my-task 10 11

You will get a colored overview of all differences between those two revisions.

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