ECS / Client / describe_service_deployments
describe_service_deployments¶
- ECS.Client.describe_service_deployments(**kwargs)¶
Describes one or more of your service deployments.
A service deployment happens when you release a software update for the service. For more information, see View service history using Amazon ECS service deployments.
See also: AWS API Documentation
Request Syntax
response = client.describe_service_deployments( serviceDeploymentArns=[ 'string', ] )
- Parameters:
serviceDeploymentArns (list) –
[REQUIRED]
The ARN of the service deployment.
You can specify a maximum of 20 ARNs.
(string) –
- Return type:
dict
- Returns:
Response Syntax
{ 'serviceDeployments': [ { 'serviceDeploymentArn': 'string', 'serviceArn': 'string', 'clusterArn': 'string', 'createdAt': datetime(2015, 1, 1), 'startedAt': datetime(2015, 1, 1), 'finishedAt': datetime(2015, 1, 1), 'stoppedAt': datetime(2015, 1, 1), 'updatedAt': datetime(2015, 1, 1), 'sourceServiceRevisions': [ { 'arn': 'string', 'requestedTaskCount': 123, 'runningTaskCount': 123, 'pendingTaskCount': 123 }, ], 'targetServiceRevision': { 'arn': 'string', 'requestedTaskCount': 123, 'runningTaskCount': 123, 'pendingTaskCount': 123 }, 'status': 'PENDING'|'SUCCESSFUL'|'STOPPED'|'STOP_REQUESTED'|'IN_PROGRESS'|'ROLLBACK_REQUESTED'|'ROLLBACK_IN_PROGRESS'|'ROLLBACK_SUCCESSFUL'|'ROLLBACK_FAILED', 'statusReason': 'string', 'lifecycleStage': 'RECONCILE_SERVICE'|'PRE_SCALE_UP'|'SCALE_UP'|'POST_SCALE_UP'|'TEST_TRAFFIC_SHIFT'|'POST_TEST_TRAFFIC_SHIFT'|'PRODUCTION_TRAFFIC_SHIFT'|'POST_PRODUCTION_TRAFFIC_SHIFT'|'BAKE_TIME'|'CLEAN_UP', 'deploymentConfiguration': { 'deploymentCircuitBreaker': { 'enable': True|False, 'rollback': True|False }, 'maximumPercent': 123, 'minimumHealthyPercent': 123, 'alarms': { 'alarmNames': [ 'string', ], 'rollback': True|False, 'enable': True|False }, 'strategy': 'ROLLING'|'BLUE_GREEN', 'bakeTimeInMinutes': 123, 'lifecycleHooks': [ { 'hookTargetArn': 'string', 'roleArn': 'string', 'lifecycleStages': [ 'RECONCILE_SERVICE'|'PRE_SCALE_UP'|'POST_SCALE_UP'|'TEST_TRAFFIC_SHIFT'|'POST_TEST_TRAFFIC_SHIFT'|'PRODUCTION_TRAFFIC_SHIFT'|'POST_PRODUCTION_TRAFFIC_SHIFT', ] }, ] }, 'rollback': { 'reason': 'string', 'startedAt': datetime(2015, 1, 1), 'serviceRevisionArn': 'string' }, 'deploymentCircuitBreaker': { 'status': 'TRIGGERED'|'MONITORING'|'MONITORING_COMPLETE'|'DISABLED', 'failureCount': 123, 'threshold': 123 }, 'alarms': { 'status': 'TRIGGERED'|'MONITORING'|'MONITORING_COMPLETE'|'DISABLED', 'alarmNames': [ 'string', ], 'triggeredAlarmNames': [ 'string', ] } }, ], 'failures': [ { 'arn': 'string', 'reason': 'string', 'detail': 'string' }, ] }
Response Structure
(dict) –
serviceDeployments (list) –
The list of service deployments described.
(dict) –
Information about the service deployment.
Service deployments provide a comprehensive view of your deployments. For information about service deployments, see View service history using Amazon ECS service deployments in the Amazon Elastic Container Service Developer Guide .
serviceDeploymentArn (string) –
The ARN of the service deployment.
serviceArn (string) –
The ARN of the service for this service deployment.
clusterArn (string) –
The ARN of the cluster that hosts the service.
createdAt (datetime) –
The time the service deployment was created. The format is yyyy-MM-dd HH:mm:ss.SSSSSS.
startedAt (datetime) –
The time the service deployment statred. The format is yyyy-MM-dd HH:mm:ss.SSSSSS.
finishedAt (datetime) –
The time the service deployment finished. The format is yyyy-MM-dd HH:mm:ss.SSSSSS.
stoppedAt (datetime) –
The time the service deployment stopped. The format is yyyy-MM-dd HH:mm:ss.SSSSSS.
The service deployment stops when any of the following actions happen:
A user manually stops the deployment
The rollback option is not in use for the failure detection mechanism (the circuit breaker or alarm-based) and the service fails.
updatedAt (datetime) –
The time that the service deployment was last updated. The format is yyyy-MM-dd HH:mm:ss.SSSSSS.
sourceServiceRevisions (list) –
The currently deployed workload configuration.
(dict) –
The information about the number of requested, pending, and running tasks for a service revision.
arn (string) –
The ARN of the service revision.
requestedTaskCount (integer) –
The number of requested tasks for the service revision.
runningTaskCount (integer) –
The number of running tasks for the service revision.
pendingTaskCount (integer) –
The number of pending tasks for the service revision.
targetServiceRevision (dict) –
The workload configuration being deployed.
arn (string) –
The ARN of the service revision.
requestedTaskCount (integer) –
The number of requested tasks for the service revision.
runningTaskCount (integer) –
The number of running tasks for the service revision.
pendingTaskCount (integer) –
The number of pending tasks for the service revision.
status (string) –
The service deployment state.
statusReason (string) –
Information about why the service deployment is in the current status. For example, the circuit breaker detected a failure.
lifecycleStage (string) –
The current lifecycle stage of the deployment. Possible values include:
RECONCILE_SERVICE The reconciliation stage that only happens when you start a new service deployment with more than 1 service revision in an ACTIVE state.
PRE_SCALE_UP The green service revision has not started. The blue service revision is handling 100% of the production traffic. There is no test traffic.
SCALE_UP The stage when the green service revision scales up to 100% and launches new tasks. The green service revision is not serving any traffic at this point.
POST_SCALE_UP The green service revision has started. The blue service revision is handling 100% of the production traffic. There is no test traffic.
TEST_TRAFFIC_SHIFT The blue and green service revisions are running. The blue service revision handles 100% of the production traffic. The green service revision is migrating from 0% to 100% of test traffic.
POST_TEST_TRAFFIC_SHIFT The test traffic shift is complete. The green service revision handles 100% of the test traffic.
PRODUCTION_TRAFFIC_SHIFT Production traffic is shifting to the green service revision. The green service revision is migrating from 0% to 100% of production traffic.
POST_PRODUCTION_TRAFFIC_SHIFT The production traffic shift is complete.
BAKE_TIME The stage when both blue and green service revisions are running simultaneously after the production traffic has shifted.
CLEAN_UP The stage when the blue service revision has completely scaled down to 0 running tasks. The green service revision is now the production service revision after this stage.
deploymentConfiguration (dict) –
Optional deployment parameters that control how many tasks run during a deployment and the ordering of stopping and starting tasks.
deploymentCircuitBreaker (dict) –
Note
The deployment circuit breaker can only be used for services using the rolling update (
ECS
) deployment type.The deployment circuit breaker determines whether a service deployment will fail if the service can’t reach a steady state. If you use the deployment circuit breaker, a service deployment will transition to a failed state and stop launching new tasks. If you use the rollback option, when a service deployment fails, the service is rolled back to the last deployment that completed successfully. For more information, see Rolling update in the Amazon Elastic Container Service Developer Guide
enable (boolean) –
Determines whether to use the deployment circuit breaker logic for the service.
rollback (boolean) –
Determines whether to configure Amazon ECS to roll back the service if a service deployment fails. If rollback is on, when a service deployment fails, the service is rolled back to the last deployment that completed successfully.
maximumPercent (integer) –
If a service is using the rolling update (
ECS
) deployment type, themaximumPercent
parameter represents an upper limit on the number of your service’s tasks that are allowed in theRUNNING
orPENDING
state during a deployment, as a percentage of thedesiredCount
(rounded down to the nearest integer). This parameter enables you to define the deployment batch size. For example, if your service is using theREPLICA
service scheduler and has adesiredCount
of four tasks and amaximumPercent
value of 200%, the scheduler may start four new tasks before stopping the four older tasks (provided that the cluster resources required to do this are available). The defaultmaximumPercent
value for a service using theREPLICA
service scheduler is 200%.The Amazon ECS scheduler uses this parameter to replace unhealthy tasks by starting replacement tasks first and then stopping the unhealthy tasks, as long as cluster resources for starting replacement tasks are available. For more information about how the scheduler replaces unhealthy tasks, see Amazon ECS services.
If a service is using either the blue/green (
CODE_DEPLOY
) orEXTERNAL
deployment types, and tasks in the service use the EC2 launch type, the maximum percent value is set to the default value. The maximum percent value is used to define the upper limit on the number of the tasks in the service that remain in theRUNNING
state while the container instances are in theDRAINING
state.Note
You can’t specify a custom
maximumPercent
value for a service that uses either the blue/green (CODE_DEPLOY
) orEXTERNAL
deployment types and has tasks that use the EC2 launch type.If the service uses either the blue/green (
CODE_DEPLOY
) orEXTERNAL
deployment types, and the tasks in the service use the Fargate launch type, the maximum percent value is not used. The value is still returned when describing your service.minimumHealthyPercent (integer) –
If a service is using the rolling update (
ECS
) deployment type, theminimumHealthyPercent
represents a lower limit on the number of your service’s tasks that must remain in theRUNNING
state during a deployment, as a percentage of thedesiredCount
(rounded up to the nearest integer). This parameter enables you to deploy without using additional cluster capacity. For example, if your service has adesiredCount
of four tasks and aminimumHealthyPercent
of 50%, the service scheduler may stop two existing tasks to free up cluster capacity before starting two new tasks.If any tasks are unhealthy and if
maximumPercent
doesn’t allow the Amazon ECS scheduler to start replacement tasks, the scheduler stops the unhealthy tasks one-by-one — using theminimumHealthyPercent
as a constraint — to clear up capacity to launch replacement tasks. For more information about how the scheduler replaces unhealthy tasks, see Amazon ECS services .For services that do not use a load balancer, the following should be noted:
A service is considered healthy if all essential containers within the tasks in the service pass their health checks.
If a task has no essential containers with a health check defined, the service scheduler will wait for 40 seconds after a task reaches a
RUNNING
state before the task is counted towards the minimum healthy percent total.If a task has one or more essential containers with a health check defined, the service scheduler will wait for the task to reach a healthy status before counting it towards the minimum healthy percent total. A task is considered healthy when all essential containers within the task have passed their health checks. The amount of time the service scheduler can wait for is determined by the container health check settings.
For services that do use a load balancer, the following should be noted:
If a task has no essential containers with a health check defined, the service scheduler will wait for the load balancer target group health check to return a healthy status before counting the task towards the minimum healthy percent total.
If a task has an essential container with a health check defined, the service scheduler will wait for both the task to reach a healthy status and the load balancer target group health check to return a healthy status before counting the task towards the minimum healthy percent total.
The default value for a replica service for
minimumHealthyPercent
is 100%. The defaultminimumHealthyPercent
value for a service using theDAEMON
service schedule is 0% for the CLI, the Amazon Web Services SDKs, and the APIs and 50% for the Amazon Web Services Management Console.The minimum number of healthy tasks during a deployment is the
desiredCount
multiplied by theminimumHealthyPercent
/100, rounded up to the nearest integer value.If a service is using either the blue/green (
CODE_DEPLOY
) orEXTERNAL
deployment types and is running tasks that use the EC2 launch type, the minimum healthy percent value is set to the default value. The minimum healthy percent value is used to define the lower limit on the number of the tasks in the service that remain in theRUNNING
state while the container instances are in theDRAINING
state.Note
You can’t specify a custom
minimumHealthyPercent
value for a service that uses either the blue/green (CODE_DEPLOY
) orEXTERNAL
deployment types and has tasks that use the EC2 launch type.If a service is using either the blue/green (
CODE_DEPLOY
) orEXTERNAL
deployment types and is running tasks that use the Fargate launch type, the minimum healthy percent value is not used, although it is returned when describing your service.alarms (dict) –
Information about the CloudWatch alarms.
alarmNames (list) –
One or more CloudWatch alarm names. Use a “,” to separate the alarms.
(string) –
rollback (boolean) –
Determines whether to configure Amazon ECS to roll back the service if a service deployment fails. If rollback is used, when a service deployment fails, the service is rolled back to the last deployment that completed successfully.
enable (boolean) –
Determines whether to use the CloudWatch alarm option in the service deployment process.
strategy (string) –
The deployment strategy for the service. Choose from these valid values:
ROLLING
- When you create a service which uses the rolling update (ROLLING
) deployment strategy, the Amazon ECS service scheduler replaces the currently running tasks with new tasks. The number of tasks that Amazon ECS adds or removes from the service during a rolling update is controlled by the service deployment configuration.BLUE_GREEN
- A blue/green deployment strategy (BLUE_GREEN
) is a release methodology that reduces downtime and risk by running two identical production environments called blue and green. With Amazon ECS blue/green deployments, you can validate new service revisions before directing production traffic to them. This approach provides a safer way to deploy changes with the ability to quickly roll back if needed.
bakeTimeInMinutes (integer) –
The time period when both blue and green service revisions are running simultaneously after the production traffic has shifted.
You must provide this parameter when you use the
BLUE_GREEN
deployment strategy.lifecycleHooks (list) –
An array of deployment lifecycle hook objects to run custom logic at specific stages of the deployment lifecycle.
(dict) –
A deployment lifecycle hook runs custom logic at specific stages of the deployment process. Currently, you can use Lambda functions as hook targets.
For more information, see Lifecycle hooks for Amazon ECS service deployments in the Amazon Elastic Container Service Developer Guide.
hookTargetArn (string) –
The Amazon Resource Name (ARN) of the hook target. Currently, only Lambda function ARNs are supported.
You must provide this parameter when configuring a deployment lifecycle hook.
roleArn (string) –
The Amazon Resource Name (ARN) of the IAM role that grants Amazon ECS permission to call Lambda functions on your behalf.
For more information, see Permissions required for Lambda functions in Amazon ECS blue/green deployments in the Amazon Elastic Container Service Developer Guide.
lifecycleStages (list) –
The lifecycle stages at which to run the hook. Choose from these valid values:
RECONCILE_SERVICE The reconciliation stage that only happens when you start a new service deployment with more than 1 service revision in an ACTIVE state. You can use a lifecycle hook for this stage.
PRE_SCALE_UP The green service revision has not started. The blue service revision is handling 100% of the production traffic. There is no test traffic. You can use a lifecycle hook for this stage.
POST_SCALE_UP The green service revision has started. The blue service revision is handling 100% of the production traffic. There is no test traffic. You can use a lifecycle hook for this stage.
TEST_TRAFFIC_SHIFT The blue and green service revisions are running. The blue service revision handles 100% of the production traffic. The green service revision is migrating from 0% to 100% of test traffic. You can use a lifecycle hook for this stage.
POST_TEST_TRAFFIC_SHIFT The test traffic shift is complete. The green service revision handles 100% of the test traffic. You can use a lifecycle hook for this stage.
PRODUCTION_TRAFFIC_SHIFT Production traffic is shifting to the green service revision. The green service revision is migrating from 0% to 100% of production traffic. You can use a lifecycle hook for this stage.
POST_PRODUCTION_TRAFFIC_SHIFT The production traffic shift is complete. You can use a lifecycle hook for this stage.
You must provide this parameter when configuring a deployment lifecycle hook.
(string) –
rollback (dict) –
The rollback options the service deployment uses when the deployment fails.
reason (string) –
The reason the rollback happened. For example, the circuit breaker initiated the rollback operation.
startedAt (datetime) –
Time time that the rollback started. The format is yyyy-MM-dd HH:mm:ss.SSSSSS.
serviceRevisionArn (string) –
The ARN of the service revision deployed as part of the rollback.
deploymentCircuitBreaker (dict) –
The circuit breaker configuration that determines a service deployment failed.
status (string) –
The circuit breaker status. Amazon ECS is not using the circuit breaker for service deployment failures when the status is
DISABLED
.failureCount (integer) –
The number of times the circuit breaker detected a service deploymeny failure.
threshold (integer) –
The threshhold which determines that the service deployment failed.
The deployment circuit breaker calculates the threshold value, and then uses the value to determine when to move the deployment to a FAILED state. The deployment circuit breaker has a minimum threshold of 3 and a maximum threshold of 200. and uses the values in the following formula to determine the deployment failure.
0.5 * desired task count
alarms (dict) –
The CloudWatch alarms that determine when a service deployment fails.
status (string) –
The status of the alarms check. Amazon ECS is not using alarms for service deployment failures when the status is
DISABLED
.alarmNames (list) –
The name of the CloudWatch alarms that determine when a service deployment failed. A “,” separates the alarms.
(string) –
triggeredAlarmNames (list) –
One or more CloudWatch alarm names that have been triggered during the service deployment. A “,” separates the alarm names.
(string) –
failures (list) –
Any failures associated with the call.
If you decsribe a deployment with a service revision created before October 25, 2024, the call fails. The failure includes the service revision ARN and the reason set to
MISSING
.(dict) –
A failed resource. For a list of common causes, see API failure reasons in the Amazon Elastic Container Service Developer Guide.
arn (string) –
The Amazon Resource Name (ARN) of the failed resource.
reason (string) –
The reason for the failure.
detail (string) –
The details of the failure.
Exceptions