Groups are Monk's composition constructs. Groups allow for composing
services and other groups into sets that can be ran and managed as single entities. This allows for expressing complex systems in a portable and modular way. Additionally, a group can define additional resources, such as load balancers that apply to all members of the group.
Groups can also contain common
variables shared by the group members providing a scoped state storage and communication bus.
This example shows a group
example-group inside a namespace
reference. At minimum, a valid
process-group must have at least one
runnable (or other object) specified in the
|list of paths||List of members of the group, can be namespace paths to ||yes|
Runnable sections can have multiple sub-sections of special meaning. All definitions applicable inside a
runnable are described below.
Variables section is a map of
variable, each container is named by its key (
variable-b in above example). Names can be any valid YAML key.
Variables in groups are visible to all member
runnables as if they were declared in the runnable as long as there is no definition for a variable of the same name inside the runnable itself. In other words, whenever resolving a variable inside a
runnable, Monk first looks at variables defined or inherited in that runnable, only then looks at the variables defined in the group containing the runnable.
These variables are not environment variables - they live on Monk's control plane. Use
env to bind them to environment variables if you need.
type: variable type
value: variable value
env: environment variable to bind to
variable-name: variable value
Required: at least one
A variable can either just specify the value - in which case the type is inferred automatically, or specify its type and value.
|one of: ||Type of the variable||yes|
|anything||Initial value of the variable||yes|
|Name of environment variable that will receive the variable's value in all containers||no|
Action section is a map of
action, each container is named by its key (
action-b in above example). Names can be any valid YAML key.
description: action description
type: argument type
description: argument description
default: argument default value
code: Arrow script code
Actions are somewhat akin to function definitions known from regular programming languages. They are specified by name, list of arguments and code to be executed upon calling the action.
action specifies its code using Arrow script syntax but without
<- as the code is constant here.
|human readable string||Human readable description of the action. MonkHub displays these.||yes|
|Arrow script code||Code for the action, notice that the ||yes|
|map of ||Specifies action's expected arguments. See the table below||no|
|human readable string||Human readable description of the argument. MonkHub displays these.||yes|
|one of: ||Type of the argument||yes|
|anything||Value of the argument used when it is not specified during call||no|
description: sums two numbers
description: first number
description: second number
description: add 1 to result
default: false # if default is not set, the argument is required
code: $args["a"] $args["b"] add $args["add-one"] add
Balancers section is a map of
balancer, each load balancer is named by its key (
balancer-b in above example). Names can be any valid YAML key.
type: load balancer type
port: target port
- list of runnables to balance between
Required: at least one