Skip to main content

Groups

Groups are Monk's composition constructs. Groups allow for composing runnables, 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.

Minimal example

runnable.yaml
namespace: reference

example-group:
defines: process-group
runnable-list:
- reference/runnable-a
- reference/runnable-b

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 runnable-list.

process-group

FieldValuePurposeRequired
runnable-listlist of pathsList of members of the group, can be namespace paths to runnable, service or other group.yes

Sub-sections

Runnable sections can have multiple sub-sections of special meaning. All definitions applicable inside a runnable are described below.

variables

variables:
defines: variables
variable-a: ...
variable-b: ...
info

Applicable to: process-group

Required: no

Variables section is a map of variable, each container is named by its key (variable-a, 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.

note

These variables are not environment variables - they live on Monk's control plane. Use env to bind them to environment variables if you need.

variable

variable-name:
type: variable type
value: variable value
env: environment variable to bind to

variable-name: variable value
info

Applicable to: variables

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.

FieldValuePurposeRequired
typeone of: string, int, floatType of the variableyes
valueanythingInitial value of the variableyes
envVAIRABLE_NAMEName of environment variable that will receive the variable's value in all containersno

actions

variables:
defines: actions
action-a: ...
action-b: ...
info

Applicable to: process-group

Required: no

Action section is a map of action, each container is named by its key (action-a, action-b in above example). Names can be any valid YAML key.

action

action-name:
description: action description
arguments:
arg-a:
type: argument type
description: argument description
default: argument default value
arg-b: ...
code: Arrow script code
info

Applicable to: actions

Required: yes

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.

FieldValuePurposeRequired
descriptionhuman readable stringHuman readable description of the action. MonkHub displays these.yes
codeArrow script codeCode for the action, notice that the <- prefix is not neededyes
argumentsmap of argumentsSpecifies action's expected arguments. See the table belowno

argument

FieldValuePurposeRequired
descriptionhuman readable stringHuman readable description of the argument. MonkHub displays these.yes
typeone of: string, int, floatType of the argumentyes
defaultanythingValue of the argument used when it is not specified during callno

Example

actions:
defines: actions

sum:
description: sums two numbers
arguments:
a:
type: int
description: first number
b:
type: int
description: second number
add-one:
type: bool
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

balancers:
defines: balancers
balancer-a: ...
balancer-b: ...
info

Applicable to: process-group

Required: no

Balancers section is a map of balancer, each load balancer is named by its key (balancer-a, balancer-b in above example). Names can be any valid YAML key.

balancer

balancer-a:
type: load balancer type
port: target port
instances:
- list of runnables to balance between
info

Applicable to: balancers

Required: at least one

Rate this page