At the moment the Hostea architecture can be summarized to be a repository containing an Enough configuration tree describing all existing instances. Since each instance is independent of the others, it would be more sensible to have one Enough configuration tree for each instance.
- h.gna.org is delegated to bind.h.gna.org: it is an Enough instance that runs a single host for the DNS
- xxx.h.gna.org is a single host that runs DNS, backups, reverse proxy, gitea, woodpecker as described by its own Enough instance
Creating a new instance:
- scafold a new Enough instance file tree for ~/.enough/xxx.h.gna.org
- create the VM xxx-host and obtain the IP
- configure ns1.h.gna.org to delegate xxx.h.gna.org to xxx-host IP (similar to what is done for tests)
- create the gitea/woodpecker service on xxx-host
Deleting an existing instance:
- delete the xxx-host & all backups
- remove the ~/.enough/xxx.h.gna.org file tree
- remove the DNS delegation from ns1.h.gna.org
These actions are triggered by the CI using a repository that contains
~/.enough (instead of
~/.enough/h.gna.org). The CI script (hostea.sh) logic is:
- Figure out which instance to focus on depending on the output of git stat.
- Run action depending on the content of the
- new => run host create xxx-host => host_exists
- host_exists => configure ns1.h.gna.org to delegate xxx.h.gna.org to xxx-host IP => host_ready
- host_ready => run host service create gitea => service_ready
- host_delete => host delete xxx-host & backups + unconfigure ns1.h.gna.org delegation => host_deleted
- host_deleted => rm ~/.enough/xxx.h.gna.org entirely
During the normal lifetime of an instance, the state is “service_ready” most of the time and the action is run multiple times, for instance whenever there is an upgrade to be done.