At a high level the grlx architecture looks like the following:
We can boil down the
grlx into three different parts: the farmer, the sprout, and the CLI.
The farmer is your management server running the
grlx-farmer binary. The binary can run as a systemd service or be hosted in a container. This has analogs in other similar configuration platforms such as a Salt Master in SaltStack or a Chef Server in Chef. grlx utilizes the farmer for things like authentication, job processing, and ingredients. Additionally, the farmer contains is responsible for holding your recipes.
The sprout is a managed node running the
grlx-sprout binary. Sprouts receive commands from the farmer over the NATS message bus. These can be immediate shell commands, or actions that are performed by Ingredients defined in a recipe (e.g. ensure that a file exists, a service is started). Sprouts are similar to a Salt Minion in SaltStack or a Chef Client in Chef. Jobs are received from the farmer over the NATS message bus. Sprouts will then execute the job and report back to the farmer the results of the job.
The CLI is a tool used to interact with the farmer and manage sprouts. The CLI is used to accept keys from sprouts and
cook (run) recipes that are hosted on the farmer. The CLI also contains tools to tail the traffic over the NATS bus, test sprout connections, and run arbitrary commands on sprouts.
Recipes are the core of grlx and are responsible for handling the configuration of your sprouts. Recipes are written with the
.grlx extension and are a combination of YAML and Go templates. Recipes are stored on the farmer and are executed by the sprouts. Recipes are responsible for defining the ingredients and in what order they are executed. For more information see the recipes section.