Struct aws_sdk_ecs::model::ContainerDefinition
source · [−]#[non_exhaustive]pub struct ContainerDefinition {Show 39 fields
pub name: Option<String>,
pub image: Option<String>,
pub repository_credentials: Option<RepositoryCredentials>,
pub cpu: i32,
pub memory: Option<i32>,
pub memory_reservation: Option<i32>,
pub links: Option<Vec<String>>,
pub port_mappings: Option<Vec<PortMapping>>,
pub essential: Option<bool>,
pub entry_point: Option<Vec<String>>,
pub command: Option<Vec<String>>,
pub environment: Option<Vec<KeyValuePair>>,
pub environment_files: Option<Vec<EnvironmentFile>>,
pub mount_points: Option<Vec<MountPoint>>,
pub volumes_from: Option<Vec<VolumeFrom>>,
pub linux_parameters: Option<LinuxParameters>,
pub secrets: Option<Vec<Secret>>,
pub depends_on: Option<Vec<ContainerDependency>>,
pub start_timeout: Option<i32>,
pub stop_timeout: Option<i32>,
pub hostname: Option<String>,
pub user: Option<String>,
pub working_directory: Option<String>,
pub disable_networking: Option<bool>,
pub privileged: Option<bool>,
pub readonly_root_filesystem: Option<bool>,
pub dns_servers: Option<Vec<String>>,
pub dns_search_domains: Option<Vec<String>>,
pub extra_hosts: Option<Vec<HostEntry>>,
pub docker_security_options: Option<Vec<String>>,
pub interactive: Option<bool>,
pub pseudo_terminal: Option<bool>,
pub docker_labels: Option<HashMap<String, String>>,
pub ulimits: Option<Vec<Ulimit>>,
pub log_configuration: Option<LogConfiguration>,
pub health_check: Option<HealthCheck>,
pub system_controls: Option<Vec<SystemControl>>,
pub resource_requirements: Option<Vec<ResourceRequirement>>,
pub firelens_configuration: Option<FirelensConfiguration>,
}
Expand description
Container definitions are used in task definitions to describe the different containers that are launched as part of a task.
Fields (Non-exhaustive)
This struct is marked as non-exhaustive
Struct { .. }
syntax; cannot be matched against without a wildcard ..
; and struct update syntax will not work.name: Option<String>
The name of a container. If you're linking multiple containers together in a task definition, the name
of one container can be entered in the links
of another container to connect the containers. Up to 255 letters (uppercase and lowercase), numbers, underscores, and hyphens are allowed. This parameter maps to name
in the Create a container section of the Docker Remote API and the --name
option to docker run.
image: Option<String>
The image used to start a container. This string is passed directly to the Docker daemon. By default, images in the Docker Hub registry are available. Other repositories are specified with either repository-url/image:tag
or repository-url/image@digest
. Up to 255 letters (uppercase and lowercase), numbers, hyphens, underscores, colons, periods, forward slashes, and number signs are allowed. This parameter maps to Image
in the Create a container section of the Docker Remote API and the IMAGE
parameter of docker run.
-
When a new task starts, the Amazon ECS container agent pulls the latest version of the specified image and tag for the container to use. However, subsequent updates to a repository image aren't propagated to already running tasks.
-
Images in Amazon ECR repositories can be specified by either using the full
registry/repository:tag
orregistry/repository@digest
. For example,012345678910.dkr.ecr.
or.amazonaws.com/ :latest 012345678910.dkr.ecr.
..amazonaws.com/ @sha256:94afd1f2e64d908bc90dbca0035a5b567EXAMPLE -
Images in official repositories on Docker Hub use a single name (for example,
ubuntu
ormongo
). -
Images in other repositories on Docker Hub are qualified with an organization name (for example,
amazon/amazon-ecs-agent
). -
Images in other online repositories are qualified further by a domain name (for example,
quay.io/assemblyline/ubuntu
).
repository_credentials: Option<RepositoryCredentials>
The private repository authentication credentials to use.
cpu: i32
The number of cpu
units reserved for the container. This parameter maps to CpuShares
in the Create a container section of the Docker Remote API and the --cpu-shares
option to docker run.
This field is optional for tasks using the Fargate launch type, and the only requirement is that the total amount of CPU reserved for all containers within a task be lower than the task-level cpu
value.
You can determine the number of CPU units that are available per EC2 instance type by multiplying the vCPUs listed for that instance type on the Amazon EC2 Instances detail page by 1,024.
Linux containers share unallocated CPU units with other containers on the container instance with the same ratio as their allocated amount. For example, if you run a single-container task on a single-core instance type with 512 CPU units specified for that container, and that's the only task running on the container instance, that container could use the full 1,024 CPU unit share at any given time. However, if you launched another copy of the same task on that container instance, each task is guaranteed a minimum of 512 CPU units when needed. Moreover, each container could float to higher CPU usage if the other container was not using it. If both tasks were 100% active all of the time, they would be limited to 512 CPU units.
On Linux container instances, the Docker daemon on the container instance uses the CPU value to calculate the relative CPU share ratios for running containers. For more information, see CPU share constraint in the Docker documentation. The minimum valid CPU share value that the Linux kernel allows is 2. However, the CPU parameter isn't required, and you can use CPU values below 2 in your container definitions. For CPU values below 2 (including null), the behavior varies based on your Amazon ECS container agent version:
-
Agent versions less than or equal to 1.1.0: Null and zero CPU values are passed to Docker as 0, which Docker then converts to 1,024 CPU shares. CPU values of 1 are passed to Docker as 1, which the Linux kernel converts to two CPU shares.
-
Agent versions greater than or equal to 1.2.0: Null, zero, and CPU values of 1 are passed to Docker as 2.
On Windows container instances, the CPU limit is enforced as an absolute limit, or a quota. Windows containers only have access to the specified amount of CPU that's described in the task definition. A null or zero CPU value is passed to Docker as 0
, which Windows interprets as 1% of one CPU.
memory: Option<i32>
The amount (in MiB) of memory to present to the container. If your container attempts to exceed the memory specified here, the container is killed. The total amount of memory reserved for all containers within a task must be lower than the task memory
value, if one is specified. This parameter maps to Memory
in the Create a container section of the Docker Remote API and the --memory
option to docker run.
If using the Fargate launch type, this parameter is optional.
If using the EC2 launch type, you must specify either a task-level memory value or a container-level memory value. If you specify both a container-level memory
and memoryReservation
value, memory
must be greater than memoryReservation
. If you specify memoryReservation
, then that value is subtracted from the available memory resources for the container instance where the container is placed. Otherwise, the value of memory
is used.
The Docker 20.10.0 or later daemon reserves a minimum of 6 MiB of memory for a container, so you should not specify fewer than 6 MiB of memory for your containers.
The Docker 19.03.13-ce or earlier daemon reserves a minimum of 4 MiB of memory for a container, so you should not specify fewer than 4 MiB of memory for your containers.
memory_reservation: Option<i32>
The soft limit (in MiB) of memory to reserve for the container. When system memory is under heavy contention, Docker attempts to keep the container memory to this soft limit. However, your container can consume more memory when it needs to, up to either the hard limit specified with the memory
parameter (if applicable), or all of the available memory on the container instance, whichever comes first. This parameter maps to MemoryReservation
in the Create a container section of the Docker Remote API and the --memory-reservation
option to docker run.
If a task-level memory value is not specified, you must specify a non-zero integer for one or both of memory
or memoryReservation
in a container definition. If you specify both, memory
must be greater than memoryReservation
. If you specify memoryReservation
, then that value is subtracted from the available memory resources for the container instance where the container is placed. Otherwise, the value of memory
is used.
For example, if your container normally uses 128 MiB of memory, but occasionally bursts to 256 MiB of memory for short periods of time, you can set a memoryReservation
of 128 MiB, and a memory
hard limit of 300 MiB. This configuration would allow the container to only reserve 128 MiB of memory from the remaining resources on the container instance, but also allow the container to consume more memory resources when needed.
The Docker daemon reserves a minimum of 4 MiB of memory for a container. Therefore, we recommend that you specify fewer than 4 MiB of memory for your containers.
links: Option<Vec<String>>
The links
parameter allows containers to communicate with each other without the need for port mappings. This parameter is only supported if the network mode of a task definition is bridge
. The name:internalName
construct is analogous to name:alias
in Docker links. Up to 255 letters (uppercase and lowercase), numbers, underscores, and hyphens are allowed. For more information about linking Docker containers, go to Legacy container links in the Docker documentation. This parameter maps to Links
in the Create a container section of the Docker Remote API and the --link
option to docker run.
This parameter is not supported for Windows containers.
Containers that are collocated on a single container instance may be able to communicate with each other without requiring links or host port mappings. Network isolation is achieved on the container instance using security groups and VPC settings.
port_mappings: Option<Vec<PortMapping>>
The list of port mappings for the container. Port mappings allow containers to access ports on the host container instance to send or receive traffic.
For task definitions that use the awsvpc
network mode, only specify the containerPort
. The hostPort
can be left blank or it must be the same value as the containerPort
.
Port mappings on Windows use the NetNAT
gateway address rather than localhost
. There's no loopback for port mappings on Windows, so you can't access a container's mapped port from the host itself.
This parameter maps to PortBindings
in the Create a container section of the Docker Remote API and the --publish
option to docker run. If the network mode of a task definition is set to none
, then you can't specify port mappings. If the network mode of a task definition is set to host
, then host ports must either be undefined or they must match the container port in the port mapping.
After a task reaches the RUNNING
status, manual and automatic host and container port assignments are visible in the Network Bindings section of a container description for a selected task in the Amazon ECS console. The assignments are also visible in the networkBindings
section DescribeTasks
responses.
essential: Option<bool>
If the essential
parameter of a container is marked as true
, and that container fails or stops for any reason, all other containers that are part of the task are stopped. If the essential
parameter of a container is marked as false
, its failure doesn't affect the rest of the containers in a task. If this parameter is omitted, a container is assumed to be essential.
All tasks must have at least one essential container. If you have an application that's composed of multiple containers, group containers that are used for a common purpose into components, and separate the different components into multiple task definitions. For more information, see Application Architecture in the Amazon Elastic Container Service Developer Guide.
entry_point: Option<Vec<String>>
Early versions of the Amazon ECS container agent don't properly handle entryPoint
parameters. If you have problems using entryPoint
, update your container agent or enter your commands and arguments as command
array items instead.
The entry point that's passed to the container. This parameter maps to Entrypoint
in the Create a container section of the Docker Remote API and the --entrypoint
option to docker run. For more information, see https://docs.docker.com/engine/reference/builder/#entrypoint.
command: Option<Vec<String>>
The command that's passed to the container. This parameter maps to Cmd
in the Create a container section of the Docker Remote API and the COMMAND
parameter to docker run. For more information, see https://docs.docker.com/engine/reference/builder/#cmd. If there are multiple arguments, each argument is a separated string in the array.
environment: Option<Vec<KeyValuePair>>
The environment variables to pass to a container. This parameter maps to Env
in the Create a container section of the Docker Remote API and the --env
option to docker run.
We don't recommend that you use plaintext environment variables for sensitive information, such as credential data.
environment_files: Option<Vec<EnvironmentFile>>
A list of files containing the environment variables to pass to a container. This parameter maps to the --env-file
option to docker run.
You can specify up to ten environment files. The file must have a .env
file extension. Each line in an environment file contains an environment variable in VARIABLE=VALUE
format. Lines beginning with #
are treated as comments and are ignored. For more information about the environment variable file syntax, see Declare default environment variables in file.
If there are environment variables specified using the environment
parameter in a container definition, they take precedence over the variables contained within an environment file. If multiple environment files are specified that contain the same variable, they're processed from the top down. We recommend that you use unique variable names. For more information, see Specifying Environment Variables in the Amazon Elastic Container Service Developer Guide.
mount_points: Option<Vec<MountPoint>>
The mount points for data volumes in your container.
This parameter maps to Volumes
in the Create a container section of the Docker Remote API and the --volume
option to docker run.
Windows containers can mount whole directories on the same drive as $env:ProgramData
. Windows containers can't mount directories on a different drive, and mount point can't be across drives.
volumes_from: Option<Vec<VolumeFrom>>
Data volumes to mount from another container. This parameter maps to VolumesFrom
in the Create a container section of the Docker Remote API and the --volumes-from
option to docker run.
linux_parameters: Option<LinuxParameters>
Linux-specific modifications that are applied to the container, such as Linux kernel capabilities. For more information see KernelCapabilities
.
This parameter is not supported for Windows containers.
secrets: Option<Vec<Secret>>
The secrets to pass to the container. For more information, see Specifying Sensitive Data in the Amazon Elastic Container Service Developer Guide.
depends_on: Option<Vec<ContainerDependency>>
The dependencies defined for container startup and shutdown. A container can contain multiple dependencies. When a dependency is defined for container startup, for container shutdown it is reversed.
For tasks using the EC2 launch type, the container instances require at least version 1.26.0 of the container agent to turn on container dependencies. However, we recommend using the latest container agent version. For information about checking your agent version and updating to the latest version, see Updating the Amazon ECS Container Agent in the Amazon Elastic Container Service Developer Guide. If you're using an Amazon ECS-optimized Linux AMI, your instance needs at least version 1.26.0-1 of the ecs-init
package. If your container instances are launched from version 20190301
or later, then they contain the required versions of the container agent and ecs-init
. For more information, see Amazon ECS-optimized Linux AMI in the Amazon Elastic Container Service Developer Guide.
For tasks using the Fargate launch type, the task or service requires the following platforms:
-
Linux platform version
1.3.0
or later. -
Windows platform version
1.0.0
or later.
start_timeout: Option<i32>
Time duration (in seconds) to wait before giving up on resolving dependencies for a container. For example, you specify two containers in a task definition with containerA having a dependency on containerB reaching a COMPLETE
, SUCCESS
, or HEALTHY
status. If a startTimeout
value is specified for containerB and it doesn't reach the desired status within that time then containerA gives up and not start. This results in the task transitioning to a STOPPED
state.
When the ECS_CONTAINER_START_TIMEOUT
container agent configuration variable is used, it's enforced independently from this start timeout value.
For tasks using the Fargate launch type, the task or service requires the following platforms:
-
Linux platform version
1.3.0
or later. -
Windows platform version
1.0.0
or later.
For tasks using the EC2 launch type, your container instances require at least version 1.26.0
of the container agent to use a container start timeout value. However, we recommend using the latest container agent version. For information about checking your agent version and updating to the latest version, see Updating the Amazon ECS Container Agent in the Amazon Elastic Container Service Developer Guide. If you're using an Amazon ECS-optimized Linux AMI, your instance needs at least version 1.26.0-1
of the ecs-init
package. If your container instances are launched from version 20190301
or later, then they contain the required versions of the container agent and ecs-init
. For more information, see Amazon ECS-optimized Linux AMI in the Amazon Elastic Container Service Developer Guide.
stop_timeout: Option<i32>
Time duration (in seconds) to wait before the container is forcefully killed if it doesn't exit normally on its own.
For tasks using the Fargate launch type, the task or service requires the following platforms:
-
Linux platform version
1.3.0
or later. -
Windows platform version
1.0.0
or later.
The max stop timeout value is 120 seconds and if the parameter is not specified, the default value of 30 seconds is used.
For tasks that use the EC2 launch type, if the stopTimeout
parameter isn't specified, the value set for the Amazon ECS container agent configuration variable ECS_CONTAINER_STOP_TIMEOUT
is used. If neither the stopTimeout
parameter or the ECS_CONTAINER_STOP_TIMEOUT
agent configuration variable are set, then the default values of 30 seconds for Linux containers and 30 seconds on Windows containers are used. Your container instances require at least version 1.26.0 of the container agent to use a container stop timeout value. However, we recommend using the latest container agent version. For information about checking your agent version and updating to the latest version, see Updating the Amazon ECS Container Agent in the Amazon Elastic Container Service Developer Guide. If you're using an Amazon ECS-optimized Linux AMI, your instance needs at least version 1.26.0-1 of the ecs-init
package. If your container instances are launched from version 20190301
or later, then they contain the required versions of the container agent and ecs-init
. For more information, see Amazon ECS-optimized Linux AMI in the Amazon Elastic Container Service Developer Guide.
hostname: Option<String>
The hostname to use for your container. This parameter maps to Hostname
in the Create a container section of the Docker Remote API and the --hostname
option to docker run.
The hostname
parameter is not supported if you're using the awsvpc
network mode.
user: Option<String>
The user to use inside the container. This parameter maps to User
in the Create a container section of the Docker Remote API and the --user
option to docker run.
When running tasks using the host
network mode, don't run containers using the root user (UID 0). We recommend using a non-root user for better security.
You can specify the user
using the following formats. If specifying a UID or GID, you must specify it as a positive integer.
-
user
-
user:group
-
uid
-
uid:gid
-
user:gid
-
uid:group
This parameter is not supported for Windows containers.
working_directory: Option<String>
The working directory to run commands inside the container in. This parameter maps to WorkingDir
in the Create a container section of the Docker Remote API and the --workdir
option to docker run.
disable_networking: Option<bool>
When this parameter is true, networking is disabled within the container. This parameter maps to NetworkDisabled
in the Create a container section of the Docker Remote API.
This parameter is not supported for Windows containers.
privileged: Option<bool>
When this parameter is true, the container is given elevated privileges on the host container instance (similar to the root
user). This parameter maps to Privileged
in the Create a container section of the Docker Remote API and the --privileged
option to docker run.
This parameter is not supported for Windows containers or tasks run on Fargate.
readonly_root_filesystem: Option<bool>
When this parameter is true, the container is given read-only access to its root file system. This parameter maps to ReadonlyRootfs
in the Create a container section of the Docker Remote API and the --read-only
option to docker run.
This parameter is not supported for Windows containers.
dns_servers: Option<Vec<String>>
A list of DNS servers that are presented to the container. This parameter maps to Dns
in the Create a container section of the Docker Remote API and the --dns
option to docker run.
This parameter is not supported for Windows containers.
dns_search_domains: Option<Vec<String>>
A list of DNS search domains that are presented to the container. This parameter maps to DnsSearch
in the Create a container section of the Docker Remote API and the --dns-search
option to docker run.
This parameter is not supported for Windows containers.
extra_hosts: Option<Vec<HostEntry>>
A list of hostnames and IP address mappings to append to the /etc/hosts
file on the container. This parameter maps to ExtraHosts
in the Create a container section of the Docker Remote API and the --add-host
option to docker run.
This parameter isn't supported for Windows containers or tasks that use the awsvpc
network mode.
docker_security_options: Option<Vec<String>>
A list of strings to provide custom labels for SELinux and AppArmor multi-level security systems. This field isn't valid for containers in tasks using the Fargate launch type.
With Windows containers, this parameter can be used to reference a credential spec file when configuring a container for Active Directory authentication. For more information, see Using gMSAs for Windows Containers in the Amazon Elastic Container Service Developer Guide.
This parameter maps to SecurityOpt
in the Create a container section of the Docker Remote API and the --security-opt
option to docker run.
The Amazon ECS container agent running on a container instance must register with the ECS_SELINUX_CAPABLE=true
or ECS_APPARMOR_CAPABLE=true
environment variables before containers placed on that instance can use these security options. For more information, see Amazon ECS Container Agent Configuration in the Amazon Elastic Container Service Developer Guide.
For more information about valid values, see Docker Run Security Configuration.
Valid values: "no-new-privileges" | "apparmor:PROFILE" | "label:value" | "credentialspec:CredentialSpecFilePath"
interactive: Option<bool>
When this parameter is true
, you can deploy containerized applications that require stdin
or a tty
to be allocated. This parameter maps to OpenStdin
in the Create a container section of the Docker Remote API and the --interactive
option to docker run.
pseudo_terminal: Option<bool>
When this parameter is true
, a TTY is allocated. This parameter maps to Tty
in the Create a container section of the Docker Remote API and the --tty
option to docker run.
docker_labels: Option<HashMap<String, String>>
A key/value map of labels to add to the container. This parameter maps to Labels
in the Create a container section of the Docker Remote API and the --label
option to docker run. This parameter requires version 1.18 of the Docker Remote API or greater on your container instance. To check the Docker Remote API version on your container instance, log in to your container instance and run the following command: sudo docker version --format '{{.Server.APIVersion}}'
ulimits: Option<Vec<Ulimit>>
A list of ulimits
to set in the container. If a ulimit value is specified in a task definition, it overrides the default values set by Docker. This parameter maps to Ulimits
in the Create a container section of the Docker Remote API and the --ulimit
option to docker run. Valid naming values are displayed in the Ulimit
data type.
Amazon ECS tasks hosted on Fargate use the default resource limit values set by the operating system with the exception of the nofile
resource limit parameter which Fargate overrides. The nofile
resource limit sets a restriction on the number of open files that a container can use. The default nofile
soft limit is 1024
and hard limit is 4096
.
This parameter requires version 1.18 of the Docker Remote API or greater on your container instance. To check the Docker Remote API version on your container instance, log in to your container instance and run the following command: sudo docker version --format '{{.Server.APIVersion}}'
This parameter is not supported for Windows containers.
log_configuration: Option<LogConfiguration>
The log configuration specification for the container.
This parameter maps to LogConfig
in the Create a container section of the Docker Remote API and the --log-driver
option to docker run. By default, containers use the same logging driver that the Docker daemon uses. However the container can use a different logging driver than the Docker daemon by specifying a log driver with this parameter in the container definition. To use a different logging driver for a container, the log system must be configured properly on the container instance (or on a different log server for remote logging options). For more information about the options for different supported log drivers, see Configure logging drivers in the Docker documentation.
Amazon ECS currently supports a subset of the logging drivers available to the Docker daemon (shown in the LogConfiguration
data type). Additional log drivers may be available in future releases of the Amazon ECS container agent.
This parameter requires version 1.18 of the Docker Remote API or greater on your container instance. To check the Docker Remote API version on your container instance, log in to your container instance and run the following command: sudo docker version --format '{{.Server.APIVersion}}'
The Amazon ECS container agent running on a container instance must register the logging drivers available on that instance with the ECS_AVAILABLE_LOGGING_DRIVERS
environment variable before containers placed on that instance can use these log configuration options. For more information, see Amazon ECS Container Agent Configuration in the Amazon Elastic Container Service Developer Guide.
health_check: Option<HealthCheck>
The container health check command and associated configuration parameters for the container. This parameter maps to HealthCheck
in the Create a container section of the Docker Remote API and the HEALTHCHECK
parameter of docker run.
system_controls: Option<Vec<SystemControl>>
A list of namespaced kernel parameters to set in the container. This parameter maps to Sysctls
in the Create a container section of the Docker Remote API and the --sysctl
option to docker run.
We don't recommended that you specify network-related systemControls
parameters for multiple containers in a single task that also uses either the awsvpc
or host
network modes. For tasks that use the awsvpc
network mode, the container that's started last determines which systemControls
parameters take effect. For tasks that use the host
network mode, it changes the container instance's namespaced kernel parameters as well as the containers.
resource_requirements: Option<Vec<ResourceRequirement>>
The type and amount of a resource to assign to a container. The only supported resource is a GPU.
firelens_configuration: Option<FirelensConfiguration>
The FireLens configuration for the container. This is used to specify and configure a log router for container logs. For more information, see Custom Log Routing in the Amazon Elastic Container Service Developer Guide.
Implementations
sourceimpl ContainerDefinition
impl ContainerDefinition
sourcepub fn name(&self) -> Option<&str>
pub fn name(&self) -> Option<&str>
The name of a container. If you're linking multiple containers together in a task definition, the name
of one container can be entered in the links
of another container to connect the containers. Up to 255 letters (uppercase and lowercase), numbers, underscores, and hyphens are allowed. This parameter maps to name
in the Create a container section of the Docker Remote API and the --name
option to docker run.
sourcepub fn image(&self) -> Option<&str>
pub fn image(&self) -> Option<&str>
The image used to start a container. This string is passed directly to the Docker daemon. By default, images in the Docker Hub registry are available. Other repositories are specified with either repository-url/image:tag
or repository-url/image@digest
. Up to 255 letters (uppercase and lowercase), numbers, hyphens, underscores, colons, periods, forward slashes, and number signs are allowed. This parameter maps to Image
in the Create a container section of the Docker Remote API and the IMAGE
parameter of docker run.
-
When a new task starts, the Amazon ECS container agent pulls the latest version of the specified image and tag for the container to use. However, subsequent updates to a repository image aren't propagated to already running tasks.
-
Images in Amazon ECR repositories can be specified by either using the full
registry/repository:tag
orregistry/repository@digest
. For example,012345678910.dkr.ecr.
or.amazonaws.com/ :latest 012345678910.dkr.ecr.
..amazonaws.com/ @sha256:94afd1f2e64d908bc90dbca0035a5b567EXAMPLE -
Images in official repositories on Docker Hub use a single name (for example,
ubuntu
ormongo
). -
Images in other repositories on Docker Hub are qualified with an organization name (for example,
amazon/amazon-ecs-agent
). -
Images in other online repositories are qualified further by a domain name (for example,
quay.io/assemblyline/ubuntu
).
sourcepub fn repository_credentials(&self) -> Option<&RepositoryCredentials>
pub fn repository_credentials(&self) -> Option<&RepositoryCredentials>
The private repository authentication credentials to use.
sourcepub fn cpu(&self) -> i32
pub fn cpu(&self) -> i32
The number of cpu
units reserved for the container. This parameter maps to CpuShares
in the Create a container section of the Docker Remote API and the --cpu-shares
option to docker run.
This field is optional for tasks using the Fargate launch type, and the only requirement is that the total amount of CPU reserved for all containers within a task be lower than the task-level cpu
value.
You can determine the number of CPU units that are available per EC2 instance type by multiplying the vCPUs listed for that instance type on the Amazon EC2 Instances detail page by 1,024.
Linux containers share unallocated CPU units with other containers on the container instance with the same ratio as their allocated amount. For example, if you run a single-container task on a single-core instance type with 512 CPU units specified for that container, and that's the only task running on the container instance, that container could use the full 1,024 CPU unit share at any given time. However, if you launched another copy of the same task on that container instance, each task is guaranteed a minimum of 512 CPU units when needed. Moreover, each container could float to higher CPU usage if the other container was not using it. If both tasks were 100% active all of the time, they would be limited to 512 CPU units.
On Linux container instances, the Docker daemon on the container instance uses the CPU value to calculate the relative CPU share ratios for running containers. For more information, see CPU share constraint in the Docker documentation. The minimum valid CPU share value that the Linux kernel allows is 2. However, the CPU parameter isn't required, and you can use CPU values below 2 in your container definitions. For CPU values below 2 (including null), the behavior varies based on your Amazon ECS container agent version:
-
Agent versions less than or equal to 1.1.0: Null and zero CPU values are passed to Docker as 0, which Docker then converts to 1,024 CPU shares. CPU values of 1 are passed to Docker as 1, which the Linux kernel converts to two CPU shares.
-
Agent versions greater than or equal to 1.2.0: Null, zero, and CPU values of 1 are passed to Docker as 2.
On Windows container instances, the CPU limit is enforced as an absolute limit, or a quota. Windows containers only have access to the specified amount of CPU that's described in the task definition. A null or zero CPU value is passed to Docker as 0
, which Windows interprets as 1% of one CPU.
sourcepub fn memory(&self) -> Option<i32>
pub fn memory(&self) -> Option<i32>
The amount (in MiB) of memory to present to the container. If your container attempts to exceed the memory specified here, the container is killed. The total amount of memory reserved for all containers within a task must be lower than the task memory
value, if one is specified. This parameter maps to Memory
in the Create a container section of the Docker Remote API and the --memory
option to docker run.
If using the Fargate launch type, this parameter is optional.
If using the EC2 launch type, you must specify either a task-level memory value or a container-level memory value. If you specify both a container-level memory
and memoryReservation
value, memory
must be greater than memoryReservation
. If you specify memoryReservation
, then that value is subtracted from the available memory resources for the container instance where the container is placed. Otherwise, the value of memory
is used.
The Docker 20.10.0 or later daemon reserves a minimum of 6 MiB of memory for a container, so you should not specify fewer than 6 MiB of memory for your containers.
The Docker 19.03.13-ce or earlier daemon reserves a minimum of 4 MiB of memory for a container, so you should not specify fewer than 4 MiB of memory for your containers.
sourcepub fn memory_reservation(&self) -> Option<i32>
pub fn memory_reservation(&self) -> Option<i32>
The soft limit (in MiB) of memory to reserve for the container. When system memory is under heavy contention, Docker attempts to keep the container memory to this soft limit. However, your container can consume more memory when it needs to, up to either the hard limit specified with the memory
parameter (if applicable), or all of the available memory on the container instance, whichever comes first. This parameter maps to MemoryReservation
in the Create a container section of the Docker Remote API and the --memory-reservation
option to docker run.
If a task-level memory value is not specified, you must specify a non-zero integer for one or both of memory
or memoryReservation
in a container definition. If you specify both, memory
must be greater than memoryReservation
. If you specify memoryReservation
, then that value is subtracted from the available memory resources for the container instance where the container is placed. Otherwise, the value of memory
is used.
For example, if your container normally uses 128 MiB of memory, but occasionally bursts to 256 MiB of memory for short periods of time, you can set a memoryReservation
of 128 MiB, and a memory
hard limit of 300 MiB. This configuration would allow the container to only reserve 128 MiB of memory from the remaining resources on the container instance, but also allow the container to consume more memory resources when needed.
The Docker daemon reserves a minimum of 4 MiB of memory for a container. Therefore, we recommend that you specify fewer than 4 MiB of memory for your containers.
sourcepub fn links(&self) -> Option<&[String]>
pub fn links(&self) -> Option<&[String]>
The links
parameter allows containers to communicate with each other without the need for port mappings. This parameter is only supported if the network mode of a task definition is bridge
. The name:internalName
construct is analogous to name:alias
in Docker links. Up to 255 letters (uppercase and lowercase), numbers, underscores, and hyphens are allowed. For more information about linking Docker containers, go to Legacy container links in the Docker documentation. This parameter maps to Links
in the Create a container section of the Docker Remote API and the --link
option to docker run.
This parameter is not supported for Windows containers.
Containers that are collocated on a single container instance may be able to communicate with each other without requiring links or host port mappings. Network isolation is achieved on the container instance using security groups and VPC settings.
sourcepub fn port_mappings(&self) -> Option<&[PortMapping]>
pub fn port_mappings(&self) -> Option<&[PortMapping]>
The list of port mappings for the container. Port mappings allow containers to access ports on the host container instance to send or receive traffic.
For task definitions that use the awsvpc
network mode, only specify the containerPort
. The hostPort
can be left blank or it must be the same value as the containerPort
.
Port mappings on Windows use the NetNAT
gateway address rather than localhost
. There's no loopback for port mappings on Windows, so you can't access a container's mapped port from the host itself.
This parameter maps to PortBindings
in the Create a container section of the Docker Remote API and the --publish
option to docker run. If the network mode of a task definition is set to none
, then you can't specify port mappings. If the network mode of a task definition is set to host
, then host ports must either be undefined or they must match the container port in the port mapping.
After a task reaches the RUNNING
status, manual and automatic host and container port assignments are visible in the Network Bindings section of a container description for a selected task in the Amazon ECS console. The assignments are also visible in the networkBindings
section DescribeTasks
responses.
sourcepub fn essential(&self) -> Option<bool>
pub fn essential(&self) -> Option<bool>
If the essential
parameter of a container is marked as true
, and that container fails or stops for any reason, all other containers that are part of the task are stopped. If the essential
parameter of a container is marked as false
, its failure doesn't affect the rest of the containers in a task. If this parameter is omitted, a container is assumed to be essential.
All tasks must have at least one essential container. If you have an application that's composed of multiple containers, group containers that are used for a common purpose into components, and separate the different components into multiple task definitions. For more information, see Application Architecture in the Amazon Elastic Container Service Developer Guide.
sourcepub fn entry_point(&self) -> Option<&[String]>
pub fn entry_point(&self) -> Option<&[String]>
Early versions of the Amazon ECS container agent don't properly handle entryPoint
parameters. If you have problems using entryPoint
, update your container agent or enter your commands and arguments as command
array items instead.
The entry point that's passed to the container. This parameter maps to Entrypoint
in the Create a container section of the Docker Remote API and the --entrypoint
option to docker run. For more information, see https://docs.docker.com/engine/reference/builder/#entrypoint.
sourcepub fn command(&self) -> Option<&[String]>
pub fn command(&self) -> Option<&[String]>
The command that's passed to the container. This parameter maps to Cmd
in the Create a container section of the Docker Remote API and the COMMAND
parameter to docker run. For more information, see https://docs.docker.com/engine/reference/builder/#cmd. If there are multiple arguments, each argument is a separated string in the array.
sourcepub fn environment(&self) -> Option<&[KeyValuePair]>
pub fn environment(&self) -> Option<&[KeyValuePair]>
The environment variables to pass to a container. This parameter maps to Env
in the Create a container section of the Docker Remote API and the --env
option to docker run.
We don't recommend that you use plaintext environment variables for sensitive information, such as credential data.
sourcepub fn environment_files(&self) -> Option<&[EnvironmentFile]>
pub fn environment_files(&self) -> Option<&[EnvironmentFile]>
A list of files containing the environment variables to pass to a container. This parameter maps to the --env-file
option to docker run.
You can specify up to ten environment files. The file must have a .env
file extension. Each line in an environment file contains an environment variable in VARIABLE=VALUE
format. Lines beginning with #
are treated as comments and are ignored. For more information about the environment variable file syntax, see Declare default environment variables in file.
If there are environment variables specified using the environment
parameter in a container definition, they take precedence over the variables contained within an environment file. If multiple environment files are specified that contain the same variable, they're processed from the top down. We recommend that you use unique variable names. For more information, see Specifying Environment Variables in the Amazon Elastic Container Service Developer Guide.
sourcepub fn mount_points(&self) -> Option<&[MountPoint]>
pub fn mount_points(&self) -> Option<&[MountPoint]>
The mount points for data volumes in your container.
This parameter maps to Volumes
in the Create a container section of the Docker Remote API and the --volume
option to docker run.
Windows containers can mount whole directories on the same drive as $env:ProgramData
. Windows containers can't mount directories on a different drive, and mount point can't be across drives.
sourcepub fn volumes_from(&self) -> Option<&[VolumeFrom]>
pub fn volumes_from(&self) -> Option<&[VolumeFrom]>
Data volumes to mount from another container. This parameter maps to VolumesFrom
in the Create a container section of the Docker Remote API and the --volumes-from
option to docker run.
sourcepub fn linux_parameters(&self) -> Option<&LinuxParameters>
pub fn linux_parameters(&self) -> Option<&LinuxParameters>
Linux-specific modifications that are applied to the container, such as Linux kernel capabilities. For more information see KernelCapabilities
.
This parameter is not supported for Windows containers.
sourcepub fn secrets(&self) -> Option<&[Secret]>
pub fn secrets(&self) -> Option<&[Secret]>
The secrets to pass to the container. For more information, see Specifying Sensitive Data in the Amazon Elastic Container Service Developer Guide.
sourcepub fn depends_on(&self) -> Option<&[ContainerDependency]>
pub fn depends_on(&self) -> Option<&[ContainerDependency]>
The dependencies defined for container startup and shutdown. A container can contain multiple dependencies. When a dependency is defined for container startup, for container shutdown it is reversed.
For tasks using the EC2 launch type, the container instances require at least version 1.26.0 of the container agent to turn on container dependencies. However, we recommend using the latest container agent version. For information about checking your agent version and updating to the latest version, see Updating the Amazon ECS Container Agent in the Amazon Elastic Container Service Developer Guide. If you're using an Amazon ECS-optimized Linux AMI, your instance needs at least version 1.26.0-1 of the ecs-init
package. If your container instances are launched from version 20190301
or later, then they contain the required versions of the container agent and ecs-init
. For more information, see Amazon ECS-optimized Linux AMI in the Amazon Elastic Container Service Developer Guide.
For tasks using the Fargate launch type, the task or service requires the following platforms:
-
Linux platform version
1.3.0
or later. -
Windows platform version
1.0.0
or later.
sourcepub fn start_timeout(&self) -> Option<i32>
pub fn start_timeout(&self) -> Option<i32>
Time duration (in seconds) to wait before giving up on resolving dependencies for a container. For example, you specify two containers in a task definition with containerA having a dependency on containerB reaching a COMPLETE
, SUCCESS
, or HEALTHY
status. If a startTimeout
value is specified for containerB and it doesn't reach the desired status within that time then containerA gives up and not start. This results in the task transitioning to a STOPPED
state.
When the ECS_CONTAINER_START_TIMEOUT
container agent configuration variable is used, it's enforced independently from this start timeout value.
For tasks using the Fargate launch type, the task or service requires the following platforms:
-
Linux platform version
1.3.0
or later. -
Windows platform version
1.0.0
or later.
For tasks using the EC2 launch type, your container instances require at least version 1.26.0
of the container agent to use a container start timeout value. However, we recommend using the latest container agent version. For information about checking your agent version and updating to the latest version, see Updating the Amazon ECS Container Agent in the Amazon Elastic Container Service Developer Guide. If you're using an Amazon ECS-optimized Linux AMI, your instance needs at least version 1.26.0-1
of the ecs-init
package. If your container instances are launched from version 20190301
or later, then they contain the required versions of the container agent and ecs-init
. For more information, see Amazon ECS-optimized Linux AMI in the Amazon Elastic Container Service Developer Guide.
sourcepub fn stop_timeout(&self) -> Option<i32>
pub fn stop_timeout(&self) -> Option<i32>
Time duration (in seconds) to wait before the container is forcefully killed if it doesn't exit normally on its own.
For tasks using the Fargate launch type, the task or service requires the following platforms:
-
Linux platform version
1.3.0
or later. -
Windows platform version
1.0.0
or later.
The max stop timeout value is 120 seconds and if the parameter is not specified, the default value of 30 seconds is used.
For tasks that use the EC2 launch type, if the stopTimeout
parameter isn't specified, the value set for the Amazon ECS container agent configuration variable ECS_CONTAINER_STOP_TIMEOUT
is used. If neither the stopTimeout
parameter or the ECS_CONTAINER_STOP_TIMEOUT
agent configuration variable are set, then the default values of 30 seconds for Linux containers and 30 seconds on Windows containers are used. Your container instances require at least version 1.26.0 of the container agent to use a container stop timeout value. However, we recommend using the latest container agent version. For information about checking your agent version and updating to the latest version, see Updating the Amazon ECS Container Agent in the Amazon Elastic Container Service Developer Guide. If you're using an Amazon ECS-optimized Linux AMI, your instance needs at least version 1.26.0-1 of the ecs-init
package. If your container instances are launched from version 20190301
or later, then they contain the required versions of the container agent and ecs-init
. For more information, see Amazon ECS-optimized Linux AMI in the Amazon Elastic Container Service Developer Guide.
sourcepub fn hostname(&self) -> Option<&str>
pub fn hostname(&self) -> Option<&str>
The hostname to use for your container. This parameter maps to Hostname
in the Create a container section of the Docker Remote API and the --hostname
option to docker run.
The hostname
parameter is not supported if you're using the awsvpc
network mode.
sourcepub fn user(&self) -> Option<&str>
pub fn user(&self) -> Option<&str>
The user to use inside the container. This parameter maps to User
in the Create a container section of the Docker Remote API and the --user
option to docker run.
When running tasks using the host
network mode, don't run containers using the root user (UID 0). We recommend using a non-root user for better security.
You can specify the user
using the following formats. If specifying a UID or GID, you must specify it as a positive integer.
-
user
-
user:group
-
uid
-
uid:gid
-
user:gid
-
uid:group
This parameter is not supported for Windows containers.
sourcepub fn working_directory(&self) -> Option<&str>
pub fn working_directory(&self) -> Option<&str>
The working directory to run commands inside the container in. This parameter maps to WorkingDir
in the Create a container section of the Docker Remote API and the --workdir
option to docker run.
sourcepub fn disable_networking(&self) -> Option<bool>
pub fn disable_networking(&self) -> Option<bool>
When this parameter is true, networking is disabled within the container. This parameter maps to NetworkDisabled
in the Create a container section of the Docker Remote API.
This parameter is not supported for Windows containers.
sourcepub fn privileged(&self) -> Option<bool>
pub fn privileged(&self) -> Option<bool>
When this parameter is true, the container is given elevated privileges on the host container instance (similar to the root
user). This parameter maps to Privileged
in the Create a container section of the Docker Remote API and the --privileged
option to docker run.
This parameter is not supported for Windows containers or tasks run on Fargate.
sourcepub fn readonly_root_filesystem(&self) -> Option<bool>
pub fn readonly_root_filesystem(&self) -> Option<bool>
When this parameter is true, the container is given read-only access to its root file system. This parameter maps to ReadonlyRootfs
in the Create a container section of the Docker Remote API and the --read-only
option to docker run.
This parameter is not supported for Windows containers.
sourcepub fn dns_servers(&self) -> Option<&[String]>
pub fn dns_servers(&self) -> Option<&[String]>
A list of DNS servers that are presented to the container. This parameter maps to Dns
in the Create a container section of the Docker Remote API and the --dns
option to docker run.
This parameter is not supported for Windows containers.
sourcepub fn dns_search_domains(&self) -> Option<&[String]>
pub fn dns_search_domains(&self) -> Option<&[String]>
A list of DNS search domains that are presented to the container. This parameter maps to DnsSearch
in the Create a container section of the Docker Remote API and the --dns-search
option to docker run.
This parameter is not supported for Windows containers.
sourcepub fn extra_hosts(&self) -> Option<&[HostEntry]>
pub fn extra_hosts(&self) -> Option<&[HostEntry]>
A list of hostnames and IP address mappings to append to the /etc/hosts
file on the container. This parameter maps to ExtraHosts
in the Create a container section of the Docker Remote API and the --add-host
option to docker run.
This parameter isn't supported for Windows containers or tasks that use the awsvpc
network mode.
sourcepub fn docker_security_options(&self) -> Option<&[String]>
pub fn docker_security_options(&self) -> Option<&[String]>
A list of strings to provide custom labels for SELinux and AppArmor multi-level security systems. This field isn't valid for containers in tasks using the Fargate launch type.
With Windows containers, this parameter can be used to reference a credential spec file when configuring a container for Active Directory authentication. For more information, see Using gMSAs for Windows Containers in the Amazon Elastic Container Service Developer Guide.
This parameter maps to SecurityOpt
in the Create a container section of the Docker Remote API and the --security-opt
option to docker run.
The Amazon ECS container agent running on a container instance must register with the ECS_SELINUX_CAPABLE=true
or ECS_APPARMOR_CAPABLE=true
environment variables before containers placed on that instance can use these security options. For more information, see Amazon ECS Container Agent Configuration in the Amazon Elastic Container Service Developer Guide.
For more information about valid values, see Docker Run Security Configuration.
Valid values: "no-new-privileges" | "apparmor:PROFILE" | "label:value" | "credentialspec:CredentialSpecFilePath"
sourcepub fn interactive(&self) -> Option<bool>
pub fn interactive(&self) -> Option<bool>
When this parameter is true
, you can deploy containerized applications that require stdin
or a tty
to be allocated. This parameter maps to OpenStdin
in the Create a container section of the Docker Remote API and the --interactive
option to docker run.
sourcepub fn pseudo_terminal(&self) -> Option<bool>
pub fn pseudo_terminal(&self) -> Option<bool>
When this parameter is true
, a TTY is allocated. This parameter maps to Tty
in the Create a container section of the Docker Remote API and the --tty
option to docker run.
sourcepub fn docker_labels(&self) -> Option<&HashMap<String, String>>
pub fn docker_labels(&self) -> Option<&HashMap<String, String>>
A key/value map of labels to add to the container. This parameter maps to Labels
in the Create a container section of the Docker Remote API and the --label
option to docker run. This parameter requires version 1.18 of the Docker Remote API or greater on your container instance. To check the Docker Remote API version on your container instance, log in to your container instance and run the following command: sudo docker version --format '{{.Server.APIVersion}}'
sourcepub fn ulimits(&self) -> Option<&[Ulimit]>
pub fn ulimits(&self) -> Option<&[Ulimit]>
A list of ulimits
to set in the container. If a ulimit value is specified in a task definition, it overrides the default values set by Docker. This parameter maps to Ulimits
in the Create a container section of the Docker Remote API and the --ulimit
option to docker run. Valid naming values are displayed in the Ulimit
data type.
Amazon ECS tasks hosted on Fargate use the default resource limit values set by the operating system with the exception of the nofile
resource limit parameter which Fargate overrides. The nofile
resource limit sets a restriction on the number of open files that a container can use. The default nofile
soft limit is 1024
and hard limit is 4096
.
This parameter requires version 1.18 of the Docker Remote API or greater on your container instance. To check the Docker Remote API version on your container instance, log in to your container instance and run the following command: sudo docker version --format '{{.Server.APIVersion}}'
This parameter is not supported for Windows containers.
sourcepub fn log_configuration(&self) -> Option<&LogConfiguration>
pub fn log_configuration(&self) -> Option<&LogConfiguration>
The log configuration specification for the container.
This parameter maps to LogConfig
in the Create a container section of the Docker Remote API and the --log-driver
option to docker run. By default, containers use the same logging driver that the Docker daemon uses. However the container can use a different logging driver than the Docker daemon by specifying a log driver with this parameter in the container definition. To use a different logging driver for a container, the log system must be configured properly on the container instance (or on a different log server for remote logging options). For more information about the options for different supported log drivers, see Configure logging drivers in the Docker documentation.
Amazon ECS currently supports a subset of the logging drivers available to the Docker daemon (shown in the LogConfiguration
data type). Additional log drivers may be available in future releases of the Amazon ECS container agent.
This parameter requires version 1.18 of the Docker Remote API or greater on your container instance. To check the Docker Remote API version on your container instance, log in to your container instance and run the following command: sudo docker version --format '{{.Server.APIVersion}}'
The Amazon ECS container agent running on a container instance must register the logging drivers available on that instance with the ECS_AVAILABLE_LOGGING_DRIVERS
environment variable before containers placed on that instance can use these log configuration options. For more information, see Amazon ECS Container Agent Configuration in the Amazon Elastic Container Service Developer Guide.
sourcepub fn health_check(&self) -> Option<&HealthCheck>
pub fn health_check(&self) -> Option<&HealthCheck>
The container health check command and associated configuration parameters for the container. This parameter maps to HealthCheck
in the Create a container section of the Docker Remote API and the HEALTHCHECK
parameter of docker run.
sourcepub fn system_controls(&self) -> Option<&[SystemControl]>
pub fn system_controls(&self) -> Option<&[SystemControl]>
A list of namespaced kernel parameters to set in the container. This parameter maps to Sysctls
in the Create a container section of the Docker Remote API and the --sysctl
option to docker run.
We don't recommended that you specify network-related systemControls
parameters for multiple containers in a single task that also uses either the awsvpc
or host
network modes. For tasks that use the awsvpc
network mode, the container that's started last determines which systemControls
parameters take effect. For tasks that use the host
network mode, it changes the container instance's namespaced kernel parameters as well as the containers.
sourcepub fn resource_requirements(&self) -> Option<&[ResourceRequirement]>
pub fn resource_requirements(&self) -> Option<&[ResourceRequirement]>
The type and amount of a resource to assign to a container. The only supported resource is a GPU.
sourcepub fn firelens_configuration(&self) -> Option<&FirelensConfiguration>
pub fn firelens_configuration(&self) -> Option<&FirelensConfiguration>
The FireLens configuration for the container. This is used to specify and configure a log router for container logs. For more information, see Custom Log Routing in the Amazon Elastic Container Service Developer Guide.
sourceimpl ContainerDefinition
impl ContainerDefinition
sourcepub fn builder() -> Builder
pub fn builder() -> Builder
Creates a new builder-style object to manufacture ContainerDefinition
Trait Implementations
sourceimpl Clone for ContainerDefinition
impl Clone for ContainerDefinition
sourcefn clone(&self) -> ContainerDefinition
fn clone(&self) -> ContainerDefinition
Returns a copy of the value. Read more
1.0.0 · sourcefn clone_from(&mut self, source: &Self)
fn clone_from(&mut self, source: &Self)
Performs copy-assignment from source
. Read more
sourceimpl Debug for ContainerDefinition
impl Debug for ContainerDefinition
sourceimpl PartialEq<ContainerDefinition> for ContainerDefinition
impl PartialEq<ContainerDefinition> for ContainerDefinition
sourcefn eq(&self, other: &ContainerDefinition) -> bool
fn eq(&self, other: &ContainerDefinition) -> bool
This method tests for self
and other
values to be equal, and is used
by ==
. Read more
sourcefn ne(&self, other: &ContainerDefinition) -> bool
fn ne(&self, other: &ContainerDefinition) -> bool
This method tests for !=
.
impl StructuralPartialEq for ContainerDefinition
Auto Trait Implementations
impl RefUnwindSafe for ContainerDefinition
impl Send for ContainerDefinition
impl Sync for ContainerDefinition
impl Unpin for ContainerDefinition
impl UnwindSafe for ContainerDefinition
Blanket Implementations
sourceimpl<T> BorrowMut<T> for T where
T: ?Sized,
impl<T> BorrowMut<T> for T where
T: ?Sized,
const: unstable · sourcefn borrow_mut(&mut self) -> &mut T
fn borrow_mut(&mut self) -> &mut T
Mutably borrows from an owned value. Read more
sourceimpl<T> Instrument for T
impl<T> Instrument for T
sourcefn instrument(self, span: Span) -> Instrumented<Self>
fn instrument(self, span: Span) -> Instrumented<Self>
sourcefn in_current_span(self) -> Instrumented<Self>
fn in_current_span(self) -> Instrumented<Self>
sourceimpl<T> WithSubscriber for T
impl<T> WithSubscriber for T
sourcefn with_subscriber<S>(self, subscriber: S) -> WithDispatch<Self> where
S: Into<Dispatch>,
fn with_subscriber<S>(self, subscriber: S) -> WithDispatch<Self> where
S: Into<Dispatch>,
Attaches the provided Subscriber
to this type, returning a
WithDispatch
wrapper. Read more
sourcefn with_current_subscriber(self) -> WithDispatch<Self>
fn with_current_subscriber(self) -> WithDispatch<Self>
Attaches the current default Subscriber
to this type, returning a
WithDispatch
wrapper. Read more