docs: refresh infra docs for post-Hetzner architecture

Closes #55.

Brings docs/ in line with the post-July-2024 architecture (single
Hetzner VM running Caddy + Sinatra/Puma API server + Prometheus,
provisioned by Ansible), replacing references to the previous
GKE Autopilot + Nginx Ingress + Cloud Run apiserver setup.

Files changed:

- docs/infrastructure-overview.md — rewritten section by section.
  Every claim is grounded in current IaC. The two GCP-service-account
  sections are folded into a single "CI/CD authentication" section
  that splits per-caller: server-edition uses GCP WIF (APT/YUM repo
  buckets + GCS CI artifacts bucket) and Azure Federated Identity
  Credentials (Azure Blob CI artifacts + CI cache + Key Vault GPG
  key); infra repo's apiserver workflow only mints a GitHub OIDC JWT
  (audience backend.fullstaqruby.org) and POSTs to
  /admin/upgrade_apiserver — it does not authenticate to GCP or
  Azure APIs. The Caddy section is corrected: there is no
  backend.fullstaqruby.org vhost; both apt. and yum. vhosts handle
  /admin/* via reverse_proxy to the apiserver Unix socket. The
  "Google Cloud projects" claim of two projects is corrected — there
  is one project, fsruby-server-edition2, provisioned by
  terraform-hisec/gcloud_project.tf and populated by terraform/; the
  hisec/non-hisec separation lives at the Terraform-state and
  access-group layer. Container registry section dropped (no
  registry resources are managed in this repo). Key Vault name
  uses the templated form ${var.key_vault_prefix}infraowners
  (currently fsruby2infraowners). CI artifacts/cache split is now
  explicit (artifacts dual-cloud, cache Azure-only). VM section
  distinguishes Terraform-managed forward DNS from the
  manually-set Hetzner PTR record.

- docs/infrastructure-overview.drawio.svg — deleted. Replaced by an
  inline Mermaid diagram in infrastructure-overview.md so future
  diagram changes are reviewable as text diffs.

- docs/editing-diagrams.md — deleted (no longer needed without the
  drawio round-trip).

- docs/deploy.md — replaces the gcloud-clusters/kubectl steps with
  a single ansible-playbook step matching bootstrapping Step 11.
  Adds a callout that apiserver code changes deploy via the
  GitHub Actions workflow.

- docs/infrastructure-as-code.md — drops Kustomize and the
  kubernetes/ directory bullet; adds Ansible to the tool list and
  an ansible/ directory bullet.

- docs/infrastructure-bootstrapping.md — intro updated to mention
  Terraform + Ansible (not Kubernetes/Kustomize); the rest of the
  file already reflected the post-migration setup.

- docs/pull_request_template.md — diagram-update checkbox now
  points to the Mermaid block instead of the deleted drawio file.

- README.md — drops the link to the deleted editing-diagrams.md.

- .editorconfig — removes the duplicate [config.ru] block (the
  tab/4 one); only the correct space/2 rule remains.

Note: the "Github CI bot account" section is kept as-is. Retiring
that PAT-based bot is already tracked in #18 and is therefore out
of scope here.

Author: abtreece

.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/editing-diagrams.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-as-code.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.