After making changes to the infrastructure in `archlinux.fg`, run
After making changes to the infrastructure in `tf-stage1/archlinux.fg`, run
cd tf-stage1
terraform plan
This will show you planned changes between the current infrastructure and the desired infrastructure.
...
...
@@ -74,6 +86,9 @@ You can then run
to actually apply your changes.
The same applies to changed application configuration in which case you'd run
it inside of `tf-stage2` instead of `tf-stage1`.
We store terraform state on a special server that is the only hcloud server NOT
managed by terraform so that we do not run into a chicken-egg problem. The
state server is assumed to just exist so in an unlikely case where we have to
...
...
@@ -193,10 +208,24 @@ The following steps should be used to update our managed servers:
#### Services:
- quassel core
## homedir.archlinux.org
### homedir.archlinux.org
#### Services:
- ~/user/ webhost
### accounts.archlinux.org
This server is /special/. It runs keycloak and is central to our unified Arch Linux account management world.
It has an Ansible playbook for the keycloak service but that only installs the package and starts it but it's configured via a secondary Terraform file only for keycloak `keycloak.tf`.
The reason for doing it this way is that Terraform support for Keycloak is much superior and it's declarative too which is great for making sure that no old config remains in the case of config changes.
So to set up this server from scratch, run:
-`terraform apply tf-first-stage`
-`terraform apply tf-second-stage`
#### Services:
- keycloak
## mirror.pkgbuild.com
...
...
@@ -252,3 +281,8 @@ Example
Example
borg list borg@vostok.archlinux.org:/backup/homedir.archlinux.org::20191127-084357
## One-shots
A bunch of once-only admin task scripts can be found in `one-shots/`.
We try to minimize the amount of manual one-shot admin work we have to do but sometimes for some migrations it might be necessary to have such scripts.