The entirety of a system managed by an Orbiter as well as the information contained in a corresponding Git repository forms an Orb
Orbiter is both released as a container image named orbiter and as a command line tool called orbctl. For bootstrapping a brand new Orb, the orbctl is invoked locally. It then provisions all provider infrastructure, installs Node Agents using SSH, installs the desired clusters and finally deploys an Orbiter to one of the new clusters (e.g. Kubernetes). The deployed Orbiter then takes over control from orbctl in order to continously ensuring the Orbs desired state.
The Orbiter has the Node Agents reconciling software versions and configuration on operating systems (e.g. nginx from yum or apt). Therefore, each server has a responsible Node Agent run by systemd.
An Orbs Git repository contains all relevant information consumed and produced by an Orbiter. Namely it contains a desired state, a current state and secrets, all declared in yaml files.
The desired state is the Orbs target state defined by humans. It holds all information the Orbiter needs to create the current state. All and only human interaction with an Orbiter is manifested by changes to its corresponding desired.yml file.
The current state is the Orbs observed internal state. It is generated by Orbiter and edited only by Orbiter and Node Agent. A Node Agents desired state is current state from the Orbiters perspective, which is why it is embedded within the current.yml file. The Node Agent reports its current state in a dedicated current key next to its desired state (which in turn is declared in a spec key) within the current.yml file
Keyed secrets are symmetrically encrypted with the AES 256 and encoded with the Base64 algorithms within the secrets.yml file.
