Interface TaskSpecContainerSpec

Arguments to the command.

A list of kernel capabilities to add to the default set for the container.

A list of kernel capabilities to drop from the default set for the container.

The command to be run in the image.

Configs contains references to zero or more configs that will be exposed to the service.

The working directory for commands to run in.

A list of environment variables in the form VAR=value.

A list of additional groups that the container process will run as.

The hostname to use for the container, as a valid RFC 1123 hostname.

A list of hostname/IP mappings to add to the container's hosts file. The format of extra hosts is specified in the hosts(5) man page: IP_address canonical_hostname [aliases...]

The image name to use for the container

Run an init inside the container that forwards signals and reaps processes. This field is omitted if empty, and the default (as configured on the daemon) is used.

Isolation technology of the containers running the service. (Windows only)

User-defined key/value data.

Specification for mounts to be added to containers created as part of the service.

Open stdin

Mount the container's root filesystem as read only.

Secrets contains references to zero or more secrets that will be exposed to the service.

Amount of time to wait for the container to terminate before forcefully killing it.

Signal to stop the container.

Set kernel namedspaced parameters (sysctls) in the container. The Sysctls option on services accepts the same sysctls as the are supported on containers. Note that while the same sysctls are supported, no guarantees or checks are made about their suitability for a clustered environment, and it's up to the user to determine whether a given sysctl will work properly in a Service.

Whether a pseudo-TTY should be allocated.

A list of resource limits to set in the container. For example: {\"Name\": \"nofile\", \"Soft\": 1024, \"Hard\": 2048}"

The user inside the container.