container

kind: Module

# The type of this module.
type:

# The name of this module.
name:

# Specify how to build the module. Note that plugins may define additional keys on this object.
build:
  # A list of modules that must be built before this module is built.
  dependencies:
    - # Module name to build ahead of this module.
      name:

      # Specify one or more files or directories to copy from the built dependency to this module.
      copy:
        - # POSIX-style path or filename of the directory or file(s) to copy to the target.
          source:

          # POSIX-style path or filename to copy the directory or file(s), relative to the build directory.
          # Defaults to the same as source path.
          target:

  # Maximum time in seconds to wait for build to finish.
  timeout: 600

  # For multi-stage Dockerfiles, specify which image/stage to build (see
  # https://docs.docker.com/engine/reference/commandline/build/#specifying-target-build-stage---target for details).
  targetImage:

# If set to true, Garden will run the build command, services, tests, and tasks in the module source directory,
# instead of in the Garden build directory (under .garden/build/<module-name>).
#
# Garden will therefore not stage the build for local modules. This means that include/exclude filters
# and ignore files are not applied to local modules, except to calculate the module/action versions.
#
# If you use use `build.dependencies[].copy` for one or more build dependencies of this module, the copied files
# will be copied to the module source directory (instead of the build directory, as is the default case when
# `local = false`).
#
# Note: This maps to the `buildAtSource` option in this module's generated Build action (if any).
local: false

# A description of the module.
description:

# Set this to `true` to disable the module. You can use this with conditional template strings to disable modules
# based on, for example, the current environment or other variables (e.g. `disabled: ${environment.name == "prod"}`).
# This can be handy when you only need certain modules for specific environments, e.g. only for development.
#
# Disabling a module means that any services, tasks and tests contained in it will not be build, deployed or run.
#
# If you disable the module, and its services, tasks or tests are referenced as _runtime_ dependencies, Garden will
# automatically ignore those dependency declarations. Note however that template strings referencing the module's
# service or task outputs (i.e. runtime outputs) will fail to resolve when the module is disabled, so you need to make
# sure to provide alternate values for those if you're using them, using conditional expressions.
disabled: false

# Specify a list of POSIX-style paths or globs that should be regarded as the source files for this module. Files that
# do *not* match these paths or globs are excluded when computing the version of the module, when responding to
# filesystem watch events, and when staging builds.
#
# Note that you can also _exclude_ files using the `exclude` field or by placing `.gardenignore` files in your source
# tree, which use the same format as `.gitignore` files. See the [Configuration Files
# guide](https://docs.garden.io/cedar-0.14/using-garden/configuration-overview#including-excluding-files-and-directories)
# for details.
#
# Also note that specifying an empty list here means _no sources_ should be included.
#
# If neither `include` nor `exclude` is set, and the module has a Dockerfile, Garden
# will parse the Dockerfile and automatically set `include` to match the files and
# folders added to the Docker image (via the `COPY` and `ADD` directives in the Dockerfile).
#
# If neither `include` nor `exclude` is set, and the module
# specifies a remote image, Garden automatically sets `include` to `[]`.
include:

# Specify a list of POSIX-style paths or glob patterns that should be excluded from the module. Files that match these
# paths or globs are excluded when computing the version of the module, when responding to filesystem watch events,
# and when staging builds.
#
# Note that you can also explicitly _include_ files using the `include` field. If you also specify the `include`
# field, the files/patterns specified here are filtered from the files matched by `include`. See the [Configuration
# Files
# guide](https://docs.garden.io/cedar-0.14/using-garden/configuration-overview#including-excluding-files-and-directories)
# for details.
#
# Unlike the `scan.exclude` field in the project config, the filters here have _no effect_ on which files and
# directories are watched for changes. Use the project `scan.exclude` field to affect those, if you have large
# directories that should not be watched for changes.
exclude:

# A remote repository URL. Currently only supports git servers. Must contain a hash suffix pointing to a specific
# branch or tag, with the format: <git remote url>#<branch|tag>
#
# Garden will import the repository source code into this module, but read the module's config from the local
# garden.yml file.
repositoryUrl:

# When false, disables pushing this module to remote registries via the publish command.
allowPublish: true

# A list of files to write to the module directory when resolving this module. This is useful to automatically
# generate (and template) any supporting files needed for the module.
generateFiles:
  - # POSIX-style filename to read the source file contents from, relative to the path of the module (or the
    # ConfigTemplate configuration file if one is being applied).
    # This file may contain template strings, much like any other field in the configuration.
    sourcePath:

    # POSIX-style filename to write the resolved file contents to, relative to the path of the module source directory
    # (for remote modules this means the root of the module repository, otherwise the directory of the module
    # configuration).
    #
    # Note that any existing file with the same name will be overwritten. If the path contains one or more
    # directories, they will be automatically created if missing.
    targetPath:

    # By default, Garden will attempt to resolve any Garden template strings in source files. Set this to false to
    # skip resolving template strings. Note that this does not apply when setting the `value` field, since that's
    # resolved earlier when parsing the configuration.
    resolveTemplates: true

    # The desired file contents as a string.
    value:

# A map of variables scoped to this particular module. These are resolved before any other parts of the module
# configuration and take precedence over project-scoped variables. They may reference project-scoped variables, and
# generally use any template strings normally allowed when resolving modules.
variables:

# Specify a path (relative to the module root) to a file containing variables, that we apply on top of the
# module-level `variables` field.
#
# The format of the files is determined by the configured file's extension:
#
# * `.yaml`/`.yml` - YAML. The file must consist of a YAML document, which must be a map (dictionary). Keys may
# contain any value type. YAML format is used by default.
# * `.env` - Standard "dotenv" format, as defined by [dotenv](https://github.com/motdotla/dotenv#rules).
# * `.json` - JSON. Must contain a single JSON _object_ (not an array).
#
# _NOTE: The default varfile format was changed to YAML in Garden v0.13, since YAML allows for definition of nested
# objects and arrays._
#
# To use different module-level varfiles in different environments, you can template in the environment name
# to the varfile name, e.g. `varfile: "my-module.${environment.name}.env` (this assumes that the corresponding
# varfiles exist).
varfile:

# Specify build arguments to use when building the container image.
#
# Note: Garden will always set a `GARDEN_ACTION_VERSION` (alias `GARDEN_MODULE_VERSION`) argument with the
# module/build version at build time.
buildArgs: {}

# Specify extra flags to use when building the container image. Note that arguments may not be portable across
# implementations.
extraFlags:

# Specify the platforms to build the image for. This is useful when building multi-platform images.
# The format is `os/arch`, e.g. `linux/amd64`, `linux/arm64`, etc.
platforms:

# Secret values that can be mounted in the Dockerfile, but do not become part of the image filesystem or image
# manifest. This is useful e.g. for private registry auth tokens.
#
# Build arguments and environment variables are inappropriate for secrets, as they persist in the final image.
#
# The secret can later be consumed in the Dockerfile like so:
#   RUN --mount=type=secret,id=mytoken TOKEN=$(cat /run/secrets/mytoken) ...
#
# See also https://docs.docker.com/build/building/secrets/
secrets:

# Specify the image name for the container. Should be a valid Docker image identifier. If specified and the module
# does not contain a Dockerfile, this image will be used to deploy services for this module. If specified and the
# module does contain a Dockerfile, this identifier is used when pushing the built image.
image:

# POSIX-style name of a Dockerfile, relative to module root.
dockerfile:

# A list of services to deploy from this container module.
services:
  - # Valid RFC1035/RFC1123 (DNS) label (may contain lowercase letters, numbers and dashes, must start with a letter,
    # and cannot end with a dash), cannot contain consecutive dashes or start with `garden`, or be longer than 63
    # characters.
    name:

    # The names of any services that this service depends on at runtime, and the names of any tasks that should be
    # executed before this service is deployed.
    dependencies: []

    # Set this to `true` to disable the service. You can use this with conditional template strings to enable/disable
    # services based on, for example, the current environment or other variables (e.g. `enabled: ${environment.name !=
    # "prod"}`). This can be handy when you only need certain services for specific environments, e.g. only for
    # development.
    #
    # Disabling a service means that it will not be deployed, and will also be ignored if it is declared as a runtime
    # dependency for another service, test or task.
    #
    # Note however that template strings referencing the service's outputs (i.e. runtime outputs) will fail to resolve
    # when the service is disabled, so you need to make sure to provide alternate values for those if you're using
    # them, using conditional expressions.
    disabled: false

    # The command/entrypoint to run the container with.
    command:

    # The arguments (on top of the `command`, i.e. entrypoint) to run the container with.
    args:

    # Key/value map of environment variables. Keys must be valid POSIX environment variable names (must not start with
    # `GARDEN`) and values must be primitives or references to secrets.
    env: {}

    cpu:
      # The minimum amount of CPU the container needs to be available for it to be deployed, in millicpus (i.e. 1000 =
      # 1 CPU)
      min: 10

      # The maximum amount of CPU the container can use, in millicpus (i.e. 1000 = 1 CPU). If set to null will result
      # in no limit being set.
      max: 1000

    memory:
      # The minimum amount of RAM the container needs to be available for it to be deployed, in megabytes (i.e. 1024 =
      # 1 GB)
      min: 90

      # The maximum amount of RAM the container can use, in megabytes (i.e. 1024 = 1 GB) If set to null will result in
      # no limit being set.
      max: 1024

    # List of volumes that should be mounted when starting the container.
    #
    # Note: If neither `hostPath` nor `module` is specified,
    # an empty ephemeral volume is created and mounted when deploying the container.
    volumes:
      - # The name of the allocated volume.
        name:

        # The path where the volume should be mounted in the container.
        containerPath:

        # _NOTE: Usage of hostPath is generally discouraged, since it doesn't work reliably across different platforms
        # and providers. Some providers may not support it at all._
        #
        # A local path or path on the node that's running the container, to mount in the container, relative to the
        # config source directory (or absolute).
        hostPath:

    # If true, run the main container in privileged mode. Processes in privileged containers are essentially
    # equivalent to root on the host. Defaults to false.
    privileged:

    # POSIX capabilities to add when running the container.
    addCapabilities:

    # POSIX capabilities to remove when running the container.
    dropCapabilities:

    # Specify if containers in this action have TTY support enabled (which implies having stdin support enabled)