docs+ui: explain why podinfo/hello share a Caddy target; genericize hero copy
All checks were successful
build-hello-app / build-and-push (push) Successful in 32s
All checks were successful
build-hello-app / build-and-push (push) Successful in 32s
docs/03-flux.md: clarify that podinfo/hello-app pointing at the same <VM_IP> in Caddy isn't a routing choice - there's only one VM right now, doubling as both control plane and workload node, and Traefik is what actually does per-hostname routing once the request lands there. index.html: drop the specific "Dell T630" hardware reference from the public-facing tagline in favor of a generic "Home server". Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Y4YNpuC2bgT224suQLLJ7B
This commit is contained in:
parent
a803eda2c0
commit
b3da26e337
2 changed files with 11 additions and 2 deletions
|
|
@ -102,7 +102,7 @@
|
|||
<body>
|
||||
<main>
|
||||
<h1>Homelab GitOps Platform</h1>
|
||||
<p class="tagline">Terraform-provisioned k3s cluster on a Dell T630, deployed and kept in sync entirely through GitOps. This page is served from it — and this line proves it: edited via git push.</p>
|
||||
<p class="tagline">Terraform-provisioned self-hosted k3s cluster on a Home server, deployed and kept in sync entirely through GitOps. This page is served from it — and this line proves it: edited via git push.</p>
|
||||
|
||||
<div class="badge-row">
|
||||
<span class="badge">commit <strong>__GIT_SHA__</strong></span>
|
||||
|
|
|
|||
|
|
@ -452,7 +452,16 @@ podinfo.boglabob.com CNAME boglabob.com
|
|||
hello.boglabob.com CNAME boglabob.com
|
||||
```
|
||||
|
||||
Then in Caddy's own config, using the VM's pinned IP from stage 2:
|
||||
Then in Caddy's own config, using the VM's pinned IP from stage 2. Both
|
||||
blocks point at the exact same `<VM_IP>` — that's not a mistake, there's
|
||||
only one VM right now, and it's simultaneously the control plane *and*
|
||||
the only place pods can run ("Why one node is enough," above). Caddy
|
||||
isn't picking between podinfo/hello-app here at all — it just forwards
|
||||
everything for both hostnames to that one node's port 80, and it's
|
||||
Traefik, once the request lands there, that actually reads the `Host:`
|
||||
header and routes to the right backend. This changes in stage 4, where
|
||||
there are real node IPs to load-balance across (`docs/Caddyfile.example`'s
|
||||
multi-node blocks):
|
||||
|
||||
```
|
||||
podinfo.boglabob.com {
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue