Ecs-deploy

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.