galaxy/config/containers_conf.yml.sample

---
# Galaxy container interface configuration file
#
# To configure the location of this file, use the `containers_config_file`
# setting in galaxy.ini

###
### Container Interfaces
###

## Define container interfaces beneath the top-level `containers` dictionary. By # default, a single `_default_`
## container of type `docker` is defined:

#containers:
#  _default_:
#    type: docker

## Additional options can be specified are specific to the container type:

#containers:
#  _default_:
#    type: docker
#    host: docker.example.org:2376
#    force_tlsverify: yes

## Keys in `containers` are used to map container consumers to specific # container consumers. If a mapping is not
## configured, the _default_ # configuration will be used. An example of multiple container configurations would be:

#containers:
#  _default_:
#    type: docker
#    ... additional options ...
#  example_swarm:
#    type: docker_swarm
#    ... additional options ...
#

###
### Container Types and Supported Options
###

## Command-line equivalent arguments are in [brackets] (if applicable)

### All types
##
## The following options are applicable to all container types:
##

#containers:
#  _default_:
#    type: ...

## [`--name` (partial)] Prepend this string to the name of containers created
#    name_prefix: galaxy_

## Prefix to prepend to 

### `docker` and `docker_cli` types
##
## `docker_cli` interacts with Docker via its command-line interface. In the future `docker` will use the API (currently
## it's an alias for `docker_cli`)
##

#containers:
#  _default_:
#    type: docker

## [`-H`/`--host] Daemon socket(s) to connect to
#    host: null

## [`--tlsverify`] Use TLS and verify the remote
#    force_tlsverify: no

## [`--cpus`] Number of CPUs (default 0.000)
#    cpus: null

## [`-m`/`--memory`] Memory limit
#    memory: null

## Default image to run if one is not provided to the run method
#    image: null

### `docker_swarm` and `docker_swarm_cli` types
##
## All of the `docker` type arguments are supported. Additionally:
##

#containers:
#  _default_:
#    type: docker_swarm

## [`--resverve-cpu` and `--limit-cpu`] Reserve the given number of CPUs when containers are run to prevent other
## containers from being scheduled on the same node once all of its CPUs are allocated. Additionally, prevent container
## from using more than the given number of CPUs
#    cpus: null

## [`--resverve-memory` and `--limit-memory`] Reserve the given amount of memory when containers are run to prevent
## other containers from being scheduled on the same node once all of its memory is allocated. Additionally, prevent
## container from using more than the given amount of memory
#    memory: null

## If set, only nodes whose names begin with this string will be visible to and managed by the swarm manager. Note that
## regardless of whether this is set, the swarm manager will not attempt to control manager nodes
#    node_prefix: null

# Convert image from name[:tag] form to name@digest form when possible, to
# avoid dependency on the image registry (e.g. Docker Hub or wherever the image
# was pulled from) at service creation time. For details see:
#  https://github.com/docker/docker/issues/31427
#    resolve_image_digest: no

# If a container run request is received that defines volumes to attach, should those volumes be ignored? Swarm mode
# does not support mounting volumes.
#    ignore_volumes: no

## For the following `service_create_*_constraint` options, if set, the swarm manager automatically sets a corresponding
## label on nodes it spawns for services with the given constraints.

## [`--constraint node.labels._galaxy_image=={image}`]
## Automatically create a constraint based on the requested image name when new services are created (the image name is
## the resolved form if `resolve_image_digest` is set). This is useful if your nodes do not all have all of the possible
## images you'll want to run.
#    service_create_image_constraint: no

## [`--constraint node.labels._galaxy_cpus=={cpus}`]
## Automatically create a constraint based on the requested number of CPUs (or 1, if `cpus` is unset). This is useful if
## you are spawning nodes with a mixture of CPU counts and want to prevent (for example) 1-cpu services from being
## scheduled on 2-cpu nodes when 2-cpu jobs are waiting.
#    service_create_cpus_constraint: no

## Use the swarm manager to manage services on this swarm. Even if your swarm is static, using the manager is
## recommended as the manager will automatically remove services after they have terminated.
#    managed: yes

## Automatically start the swarm manager when new services are created. Useful if you want to run the swarm manager but
## control it separately from Galaxy.
#    manager_autostart: yes

### `docker_swarm` swarm manager options

## Galaxy can manage a Docker swarm using a built-in daemon and callouts to commands to add/remove nodes from your swarm.
## These options are set on `docker_swarm` type containers underneath a `manager_conf` key, like so:

#containers:
#  _default_:
#    type: docker_swarm
#    manager_conf:
#      spawn_command: openstack server create ...
#      ...

## When the swarm manager daemonizes, it writes a pid file so that only one manager will run at a time. This is the path
## to that pid file. {xdg_data_home} will be templated automatically and defaults to ~/.local/share as per the XDG
## specification
#      pid_file: '{xdg_data_home}/galaxy_swarm_manager.pid'

## Program output will be written to the log
#      log_file: '{xdg_data_home}/galaxy_swarm_manager.log'

## Level of log messages (levels should be Python logging module level names (case insensitive)
#      log_level: INFO

## Log message format
#      log_format: %(name)s %(levelname)s %(asctime)s %(message)s

## Limits:
##
## - service_wait_count_limit: number of services that should be waiting for each set of unique constraints before
##   attempting to spawn a node
## - service_wait_time_limit: number of seconds a service should be waiting before attempting to spawn a node
## - node_idle_limit: number of seconds a node should be idle before terminating it
## - slots_min_limit: minimum number of worker slots that should be started and active
## - slots_min_spare: number of spare (unused) worker slots that should be started and active
#      service_wait_count_limit: 0
#      service_wait_time_limit: 5
#      node_idle_limit: 120
#      slots_min_limit: 0
#      slots_min_spare: 0

# Each set of limits can also be set on a per-constraint basis under the `limits` list. Each member of `limits` is a
# dictionary with at least the key `constraints`, whose value is a list of constraint strings matching constraint
# strings that jobs will be created with, either by the use of `service_create_*_constraint` or manually setting
# constraints. Other keys match the `node_*` and `slots_*` limits above. Any limits unset will default to the "global"
# limits as set above, or their defaults. For example:
#      limits:
#        - constraints:
#          - node.labels._galaxy_image==bgruening/docker-jupyter-notebook:16.01.1
#          - node.labels._galaxy_cpus==1
#        slots_min_limit: 2
#        slots_min_spare: 1

# Amount of time to wait for a spawning node to appear in `docker node ls` before considering it failed
#      spawn_wait_time: 30

## Command to run to spawn new nodes. This command should join the node to the swarm. It is run once per unique set
## of constraints of waiting services. Can include template variables:
##  - {cpus}: Number of CPUs needed by the requested service(s) or minimum limits
##  - {slots}: Number of "slots" needed by the requested service(s) or minimum limits, where slots are CPU fractions
#i#   determined by use of the "cpus" option in the `docker_swarm` section.
##  - {image}: Image requested by service
##  - {service_ids}: Comma-separated list of service ids with these constraints currently waiting
##  - {service_count}: Number of services with these constraints currently waiting
## If this command does not block until the node is joined to the swarm, make sure it at least completes that step in
## `spawn_wait_time` once it returns control. How the `spawn_command` exits controls the swarm manager's behavior:
##  - return code: 0, output: space-separated list of spawned nodes:
##    Swarm manager will wait for the nodes to appear in the swarm and manage them. You are responsible for ensuring
##    the names returned match the name as it will appear in the output of `docker node ls`.
##  - return code: 0, output: empty:
##    Refusing to allocate nodes and the swarm manager should not attempt to spawn nodes for the given service(s)
##    again.
##  - return code: 2, output: anything (it will be logged as a message)
##    Refusing to allocate nodes and the swarm manager should attempt to spawn nodes for the given service(s) again.
##    This is useful for controlling the maximum number of nodes that will be spawned.
#       spawn_command: /bin/true

## Command to run to destroy idle nodes. Can include template variables:
##   - {nodes}: Space-separated list of node names to destroy
## This command should block until at least the point at which any nodes being destroyed no longer appear in
## `docker node ls`. It should return the names of nodes destroyed, separated by spaces.
#      destroy_command: /bin/true

## Command to run if either of the above commands failed (e.g. to notify an administrator). Can include template
## variables:
##  - {failed_command}: Command line of the command that failed
#      command_failure_command: /bin/true

## Number of times to retry spawn/destroy commands before considering them to have failed, and seconds to wait between
## retries
#      command_retries: 0
#      command_retry_wait: 10

## Stop the swarm manager daemon when there are no services or nodes to manage
#      terminate_when_idle: yes