silentmode/prometheus
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
prometheus/deploy/prometheus-snapshot.service

21 lines
1.1 KiB
SYSTEMD
Raw Normal View History

prometheus: weekly s3 snapshot of the browse surface to bns/prometheus scripts/snapshot.mjs renders every public page (home, browse, publish, boundaries, 8 categories, every active listing) to <out>/<path>/index.html, plus /sitemap.xml, /robots.txt, and the two static assets. Writing to a directory next to the service AND uploading via `aws s3 sync` are two flags on the same command: --out to pick the directory, --upload to push. Live routes added for /sitemap.xml and /robots.txt so a crawler hitting the live service sees the same enumeration the snapshot bakes into the bucket. renderSitemap / renderRobots in service/seo.js are the single rendering path both call sites use. Scope deliberately limited to the browse surface — /submit and the API routes depend on the live backend and were never going to work on a static mirror. The browse surface IS what the fallback is for: readers survive an outage, publishers can't. systemd unit + timer under deploy/ run the snapshot weekly on Sunday 04:00 UTC with 30 min jitter and Persistent=yes so a missed run after a reboot catches up. Unit uses the sia-storage AWS profile per [[sia-storage-credentials-location]] and the per-process endpoint URL baked in via Environment=. Local dry-run against an empty DB produced 14 HTML files + sitemap + robots + the two assets.
2026-10-08 21:42:54 +02:00
[Unit]
Description=Prometheus — render + upload the static snapshot to bns/prometheus
prometheus: rework snapshot timer unit for the docker deploy The .service unit assumed a native systemd install (ExecStart=/usr/bin/node /opt/prometheus/scripts/snapshot.mjs --upload) that does not match how the service actually runs on p2pexchange — it is a docker-compose sibling of Hephaestus's Caddy stack, not a user=prometheus host process. Two phases now: 1. docker exec into the running prometheus container, render the static mirror into /data/build (which is in the container's data volume on the host at /var/lib/docker/volumes/prometheus_data/_data/build). 2. On the host, aws --profile sia-storage s3 sync that directory to bns/prometheus/, using the operator's existing sia-storage credentials per [[sia-storage-credentials-location]]. Keeping aws CLI out of the service image is a deliberate trade — adding it would bloat the image by ~100 MB for a once-a-week job the host is already set up to run. Not yet installed on the VPS. To enable: install -m644 ~/prometheus/deploy/prometheus-snapshot.{service,timer} \ /etc/systemd/system/ systemctl daemon-reload systemctl enable --now prometheus-snapshot.timer
2026-10-11 00:58:53 +02:00
After=docker.service network-online.target
prometheus: weekly s3 snapshot of the browse surface to bns/prometheus scripts/snapshot.mjs renders every public page (home, browse, publish, boundaries, 8 categories, every active listing) to <out>/<path>/index.html, plus /sitemap.xml, /robots.txt, and the two static assets. Writing to a directory next to the service AND uploading via `aws s3 sync` are two flags on the same command: --out to pick the directory, --upload to push. Live routes added for /sitemap.xml and /robots.txt so a crawler hitting the live service sees the same enumeration the snapshot bakes into the bucket. renderSitemap / renderRobots in service/seo.js are the single rendering path both call sites use. Scope deliberately limited to the browse surface — /submit and the API routes depend on the live backend and were never going to work on a static mirror. The browse surface IS what the fallback is for: readers survive an outage, publishers can't. systemd unit + timer under deploy/ run the snapshot weekly on Sunday 04:00 UTC with 30 min jitter and Persistent=yes so a missed run after a reboot catches up. Unit uses the sia-storage AWS profile per [[sia-storage-credentials-location]] and the per-process endpoint URL baked in via Environment=. Local dry-run against an empty DB produced 14 HTML files + sitemap + robots + the two assets.
2026-10-08 21:42:54 +02:00
Wants=network-online.target
prometheus: rework snapshot timer unit for the docker deploy The .service unit assumed a native systemd install (ExecStart=/usr/bin/node /opt/prometheus/scripts/snapshot.mjs --upload) that does not match how the service actually runs on p2pexchange — it is a docker-compose sibling of Hephaestus's Caddy stack, not a user=prometheus host process. Two phases now: 1. docker exec into the running prometheus container, render the static mirror into /data/build (which is in the container's data volume on the host at /var/lib/docker/volumes/prometheus_data/_data/build). 2. On the host, aws --profile sia-storage s3 sync that directory to bns/prometheus/, using the operator's existing sia-storage credentials per [[sia-storage-credentials-location]]. Keeping aws CLI out of the service image is a deliberate trade — adding it would bloat the image by ~100 MB for a once-a-week job the host is already set up to run. Not yet installed on the VPS. To enable: install -m644 ~/prometheus/deploy/prometheus-snapshot.{service,timer} \ /etc/systemd/system/ systemctl daemon-reload systemctl enable --now prometheus-snapshot.timer
2026-10-11 00:58:53 +02:00
Requires=docker.service
prometheus: weekly s3 snapshot of the browse surface to bns/prometheus scripts/snapshot.mjs renders every public page (home, browse, publish, boundaries, 8 categories, every active listing) to <out>/<path>/index.html, plus /sitemap.xml, /robots.txt, and the two static assets. Writing to a directory next to the service AND uploading via `aws s3 sync` are two flags on the same command: --out to pick the directory, --upload to push. Live routes added for /sitemap.xml and /robots.txt so a crawler hitting the live service sees the same enumeration the snapshot bakes into the bucket. renderSitemap / renderRobots in service/seo.js are the single rendering path both call sites use. Scope deliberately limited to the browse surface — /submit and the API routes depend on the live backend and were never going to work on a static mirror. The browse surface IS what the fallback is for: readers survive an outage, publishers can't. systemd unit + timer under deploy/ run the snapshot weekly on Sunday 04:00 UTC with 30 min jitter and Persistent=yes so a missed run after a reboot catches up. Unit uses the sia-storage AWS profile per [[sia-storage-credentials-location]] and the per-process endpoint URL baked in via Environment=. Local dry-run against an empty DB produced 14 HTML files + sitemap + robots + the two assets.
2026-10-08 21:42:54 +02:00
[Service]
Type=oneshot
prometheus: rework snapshot timer unit for the docker deploy The .service unit assumed a native systemd install (ExecStart=/usr/bin/node /opt/prometheus/scripts/snapshot.mjs --upload) that does not match how the service actually runs on p2pexchange — it is a docker-compose sibling of Hephaestus's Caddy stack, not a user=prometheus host process. Two phases now: 1. docker exec into the running prometheus container, render the static mirror into /data/build (which is in the container's data volume on the host at /var/lib/docker/volumes/prometheus_data/_data/build). 2. On the host, aws --profile sia-storage s3 sync that directory to bns/prometheus/, using the operator's existing sia-storage credentials per [[sia-storage-credentials-location]]. Keeping aws CLI out of the service image is a deliberate trade — adding it would bloat the image by ~100 MB for a once-a-week job the host is already set up to run. Not yet installed on the VPS. To enable: install -m644 ~/prometheus/deploy/prometheus-snapshot.{service,timer} \ /etc/systemd/system/ systemctl daemon-reload systemctl enable --now prometheus-snapshot.timer
2026-10-11 00:58:53 +02:00
# Two phases:
# 1. Render inside the prometheus container — it already has the DB, the
# Node service's imports, and the right USER. --upload is deliberately
# NOT passed; the aws CLI is not installed in the container (adding it
# bloats the image by ~100 MB for a once-a-week job).
# 2. Upload from the host, using root's existing sia-storage AWS profile
# per [[sia-storage-credentials-location]]. The docker-named volume
# mounts at /var/lib/docker/volumes/prometheus_data/_data; the build
# dir inside it is what the container just wrote.
ExecStart=/usr/bin/docker exec prometheus-prometheus-1 node scripts/snapshot.mjs --out /data/build
ExecStart=/usr/bin/aws --profile sia-storage --endpoint-url https://p2pexchange.silentmode.st:9980 s3 sync /var/lib/docker/volumes/prometheus_data/_data/build/ s3://bns/prometheus/ --delete
prometheus: weekly s3 snapshot of the browse surface to bns/prometheus scripts/snapshot.mjs renders every public page (home, browse, publish, boundaries, 8 categories, every active listing) to <out>/<path>/index.html, plus /sitemap.xml, /robots.txt, and the two static assets. Writing to a directory next to the service AND uploading via `aws s3 sync` are two flags on the same command: --out to pick the directory, --upload to push. Live routes added for /sitemap.xml and /robots.txt so a crawler hitting the live service sees the same enumeration the snapshot bakes into the bucket. renderSitemap / renderRobots in service/seo.js are the single rendering path both call sites use. Scope deliberately limited to the browse surface — /submit and the API routes depend on the live backend and were never going to work on a static mirror. The browse surface IS what the fallback is for: readers survive an outage, publishers can't. systemd unit + timer under deploy/ run the snapshot weekly on Sunday 04:00 UTC with 30 min jitter and Persistent=yes so a missed run after a reboot catches up. Unit uses the sia-storage AWS profile per [[sia-storage-credentials-location]] and the per-process endpoint URL baked in via Environment=. Local dry-run against an empty DB produced 14 HTML files + sitemap + robots + the two assets.
2026-10-08 21:42:54 +02:00
Nice=10
Reference in a new issue Copy permalink