@Generated(value="com.amazonaws:aws-java-sdk-code-generator") public class DeploymentConfiguration extends Object implements Serializable, Cloneable, StructuredPojo
Optional deployment parameters that control how many tasks run during a deployment and the ordering of stopping and starting tasks.
| Constructor and Description |
|---|
DeploymentConfiguration() |
| Modifier and Type | Method and Description |
|---|---|
DeploymentConfiguration |
clone() |
boolean |
equals(Object obj) |
DeploymentAlarms |
getAlarms()
Information about the CloudWatch alarms.
|
DeploymentCircuitBreaker |
getDeploymentCircuitBreaker()
|
Integer |
getMaximumPercent()
If a service is using the rolling update (
ECS) deployment type, the maximumPercent
parameter represents an upper limit on the number of your service's tasks that are allowed in the
RUNNING or PENDING state during a deployment, as a percentage of the
desiredCount (rounded down to the nearest integer). |
Integer |
getMinimumHealthyPercent()
If a service is using the rolling update (
ECS) deployment type, the
minimumHealthyPercent represents a lower limit on the number of your service's tasks that must
remain in the RUNNING state during a deployment, as a percentage of the desiredCount
(rounded up to the nearest integer). |
int |
hashCode() |
void |
marshall(ProtocolMarshaller protocolMarshaller)
Marshalls this structured data using the given
ProtocolMarshaller. |
void |
setAlarms(DeploymentAlarms alarms)
Information about the CloudWatch alarms.
|
void |
setDeploymentCircuitBreaker(DeploymentCircuitBreaker deploymentCircuitBreaker)
|
void |
setMaximumPercent(Integer maximumPercent)
If a service is using the rolling update (
ECS) deployment type, the maximumPercent
parameter represents an upper limit on the number of your service's tasks that are allowed in the
RUNNING or PENDING state during a deployment, as a percentage of the
desiredCount (rounded down to the nearest integer). |
void |
setMinimumHealthyPercent(Integer minimumHealthyPercent)
If a service is using the rolling update (
ECS) deployment type, the
minimumHealthyPercent represents a lower limit on the number of your service's tasks that must
remain in the RUNNING state during a deployment, as a percentage of the desiredCount
(rounded up to the nearest integer). |
String |
toString()
Returns a string representation of this object.
|
DeploymentConfiguration |
withAlarms(DeploymentAlarms alarms)
Information about the CloudWatch alarms.
|
DeploymentConfiguration |
withDeploymentCircuitBreaker(DeploymentCircuitBreaker deploymentCircuitBreaker)
|
DeploymentConfiguration |
withMaximumPercent(Integer maximumPercent)
If a service is using the rolling update (
ECS) deployment type, the maximumPercent
parameter represents an upper limit on the number of your service's tasks that are allowed in the
RUNNING or PENDING state during a deployment, as a percentage of the
desiredCount (rounded down to the nearest integer). |
DeploymentConfiguration |
withMinimumHealthyPercent(Integer minimumHealthyPercent)
If a service is using the rolling update (
ECS) deployment type, the
minimumHealthyPercent represents a lower limit on the number of your service's tasks that must
remain in the RUNNING state during a deployment, as a percentage of the desiredCount
(rounded up to the nearest integer). |
public void setDeploymentCircuitBreaker(DeploymentCircuitBreaker deploymentCircuitBreaker)
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
deploymentCircuitBreaker -
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
public DeploymentCircuitBreaker getDeploymentCircuitBreaker()
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
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
public DeploymentConfiguration withDeploymentCircuitBreaker(DeploymentCircuitBreaker deploymentCircuitBreaker)
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
deploymentCircuitBreaker -
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
public void setMaximumPercent(Integer maximumPercent)
If a service is using the rolling update (ECS) deployment type, the maximumPercent
parameter represents an upper limit on the number of your service's tasks that are allowed in the
RUNNING or PENDING state during a deployment, as a percentage of the
desiredCount (rounded down to the nearest integer). This parameter enables you to define the
deployment batch size. For example, if your service is using the REPLICA service scheduler and has a
desiredCount of four tasks and a maximumPercent 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 default maximumPercent value for a service using the REPLICA service
scheduler is 200%.
If a service is using either the blue/green (CODE_DEPLOY) or EXTERNAL deployment types
and tasks that use the EC2 launch type, the maximum percent value is set to the default value and is used
to define the upper limit on the number of the tasks in the service that remain in the RUNNING state
while the container instances are in the DRAINING state. If the tasks in the service use the Fargate
launch type, the maximum percent value is not used, although it is returned when describing your service.
maximumPercent - If a service is using the rolling update (ECS) deployment type, the
maximumPercent parameter represents an upper limit on the number of your service's tasks that
are allowed in the RUNNING or PENDING state during a deployment, as a percentage
of the desiredCount (rounded down to the nearest integer). This parameter enables you to
define the deployment batch size. For example, if your service is using the REPLICA service
scheduler and has a desiredCount of four tasks and a maximumPercent 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 default maximumPercent value for a
service using the REPLICA service scheduler is 200%.
If a service is using either the blue/green (CODE_DEPLOY) or EXTERNAL deployment
types and tasks that use the EC2 launch type, the maximum percent value is set to the default value
and is used to define the upper limit on the number of the tasks in the service that remain in the
RUNNING state while the container instances are in the DRAINING state. If the
tasks in the service use the Fargate launch type, the maximum percent value is not used, although it is
returned when describing your service.
public Integer getMaximumPercent()
If a service is using the rolling update (ECS) deployment type, the maximumPercent
parameter represents an upper limit on the number of your service's tasks that are allowed in the
RUNNING or PENDING state during a deployment, as a percentage of the
desiredCount (rounded down to the nearest integer). This parameter enables you to define the
deployment batch size. For example, if your service is using the REPLICA service scheduler and has a
desiredCount of four tasks and a maximumPercent 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 default maximumPercent value for a service using the REPLICA service
scheduler is 200%.
If a service is using either the blue/green (CODE_DEPLOY) or EXTERNAL deployment types
and tasks that use the EC2 launch type, the maximum percent value is set to the default value and is used
to define the upper limit on the number of the tasks in the service that remain in the RUNNING state
while the container instances are in the DRAINING state. If the tasks in the service use the Fargate
launch type, the maximum percent value is not used, although it is returned when describing your service.
ECS) deployment type, the
maximumPercent parameter represents an upper limit on the number of your service's tasks
that are allowed in the RUNNING or PENDING state during a deployment, as a
percentage of the desiredCount (rounded down to the nearest integer). This parameter enables
you to define the deployment batch size. For example, if your service is using the REPLICA
service scheduler and has a desiredCount of four tasks and a maximumPercent
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 default maximumPercent value
for a service using the REPLICA service scheduler is 200%.
If a service is using either the blue/green (CODE_DEPLOY) or EXTERNAL
deployment types and tasks that use the EC2 launch type, the maximum percent value is set to the
default value and is used to define the upper limit on the number of the tasks in the service that remain
in the RUNNING state while the container instances are in the DRAINING state.
If the tasks in the service use the Fargate launch type, the maximum percent value is not used, although
it is returned when describing your service.
public DeploymentConfiguration withMaximumPercent(Integer maximumPercent)
If a service is using the rolling update (ECS) deployment type, the maximumPercent
parameter represents an upper limit on the number of your service's tasks that are allowed in the
RUNNING or PENDING state during a deployment, as a percentage of the
desiredCount (rounded down to the nearest integer). This parameter enables you to define the
deployment batch size. For example, if your service is using the REPLICA service scheduler and has a
desiredCount of four tasks and a maximumPercent 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 default maximumPercent value for a service using the REPLICA service
scheduler is 200%.
If a service is using either the blue/green (CODE_DEPLOY) or EXTERNAL deployment types
and tasks that use the EC2 launch type, the maximum percent value is set to the default value and is used
to define the upper limit on the number of the tasks in the service that remain in the RUNNING state
while the container instances are in the DRAINING state. If the tasks in the service use the Fargate
launch type, the maximum percent value is not used, although it is returned when describing your service.
maximumPercent - If a service is using the rolling update (ECS) deployment type, the
maximumPercent parameter represents an upper limit on the number of your service's tasks that
are allowed in the RUNNING or PENDING state during a deployment, as a percentage
of the desiredCount (rounded down to the nearest integer). This parameter enables you to
define the deployment batch size. For example, if your service is using the REPLICA service
scheduler and has a desiredCount of four tasks and a maximumPercent 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 default maximumPercent value for a
service using the REPLICA service scheduler is 200%.
If a service is using either the blue/green (CODE_DEPLOY) or EXTERNAL deployment
types and tasks that use the EC2 launch type, the maximum percent value is set to the default value
and is used to define the upper limit on the number of the tasks in the service that remain in the
RUNNING state while the container instances are in the DRAINING state. If the
tasks in the service use the Fargate launch type, the maximum percent value is not used, although it is
returned when describing your service.
public void setMinimumHealthyPercent(Integer minimumHealthyPercent)
If a service is using the rolling update (ECS) deployment type, the
minimumHealthyPercent represents a lower limit on the number of your service's tasks that must
remain in the RUNNING state during a deployment, as a percentage of the desiredCount
(rounded up to the nearest integer). This parameter enables you to deploy without using additional cluster
capacity. For example, if your service has a desiredCount of four tasks and a
minimumHealthyPercent of 50%, the service scheduler may stop two existing tasks to free up cluster
capacity before starting two new tasks.
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 default
minimumHealthyPercent value for a service using the DAEMON 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 the
minimumHealthyPercent/100, rounded up to the nearest integer value.
If a service is using either the blue/green (CODE_DEPLOY) or EXTERNAL deployment types
and is running tasks that use the EC2 launch type, the minimum healthy percent value is set to the default
value and is used to define the lower limit on the number of the tasks in the service that remain in the
RUNNING state while the container instances are in the DRAINING state. If a service is
using either the blue/green (CODE_DEPLOY) or EXTERNAL 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.
minimumHealthyPercent - If a service is using the rolling update (ECS) deployment type, the
minimumHealthyPercent represents a lower limit on the number of your service's tasks that
must remain in the RUNNING state during a deployment, as a percentage of the
desiredCount (rounded up to the nearest integer). This parameter enables you to deploy
without using additional cluster capacity. For example, if your service has a desiredCount of
four tasks and a minimumHealthyPercent of 50%, the service scheduler may stop two existing
tasks to free up cluster capacity before starting two new tasks.
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 default
minimumHealthyPercent value for a service using the DAEMON 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 the
minimumHealthyPercent/100, rounded up to the nearest integer value.
If a service is using either the blue/green (CODE_DEPLOY) or EXTERNAL deployment
types and is running tasks that use the EC2 launch type, the minimum healthy percent value is set
to the default value and is used to define the lower limit on the number of the tasks in the service that
remain in the RUNNING state while the container instances are in the DRAINING
state. If a service is using either the blue/green (CODE_DEPLOY) or EXTERNAL
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.
public Integer getMinimumHealthyPercent()
If a service is using the rolling update (ECS) deployment type, the
minimumHealthyPercent represents a lower limit on the number of your service's tasks that must
remain in the RUNNING state during a deployment, as a percentage of the desiredCount
(rounded up to the nearest integer). This parameter enables you to deploy without using additional cluster
capacity. For example, if your service has a desiredCount of four tasks and a
minimumHealthyPercent of 50%, the service scheduler may stop two existing tasks to free up cluster
capacity before starting two new tasks.
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 default
minimumHealthyPercent value for a service using the DAEMON 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 the
minimumHealthyPercent/100, rounded up to the nearest integer value.
If a service is using either the blue/green (CODE_DEPLOY) or EXTERNAL deployment types
and is running tasks that use the EC2 launch type, the minimum healthy percent value is set to the default
value and is used to define the lower limit on the number of the tasks in the service that remain in the
RUNNING state while the container instances are in the DRAINING state. If a service is
using either the blue/green (CODE_DEPLOY) or EXTERNAL 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.
ECS) deployment type, the
minimumHealthyPercent represents a lower limit on the number of your service's tasks that
must remain in the RUNNING state during a deployment, as a percentage of the
desiredCount (rounded up to the nearest integer). This parameter enables you to deploy
without using additional cluster capacity. For example, if your service has a desiredCount
of four tasks and a minimumHealthyPercent of 50%, the service scheduler may stop two
existing tasks to free up cluster capacity before starting two new tasks.
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 default
minimumHealthyPercent value for a service using the DAEMON 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
the minimumHealthyPercent/100, rounded up to the nearest integer value.
If a service is using either the blue/green (CODE_DEPLOY) or EXTERNAL
deployment types and is running tasks that use the EC2 launch type, the minimum healthy percent
value is set to the default value and is used to define the lower limit on the number of the tasks in the
service that remain in the RUNNING state while the container instances are in the
DRAINING state. If a service is using either the blue/green (CODE_DEPLOY) or
EXTERNAL 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.
public DeploymentConfiguration withMinimumHealthyPercent(Integer minimumHealthyPercent)
If a service is using the rolling update (ECS) deployment type, the
minimumHealthyPercent represents a lower limit on the number of your service's tasks that must
remain in the RUNNING state during a deployment, as a percentage of the desiredCount
(rounded up to the nearest integer). This parameter enables you to deploy without using additional cluster
capacity. For example, if your service has a desiredCount of four tasks and a
minimumHealthyPercent of 50%, the service scheduler may stop two existing tasks to free up cluster
capacity before starting two new tasks.
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 default
minimumHealthyPercent value for a service using the DAEMON 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 the
minimumHealthyPercent/100, rounded up to the nearest integer value.
If a service is using either the blue/green (CODE_DEPLOY) or EXTERNAL deployment types
and is running tasks that use the EC2 launch type, the minimum healthy percent value is set to the default
value and is used to define the lower limit on the number of the tasks in the service that remain in the
RUNNING state while the container instances are in the DRAINING state. If a service is
using either the blue/green (CODE_DEPLOY) or EXTERNAL 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.
minimumHealthyPercent - If a service is using the rolling update (ECS) deployment type, the
minimumHealthyPercent represents a lower limit on the number of your service's tasks that
must remain in the RUNNING state during a deployment, as a percentage of the
desiredCount (rounded up to the nearest integer). This parameter enables you to deploy
without using additional cluster capacity. For example, if your service has a desiredCount of
four tasks and a minimumHealthyPercent of 50%, the service scheduler may stop two existing
tasks to free up cluster capacity before starting two new tasks.
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 default
minimumHealthyPercent value for a service using the DAEMON 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 the
minimumHealthyPercent/100, rounded up to the nearest integer value.
If a service is using either the blue/green (CODE_DEPLOY) or EXTERNAL deployment
types and is running tasks that use the EC2 launch type, the minimum healthy percent value is set
to the default value and is used to define the lower limit on the number of the tasks in the service that
remain in the RUNNING state while the container instances are in the DRAINING
state. If a service is using either the blue/green (CODE_DEPLOY) or EXTERNAL
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.
public void setAlarms(DeploymentAlarms alarms)
Information about the CloudWatch alarms.
alarms - Information about the CloudWatch alarms.public DeploymentAlarms getAlarms()
Information about the CloudWatch alarms.
public DeploymentConfiguration withAlarms(DeploymentAlarms alarms)
Information about the CloudWatch alarms.
alarms - Information about the CloudWatch alarms.public String toString()
toString in class ObjectObject.toString()public DeploymentConfiguration clone()
public void marshall(ProtocolMarshaller protocolMarshaller)
StructuredPojoProtocolMarshaller.marshall in interface StructuredPojoprotocolMarshaller - Implementation of ProtocolMarshaller used to marshall this object's data.