Class DeploymentController

java.lang.Object
software.amazon.awssdk.services.ecs.model.DeploymentController
All Implemented Interfaces:
Serializable, SdkPojo, ToCopyableBuilder<DeploymentController.Builder,DeploymentController>
@Generated("software.amazon.awssdk:codegen") public final class DeploymentController extends Object implements SdkPojo, Serializable, ToCopyableBuilder<DeploymentController.Builder,DeploymentController>

The deployment controller to use for the service.

See Also:

  • Method Details

    • type

      public final DeploymentControllerType type()

      The deployment controller type to use.

      The deployment controller is the mechanism that determines how tasks are deployed for your service. The valid options are:

      • ECS

        When you create a service which uses the ECS deployment controller, you can choose between the following deployment strategies:

        • 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.

          Rolling update deployments are best suited for the following scenarios:

          • Gradual service updates: You need to update your service incrementally without taking the entire service offline at once.

          • Limited resource requirements: You want to avoid the additional resource costs of running two complete environments simultaneously (as required by blue/green deployments).

          • Acceptable deployment time: Your application can tolerate a longer deployment process, as rolling updates replace tasks one by one.

          • No need for instant roll back: Your service can tolerate a rollback process that takes minutes rather than seconds.

          • Simple deployment process: You prefer a straightforward deployment approach without the complexity of managing multiple environments, target groups, and listeners.

          • No load balancer requirement: Your service doesn't use or require a load balancer, Application Load Balancer, Network Load Balancer, or Service Connect (which are required for blue/green deployments).

          • Stateful applications: Your application maintains state that makes it difficult to run two parallel environments.

          • Cost sensitivity: You want to minimize deployment costs by not running duplicate environments during deployment.

          Rolling updates are the default deployment strategy for services and provide a balance between deployment safety and resource efficiency for many common application scenarios.

        • 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.

          Amazon ECS blue/green deployments are best suited for the following scenarios:

          • Service validation: When you need to validate new service revisions before directing production traffic to them

          • Zero downtime: When your service requires zero-downtime deployments

          • Instant roll back: When you need the ability to quickly roll back if issues are detected

          • Load balancer requirement: When your service uses Application Load Balancer, Network Load Balancer, or Service Connect

      • External

        Use a third-party deployment controller.

      • Blue/green deployment (powered by CodeDeploy)

        CodeDeploy installs an updated version of the application as a new replacement task set and reroutes production traffic from the original application task set to the replacement task set. The original task set is terminated after a successful deployment. Use this deployment controller to verify a new deployment of a service before sending production traffic to it.

      If the service returns an enum value that is not available in the current SDK version, type will return DeploymentControllerType.UNKNOWN_TO_SDK_VERSION. The raw value returned by the service is available from typeAsString().

      Returns:
      The deployment controller type to use.

      The deployment controller is the mechanism that determines how tasks are deployed for your service. The valid options are:

      • ECS

        When you create a service which uses the ECS deployment controller, you can choose between the following deployment strategies:

        • 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.

          Rolling update deployments are best suited for the following scenarios:

          • Gradual service updates: You need to update your service incrementally without taking the entire service offline at once.

          • Limited resource requirements: You want to avoid the additional resource costs of running two complete environments simultaneously (as required by blue/green deployments).

          • Acceptable deployment time: Your application can tolerate a longer deployment process, as rolling updates replace tasks one by one.

          • No need for instant roll back: Your service can tolerate a rollback process that takes minutes rather than seconds.

          • Simple deployment process: You prefer a straightforward deployment approach without the complexity of managing multiple environments, target groups, and listeners.

          • No load balancer requirement: Your service doesn't use or require a load balancer, Application Load Balancer, Network Load Balancer, or Service Connect (which are required for blue/green deployments).

          • Stateful applications: Your application maintains state that makes it difficult to run two parallel environments.

          • Cost sensitivity: You want to minimize deployment costs by not running duplicate environments during deployment.

          Rolling updates are the default deployment strategy for services and provide a balance between deployment safety and resource efficiency for many common application scenarios.

        • 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.

          Amazon ECS blue/green deployments are best suited for the following scenarios:

          • Service validation: When you need to validate new service revisions before directing production traffic to them

          • Zero downtime: When your service requires zero-downtime deployments

          • Instant roll back: When you need the ability to quickly roll back if issues are detected

          • Load balancer requirement: When your service uses Application Load Balancer, Network Load Balancer, or Service Connect

      • External

        Use a third-party deployment controller.

      • Blue/green deployment (powered by CodeDeploy)

        CodeDeploy installs an updated version of the application as a new replacement task set and reroutes production traffic from the original application task set to the replacement task set. The original task set is terminated after a successful deployment. Use this deployment controller to verify a new deployment of a service before sending production traffic to it.

      See Also:

    • typeAsString

      public final String typeAsString()

      The deployment controller type to use.

      The deployment controller is the mechanism that determines how tasks are deployed for your service. The valid options are:

      • ECS

        When you create a service which uses the ECS deployment controller, you can choose between the following deployment strategies:

        • 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.

          Rolling update deployments are best suited for the following scenarios:

          • Gradual service updates: You need to update your service incrementally without taking the entire service offline at once.

          • Limited resource requirements: You want to avoid the additional resource costs of running two complete environments simultaneously (as required by blue/green deployments).

          • Acceptable deployment time: Your application can tolerate a longer deployment process, as rolling updates replace tasks one by one.

          • No need for instant roll back: Your service can tolerate a rollback process that takes minutes rather than seconds.

          • Simple deployment process: You prefer a straightforward deployment approach without the complexity of managing multiple environments, target groups, and listeners.

          • No load balancer requirement: Your service doesn't use or require a load balancer, Application Load Balancer, Network Load Balancer, or Service Connect (which are required for blue/green deployments).

          • Stateful applications: Your application maintains state that makes it difficult to run two parallel environments.

          • Cost sensitivity: You want to minimize deployment costs by not running duplicate environments during deployment.

          Rolling updates are the default deployment strategy for services and provide a balance between deployment safety and resource efficiency for many common application scenarios.

        • 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.

          Amazon ECS blue/green deployments are best suited for the following scenarios:

          • Service validation: When you need to validate new service revisions before directing production traffic to them

          • Zero downtime: When your service requires zero-downtime deployments

          • Instant roll back: When you need the ability to quickly roll back if issues are detected

          • Load balancer requirement: When your service uses Application Load Balancer, Network Load Balancer, or Service Connect

      • External

        Use a third-party deployment controller.

      • Blue/green deployment (powered by CodeDeploy)

        CodeDeploy installs an updated version of the application as a new replacement task set and reroutes production traffic from the original application task set to the replacement task set. The original task set is terminated after a successful deployment. Use this deployment controller to verify a new deployment of a service before sending production traffic to it.

      If the service returns an enum value that is not available in the current SDK version, type will return DeploymentControllerType.UNKNOWN_TO_SDK_VERSION. The raw value returned by the service is available from typeAsString().

      Returns:
      The deployment controller type to use.

      The deployment controller is the mechanism that determines how tasks are deployed for your service. The valid options are:

      • ECS

        When you create a service which uses the ECS deployment controller, you can choose between the following deployment strategies:

        • 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.

          Rolling update deployments are best suited for the following scenarios:

          • Gradual service updates: You need to update your service incrementally without taking the entire service offline at once.

          • Limited resource requirements: You want to avoid the additional resource costs of running two complete environments simultaneously (as required by blue/green deployments).

          • Acceptable deployment time: Your application can tolerate a longer deployment process, as rolling updates replace tasks one by one.

          • No need for instant roll back: Your service can tolerate a rollback process that takes minutes rather than seconds.

          • Simple deployment process: You prefer a straightforward deployment approach without the complexity of managing multiple environments, target groups, and listeners.

          • No load balancer requirement: Your service doesn't use or require a load balancer, Application Load Balancer, Network Load Balancer, or Service Connect (which are required for blue/green deployments).

          • Stateful applications: Your application maintains state that makes it difficult to run two parallel environments.

          • Cost sensitivity: You want to minimize deployment costs by not running duplicate environments during deployment.

          Rolling updates are the default deployment strategy for services and provide a balance between deployment safety and resource efficiency for many common application scenarios.

        • 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.

          Amazon ECS blue/green deployments are best suited for the following scenarios:

          • Service validation: When you need to validate new service revisions before directing production traffic to them

          • Zero downtime: When your service requires zero-downtime deployments

          • Instant roll back: When you need the ability to quickly roll back if issues are detected

          • Load balancer requirement: When your service uses Application Load Balancer, Network Load Balancer, or Service Connect

      • External

        Use a third-party deployment controller.

      • Blue/green deployment (powered by CodeDeploy)

        CodeDeploy installs an updated version of the application as a new replacement task set and reroutes production traffic from the original application task set to the replacement task set. The original task set is terminated after a successful deployment. Use this deployment controller to verify a new deployment of a service before sending production traffic to it.

      See Also:

    • toBuilder

      public DeploymentController.Builder toBuilder()
      Description copied from interface: ToCopyableBuilder
      Take this object and create a builder that contains all of the current property values of this object.
      Specified by:
      toBuilder in interface ToCopyableBuilder<DeploymentController.Builder,DeploymentController>
      Returns:
      a builder for type T

    • builder

      public static DeploymentController.Builder builder()

    • serializableBuilderClass

      public static Class<? extends DeploymentController.Builder> serializableBuilderClass()

    • hashCode

      public final int hashCode()
      Overrides:
      hashCode in class Object

    • equals

      public final boolean equals(Object obj)
      Overrides:
      equals in class Object

    • equalsBySdkFields

      public final boolean equalsBySdkFields(Object obj)
      Description copied from interface: SdkPojo
      Indicates whether some other object is "equal to" this one by SDK fields. An SDK field is a modeled, non-inherited field in an SdkPojo class, and is generated based on a service model.

      If an SdkPojo class does not have any inherited fields, equalsBySdkFields and equals are essentially the same.

      Specified by:
      equalsBySdkFields in interface SdkPojo
      Parameters:
      obj - the object to be compared with
      Returns:
      true if the other object equals to this object by sdk fields, false otherwise.

    • toString

      public final String toString()
      Returns a string representation of this object. This is useful for testing and debugging. Sensitive data will be redacted from this string using a placeholder value.
      Overrides:
      toString in class Object

    • getValueForField

      public final <T> Optional<T> getValueForField(String fieldName, Class<T> clazz)

    • sdkFields

      public final List<SdkField<?>> sdkFields()
      Specified by:
      sdkFields in interface SdkPojo
      Returns:
      List of SdkField in this POJO. May be empty list but should never be null.

    • sdkFieldNameToField

      public final Map<String,SdkField<?>> sdkFieldNameToField()
      Specified by:
      sdkFieldNameToField in interface SdkPojo
      Returns:
      The mapping between the field name and its corresponding field.