| 1 |
# How Bento releases wam. Lives here rather than in the daemon's config so it is |
| 2 |
# versioned with the code it describes. |
| 3 |
# |
| 4 |
# A service, not an app or a library: wam is run rather than distributed. There |
| 5 |
# is no bundle for a user to download and no crate to publish. |
| 6 |
# |
| 7 |
# wam deploys ITSELF, and that is the deliberate difference from pom. pom hands |
| 8 |
# its artifact to Sando, which gates it and promotes it tier by tier; wam keeps |
| 9 |
# the `[[deploy]]` tables and lets Bento install and restart directly. The two |
| 10 |
# are not disagreeing about what good practice is. They are answering a question |
| 11 |
# about blast radius, and getting different answers: |
| 12 |
# |
| 13 |
# What does a bad deploy cost? For the MNW server it costs paying creators |
| 14 |
# their platform, so it earns burn-in, tiers, migration dry-runs and a |
| 15 |
# rollback horizon. For pom it costs the monitoring, which is how anyone finds |
| 16 |
# out the server broke, so it earns the gates too. For wam it costs an |
| 17 |
# internal ticket list nobody's money or morning depends on -- and the |
| 18 |
# recovery is `install-service.sh`'s own `<dst>.prev` plus a restart. |
| 19 |
# |
| 20 |
# Charging wam the full Sando ceremony would buy a rollback horizon for tickets |
| 21 |
# we could re-sync from the peer, and would cost an afternoon of topology per |
| 22 |
# release path. The ladder is a real cost and it should be spent where a bad |
| 23 |
# deploy is expensive. See wiki `deploy-ceremony-tiers`. |
| 24 |
kind = "service" |
| 25 |
|
| 26 |
# Two arches, two machines, built natively on each: x86_64 on fw13 for the |
| 27 |
# Hetzner box, aarch64 on astra for astra. Same reason pom needs both -- the |
| 28 |
# mesh has a node on each -- and the same reason neither can be built by Sando, |
| 29 |
# whose build::run compiles only on its single configured build host. |
| 30 |
targets = ["linux/x86_64", "linux/aarch64"] |
| 31 |
|
| 32 |
version_path = "Cargo.toml" |
| 33 |
|
| 34 |
# MNW is one .git over the server, sando, multithreaded, pom, wam and more, each |
| 35 |
# versioned separately, so the default `v{version}` names no product in |
| 36 |
# particular here. |
| 37 |
tag_format = "wam-v{version}" |
| 38 |
|
| 39 |
# Both nodes or neither. The mesh syncs tickets between them and the sync |
| 40 |
# protocol is the thing most likely to break across a version boundary, so a |
| 41 |
# release that lands on one node and fails on the other leaves the mesh talking |
| 42 |
# to itself across a version gap. That is exactly the split-mesh failure pom's |
| 43 |
# 0.4.1 release hit. |
| 44 |
require_all_targets = true |
| 45 |
|
| 46 |
# The service hosts. A deploy destination is deliberately NOT a `[[host]]` in |
| 47 |
# the daemon config: a build host is granted build/package, a service host |
| 48 |
# deploy/restart, and neither is granted the other's. |
| 49 |
# |
| 50 |
# install_path is /usr/local/bin/wam on both, which is a move: the running |
| 51 |
# binary is at /opt/wam/wam on Hetzner today, placed there by hand in April. |
| 52 |
# install-service.sh refuses any dst outside /usr/local/bin, and that guard is |
| 53 |
# the only thing bounding a NOPASSWD sudo grant, so the binary moves rather than |
| 54 |
# the guard widening. Both units' ExecStart move with it. |
| 55 |
|
| 56 |
# Hetzner, reached over Tailscale SSH on 22 as root. NOT port 2200: that is what |
| 57 |
# the retired deploy.sh used, and it refuses this machine's key. |
| 58 |
[[deploy]] |
| 59 |
target = "linux/x86_64" |
| 60 |
host = "root@100.120.174.96" |
| 61 |
install_path = "/usr/local/bin/wam" |
| 62 |
service = "wam.service" |
| 63 |
health_url = "http://127.0.0.1:7890/tickets" |
| 64 |
|
| 65 |
# astra, over the tailnet as max. |
| 66 |
[[deploy]] |
| 67 |
target = "linux/aarch64" |
| 68 |
host = "astra" |
| 69 |
install_path = "/usr/local/bin/wam" |
| 70 |
service = "wam.service" |
| 71 |
health_url = "http://127.0.0.1:7890/tickets" |
| 72 |
|