||2 years ago|
|ansible-roles||2 years ago|
|ansible-wrapper||2 years ago|
|application-modules||2 years ago|
|automation||2 years ago|
|configuration||2 years ago|
|host-key-poller||2 years ago|
|objectStorage||2 years ago|
|pki||2 years ago|
|terraform-modules||2 years ago|
|.gitignore||2 years ago|
|ReadMe.md||2 years ago|
|build.sh||2 years ago|
|lock.go||2 years ago|
|main.go||2 years ago|
|notes.txt||2 years ago|
|pull.sh||2 years ago|
|terraformStateHandler.go||2 years ago|
server.garden Privileged Automation Agent
mkdir -p ssh ssh-keygen -t ed25519 -N '' -f ./ssh/servergarden_builtin_ed22519 go build -o ansible-wrapper/ansible-playbook-wrapper ansible-wrapper/main.go go build -o host-key-poller/host-key-poller host-key-poller/main.go # you will have to provide a complete config file. normally this would be provideded by seedpacket nano config.json go run *.go
Rootsystem is the entrypoint & most highly privileged part of the server.garden automation system, hence "root" in the name.
Rootsystem starts the first time a server.garden system boots, and it uses provided credentials and options to create, plan & apply multiple terraform projects based on its own collection of terraform modules & ansible roles. It is responsible for installing and configuring the required base-system components of a server.garden datacenter, such as:
- threshold, the public-internet-facing gateway & TCP reverse tunnel
- serviceroad, the peer-to-peer vpn
- spigot, the consensus & leader-election service
- caddy, the Let's Encrypt ACME client, TLS terminator & reverse-proxy
Rootsystem will create one
terraform-global project first, where it configures DNS entries and an optional cloud instance to act as an ingress gateway.
Then, it will create a
terraform-local-<node-name> project on each node, which will set up node-specific elements of the system, both in the cloud (node-specific DNS entries, threshold configurations, etc) and locally on the node itself.
In the future, rootsystem will also have a continuous-integration-ish role, where it handles configuration changes as they are posted & re-runs builds as needed.
Rootsystem has no user-interface of its own, however, it is tightly coupled to the seedpacket desktop application. Rootsystem posts status updates to object storage, which seedpacket can read & display to the user in real time via polling.