pub struct RegisterTaskDefinitionFluentBuilder { /* private fields */ }
Expand description
Fluent builder constructing a request to RegisterTaskDefinition
.
Registers a new task definition from the supplied family
and containerDefinitions
. Optionally, you can add data volumes to your containers with the volumes
parameter. For more information about task definition parameters and defaults, see Amazon ECS Task Definitions in the Amazon Elastic Container Service Developer Guide.
You can specify a role for your task with the taskRoleArn
parameter. When you specify a role for a task, its containers can then use the latest versions of the CLI or SDKs to make API requests to the Amazon Web Services services that are specified in the policy that's associated with the role. For more information, see IAM Roles for Tasks in the Amazon Elastic Container Service Developer Guide.
You can specify a Docker networking mode for the containers in your task definition with the networkMode
parameter. If you specify the awsvpc
network mode, the task is allocated an elastic network interface, and you must specify a NetworkConfiguration when you create a service or run a task with the task definition. For more information, see Task Networking in the Amazon Elastic Container Service Developer Guide.
Implementations§
Source§impl RegisterTaskDefinitionFluentBuilder
impl RegisterTaskDefinitionFluentBuilder
Sourcepub fn as_input(&self) -> &RegisterTaskDefinitionInputBuilder
pub fn as_input(&self) -> &RegisterTaskDefinitionInputBuilder
Access the RegisterTaskDefinition as a reference.
Sourcepub async fn send(
self,
) -> Result<RegisterTaskDefinitionOutput, SdkError<RegisterTaskDefinitionError, HttpResponse>>
pub async fn send( self, ) -> Result<RegisterTaskDefinitionOutput, SdkError<RegisterTaskDefinitionError, HttpResponse>>
Sends the request and returns the response.
If an error occurs, an SdkError
will be returned with additional details that
can be matched against.
By default, any retryable failures will be retried twice. Retry behavior is configurable with the RetryConfig, which can be set when configuring the client.
Sourcepub fn customize(
self,
) -> CustomizableOperation<RegisterTaskDefinitionOutput, RegisterTaskDefinitionError, Self>
pub fn customize( self, ) -> CustomizableOperation<RegisterTaskDefinitionOutput, RegisterTaskDefinitionError, Self>
Consumes this builder, creating a customizable operation that can be modified before being sent.
Sourcepub fn family(self, input: impl Into<String>) -> Self
pub fn family(self, input: impl Into<String>) -> Self
You must specify a family
for a task definition. You can use it track multiple versions of the same task definition. The family
is used as a name for your task definition. Up to 255 letters (uppercase and lowercase), numbers, underscores, and hyphens are allowed.
Sourcepub fn set_family(self, input: Option<String>) -> Self
pub fn set_family(self, input: Option<String>) -> Self
You must specify a family
for a task definition. You can use it track multiple versions of the same task definition. The family
is used as a name for your task definition. Up to 255 letters (uppercase and lowercase), numbers, underscores, and hyphens are allowed.
Sourcepub fn get_family(&self) -> &Option<String>
pub fn get_family(&self) -> &Option<String>
You must specify a family
for a task definition. You can use it track multiple versions of the same task definition. The family
is used as a name for your task definition. Up to 255 letters (uppercase and lowercase), numbers, underscores, and hyphens are allowed.
Sourcepub fn task_role_arn(self, input: impl Into<String>) -> Self
pub fn task_role_arn(self, input: impl Into<String>) -> Self
The short name or full Amazon Resource Name (ARN) of the IAM role that containers in this task can assume. All containers in this task are granted the permissions that are specified in this role. For more information, see IAM Roles for Tasks in the Amazon Elastic Container Service Developer Guide.
Sourcepub fn set_task_role_arn(self, input: Option<String>) -> Self
pub fn set_task_role_arn(self, input: Option<String>) -> Self
The short name or full Amazon Resource Name (ARN) of the IAM role that containers in this task can assume. All containers in this task are granted the permissions that are specified in this role. For more information, see IAM Roles for Tasks in the Amazon Elastic Container Service Developer Guide.
Sourcepub fn get_task_role_arn(&self) -> &Option<String>
pub fn get_task_role_arn(&self) -> &Option<String>
The short name or full Amazon Resource Name (ARN) of the IAM role that containers in this task can assume. All containers in this task are granted the permissions that are specified in this role. For more information, see IAM Roles for Tasks in the Amazon Elastic Container Service Developer Guide.
Sourcepub fn execution_role_arn(self, input: impl Into<String>) -> Self
pub fn execution_role_arn(self, input: impl Into<String>) -> Self
The Amazon Resource Name (ARN) of the task execution role that grants the Amazon ECS container agent permission to make Amazon Web Services API calls on your behalf. For informationabout the required IAM roles for Amazon ECS, see IAM roles for Amazon ECS in the Amazon Elastic Container Service Developer Guide.
Sourcepub fn set_execution_role_arn(self, input: Option<String>) -> Self
pub fn set_execution_role_arn(self, input: Option<String>) -> Self
The Amazon Resource Name (ARN) of the task execution role that grants the Amazon ECS container agent permission to make Amazon Web Services API calls on your behalf. For informationabout the required IAM roles for Amazon ECS, see IAM roles for Amazon ECS in the Amazon Elastic Container Service Developer Guide.
Sourcepub fn get_execution_role_arn(&self) -> &Option<String>
pub fn get_execution_role_arn(&self) -> &Option<String>
The Amazon Resource Name (ARN) of the task execution role that grants the Amazon ECS container agent permission to make Amazon Web Services API calls on your behalf. For informationabout the required IAM roles for Amazon ECS, see IAM roles for Amazon ECS in the Amazon Elastic Container Service Developer Guide.
Sourcepub fn network_mode(self, input: NetworkMode) -> Self
pub fn network_mode(self, input: NetworkMode) -> Self
The Docker networking mode to use for the containers in the task. The valid values are none
, bridge
, awsvpc
, and host
. If no network mode is specified, the default is bridge
.
For Amazon ECS tasks on Fargate, the awsvpc
network mode is required. For Amazon ECS tasks on Amazon EC2 Linux instances, any network mode can be used. For Amazon ECS tasks on Amazon EC2 Windows instances,
or awsvpc
can be used. If the network mode is set to none
, you cannot specify port mappings in your container definitions, and the tasks containers do not have external connectivity. The host
and awsvpc
network modes offer the highest networking performance for containers because they use the EC2 network stack instead of the virtualized network stack provided by the bridge
mode.
With the host
and awsvpc
network modes, exposed container ports are mapped directly to the corresponding host port (for the host
network mode) or the attached elastic network interface port (for the awsvpc
network mode), so you cannot take advantage of dynamic host port mappings.
When using the host
network mode, you should not run containers using the root user (UID 0). It is considered best practice to use a non-root user.
If the network mode is awsvpc
, the task is allocated an elastic network interface, and you must specify a NetworkConfiguration value when you create a service or run a task with the task definition. For more information, see Task Networking in the Amazon Elastic Container Service Developer Guide.
If the network mode is host
, you cannot run multiple instantiations of the same task on a single container instance when port mappings are used.
Sourcepub fn set_network_mode(self, input: Option<NetworkMode>) -> Self
pub fn set_network_mode(self, input: Option<NetworkMode>) -> Self
The Docker networking mode to use for the containers in the task. The valid values are none
, bridge
, awsvpc
, and host
. If no network mode is specified, the default is bridge
.
For Amazon ECS tasks on Fargate, the awsvpc
network mode is required. For Amazon ECS tasks on Amazon EC2 Linux instances, any network mode can be used. For Amazon ECS tasks on Amazon EC2 Windows instances,
or awsvpc
can be used. If the network mode is set to none
, you cannot specify port mappings in your container definitions, and the tasks containers do not have external connectivity. The host
and awsvpc
network modes offer the highest networking performance for containers because they use the EC2 network stack instead of the virtualized network stack provided by the bridge
mode.
With the host
and awsvpc
network modes, exposed container ports are mapped directly to the corresponding host port (for the host
network mode) or the attached elastic network interface port (for the awsvpc
network mode), so you cannot take advantage of dynamic host port mappings.
When using the host
network mode, you should not run containers using the root user (UID 0). It is considered best practice to use a non-root user.
If the network mode is awsvpc
, the task is allocated an elastic network interface, and you must specify a NetworkConfiguration value when you create a service or run a task with the task definition. For more information, see Task Networking in the Amazon Elastic Container Service Developer Guide.
If the network mode is host
, you cannot run multiple instantiations of the same task on a single container instance when port mappings are used.
Sourcepub fn get_network_mode(&self) -> &Option<NetworkMode>
pub fn get_network_mode(&self) -> &Option<NetworkMode>
The Docker networking mode to use for the containers in the task. The valid values are none
, bridge
, awsvpc
, and host
. If no network mode is specified, the default is bridge
.
For Amazon ECS tasks on Fargate, the awsvpc
network mode is required. For Amazon ECS tasks on Amazon EC2 Linux instances, any network mode can be used. For Amazon ECS tasks on Amazon EC2 Windows instances,
or awsvpc
can be used. If the network mode is set to none
, you cannot specify port mappings in your container definitions, and the tasks containers do not have external connectivity. The host
and awsvpc
network modes offer the highest networking performance for containers because they use the EC2 network stack instead of the virtualized network stack provided by the bridge
mode.
With the host
and awsvpc
network modes, exposed container ports are mapped directly to the corresponding host port (for the host
network mode) or the attached elastic network interface port (for the awsvpc
network mode), so you cannot take advantage of dynamic host port mappings.
When using the host
network mode, you should not run containers using the root user (UID 0). It is considered best practice to use a non-root user.
If the network mode is awsvpc
, the task is allocated an elastic network interface, and you must specify a NetworkConfiguration value when you create a service or run a task with the task definition. For more information, see Task Networking in the Amazon Elastic Container Service Developer Guide.
If the network mode is host
, you cannot run multiple instantiations of the same task on a single container instance when port mappings are used.
Sourcepub fn container_definitions(self, input: ContainerDefinition) -> Self
pub fn container_definitions(self, input: ContainerDefinition) -> Self
Appends an item to containerDefinitions
.
To override the contents of this collection use set_container_definitions
.
A list of container definitions in JSON format that describe the different containers that make up your task.
Sourcepub fn set_container_definitions(
self,
input: Option<Vec<ContainerDefinition>>,
) -> Self
pub fn set_container_definitions( self, input: Option<Vec<ContainerDefinition>>, ) -> Self
A list of container definitions in JSON format that describe the different containers that make up your task.
Sourcepub fn get_container_definitions(&self) -> &Option<Vec<ContainerDefinition>>
pub fn get_container_definitions(&self) -> &Option<Vec<ContainerDefinition>>
A list of container definitions in JSON format that describe the different containers that make up your task.
Sourcepub fn volumes(self, input: Volume) -> Self
pub fn volumes(self, input: Volume) -> Self
Appends an item to volumes
.
To override the contents of this collection use set_volumes
.
A list of volume definitions in JSON format that containers in your task might use.
Sourcepub fn set_volumes(self, input: Option<Vec<Volume>>) -> Self
pub fn set_volumes(self, input: Option<Vec<Volume>>) -> Self
A list of volume definitions in JSON format that containers in your task might use.
Sourcepub fn get_volumes(&self) -> &Option<Vec<Volume>>
pub fn get_volumes(&self) -> &Option<Vec<Volume>>
A list of volume definitions in JSON format that containers in your task might use.
Sourcepub fn placement_constraints(
self,
input: TaskDefinitionPlacementConstraint,
) -> Self
pub fn placement_constraints( self, input: TaskDefinitionPlacementConstraint, ) -> Self
Appends an item to placementConstraints
.
To override the contents of this collection use set_placement_constraints
.
An array of placement constraint objects to use for the task. You can specify a maximum of 10 constraints for each task. This limit includes constraints in the task definition and those specified at runtime.
Sourcepub fn set_placement_constraints(
self,
input: Option<Vec<TaskDefinitionPlacementConstraint>>,
) -> Self
pub fn set_placement_constraints( self, input: Option<Vec<TaskDefinitionPlacementConstraint>>, ) -> Self
An array of placement constraint objects to use for the task. You can specify a maximum of 10 constraints for each task. This limit includes constraints in the task definition and those specified at runtime.
Sourcepub fn get_placement_constraints(
&self,
) -> &Option<Vec<TaskDefinitionPlacementConstraint>>
pub fn get_placement_constraints( &self, ) -> &Option<Vec<TaskDefinitionPlacementConstraint>>
An array of placement constraint objects to use for the task. You can specify a maximum of 10 constraints for each task. This limit includes constraints in the task definition and those specified at runtime.
Sourcepub fn requires_compatibilities(self, input: Compatibility) -> Self
pub fn requires_compatibilities(self, input: Compatibility) -> Self
Appends an item to requiresCompatibilities
.
To override the contents of this collection use set_requires_compatibilities
.
The task launch type that Amazon ECS validates the task definition against. A client exception is returned if the task definition doesn't validate against the compatibilities specified. If no value is specified, the parameter is omitted from the response.
Sourcepub fn set_requires_compatibilities(
self,
input: Option<Vec<Compatibility>>,
) -> Self
pub fn set_requires_compatibilities( self, input: Option<Vec<Compatibility>>, ) -> Self
The task launch type that Amazon ECS validates the task definition against. A client exception is returned if the task definition doesn't validate against the compatibilities specified. If no value is specified, the parameter is omitted from the response.
Sourcepub fn get_requires_compatibilities(&self) -> &Option<Vec<Compatibility>>
pub fn get_requires_compatibilities(&self) -> &Option<Vec<Compatibility>>
The task launch type that Amazon ECS validates the task definition against. A client exception is returned if the task definition doesn't validate against the compatibilities specified. If no value is specified, the parameter is omitted from the response.
Sourcepub fn cpu(self, input: impl Into<String>) -> Self
pub fn cpu(self, input: impl Into<String>) -> Self
The number of CPU units used by the task. It can be expressed as an integer using CPU units (for example, 1024
) or as a string using vCPUs (for example, 1 vCPU
or 1 vcpu
) in a task definition. String values are converted to an integer indicating the CPU units when the task definition is registered.
Task-level CPU and memory parameters are ignored for Windows containers. We recommend specifying container-level resources for Windows containers.
If you're using the EC2 launch type or external launch type, this field is optional. Supported values are between 128
CPU units (0.125
vCPUs) and 196608
CPU units (192
vCPUs). If you do not specify a value, the parameter is ignored.
This field is required for Fargate. For information about the valid values, see Task size in the Amazon Elastic Container Service Developer Guide.
Sourcepub fn set_cpu(self, input: Option<String>) -> Self
pub fn set_cpu(self, input: Option<String>) -> Self
The number of CPU units used by the task. It can be expressed as an integer using CPU units (for example, 1024
) or as a string using vCPUs (for example, 1 vCPU
or 1 vcpu
) in a task definition. String values are converted to an integer indicating the CPU units when the task definition is registered.
Task-level CPU and memory parameters are ignored for Windows containers. We recommend specifying container-level resources for Windows containers.
If you're using the EC2 launch type or external launch type, this field is optional. Supported values are between 128
CPU units (0.125
vCPUs) and 196608
CPU units (192
vCPUs). If you do not specify a value, the parameter is ignored.
This field is required for Fargate. For information about the valid values, see Task size in the Amazon Elastic Container Service Developer Guide.
Sourcepub fn get_cpu(&self) -> &Option<String>
pub fn get_cpu(&self) -> &Option<String>
The number of CPU units used by the task. It can be expressed as an integer using CPU units (for example, 1024
) or as a string using vCPUs (for example, 1 vCPU
or 1 vcpu
) in a task definition. String values are converted to an integer indicating the CPU units when the task definition is registered.
Task-level CPU and memory parameters are ignored for Windows containers. We recommend specifying container-level resources for Windows containers.
If you're using the EC2 launch type or external launch type, this field is optional. Supported values are between 128
CPU units (0.125
vCPUs) and 196608
CPU units (192
vCPUs). If you do not specify a value, the parameter is ignored.
This field is required for Fargate. For information about the valid values, see Task size in the Amazon Elastic Container Service Developer Guide.
Sourcepub fn memory(self, input: impl Into<String>) -> Self
pub fn memory(self, input: impl Into<String>) -> Self
The amount of memory (in MiB) used by the task. It can be expressed as an integer using MiB (for example ,1024
) or as a string using GB (for example, 1GB
or 1 GB
) in a task definition. String values are converted to an integer indicating the MiB when the task definition is registered.
Task-level CPU and memory parameters are ignored for Windows containers. We recommend specifying container-level resources for Windows containers.
If using the EC2 launch type, this field is optional.
If using the Fargate launch type, this field is required and you must use one of the following values. This determines your range of supported values for the cpu
parameter.
The CPU units cannot be less than 1 vCPU when you use Windows containers on Fargate.
-
512 (0.5 GB), 1024 (1 GB), 2048 (2 GB) - Available
cpu
values: 256 (.25 vCPU) -
1024 (1 GB), 2048 (2 GB), 3072 (3 GB), 4096 (4 GB) - Available
cpu
values: 512 (.5 vCPU) -
2048 (2 GB), 3072 (3 GB), 4096 (4 GB), 5120 (5 GB), 6144 (6 GB), 7168 (7 GB), 8192 (8 GB) - Available
cpu
values: 1024 (1 vCPU) -
Between 4096 (4 GB) and 16384 (16 GB) in increments of 1024 (1 GB) - Available
cpu
values: 2048 (2 vCPU) -
Between 8192 (8 GB) and 30720 (30 GB) in increments of 1024 (1 GB) - Available
cpu
values: 4096 (4 vCPU) -
Between 16 GB and 60 GB in 4 GB increments - Available
cpu
values: 8192 (8 vCPU)This option requires Linux platform
1.4.0
or later. -
Between 32GB and 120 GB in 8 GB increments - Available
cpu
values: 16384 (16 vCPU)This option requires Linux platform
1.4.0
or later.
Sourcepub fn set_memory(self, input: Option<String>) -> Self
pub fn set_memory(self, input: Option<String>) -> Self
The amount of memory (in MiB) used by the task. It can be expressed as an integer using MiB (for example ,1024
) or as a string using GB (for example, 1GB
or 1 GB
) in a task definition. String values are converted to an integer indicating the MiB when the task definition is registered.
Task-level CPU and memory parameters are ignored for Windows containers. We recommend specifying container-level resources for Windows containers.
If using the EC2 launch type, this field is optional.
If using the Fargate launch type, this field is required and you must use one of the following values. This determines your range of supported values for the cpu
parameter.
The CPU units cannot be less than 1 vCPU when you use Windows containers on Fargate.
-
512 (0.5 GB), 1024 (1 GB), 2048 (2 GB) - Available
cpu
values: 256 (.25 vCPU) -
1024 (1 GB), 2048 (2 GB), 3072 (3 GB), 4096 (4 GB) - Available
cpu
values: 512 (.5 vCPU) -
2048 (2 GB), 3072 (3 GB), 4096 (4 GB), 5120 (5 GB), 6144 (6 GB), 7168 (7 GB), 8192 (8 GB) - Available
cpu
values: 1024 (1 vCPU) -
Between 4096 (4 GB) and 16384 (16 GB) in increments of 1024 (1 GB) - Available
cpu
values: 2048 (2 vCPU) -
Between 8192 (8 GB) and 30720 (30 GB) in increments of 1024 (1 GB) - Available
cpu
values: 4096 (4 vCPU) -
Between 16 GB and 60 GB in 4 GB increments - Available
cpu
values: 8192 (8 vCPU)This option requires Linux platform
1.4.0
or later. -
Between 32GB and 120 GB in 8 GB increments - Available
cpu
values: 16384 (16 vCPU)This option requires Linux platform
1.4.0
or later.
Sourcepub fn get_memory(&self) -> &Option<String>
pub fn get_memory(&self) -> &Option<String>
The amount of memory (in MiB) used by the task. It can be expressed as an integer using MiB (for example ,1024
) or as a string using GB (for example, 1GB
or 1 GB
) in a task definition. String values are converted to an integer indicating the MiB when the task definition is registered.
Task-level CPU and memory parameters are ignored for Windows containers. We recommend specifying container-level resources for Windows containers.
If using the EC2 launch type, this field is optional.
If using the Fargate launch type, this field is required and you must use one of the following values. This determines your range of supported values for the cpu
parameter.
The CPU units cannot be less than 1 vCPU when you use Windows containers on Fargate.
-
512 (0.5 GB), 1024 (1 GB), 2048 (2 GB) - Available
cpu
values: 256 (.25 vCPU) -
1024 (1 GB), 2048 (2 GB), 3072 (3 GB), 4096 (4 GB) - Available
cpu
values: 512 (.5 vCPU) -
2048 (2 GB), 3072 (3 GB), 4096 (4 GB), 5120 (5 GB), 6144 (6 GB), 7168 (7 GB), 8192 (8 GB) - Available
cpu
values: 1024 (1 vCPU) -
Between 4096 (4 GB) and 16384 (16 GB) in increments of 1024 (1 GB) - Available
cpu
values: 2048 (2 vCPU) -
Between 8192 (8 GB) and 30720 (30 GB) in increments of 1024 (1 GB) - Available
cpu
values: 4096 (4 vCPU) -
Between 16 GB and 60 GB in 4 GB increments - Available
cpu
values: 8192 (8 vCPU)This option requires Linux platform
1.4.0
or later. -
Between 32GB and 120 GB in 8 GB increments - Available
cpu
values: 16384 (16 vCPU)This option requires Linux platform
1.4.0
or later.
Appends an item to tags
.
To override the contents of this collection use set_tags
.
The metadata that you apply to the task definition to help you categorize and organize them. Each tag consists of a key and an optional value. You define both of them.
The following basic restrictions apply to tags:
-
Maximum number of tags per resource - 50
-
For each resource, each tag key must be unique, and each tag key can have only one value.
-
Maximum key length - 128 Unicode characters in UTF-8
-
Maximum value length - 256 Unicode characters in UTF-8
-
If your tagging schema is used across multiple services and resources, remember that other services may have restrictions on allowed characters. Generally allowed characters are: letters, numbers, and spaces representable in UTF-8, and the following characters: + - = . _ : / @.
-
Tag keys and values are case-sensitive.
-
Do not use
aws:
,AWS:
, or any upper or lowercase combination of such as a prefix for either keys or values as it is reserved for Amazon Web Services use. You cannot edit or delete tag keys or values with this prefix. Tags with this prefix do not count against your tags per resource limit.
The metadata that you apply to the task definition to help you categorize and organize them. Each tag consists of a key and an optional value. You define both of them.
The following basic restrictions apply to tags:
-
Maximum number of tags per resource - 50
-
For each resource, each tag key must be unique, and each tag key can have only one value.
-
Maximum key length - 128 Unicode characters in UTF-8
-
Maximum value length - 256 Unicode characters in UTF-8
-
If your tagging schema is used across multiple services and resources, remember that other services may have restrictions on allowed characters. Generally allowed characters are: letters, numbers, and spaces representable in UTF-8, and the following characters: + - = . _ : / @.
-
Tag keys and values are case-sensitive.
-
Do not use
aws:
,AWS:
, or any upper or lowercase combination of such as a prefix for either keys or values as it is reserved for Amazon Web Services use. You cannot edit or delete tag keys or values with this prefix. Tags with this prefix do not count against your tags per resource limit.
The metadata that you apply to the task definition to help you categorize and organize them. Each tag consists of a key and an optional value. You define both of them.
The following basic restrictions apply to tags:
-
Maximum number of tags per resource - 50
-
For each resource, each tag key must be unique, and each tag key can have only one value.
-
Maximum key length - 128 Unicode characters in UTF-8
-
Maximum value length - 256 Unicode characters in UTF-8
-
If your tagging schema is used across multiple services and resources, remember that other services may have restrictions on allowed characters. Generally allowed characters are: letters, numbers, and spaces representable in UTF-8, and the following characters: + - = . _ : / @.
-
Tag keys and values are case-sensitive.
-
Do not use
aws:
,AWS:
, or any upper or lowercase combination of such as a prefix for either keys or values as it is reserved for Amazon Web Services use. You cannot edit or delete tag keys or values with this prefix. Tags with this prefix do not count against your tags per resource limit.
Sourcepub fn pid_mode(self, input: PidMode) -> Self
pub fn pid_mode(self, input: PidMode) -> Self
The process namespace to use for the containers in the task. The valid values are host
or task
. On Fargate for Linux containers, the only valid value is task
. For example, monitoring sidecars might need pidMode
to access information about other containers running in the same task.
If host
is specified, all containers within the tasks that specified the host
PID mode on the same container instance share the same process namespace with the host Amazon EC2 instance.
If task
is specified, all containers within the specified task share the same process namespace.
If no value is specified, the default is a private namespace for each container.
If the host
PID mode is used, there's a heightened risk of undesired process namespace exposure.
This parameter is not supported for Windows containers.
This parameter is only supported for tasks that are hosted on Fargate if the tasks are using platform version 1.4.0
or later (Linux). This isn't supported for Windows containers on Fargate.
Sourcepub fn set_pid_mode(self, input: Option<PidMode>) -> Self
pub fn set_pid_mode(self, input: Option<PidMode>) -> Self
The process namespace to use for the containers in the task. The valid values are host
or task
. On Fargate for Linux containers, the only valid value is task
. For example, monitoring sidecars might need pidMode
to access information about other containers running in the same task.
If host
is specified, all containers within the tasks that specified the host
PID mode on the same container instance share the same process namespace with the host Amazon EC2 instance.
If task
is specified, all containers within the specified task share the same process namespace.
If no value is specified, the default is a private namespace for each container.
If the host
PID mode is used, there's a heightened risk of undesired process namespace exposure.
This parameter is not supported for Windows containers.
This parameter is only supported for tasks that are hosted on Fargate if the tasks are using platform version 1.4.0
or later (Linux). This isn't supported for Windows containers on Fargate.
Sourcepub fn get_pid_mode(&self) -> &Option<PidMode>
pub fn get_pid_mode(&self) -> &Option<PidMode>
The process namespace to use for the containers in the task. The valid values are host
or task
. On Fargate for Linux containers, the only valid value is task
. For example, monitoring sidecars might need pidMode
to access information about other containers running in the same task.
If host
is specified, all containers within the tasks that specified the host
PID mode on the same container instance share the same process namespace with the host Amazon EC2 instance.
If task
is specified, all containers within the specified task share the same process namespace.
If no value is specified, the default is a private namespace for each container.
If the host
PID mode is used, there's a heightened risk of undesired process namespace exposure.
This parameter is not supported for Windows containers.
This parameter is only supported for tasks that are hosted on Fargate if the tasks are using platform version 1.4.0
or later (Linux). This isn't supported for Windows containers on Fargate.
Sourcepub fn ipc_mode(self, input: IpcMode) -> Self
pub fn ipc_mode(self, input: IpcMode) -> Self
The IPC resource namespace to use for the containers in the task. The valid values are host
, task
, or none
. If host
is specified, then all containers within the tasks that specified the host
IPC mode on the same container instance share the same IPC resources with the host Amazon EC2 instance. If task
is specified, all containers within the specified task share the same IPC resources. If none
is specified, then IPC resources within the containers of a task are private and not shared with other containers in a task or on the container instance. If no value is specified, then the IPC resource namespace sharing depends on the Docker daemon setting on the container instance.
If the host
IPC mode is used, be aware that there is a heightened risk of undesired IPC namespace expose.
If you are setting namespaced kernel parameters using systemControls
for the containers in the task, the following will apply to your IPC resource namespace. For more information, see System Controls in the Amazon Elastic Container Service Developer Guide.
-
For tasks that use the
host
IPC mode, IPC namespace relatedsystemControls
are not supported. -
For tasks that use the
task
IPC mode, IPC namespace relatedsystemControls
will apply to all containers within a task.
This parameter is not supported for Windows containers or tasks run on Fargate.
Sourcepub fn set_ipc_mode(self, input: Option<IpcMode>) -> Self
pub fn set_ipc_mode(self, input: Option<IpcMode>) -> Self
The IPC resource namespace to use for the containers in the task. The valid values are host
, task
, or none
. If host
is specified, then all containers within the tasks that specified the host
IPC mode on the same container instance share the same IPC resources with the host Amazon EC2 instance. If task
is specified, all containers within the specified task share the same IPC resources. If none
is specified, then IPC resources within the containers of a task are private and not shared with other containers in a task or on the container instance. If no value is specified, then the IPC resource namespace sharing depends on the Docker daemon setting on the container instance.
If the host
IPC mode is used, be aware that there is a heightened risk of undesired IPC namespace expose.
If you are setting namespaced kernel parameters using systemControls
for the containers in the task, the following will apply to your IPC resource namespace. For more information, see System Controls in the Amazon Elastic Container Service Developer Guide.
-
For tasks that use the
host
IPC mode, IPC namespace relatedsystemControls
are not supported. -
For tasks that use the
task
IPC mode, IPC namespace relatedsystemControls
will apply to all containers within a task.
This parameter is not supported for Windows containers or tasks run on Fargate.
Sourcepub fn get_ipc_mode(&self) -> &Option<IpcMode>
pub fn get_ipc_mode(&self) -> &Option<IpcMode>
The IPC resource namespace to use for the containers in the task. The valid values are host
, task
, or none
. If host
is specified, then all containers within the tasks that specified the host
IPC mode on the same container instance share the same IPC resources with the host Amazon EC2 instance. If task
is specified, all containers within the specified task share the same IPC resources. If none
is specified, then IPC resources within the containers of a task are private and not shared with other containers in a task or on the container instance. If no value is specified, then the IPC resource namespace sharing depends on the Docker daemon setting on the container instance.
If the host
IPC mode is used, be aware that there is a heightened risk of undesired IPC namespace expose.
If you are setting namespaced kernel parameters using systemControls
for the containers in the task, the following will apply to your IPC resource namespace. For more information, see System Controls in the Amazon Elastic Container Service Developer Guide.
-
For tasks that use the
host
IPC mode, IPC namespace relatedsystemControls
are not supported. -
For tasks that use the
task
IPC mode, IPC namespace relatedsystemControls
will apply to all containers within a task.
This parameter is not supported for Windows containers or tasks run on Fargate.
Sourcepub fn proxy_configuration(self, input: ProxyConfiguration) -> Self
pub fn proxy_configuration(self, input: ProxyConfiguration) -> Self
The configuration details for the App Mesh proxy.
For tasks hosted on Amazon EC2 instances, the container instances require at least version 1.26.0
of the container agent and at least version 1.26.0-1
of the ecs-init
package to use a proxy configuration. If your container instances are launched from the Amazon ECS-optimized AMI version 20190301
or later, then they contain the required versions of the container agent and ecs-init
. For more information, see Amazon ECS-optimized AMI versions in the Amazon Elastic Container Service Developer Guide.
Sourcepub fn set_proxy_configuration(self, input: Option<ProxyConfiguration>) -> Self
pub fn set_proxy_configuration(self, input: Option<ProxyConfiguration>) -> Self
The configuration details for the App Mesh proxy.
For tasks hosted on Amazon EC2 instances, the container instances require at least version 1.26.0
of the container agent and at least version 1.26.0-1
of the ecs-init
package to use a proxy configuration. If your container instances are launched from the Amazon ECS-optimized AMI version 20190301
or later, then they contain the required versions of the container agent and ecs-init
. For more information, see Amazon ECS-optimized AMI versions in the Amazon Elastic Container Service Developer Guide.
Sourcepub fn get_proxy_configuration(&self) -> &Option<ProxyConfiguration>
pub fn get_proxy_configuration(&self) -> &Option<ProxyConfiguration>
The configuration details for the App Mesh proxy.
For tasks hosted on Amazon EC2 instances, the container instances require at least version 1.26.0
of the container agent and at least version 1.26.0-1
of the ecs-init
package to use a proxy configuration. If your container instances are launched from the Amazon ECS-optimized AMI version 20190301
or later, then they contain the required versions of the container agent and ecs-init
. For more information, see Amazon ECS-optimized AMI versions in the Amazon Elastic Container Service Developer Guide.
Sourcepub fn inference_accelerators(self, input: InferenceAccelerator) -> Self
pub fn inference_accelerators(self, input: InferenceAccelerator) -> Self
Appends an item to inferenceAccelerators
.
To override the contents of this collection use set_inference_accelerators
.
The Elastic Inference accelerators to use for the containers in the task.
Sourcepub fn set_inference_accelerators(
self,
input: Option<Vec<InferenceAccelerator>>,
) -> Self
pub fn set_inference_accelerators( self, input: Option<Vec<InferenceAccelerator>>, ) -> Self
The Elastic Inference accelerators to use for the containers in the task.
Sourcepub fn get_inference_accelerators(&self) -> &Option<Vec<InferenceAccelerator>>
pub fn get_inference_accelerators(&self) -> &Option<Vec<InferenceAccelerator>>
The Elastic Inference accelerators to use for the containers in the task.
Sourcepub fn ephemeral_storage(self, input: EphemeralStorage) -> Self
pub fn ephemeral_storage(self, input: EphemeralStorage) -> Self
The amount of ephemeral storage to allocate for the task. This parameter is used to expand the total amount of ephemeral storage available, beyond the default amount, for tasks hosted on Fargate. For more information, see Using data volumes in tasks in the Amazon ECS Developer Guide.
For tasks using the Fargate launch type, the task requires the following platforms:
-
Linux platform version
1.4.0
or later. -
Windows platform version
1.0.0
or later.
Sourcepub fn set_ephemeral_storage(self, input: Option<EphemeralStorage>) -> Self
pub fn set_ephemeral_storage(self, input: Option<EphemeralStorage>) -> Self
The amount of ephemeral storage to allocate for the task. This parameter is used to expand the total amount of ephemeral storage available, beyond the default amount, for tasks hosted on Fargate. For more information, see Using data volumes in tasks in the Amazon ECS Developer Guide.
For tasks using the Fargate launch type, the task requires the following platforms:
-
Linux platform version
1.4.0
or later. -
Windows platform version
1.0.0
or later.
Sourcepub fn get_ephemeral_storage(&self) -> &Option<EphemeralStorage>
pub fn get_ephemeral_storage(&self) -> &Option<EphemeralStorage>
The amount of ephemeral storage to allocate for the task. This parameter is used to expand the total amount of ephemeral storage available, beyond the default amount, for tasks hosted on Fargate. For more information, see Using data volumes in tasks in the Amazon ECS Developer Guide.
For tasks using the Fargate launch type, the task requires the following platforms:
-
Linux platform version
1.4.0
or later. -
Windows platform version
1.0.0
or later.
Sourcepub fn runtime_platform(self, input: RuntimePlatform) -> Self
pub fn runtime_platform(self, input: RuntimePlatform) -> Self
The operating system that your tasks definitions run on. A platform family is specified only for tasks using the Fargate launch type.
Sourcepub fn set_runtime_platform(self, input: Option<RuntimePlatform>) -> Self
pub fn set_runtime_platform(self, input: Option<RuntimePlatform>) -> Self
The operating system that your tasks definitions run on. A platform family is specified only for tasks using the Fargate launch type.
Sourcepub fn get_runtime_platform(&self) -> &Option<RuntimePlatform>
pub fn get_runtime_platform(&self) -> &Option<RuntimePlatform>
The operating system that your tasks definitions run on. A platform family is specified only for tasks using the Fargate launch type.
Sourcepub fn enable_fault_injection(self, input: bool) -> Self
pub fn enable_fault_injection(self, input: bool) -> Self
Enables fault injection when you register your task definition and allows for fault injection requests to be accepted from the task's containers. The default value is false
.
Sourcepub fn set_enable_fault_injection(self, input: Option<bool>) -> Self
pub fn set_enable_fault_injection(self, input: Option<bool>) -> Self
Enables fault injection when you register your task definition and allows for fault injection requests to be accepted from the task's containers. The default value is false
.
Sourcepub fn get_enable_fault_injection(&self) -> &Option<bool>
pub fn get_enable_fault_injection(&self) -> &Option<bool>
Enables fault injection when you register your task definition and allows for fault injection requests to be accepted from the task's containers. The default value is false
.
Trait Implementations§
Source§impl Clone for RegisterTaskDefinitionFluentBuilder
impl Clone for RegisterTaskDefinitionFluentBuilder
Source§fn clone(&self) -> RegisterTaskDefinitionFluentBuilder
fn clone(&self) -> RegisterTaskDefinitionFluentBuilder
1.0.0 · Source§fn clone_from(&mut self, source: &Self)
fn clone_from(&mut self, source: &Self)
source
. Read moreAuto Trait Implementations§
impl Freeze for RegisterTaskDefinitionFluentBuilder
impl !RefUnwindSafe for RegisterTaskDefinitionFluentBuilder
impl Send for RegisterTaskDefinitionFluentBuilder
impl Sync for RegisterTaskDefinitionFluentBuilder
impl Unpin for RegisterTaskDefinitionFluentBuilder
impl !UnwindSafe for RegisterTaskDefinitionFluentBuilder
Blanket Implementations§
Source§impl<T> BorrowMut<T> for Twhere
T: ?Sized,
impl<T> BorrowMut<T> for Twhere
T: ?Sized,
Source§fn borrow_mut(&mut self) -> &mut T
fn borrow_mut(&mut self) -> &mut T
Source§impl<T> CloneToUninit for Twhere
T: Clone,
impl<T> CloneToUninit for Twhere
T: Clone,
Source§impl<T> Instrument for T
impl<T> Instrument for T
Source§fn instrument(self, span: Span) -> Instrumented<Self>
fn instrument(self, span: Span) -> Instrumented<Self>
Source§fn in_current_span(self) -> Instrumented<Self>
fn in_current_span(self) -> Instrumented<Self>
Source§impl<T> IntoEither for T
impl<T> IntoEither for T
Source§fn into_either(self, into_left: bool) -> Either<Self, Self>
fn into_either(self, into_left: bool) -> Either<Self, Self>
self
into a Left
variant of Either<Self, Self>
if into_left
is true
.
Converts self
into a Right
variant of Either<Self, Self>
otherwise. Read moreSource§fn into_either_with<F>(self, into_left: F) -> Either<Self, Self>
fn into_either_with<F>(self, into_left: F) -> Either<Self, Self>
self
into a Left
variant of Either<Self, Self>
if into_left(&self)
returns true
.
Converts self
into a Right
variant of Either<Self, Self>
otherwise. Read moreSource§impl<T> Paint for Twhere
T: ?Sized,
impl<T> Paint for Twhere
T: ?Sized,
Source§fn fg(&self, value: Color) -> Painted<&T>
fn fg(&self, value: Color) -> Painted<&T>
Returns a styled value derived from self
with the foreground set to
value
.
This method should be used rarely. Instead, prefer to use color-specific
builder methods like red()
and
green()
, which have the same functionality but are
pithier.
§Example
Set foreground color to white using fg()
:
use yansi::{Paint, Color};
painted.fg(Color::White);
Set foreground color to white using white()
.
use yansi::Paint;
painted.white();
Source§fn bright_black(&self) -> Painted<&T>
fn bright_black(&self) -> Painted<&T>
Source§fn bright_red(&self) -> Painted<&T>
fn bright_red(&self) -> Painted<&T>
Source§fn bright_green(&self) -> Painted<&T>
fn bright_green(&self) -> Painted<&T>
Source§fn bright_yellow(&self) -> Painted<&T>
fn bright_yellow(&self) -> Painted<&T>
Source§fn bright_blue(&self) -> Painted<&T>
fn bright_blue(&self) -> Painted<&T>
Source§fn bright_magenta(&self) -> Painted<&T>
fn bright_magenta(&self) -> Painted<&T>
Source§fn bright_cyan(&self) -> Painted<&T>
fn bright_cyan(&self) -> Painted<&T>
Source§fn bright_white(&self) -> Painted<&T>
fn bright_white(&self) -> Painted<&T>
Source§fn bg(&self, value: Color) -> Painted<&T>
fn bg(&self, value: Color) -> Painted<&T>
Returns a styled value derived from self
with the background set to
value
.
This method should be used rarely. Instead, prefer to use color-specific
builder methods like on_red()
and
on_green()
, which have the same functionality but
are pithier.
§Example
Set background color to red using fg()
:
use yansi::{Paint, Color};
painted.bg(Color::Red);
Set background color to red using on_red()
.
use yansi::Paint;
painted.on_red();
Source§fn on_primary(&self) -> Painted<&T>
fn on_primary(&self) -> Painted<&T>
Source§fn on_magenta(&self) -> Painted<&T>
fn on_magenta(&self) -> Painted<&T>
Source§fn on_bright_black(&self) -> Painted<&T>
fn on_bright_black(&self) -> Painted<&T>
Source§fn on_bright_red(&self) -> Painted<&T>
fn on_bright_red(&self) -> Painted<&T>
Source§fn on_bright_green(&self) -> Painted<&T>
fn on_bright_green(&self) -> Painted<&T>
Source§fn on_bright_yellow(&self) -> Painted<&T>
fn on_bright_yellow(&self) -> Painted<&T>
Source§fn on_bright_blue(&self) -> Painted<&T>
fn on_bright_blue(&self) -> Painted<&T>
Source§fn on_bright_magenta(&self) -> Painted<&T>
fn on_bright_magenta(&self) -> Painted<&T>
Source§fn on_bright_cyan(&self) -> Painted<&T>
fn on_bright_cyan(&self) -> Painted<&T>
Source§fn on_bright_white(&self) -> Painted<&T>
fn on_bright_white(&self) -> Painted<&T>
Source§fn attr(&self, value: Attribute) -> Painted<&T>
fn attr(&self, value: Attribute) -> Painted<&T>
Enables the styling Attribute
value
.
This method should be used rarely. Instead, prefer to use
attribute-specific builder methods like bold()
and
underline()
, which have the same functionality
but are pithier.
§Example
Make text bold using attr()
:
use yansi::{Paint, Attribute};
painted.attr(Attribute::Bold);
Make text bold using using bold()
.
use yansi::Paint;
painted.bold();
Source§fn rapid_blink(&self) -> Painted<&T>
fn rapid_blink(&self) -> Painted<&T>
Source§fn quirk(&self, value: Quirk) -> Painted<&T>
fn quirk(&self, value: Quirk) -> Painted<&T>
Enables the yansi
Quirk
value
.
This method should be used rarely. Instead, prefer to use quirk-specific
builder methods like mask()
and
wrap()
, which have the same functionality but are
pithier.
§Example
Enable wrapping using .quirk()
:
use yansi::{Paint, Quirk};
painted.quirk(Quirk::Wrap);
Enable wrapping using wrap()
.
use yansi::Paint;
painted.wrap();
Source§fn clear(&self) -> Painted<&T>
👎Deprecated since 1.0.1: renamed to resetting()
due to conflicts with Vec::clear()
.
The clear()
method will be removed in a future release.
fn clear(&self) -> Painted<&T>
resetting()
due to conflicts with Vec::clear()
.
The clear()
method will be removed in a future release.Source§fn whenever(&self, value: Condition) -> Painted<&T>
fn whenever(&self, value: Condition) -> Painted<&T>
Conditionally enable styling based on whether the Condition
value
applies. Replaces any previous condition.
See the crate level docs for more details.
§Example
Enable styling painted
only when both stdout
and stderr
are TTYs:
use yansi::{Paint, Condition};
painted.red().on_yellow().whenever(Condition::STDOUTERR_ARE_TTY);