class Aws::ECS::Types::ContainerDefinition

Container definitions are used in task definitions to describe the different containers that are launched as part of a task.

@note When making an API call, you may pass ContainerDefinition

data as a hash:

    {
      name: "String",
      image: "String",
      repository_credentials: {
        credentials_parameter: "String", # required
      },
      cpu: 1,
      memory: 1,
      memory_reservation: 1,
      links: ["String"],
      port_mappings: [
        {
          container_port: 1,
          host_port: 1,
          protocol: "tcp", # accepts tcp, udp
        },
      ],
      essential: false,
      entry_point: ["String"],
      command: ["String"],
      environment: [
        {
          name: "String",
          value: "String",
        },
      ],
      environment_files: [
        {
          value: "String", # required
          type: "s3", # required, accepts s3
        },
      ],
      mount_points: [
        {
          source_volume: "String",
          container_path: "String",
          read_only: false,
        },
      ],
      volumes_from: [
        {
          source_container: "String",
          read_only: false,
        },
      ],
      linux_parameters: {
        capabilities: {
          add: ["String"],
          drop: ["String"],
        },
        devices: [
          {
            host_path: "String", # required
            container_path: "String",
            permissions: ["read"], # accepts read, write, mknod
          },
        ],
        init_process_enabled: false,
        shared_memory_size: 1,
        tmpfs: [
          {
            container_path: "String", # required
            size: 1, # required
            mount_options: ["String"],
          },
        ],
        max_swap: 1,
        swappiness: 1,
      },
      secrets: [
        {
          name: "String", # required
          value_from: "String", # required
        },
      ],
      depends_on: [
        {
          container_name: "String", # required
          condition: "START", # required, accepts START, COMPLETE, SUCCESS, HEALTHY
        },
      ],
      start_timeout: 1,
      stop_timeout: 1,
      hostname: "String",
      user: "String",
      working_directory: "String",
      disable_networking: false,
      privileged: false,
      readonly_root_filesystem: false,
      dns_servers: ["String"],
      dns_search_domains: ["String"],
      extra_hosts: [
        {
          hostname: "String", # required
          ip_address: "String", # required
        },
      ],
      docker_security_options: ["String"],
      interactive: false,
      pseudo_terminal: false,
      docker_labels: {
        "String" => "String",
      },
      ulimits: [
        {
          name: "core", # required, accepts core, cpu, data, fsize, locks, memlock, msgqueue, nice, nofile, nproc, rss, rtprio, rttime, sigpending, stack
          soft_limit: 1, # required
          hard_limit: 1, # required
        },
      ],
      log_configuration: {
        log_driver: "json-file", # required, accepts json-file, syslog, journald, gelf, fluentd, awslogs, splunk, awsfirelens
        options: {
          "String" => "String",
        },
        secret_options: [
          {
            name: "String", # required
            value_from: "String", # required
          },
        ],
      },
      health_check: {
        command: ["String"], # required
        interval: 1,
        timeout: 1,
        retries: 1,
        start_period: 1,
      },
      system_controls: [
        {
          namespace: "String",
          value: "String",
        },
      ],
      resource_requirements: [
        {
          value: "String", # required
          type: "GPU", # required, accepts GPU, InferenceAccelerator
        },
      ],
      firelens_configuration: {
        type: "fluentd", # required, accepts fluentd, fluentbit
        options: {
          "String" => "String",
        },
      },
    }

@!attribute [rw] name

The name of a container. If you are 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][1] section of the [Docker Remote API][2]
and the `--name` option to [docker run][3].

[1]: https://docs.docker.com/engine/api/v1.35/#operation/ContainerCreate
[2]: https://docs.docker.com/engine/api/v1.35/
[3]: https://docs.docker.com/engine/reference/run/#security-configuration
@return [String]

@!attribute [rw] image

The image used to start a container. This string is passed directly
to the Docker daemon. Images in the Docker Hub registry are
available by default. 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][1] section of the [Docker Remote API][2] and the `IMAGE`
parameter of [docker run][3].

* 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 are not
  propagated to already running tasks.

* Images in Amazon ECR repositories can be specified by either using
  the full `registry/repository:tag` or
  `registry/repository@digest`. For example,
  `012345678910.dkr.ecr.<region-name>.amazonaws.com/<repository-name>:latest`
  or
  `012345678910.dkr.ecr.<region-name>.amazonaws.com/<repository-name>@sha256:94afd1f2e64d908bc90dbca0035a5b567EXAMPLE`.

* Images in official repositories on Docker Hub use a single name
  (for example, `ubuntu` or `mongo`).

* 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`).

[1]: https://docs.docker.com/engine/api/v1.35/#operation/ContainerCreate
[2]: https://docs.docker.com/engine/api/v1.35/
[3]: https://docs.docker.com/engine/reference/run/#security-configuration
@return [String]

@!attribute [rw] repository_credentials

The private repository authentication credentials to use.
@return [Types::RepositoryCredentials]

@!attribute [rw] cpu

The number of `cpu` units reserved for the container. This parameter
maps to `CpuShares` in the [Create a container][1] section of the
[Docker Remote API][2] and the `--cpu-shares` option to [docker
run][3].

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.

<note markdown="1"> 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][4] detail page by 1,024.

 </note>

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 is 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 would be guaranteed a
minimum of 512 CPU units when needed, and each container could float
to higher CPU usage if the other container was not using it, but 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][5] in the Docker documentation. The minimum valid CPU
share value that the Linux kernel allows is 2. However, the CPU
parameter is not 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 is 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.

[1]: https://docs.docker.com/engine/api/v1.35/#operation/ContainerCreate
[2]: https://docs.docker.com/engine/api/v1.35/
[3]: https://docs.docker.com/engine/reference/run/#security-configuration
[4]: http://aws.amazon.com/ec2/instance-types/
[5]: https://docs.docker.com/engine/reference/run/#cpu-share-constraint
@return [Integer]

@!attribute [rw] memory

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][1] section of the [Docker Remote API][2] and the
`--memory` option to [docker run][3].

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 on which the
container is placed. Otherwise, the value of `memory` is used.

The Docker 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.

[1]: https://docs.docker.com/engine/api/v1.35/#operation/ContainerCreate
[2]: https://docs.docker.com/engine/api/v1.35/
[3]: https://docs.docker.com/engine/reference/run/#security-configuration
@return [Integer]

@!attribute [rw] memory_reservation

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][1] section of the [Docker Remote API][2] and the
`--memory-reservation` option to [docker run][3].

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 on which 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, so you should not specify fewer than 4 MiB of memory for
your containers.

[1]: https://docs.docker.com/engine/api/v1.35/#operation/ContainerCreate
[2]: https://docs.docker.com/engine/api/v1.35/
[3]: https://docs.docker.com/engine/reference/run/#security-configuration
@return [Integer]

@!attribute [rw] links

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][1] in the
Docker documentation. This parameter maps to `Links` in the [Create
a container][2] section of the [Docker Remote API][3] and the
`--link` option to [docker run][4].

<note markdown="1"> This parameter is not supported for Windows containers.

 </note>

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.

[1]: https://docs.docker.com/network/links/
[2]: https://docs.docker.com/engine/api/v1.35/#operation/ContainerCreate
[3]: https://docs.docker.com/engine/api/v1.35/
[4]: https://docs.docker.com/engine/reference/run/#security-configuration
@return [Array<String>]

@!attribute [rw] port_mappings

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, you should
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 is no loopback for port mappings on Windows,
so you cannot access a container's mapped port from the host
itself.

This parameter maps to `PortBindings` in the [Create a container][1]
section of the [Docker Remote API][2] and the `--publish` option to
[docker run][3]. 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.

<note markdown="1"> 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.

 </note>

[1]: https://docs.docker.com/engine/api/v1.35/#operation/ContainerCreate
[2]: https://docs.docker.com/engine/api/v1.35/
[3]: https://docs.docker.com/engine/reference/run/#security-configuration
@return [Array<Types::PortMapping>]

@!attribute [rw] essential

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`, then its failure does not
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 is composed of multiple containers, you should
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][1]
in the *Amazon Elastic Container Service Developer Guide*.

[1]: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/application_architecture.html
@return [Boolean]

@!attribute [rw] entry_point

Early versions of the Amazon ECS container agent do not 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 is passed to the container. This parameter maps
to `Entrypoint` in the [Create a container][1] section of the
[Docker Remote API][2] and the `--entrypoint` option to [docker
run][3]. For more information, see
[https://docs.docker.com/engine/reference/builder/#entrypoint][4].

[1]: https://docs.docker.com/engine/api/v1.35/#operation/ContainerCreate
[2]: https://docs.docker.com/engine/api/v1.35/
[3]: https://docs.docker.com/engine/reference/run/#security-configuration
[4]: https://docs.docker.com/engine/reference/builder/#entrypoint
@return [Array<String>]

@!attribute [rw] command

The command that is passed to the container. This parameter maps to
`Cmd` in the [Create a container][1] section of the [Docker Remote
API][2] and the `COMMAND` parameter to [docker run][3]. For more
information, see
[https://docs.docker.com/engine/reference/builder/#cmd][4]. If there
are multiple arguments, each argument should be a separated string
in the array.

[1]: https://docs.docker.com/engine/api/v1.35/#operation/ContainerCreate
[2]: https://docs.docker.com/engine/api/v1.35/
[3]: https://docs.docker.com/engine/reference/run/#security-configuration
[4]: https://docs.docker.com/engine/reference/builder/#cmd
@return [Array<String>]

@!attribute [rw] environment

The environment variables to pass to a container. This parameter
maps to `Env` in the [Create a container][1] section of the [Docker
Remote API][2] and the `--env` option to [docker run][3].

We do not recommend using plaintext environment variables for
sensitive information, such as credential data.

[1]: https://docs.docker.com/engine/api/v1.35/#operation/ContainerCreate
[2]: https://docs.docker.com/engine/api/v1.35/
[3]: https://docs.docker.com/engine/reference/run/#security-configuration
@return [Array<Types::KeyValuePair>]

@!attribute [rw] environment_files

A list of files containing the environment variables to pass to a
container. This parameter maps to the `--env-file` option to [docker
run][1].

You can specify up to ten environment files. The file must have a
`.env` file extension. Each line in an environment file should
contain an environment variable in `VARIABLE=VALUE` format. Lines
beginning with `#` are treated as comments and are ignored. For more
information on the environment variable file syntax, see [Declare
default environment variables in file][2].

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
are processed from the top down. It is recommended to use unique
variable names. For more information, see [Specifying Environment
Variables][3] in the *Amazon Elastic Container Service Developer
Guide*.

[1]: https://docs.docker.com/engine/reference/run/#security-configuration
[2]: https://docs.docker.com/compose/env-file/
[3]: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/taskdef-envfiles.html
@return [Array<Types::EnvironmentFile>]

@!attribute [rw] mount_points

The mount points for data volumes in your container.

This parameter maps to `Volumes` in the [Create a container][1]
section of the [Docker Remote API][2] and the `--volume` option to
[docker run][3].

Windows containers can mount whole directories on the same drive as
`$env:ProgramData`. Windows containers cannot mount directories on a
different drive, and mount point cannot be across drives.

[1]: https://docs.docker.com/engine/api/v1.35/#operation/ContainerCreate
[2]: https://docs.docker.com/engine/api/v1.35/
[3]: https://docs.docker.com/engine/reference/run/#security-configuration
@return [Array<Types::MountPoint>]

@!attribute [rw] volumes_from

Data volumes to mount from another container. This parameter maps to
`VolumesFrom` in the [Create a container][1] section of the [Docker
Remote API][2] and the `--volumes-from` option to [docker run][3].

[1]: https://docs.docker.com/engine/api/v1.35/#operation/ContainerCreate
[2]: https://docs.docker.com/engine/api/v1.35/
[3]: https://docs.docker.com/engine/reference/run/#security-configuration
@return [Array<Types::VolumeFrom>]

@!attribute [rw] linux_parameters

Linux-specific modifications that are applied to the container, such
as Linux kernel capabilities. For more information see
KernelCapabilities.

<note markdown="1"> This parameter is not supported for Windows containers.

 </note>
@return [Types::LinuxParameters]

@!attribute [rw] secrets

The secrets to pass to the container. For more information, see
[Specifying Sensitive Data][1] in the *Amazon Elastic Container
Service Developer Guide*.

[1]: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/specifying-sensitive-data.html
@return [Array<Types::Secret>]

@!attribute [rw] depends_on

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 enable 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][1] in the *Amazon Elastic Container Service
Developer Guide*. If you are 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][2] in the *Amazon Elastic Container Service
Developer Guide*.

For tasks using the Fargate launch type, the task or service
requires platform version `1.3.0` or later.

[1]: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-agent-update.html
[2]: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html
@return [Array<Types::ContainerDependency>]

@!attribute [rw] start_timeout

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 does
not reach the desired status within that time then containerA will
give up and not start. This results in the task transitioning to a
`STOPPED` state.

<note markdown="1"> When the `ECS_CONTAINER_START_TIMEOUT` container agent configuration
variable is used, it is enforced indendently from this start timeout
value.

 </note>

For tasks using the Fargate launch type, this parameter requires
that the task or service uses platform version 1.3.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 enable 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][1] in the *Amazon Elastic Container
Service Developer Guide*. If you are 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][2] in the *Amazon Elastic Container
Service Developer Guide*.

[1]: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-agent-update.html
[2]: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html
@return [Integer]

@!attribute [rw] stop_timeout

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 platform version 1.3.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 using the EC2 launch type, if the `stopTimeout` parameter
is not specified, the value set for the Amazon ECS container agent
configuration variable `ECS_CONTAINER_STOP_TIMEOUT` is used by
default. 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 enable 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][1] in the *Amazon Elastic Container Service
Developer Guide*. If you are 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][2] in the *Amazon Elastic Container Service
Developer Guide*.

[1]: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-agent-update.html
[2]: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html
@return [Integer]

@!attribute [rw] hostname

The hostname to use for your container. This parameter maps to
`Hostname` in the [Create a container][1] section of the [Docker
Remote API][2] and the `--hostname` option to [docker run][3].

<note markdown="1"> The `hostname` parameter is not supported if you are using the
`awsvpc` network mode.

 </note>

[1]: https://docs.docker.com/engine/api/v1.35/#operation/ContainerCreate
[2]: https://docs.docker.com/engine/api/v1.35/
[3]: https://docs.docker.com/engine/reference/run/#security-configuration
@return [String]

@!attribute [rw] user

The user to use inside the container. This parameter maps to `User`
in the [Create a container][1] section of the [Docker Remote API][2]
and the `--user` option to [docker run][3].

When running tasks 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.

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`

<note markdown="1"> This parameter is not supported for Windows containers.

 </note>

[1]: https://docs.docker.com/engine/api/v1.35/#operation/ContainerCreate
[2]: https://docs.docker.com/engine/api/v1.35/
[3]: https://docs.docker.com/engine/reference/run/#security-configuration
@return [String]

@!attribute [rw] working_directory

The working directory in which to run commands inside the container.
This parameter maps to `WorkingDir` in the [Create a container][1]
section of the [Docker Remote API][2] and the `--workdir` option to
[docker run][3].

[1]: https://docs.docker.com/engine/api/v1.35/#operation/ContainerCreate
[2]: https://docs.docker.com/engine/api/v1.35/
[3]: https://docs.docker.com/engine/reference/run/#security-configuration
@return [String]

@!attribute [rw] disable_networking

When this parameter is true, networking is disabled within the
container. This parameter maps to `NetworkDisabled` in the [Create a
container][1] section of the [Docker Remote API][2].

<note markdown="1"> This parameter is not supported for Windows containers.

 </note>

[1]: https://docs.docker.com/engine/api/v1.35/#operation/ContainerCreate
[2]: https://docs.docker.com/engine/api/v1.35/
@return [Boolean]

@!attribute [rw] privileged

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][1] section of the [Docker Remote API][2] and the
`--privileged` option to [docker run][3].

<note markdown="1"> This parameter is not supported for Windows containers or tasks run
on Fargate.

 </note>

[1]: https://docs.docker.com/engine/api/v1.35/#operation/ContainerCreate
[2]: https://docs.docker.com/engine/api/v1.35/
[3]: https://docs.docker.com/engine/reference/run/#security-configuration
@return [Boolean]

@!attribute [rw] readonly_root_filesystem

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][1] section of the [Docker Remote API][2]
and the `--read-only` option to [docker run][3].

<note markdown="1"> This parameter is not supported for Windows containers.

 </note>

[1]: https://docs.docker.com/engine/api/v1.35/#operation/ContainerCreate
[2]: https://docs.docker.com/engine/api/v1.35/
[3]: https://docs.docker.com/engine/reference/run/#security-configuration
@return [Boolean]

@!attribute [rw] dns_servers

A list of DNS servers that are presented to the container. This
parameter maps to `Dns` in the [Create a container][1] section of
the [Docker Remote API][2] and the `--dns` option to [docker
run][3].

<note markdown="1"> This parameter is not supported for Windows containers.

 </note>

[1]: https://docs.docker.com/engine/api/v1.35/#operation/ContainerCreate
[2]: https://docs.docker.com/engine/api/v1.35/
[3]: https://docs.docker.com/engine/reference/run/#security-configuration
@return [Array<String>]

@!attribute [rw] dns_search_domains

A list of DNS search domains that are presented to the container.
This parameter maps to `DnsSearch` in the [Create a container][1]
section of the [Docker Remote API][2] and the `--dns-search` option
to [docker run][3].

<note markdown="1"> This parameter is not supported for Windows containers.

 </note>

[1]: https://docs.docker.com/engine/api/v1.35/#operation/ContainerCreate
[2]: https://docs.docker.com/engine/api/v1.35/
[3]: https://docs.docker.com/engine/reference/run/#security-configuration
@return [Array<String>]

@!attribute [rw] extra_hosts

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][1] section of the [Docker
Remote API][2] and the `--add-host` option to [docker run][3].

<note markdown="1"> This parameter is not supported for Windows containers or tasks that
use the `awsvpc` network mode.

 </note>

[1]: https://docs.docker.com/engine/api/v1.35/#operation/ContainerCreate
[2]: https://docs.docker.com/engine/api/v1.35/
[3]: https://docs.docker.com/engine/reference/run/#security-configuration
@return [Array<Types::HostEntry>]

@!attribute [rw] docker_security_options

A list of strings to provide custom labels for SELinux and AppArmor
multi-level security systems. This field is not 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][1] in the *Amazon Elastic Container Service
Developer Guide*.

This parameter maps to `SecurityOpt` in the [Create a container][2]
section of the [Docker Remote API][3] and the `--security-opt`
option to [docker run][4].

<note markdown="1"> 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][5] in
the *Amazon Elastic Container Service Developer Guide*.

 </note>

For more information about valid values, see [Docker Run Security
Configuration][4].

Valid values: "no-new-privileges" \| "apparmor:PROFILE" \|
"label:value" \| "credentialspec:CredentialSpecFilePath"

[1]: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/windows-gmsa.html
[2]: https://docs.docker.com/engine/api/v1.35/#operation/ContainerCreate
[3]: https://docs.docker.com/engine/api/v1.35/
[4]: https://docs.docker.com/engine/reference/run/#security-configuration
[5]: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-agent-config.html
@return [Array<String>]

@!attribute [rw] interactive

When this parameter is `true`, this allows you to deploy
containerized applications that require `stdin` or a `tty` to be
allocated. This parameter maps to `OpenStdin` in the [Create a
container][1] section of the [Docker Remote API][2] and the
`--interactive` option to [docker run][3].

[1]: https://docs.docker.com/engine/api/v1.35/#operation/ContainerCreate
[2]: https://docs.docker.com/engine/api/v1.35/
[3]: https://docs.docker.com/engine/reference/run/#security-configuration
@return [Boolean]

@!attribute [rw] pseudo_terminal

When this parameter is `true`, a TTY is allocated. This parameter
maps to `Tty` in the [Create a container][1] section of the [Docker
Remote API][2] and the `--tty` option to [docker run][3].

[1]: https://docs.docker.com/engine/api/v1.35/#operation/ContainerCreate
[2]: https://docs.docker.com/engine/api/v1.35/
[3]: https://docs.docker.com/engine/reference/run/#security-configuration
@return [Boolean]

@!attribute [rw] docker_labels

A key/value map of labels to add to the container. This parameter
maps to `Labels` in the [Create a container][1] section of the
[Docker Remote API][2] and the `--label` option to [docker run][3].
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\}\}'`

[1]: https://docs.docker.com/engine/api/v1.35/#operation/ContainerCreate
[2]: https://docs.docker.com/engine/api/v1.35/
[3]: https://docs.docker.com/engine/reference/run/#security-configuration
@return [Hash<String,String>]

@!attribute [rw] ulimits

A list of `ulimits` to set in the container. If a ulimit value is
specified in a task definition, it will override the default values
set by Docker. This parameter maps to `Ulimits` in the [Create a
container][1] section of the [Docker Remote API][2] and the
`--ulimit` option to [docker run][3]. 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\}\}'`

<note markdown="1"> This parameter is not supported for Windows containers.

 </note>

[1]: https://docs.docker.com/engine/api/v1.35/#operation/ContainerCreate
[2]: https://docs.docker.com/engine/api/v1.35/
[3]: https://docs.docker.com/engine/reference/run/#security-configuration
@return [Array<Types::Ulimit>]

@!attribute [rw] log_configuration

The log configuration specification for the container.

This parameter maps to `LogConfig` in the [Create a container][1]
section of the [Docker Remote API][2] and the `--log-driver` option
to [docker run][3]. By default, containers use the same logging
driver that the Docker daemon uses. However the container may 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 on the
options for different supported log drivers, see [Configure logging
drivers][4] in the Docker documentation.

<note markdown="1"> 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.

 </note>

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\}\}'`

<note markdown="1"> 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][5] in the *Amazon Elastic Container Service Developer
Guide*.

 </note>

[1]: https://docs.docker.com/engine/api/v1.35/#operation/ContainerCreate
[2]: https://docs.docker.com/engine/api/v1.35/
[3]: https://docs.docker.com/engine/reference/run/#security-configuration
[4]: https://docs.docker.com/engine/admin/logging/overview/
[5]: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-agent-config.html
@return [Types::LogConfiguration]

@!attribute [rw] health_check

The container health check command and associated configuration
parameters for the container. This parameter maps to `HealthCheck`
in the [Create a container][1] section of the [Docker Remote API][2]
and the `HEALTHCHECK` parameter of [docker run][3].

[1]: https://docs.docker.com/engine/api/v1.35/#operation/ContainerCreate
[2]: https://docs.docker.com/engine/api/v1.35/
[3]: https://docs.docker.com/engine/reference/run/#security-configuration
@return [Types::HealthCheck]

@!attribute [rw] system_controls

A list of namespaced kernel parameters to set in the container. This
parameter maps to `Sysctls` in the [Create a container][1] section
of the [Docker Remote API][2] and the `--sysctl` option to [docker
run][3].

<note markdown="1"> It is not 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 is
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.

 </note>

[1]: https://docs.docker.com/engine/api/v1.35/#operation/ContainerCreate
[2]: https://docs.docker.com/engine/api/v1.35/
[3]: https://docs.docker.com/engine/reference/run/#security-configuration
@return [Array<Types::SystemControl>]

@!attribute [rw] resource_requirements

The type and amount of a resource to assign to a container. The only
supported resource is a GPU.
@return [Array<Types::ResourceRequirement>]

@!attribute [rw] firelens_configuration

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][1] in the *Amazon Elastic
Container Service Developer Guide*.

[1]: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_firelens.html
@return [Types::FirelensConfiguration]

@see docs.aws.amazon.com/goto/WebAPI/ecs-2014-11-13/ContainerDefinition AWS API Documentation

Constants

SENSITIVE