docs: refresh infra docs for post-Hetzner architecture

.editorconfig

@@ -16,10 +16,6 @@ indent_size = 2
 indent_style = space
 indent_size = 2
 
-[config.ru]
-indent_style = tab
-indent_size = 4
-
 [*.rb]
 indent_style = space
 indent_size = 2

README.md

@@ -16,7 +16,6 @@ Concepts:
 Tasks:
 
  * [Deployment guide](docs/deploy.md)
- * [Editing diagrams](docs/editing-diagrams.md)
 
 Organizational (for team members):
 

docs/deploy.md

@@ -56,20 +56,12 @@ This guide explains how to deploy infrastructure updates. This guide is not for
         cd ..
         ~~~
 
- 4. Get the credentials for the Kubernetes cluster:
+ 4. Apply Ansible to the backend VM:
 
     ~~~bash
-    gcloud container clusters get-credentials fullstaq-ruby-autopilot --configuration fullstaq-ruby --region us-east4
+    cd ansible
+    ansible-playbook -i hosts.ini -v main.yml
+    cd ..
     ~~~
 
- 5. Set the default namespace:
-
-    ~~~bash
-    kubectl config set-context --current --namespace=fullstaq-ruby
-    ~~~
-
- 6. Apply the Kustomization:
-
-    ~~~bash
-    kubectl apply --context=gke_fullstaq-ruby_us-east4_fullstaq-ruby-autopilot -k ../kubernetes
-    ~~~
+> The API server itself is not deployed by this playbook. Code changes under `apiserver/` are released by the `.github/workflows/apiserver.yml` workflow, which packages a tarball, attaches it to a GitHub Release, and triggers `POST /admin/upgrade_apiserver` on the live host.

docs/infrastructure-as-code.md

@@ -3,19 +3,19 @@
 We define as much infrastructure as possible in the form of code, using:
 
  * [Terraform](https://terraform.io)
- * Kubernetes YAML, managed with [Kustomize](https://kustomize.io/)
+ * [Ansible](https://www.ansible.com/)
  * Github Actions
 
 The infrastructure-as-code is stored in the following directories:
 
- * `terraform/` — Infrastructure administered by [Infra Maintainers](roles.md), except for resources inside Kubernetes. Most of the infrastructure is defined here.
+ * `terraform/` — Infrastructure administered by [Infra Maintainers](roles.md). Most of the cloud-side infrastructure is defined here.
 
- * `terraform-hisec/` — Infrastructure administered by [Infra Owners](roles.md). This covers for example resources in the `fullstaq-ruby-hisec` Google Cloud project.
+ * `terraform-hisec/` — Infrastructure administered by [Infra Owners](roles.md). This covers for example sensitive resources such as the GPG signing key in Azure Key Vault, and the high-security Terraform state backend.
 
-   Because we don't expect the infrastructure in this directory to change very often, we've chosen — for security reasons — not to run Terraform in a CI/CD pipeline. This way we don't have to worry about the security of the CI/CD pipeline's service account. Instead, an [Infra Owner](roles.md) runs Terraform manually, using that person's personal Google Cloud credentials.
+   Because we don't expect the infrastructure in this directory to change very often, we've chosen — for security reasons — not to run Terraform in a CI/CD pipeline. This way we don't have to worry about the security of any CI/CD pipeline credentials. Instead, an [Infra Owner](roles.md) runs Terraform manually, using their personal cloud credentials.
 
- * `kubernetes/` — Kubernetes resources administered by [Infra Maintainers](roles.md).
+ * `ansible/` — Configuration of the backend VM (Caddy, the API server, Prometheus, and OS hardening). Administered by [Infra Maintainers](roles.md) and applied manually; see [Deployment guide](deploy.md).
 
- * `.github/workflows/apiserver.yml` — Deploys the API server.
+ * `.github/workflows/apiserver.yml` — Builds and deploys the API server.
 
 Note that not all infrastructure can, or (for security reasons) should, be managed via code. Learn more at [Infrastructure bootstrapping](infrastructure-bootstrapping.md).

docs/infrastructure-bootstrapping.md

@@ -1,6 +1,6 @@
 # Infrastructure bootstrapping
 
-We try to codify infrastructure as much as possible using Terraform and Kubernetes YAML. However:
+We try to codify infrastructure as much as possible using Terraform and Ansible. However:
 
 - Not everything _can_ be automated. For example, we need to setup Azure Blob Storage for storing Terraform state, before we can use Terraform.
 - Not everything _should_ be automated. For example, the `fullstaq-ruby-hisec` project contains such sensitive data, that giving access to CI/CD systems would pose a security risk.