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.yml. Additionally, the
# containers interface is only used if `enable_beta_containers_interface` is set in galaxy.yml.

###
### Container Interfaces
###

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

#containers:
#    _default_:
#        type: docker

# The interface name is arbitrary and allows multiple distinct configurations to be defined. The name can be any string,
# but `_default_` is used if a component that uses the containers interface does not specify an interface. Currently
# only Galaxy Interactive Environments use the containers interface, and do not have a way to specify which interface to
# use, so configure under the `_default_` key for now.

# 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)

containers:

    #
    # Supported options for all container types
    #

    _default_:

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

    #
    # Supported options for `docker` container type
    #

    local_docker:

        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

    #
    # Supported options for `docker_swarm` container type
    #

    swarm:

        type: docker_swarm

        # All of the `docker` interface type arguments are supported. Additionally:

        # [`-H`/`--host] Daemon socket(s) to connect to. This can be a list, which allows failing over to another
        # manager when one is down, e.g.:
        #   host:
        #     - tcp://swarm1.example.org:2376
        #     - tcp://swarm2.example.org:2376
        #host: null

        # [`--reserve-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

        # [`--reserve-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. Note: It's
        # currently only possible for nodes to have a single image constraint defined. If your nodes have multiple
        # images available, do not use this option.
        #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

        #
        # Galaxy can manage a Docker swarm using a built-in daemon and callouts to commands to add/remove nodes from
        # your swarm.
        #

        # 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

        # Configuration dictionary for the swarm manager
        manager_conf:

            #
            # In order to use the swarm manager for more than just service cleanup, (e.g. its node spawn and destroy
            # features), you'll need to configure the `cpus` option in the interface. Otherwise, there are no limits on
            # the number of services that will be assigned to a given node, so the swarm manager has no way to determine
            # that more nodes should be spawned.
            #
            # Each service consumes one "slot", and the number of slots available on a node is its number of CPUs
            # divided by the value of `cpus`.
            #

            # 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 are Python logging module level names (case insensitive))
            #log_level: INFO

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

            # List of services' environment variables that should be logged when performing periodic service logging. By
            # default, none are logged, but `USER_EMAIL` is useful for GIE containers to log the user who is running the
            # container.
            #log_environment_variables:
            #    - USER_EMAIL

            # 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 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. This is useful for controlling the maximum number of nodes that will be spawned.
            #  - return code: 2, output: anything (it will be logged as a message)
            #    Refusing/failed to allocate nodes but the swarm manager should attempt to spawn nodes for the given
            #    service(s) again.
            #
            #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
            # the swarm. 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

            # Amount of time to wait for a spawning node to appear in the swarm before considering it failed
            #spawn_wait_time: 30

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

            #
            # Limits control when the swarm manager will spawn and terminate nodes.
            #

            # Number of services that must be waiting to run before attempting to spawn a node. If using constraints,
            # then waiting services are grouped by constraint.
            #service_wait_count_limit: 0

            # Number of seconds a service must be waiting before attempting to spawn a node.
            #service_wait_time_limit: 5

            # Number of seconds a node must be idle before terminating it.
            #node_idle_limit: 120

            # Minimum number of worker slots that should be started and active.
            #slots_min_limit: 0

            # Number of spare (unused) worker slots that should be started and active
            #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 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.
            #
            # If you are using constraints, you should at least define them in the limits section, even if using all
            # "global" values for the limits. This allows the swarm manager to know what node types to keep around if
            # you're using `slots_min_limit`.
            #

            # Limits section 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