_
_[_]_
_(_)______.-'`-.
/, >< ,----' `-._.-'*
\\|::| Welcome to the Circus
|/\| We already got enough Clowns,
|||| You got any experiance with
|||| Being shot from a canon??
__(_/\_)
/`-..__.,-'\
/ __/\__ \
`._ \ / _.'MJP
``|/\|-'
Ringmaster organises a bunch of other tools on your behalf so that you don't have to. The aim is you can create, updated and delete entire stacks crossing cloudformation, EKS, kubectl, helm and random Python/BASH scripts with a single command.
Ringmaster helps you create and share your automation scripts with others, so you can get up and running as quick as possible. There are no agents, hubs, gits or daemons - unless you add them yourself. jinja2 is used for templating.
Ringmaster is just files on a disk and calls to other systems made in an order you decide.
You create a directory of scripts to process, like this:
stack/
├── 0010-iam
│ ├── AWSLoadBalancerController.iam_policy.json
│ ├── Certbot.iam_policy.json
│ ├── EksDeploy.iam_policy.json
│ ├── EksExternalSecrets.iam_policy.json
│ ├── ExternalDns.iam_policy.json
│ └── metadata.yaml
├── 0020-efs
│ ├── efs.cloudformation.yaml
│ └── metadata.yaml
├── 0030-vpc
│ ├── metadata.yaml
│ ├── vpc.remote_cloudformation.yaml
│ └── vpc.yaml
...
Then you run ringmaster
like this:
ringmaster stack up
Ringmaster will carry out the create action of each script, running each script in alphabetical order by directory and then file
ringmaster stack down
Ringmaster will carry out the delete action of each script, in reverse alphabetical order
The up
and down
actions are
idempotent
so you can run them as many times as you like
No! The scripts use the languages and tools you already know and love, eg:
- Cloudformation
- Bash
- Python
- Kubernetes deployment descriptors
- ...etc
Ringmaster uses a databag to give each script the right inputs and collects outputs that may be required later. Combined with a simple built-in variable substitution system, this makes gluing completely different systems together easy, eg:
cloudformation -> ekscl -> more cloudformation -> heml -> kubectl -> ...
To reduce dependency on ringmaster and allow easy debugging and repeatable
deployments, substitution results are stored adjacent to their input files, so
they can be added to git or use directly by tools such as kubectl
.