Keel-Linux/tracker
1
0
Fork 0
Code Issues 49 Pull requests Projects Releases Packages Wiki Activity Actions

0044: Keel Web in the cloud #49

New issue
Open
opened 2026-10-02 00:06:51 -03:00 by marcos-mendez · 0 comments
marcos-mendez commented 2026-10-02 00:06:51 -03:00 (Migrated from github.com)
Copy link

Decision (maintainer, 2026-10-02). Public traffic to Keel Web in the cloud modes: DNS with a health check is the primary mechanism (0020), with a low TTL; some resolvers ignore low TTLs, and that is stated. The second mechanism is an edge node: a rendezvous point with a fixed address that receives public traffic and forwards it over the mesh to the live Keel Web nodes, with VRRP between edge nodes, which share a network in one datacenter. VRRP with a floating public address between Keel Web nodes is low priority (IPv4 scarcity, same physical network needed). The WireGuard VIP of 0029 is mesh internal and never public. Load balancing in front of applications is 0042's; in front of Keel Web nodes it is DNS with a health check plus VRRP at the edge. Keel Web gets a role in the cloud modes (active and standby, or N active), and its sites and certificates replicate across nodes over the mesh.

Handbook: docs/decisions/0044-keel-web-in-the-cloud.md (handbook#38)

Amends: 0020 (DNS service becomes Keel DNS, keepalived used at the edge, Keel Web's own role), 0024 (rendezvous points may be edge nodes), 0028 (a Keel Web role in the cloud modes), 0029 (the VIP restated as mesh internal).

Open questions (recommendations in the note)

  • Default role: N active recommended, active and standby as the operator's choice
  • Spec fields: web.cluster.mode and web.cluster.role; on an appliance with a database, the web role follows the elected database role
  • How the web section reaches other nodes: etcd in cloud advanced, pull from the first node in cloud simple
  • Certificate issuer: one per set, DNS-01 through Keel DNS by RFC 2136
  • Edge node: Keel Web with only passthrough sites plus a vrrp overlay
  • Health check target for DNS: port 443 by default, an optional public health path per site

First tasks

  • Spec fields for the Keel Web role, and the web section shared across a set (cloud simple, by pull)
  • Certificates replicated as shared secrets (0041), with deploy.d reload on every node
  • Edge node: passthrough sites to an upstream group of Keel Web nodes, PROXY protocol, vrrp overlay (keepalived 1:2.3.3-1)
  • Phase 5: the web section through etcd in cloud advanced
**Decision (maintainer, 2026-10-02).** Public traffic to Keel Web in the cloud modes: DNS with a health check is the primary mechanism (0020), with a low TTL; some resolvers ignore low TTLs, and that is stated. The second mechanism is an edge node: a rendezvous point with a fixed address that receives public traffic and forwards it over the mesh to the live Keel Web nodes, with VRRP between edge nodes, which share a network in one datacenter. VRRP with a floating public address between Keel Web nodes is low priority (IPv4 scarcity, same physical network needed). The WireGuard VIP of 0029 is mesh internal and never public. Load balancing in front of applications is 0042's; in front of Keel Web nodes it is DNS with a health check plus VRRP at the edge. Keel Web gets a role in the cloud modes (active and standby, or N active), and its sites and certificates replicate across nodes over the mesh. **Handbook:** `docs/decisions/0044-keel-web-in-the-cloud.md` (handbook#38) **Amends:** 0020 (DNS service becomes Keel DNS, keepalived used at the edge, Keel Web's own role), 0024 (rendezvous points may be edge nodes), 0028 (a Keel Web role in the cloud modes), 0029 (the VIP restated as mesh internal). **Open questions** (recommendations in the note) - [ ] Default role: N active recommended, active and standby as the operator's choice - [ ] Spec fields: `web.cluster.mode` and `web.cluster.role`; on an appliance with a database, the web role follows the elected database role - [ ] How the `web` section reaches other nodes: etcd in cloud advanced, pull from the first node in cloud simple - [ ] Certificate issuer: one per set, DNS-01 through Keel DNS by RFC 2136 - [ ] Edge node: Keel Web with only passthrough sites plus a `vrrp` overlay - [ ] Health check target for DNS: port 443 by default, an optional public health path per site **First tasks** - [ ] Spec fields for the Keel Web role, and the `web` section shared across a set (cloud simple, by pull) - [ ] Certificates replicated as shared secrets (0041), with `deploy.d` reload on every node - [ ] Edge node: passthrough sites to an upstream group of Keel Web nodes, PROXY protocol, `vrrp` overlay (keepalived 1:2.3.3-1) - [ ] Phase 5: the `web` section through etcd in cloud advanced
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
No results found.
Labels
Clear labels   
accessibility

Barrier affecting people with disabilities

  
bug

Something isn't working

  
documentation

Improvements or additions to documentation

  
duplicate

This issue or pull request already exists

  
enhancement

New feature or request

  
good first issue

Good for newcomers

  
help wanted

Extra attention is needed

  
invalid

This doesn't seem right

  
question

Further information is requested

  
wontfix

This will not be worked on

No labels
accessibility
bug
documentation
duplicate
enhancement
good first issue
help wanted
invalid
question
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Keel-Linux/tracker#49
No description provided.