||2 weeks ago|
|.github||1 year ago|
|api||2 months ago|
|bin||1 year ago|
|certs||1 year ago|
|config||1 year ago|
|cook||1 year ago|
|docker||2 months ago|
|ingredients||11 months ago|
|install||11 months ago|
|logos||1 year ago|
|pkg||2 weeks ago|
|pki||1 year ago|
|testing||1 year ago|
|types||3 weeks ago|
|.dockerignore||1 year ago|
|.gitignore||11 months ago|
|LICENSE.txt||1 year ago|
|Makefile||2 months ago|
|README.md||1 year ago|
|docker-compose.yml||1 year ago|
|go.mod||2 months ago|
|go.sum||2 months ago|
grlx - System management without the stinkin' dependencies!
grlx (pronounced "garlic") is a pure-Go alternative to other DevOps automation engines, such as Salt or Ansible.
grlx is made up of three components: the
farmer, one or many
sprouts, and a CLI utility,
farmer binary runs as a daemon on a management server (referred to as the 'farmer'), and is controlled via the
grlx can be run both locally on the management sever or remotely over a secure-by-default, TLS-encrypted API.
sprout binary should be installed as a daemon on systems that are to be managed.
Managed systems are referred to as 'sprouts.'
All binaries are built without
CGO, and should therefore be compatible with as many Linux systems as possible.
farmer contains an embedded messaging Pub-Sub server (NATS), and an api server.
sprout subscribe to messages over the bus.
Both the API server and the messaging bus use TLS encryption (elliptic curve by default), and sprouts authenticate using public-key cryptography.
Jobs can be created with the
grlx command-line interface, and typically come in the form of stateful targets, called 'recipes'.
Recipies are yaml documents which describe the desired state of a sprout after the recipe is applied (
farmer exposes an API,
grlx is by no means the only way to create or manage jobs, but it is the only supported method at the beginning.
Some features (not yet ordered) that are coming to grlx:
- Command execution
- BSD + Windows support (
grlxclient support already exists, but management does not)
- Encrypted secrets management
- External TLS certificates (i.e. LetsEncrypt, or self-signed)
- File management
- Git integration
- Integrated web-based dashboard
- Job progress
- Remote shell access (dropshell)
- S3 object storage support
- Service management
- Simple monitoring data and collection
- Standardized error handling
- Support for non-systemd init systems
- Template shell-based rendering
- ... Many more!
This project is not yet ready to accept code contributions. Notably, when working with new libraries, I (@taigrr) write code in three phases. The first cut is very ugly, and does not follow best practices or handle errors correctly. It is frankly, unacceptable for deployment until the third revision.
All code contained herein is in working-draft mode, and should not be used in production until a semantic version is released.
However, if you like what you're seeing and want to bring grlx 'to market' sooner, please feel free to throw some financial encouragement my way!
A big thank you to all of grlx's sponsors. It's your donations that allow development to continue so that grlx can grow.
Dependencies may carry their own license agreements. To see the licenses of dependencies, please view DEPENDENCIES.md.
Unless otherwise noted, the grlx source files are distibuted under the 0BSD license found in the LICENSE file.
All grlx logos are Copyright 2021 Tai Groot, and Licensed under CC BY 3.0.
The original Go Gopher was designed by Renee French.