Containers-roadmap: [ECS] [Deploys]: Add specific deploy start and end notifications

Created on 28 Apr 2020  路  4Comments  路  Source: aws/containers-roadmap

Community Note

  • Please vote on this issue by adding a 馃憤 reaction to the original issue to help the community and maintainers prioritize this request
  • Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment

Tell us about your request
What do you want us to build?
Cloudwatch events for deploy triggering and ending for ECS Rolling Deploys.

Which service(s) is this request for?
ECS (applies to both EC2 and Fargate)

Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
I'm trying to set up Slack notifications for deploys to ECS Fargate Services. I want to write a Lambda that triggers on Cloudwatch events for starting and finishing of deploys. Right now this is hard to do since there is no event for deploy starting (there is event for "starting tasks" which happens multiple times during a deploy but I only want to fire at the start). At the end of deploy, we get a "services are stable" notification but this too, fires randomly during non-deploys and can't be used. This makes it really hard to get deploy notifications.

Are you currently working around this issue?
Currently I am looking into triggering deploy start notifications before firing ecs force-update-service command and then setting up Lambda which fires on "services stable" cloudwatch event and then sending notification by describing service and checking if deployment "updatedAt" time is within 10 minutes of notification, then sending Slack notification but not at other times.

Additional context
https://github.com/aws/containers-roadmap/issues/288 I also commented here. If CodeDeploy has rolling deploys, that would work too. My services don't have an ALB and don't need blue-green deploys so notifications is not a good enough reason to switch to blue-green CodeDeploy deploys.

ECS Proposed

Most helpful comment

Hi @nakulpathak3 Thank you for the feedback. We are currently working on a deployment Circuit Breaker Feature that will include Service deployment Events corresponding to Deployment state changes:

  1. SERVICE_DEPLOYMENT_STARTED - This event is emitted when a deployment for an ECS service starts by creating a new set of tasks(task Sets) with the revised service definition. This event message will contain the primary deployment ID, Service name, number of tasks launched and the task ARNs for the new tasks launched
  2. SERVICE_DEPLOYMENT_FAILED: This event is emitted when a deployment state changes from RUNNING TO FAILED. The event message contains the service name, primary deployment id, the retry limit that was hit and the time stamp when the deployment was declared as FAILED
  3. SERVICE_DEPLOYMENT_COMPLETE: This event is emitted when a deployment state changes from RUNNING to COMPELTE. The event message contains the service name, primary deployment id, the number of healthy tasks and the time stamp when the deployment was declared as COMPLETE
  4. DEPLOYMENT_ROLLBACK_STARTED: This event is emitted when a deployment state changes from FAILED to ROLLBACK_RUNNING. The event message contains the service name, primary and secondary deployment ids, the task definition version and the time stamp when the rollback was initiated.
  5. DEPLOYMENT_ROLLBACK_COMPLETE: This event is emitted when a deployment state changes from ROLLBACK_RUNNING to ROLLBACK_COMPLETE. The event message contains the service name, primary and secondary deployment ids, the task definition version, number of healthy tasks and the time stamp when the rollback was initiated.
  6. DEPLOYMENT_ROLLBACK_FAILED: This event is emitted when a deployment state changes from ROLLBACK_RUNNING to ROLLBACK_FAILED. The event message contains the service name, primary and secondary deployment ids, the task definition version and the time stamp.

Please see issue #328 for more information.

All 4 comments

Hi @nakulpathak3 Thank you for the feedback. We are currently working on a deployment Circuit Breaker Feature that will include Service deployment Events corresponding to Deployment state changes:

  1. SERVICE_DEPLOYMENT_STARTED - This event is emitted when a deployment for an ECS service starts by creating a new set of tasks(task Sets) with the revised service definition. This event message will contain the primary deployment ID, Service name, number of tasks launched and the task ARNs for the new tasks launched
  2. SERVICE_DEPLOYMENT_FAILED: This event is emitted when a deployment state changes from RUNNING TO FAILED. The event message contains the service name, primary deployment id, the retry limit that was hit and the time stamp when the deployment was declared as FAILED
  3. SERVICE_DEPLOYMENT_COMPLETE: This event is emitted when a deployment state changes from RUNNING to COMPELTE. The event message contains the service name, primary deployment id, the number of healthy tasks and the time stamp when the deployment was declared as COMPLETE
  4. DEPLOYMENT_ROLLBACK_STARTED: This event is emitted when a deployment state changes from FAILED to ROLLBACK_RUNNING. The event message contains the service name, primary and secondary deployment ids, the task definition version and the time stamp when the rollback was initiated.
  5. DEPLOYMENT_ROLLBACK_COMPLETE: This event is emitted when a deployment state changes from ROLLBACK_RUNNING to ROLLBACK_COMPLETE. The event message contains the service name, primary and secondary deployment ids, the task definition version, number of healthy tasks and the time stamp when the rollback was initiated.
  6. DEPLOYMENT_ROLLBACK_FAILED: This event is emitted when a deployment state changes from ROLLBACK_RUNNING to ROLLBACK_FAILED. The event message contains the service name, primary and secondary deployment ids, the task definition version and the time stamp.

Please see issue #328 for more information.

@pavneeta Any updates on this feature request ? We are waiting on this feature.
Instead of writing a custom lambda function or code, it will be a very good feature addition to ECS.

Any updates? We'd really like see more features around deployments in ECS to avoid having to roll our own process in order to avoid failed deployments running indefinitely.

+1, this would help everyone a lot! Right now, it's possible to deploy a "broken" ECS service via CloudFormation, as the Service Status is CREATE_COMPLETE before the tasks pass ALB health checks.

Was this page helpful?
0 / 5 - 0 ratings