When you create a service which uses the rolling update (ECS) deployment type, 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.
Amazon ECS uses the following parameters to determine the number of tasks:
The minimumHealthyPercent represents the lower limit on the number of tasks that should be running for a service during a deployment or when a container instance is draining, as a percent of the desired number of tasks for the service. This value is rounded up. For example if the minimum healthy percent is 50 and the desired task count is four, then the scheduler can stop two existing tasks before starting two new tasks. Likewise, if the minimum healthy percent is 75% and the desired task count is two, then the scheduler can't stop any tasks due to the resulting value also being two.
If tasks become unhealthy, the Amazon ECS service scheduler will start replacement tasks first and maintain minimumHealthyPercent tasks until the replacement tasks become healthy. As the replacement tasks launch and become healthy, the unhealthy tasks will gradually be stopped.
The maximumPercent represents the upper limit on the number of tasks that should be running for a service during a deployment or when a container instance is draining, as a percent of the desired number of tasks for a service. This value is rounded down. For example if the maximum percent is 200 and the desired task count is four then the scheduler can start four new tasks before stopping four existing tasks. Likewise, if the maximum percent is 125 and the desired task count is three, the scheduler can't start any tasks due to the resulting value also being three.
Rolling deployments have 2 methods which provide a way to quickly identify when a service deployment has failed:
The methods can be used separately or together. When both methods are used, the deployment is set to failed as soon as the failure criteria for either failure method is met.
Use the following guidelines to help determine which method to use:
Circuit breaker - Use this method when you want to stop a deployment when the tasks can't start.
CloudWatch alarms - Use this method when you want to stop a deployment based on application metrics.
Both methods support rolling back to the previous service revision.
Container image resolutionBy default, Amazon ECS resolves container image tags specified in the task definition to container image digests. If you create a service that runs and maintains a single task, that task is used to establish image digests for the containers in the task. If you create a service that runs and maintains multiple tasks, the first task started by the service scheduler during deployment is used to establish the image digests for the containers in the tasks.
If three or more attempts at establishing the container image digests fail, the deployment continues without image digest resolution. If the deployment circuit breaker is enabled, the deployment is additionally failed and rolled back.
After the container image digests have been established, Amazon ECS uses the digests to start any other desired tasks, and for any future service updates. This leads to all tasks in a service always running identical container images, resulting in version consistency for your software.
You can configure this behavior for each container in your task by using the versionConsistency parameter in the container definition. For more information, see versionConsistency.
Amazon ECS Agent versions lower than 1.31.0 don't support image digest resolution. Agent versions 1.31.0 to 1.69.0 support image digest resolution only for images pushed to Amazon ECR repositories. Agent versions 1.70.0 or higher support image digest resolution for all images.
The minimum Fargate Linux platform version for image digest resolution is 1.3.0. The minimum Fargate Windows platform version for image digest resolution is 1.0.0.
Amazon ECS doesn't capture digests of sidecar containers managed by Amazon ECS, such as the Amazon GuardDuty security agent or Service Connect proxy.
To reduce potential latency associated with container image resolution in services with multiple tasks, run Amazon ECS agent version 1.83.0 or higher on EC2 container instances. To avoid potential latency, specify container image digests in your task definition.
If you create a service with a desired task count of zero, Amazon ECS can't establish container digests until you trigger another deployment of the service with a desired task count greater than zero.
To establish updated image digests, you can force a new deployment. The updated digests will be used to start new tasks and will not affect already running tasks. For more information about forcing new deployments, see forceNewDeployment in the Amazon ECS API reference.
When using EC2 capacity providers, if there is insufficient capacity to start a task during the initial deployment, software version consistency may fail. To ensure version consistency is maintained even when capacity is limited, explicitly set versionConsistency: true in your task definition container configuration rather than relying on the default behavior. This causes Amazon ECS to wait until capacity becomes available before proceeding with the deployment.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4