tajniak81andClaude Opus 5
9bd5c523c4
The integration cascade stored its top layer differently from the two below it: org (L2) and user (L3) plugin config lived in PocketBase, in a pluginSettings field, while the global (L1) layer sat in a plugins.json next to the binary. That split was accretion rather than design - the file was the whole store in the v1 MVP, and the per-tenant layers were later built on PocketBase and layered on top of it instead of replacing it. It also cost something real. plugins.json was a second state store with different durability from pb_data: its own volume, its own ownership, its own backup. Losing pb_data is unmissable; losing api_data was silent, which is how "every plugin comes back disabled after a redeploy" happened. L1 now lives in the app_settings collection - one record keyed "global", holding its settings in a pluginSettings field, the same mechanism and the same field name the layers below use. The documents still differ in shape, because only L1 carries enable state and the registration of external plugins, but the storage is no longer a special case. The Manager grows a Store seam (PocketBase in production, file for the import, memory for tests) and, more importantly, a loaded gate. Settings in a database mean the store can be unreachable at boot - a cold stack, or a service account still to be set from the panel. That must not read as "no plugins configured", or the first save would write emptiness over real settings. So until a read succeeds the Manager stays unloaded, every mutation is refused, /api/admin/plugins* answers 503, and a background retry backs off to two minutes. The same gate covers a document that will not parse: it is never replaced by one built from an empty map, which is a stronger guarantee than the .corrupt backup it replaces. Writing to a store also revealed a hole in the previous fix. Classifying a save failure as errPersist was left to each Store, and a store that returned a plain error would fall through to the "saved, but the plugin failed to start" branch and be reported as a 200 - the same silent-success bug through a different door. The Manager now classifies, whatever the Store returns; a test pins it. Upgrades are automatic: on the first boot that finds no settings in the database, an existing plugins.json is imported and renamed to plugins.json.migrated. The import is refused if the store is merely unreachable, or if the file does not parse, so a stale or broken file can never overwrite live settings. /data is still needed - the panel rewrites .env there when it retargets PocketBase - but plugin settings no longer depend on it. 21 tests in internal/plugins cover both stores, including the production path against a fake PocketBase: create-then-update of the singleton, round-trip across a restart, an outage that leaves settings intact, a missing collection reading as not-ready rather than empty, and the import running exactly once. go build, go vet and go test ./... pass. Schema changes are mirrored into scripts/setup-pocketbase.mjs as that file requires. Not verified: no Docker CLI here, so no image was built and the bootstrap of app_settings against a real PocketBase is untested outside the fake. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
85 lines
3.5 KiB
Docker
85 lines
3.5 KiB
Docker
# syntax=docker/dockerfile:1
|
|
|
|
# --- Build stage -------------------------------------------------------------
|
|
# Compile a static Go binary. The Vue panel is pre-built into internal/api/dist
|
|
# and embedded via //go:embed, so no Node toolchain is needed here.
|
|
FROM golang:1.26-alpine3.24 AS build
|
|
|
|
WORKDIR /src
|
|
|
|
# Cache module downloads separately from the source for faster rebuilds.
|
|
COPY go.mod ./
|
|
# go.sum is optional (stdlib-only module today); copy it if present.
|
|
COPY go.su[m] ./
|
|
RUN go mod download
|
|
|
|
COPY . .
|
|
|
|
# CGO_ENABLED=0 produces a static binary that runs on a bare alpine image. The
|
|
# entry point is the cmd/server package.
|
|
RUN CGO_ENABLED=0 GOOS=linux go build -trimpath -ldflags="-s -w" -o /out/api-server ./cmd/server
|
|
|
|
# --- Runtime stage -----------------------------------------------------------
|
|
FROM alpine:3.24
|
|
|
|
# HTTPS calls to PocketBase need CA certificates; tzdata for correct timestamps.
|
|
# su-exec lets the entrypoint fix /data ownership as root and then drop to app.
|
|
RUN apk add --no-cache ca-certificates tzdata su-exec
|
|
|
|
# Run as an unprivileged user.
|
|
RUN addgroup -S app && adduser -S -G app app
|
|
|
|
COPY --from=build /out/api-server /usr/local/bin/api-server
|
|
|
|
# The server writes .env relative to its working directory — the panel rewrites
|
|
# it when a superadmin retargets the PocketBase connection — and reads a legacy
|
|
# plugins.json from there once, to import it into the database. So the working
|
|
# directory must be writable and persistent: hence /data, owned by the
|
|
# unprivileged user and declared as a volume. A fresh named volume inherits this
|
|
# ownership. (Plugin settings themselves live in PocketBase, not here.)
|
|
RUN mkdir -p /data && chown app:app /data
|
|
WORKDIR /data
|
|
VOLUME /data
|
|
|
|
# A fresh named volume inherits /data's ownership, but two common cases do not:
|
|
# a host bind mount (API_DATA=/srv/... in docker-compose.prod.yml) arrives owned
|
|
# by root, and so does a volume created by an image from before /data existed,
|
|
# when the server ran with a root-owned working directory. In both cases the
|
|
# unprivileged process cannot write .env, so retargeting PocketBase from the
|
|
# panel silently fails to stick across a restart. The entrypoint therefore starts
|
|
# as root purely to fix ownership, then drops to app.
|
|
RUN cat > /entrypoint.sh <<'ENTRY'
|
|
#!/bin/sh
|
|
set -e
|
|
if [ "$(id -u)" = "0" ]; then
|
|
mkdir -p /data
|
|
if [ "$(stat -c %U /data 2>/dev/null)" != "app" ]; then
|
|
echo "entrypoint: taking ownership of /data"
|
|
chown -R app:app /data
|
|
fi
|
|
exec su-exec app "$@"
|
|
fi
|
|
# Already unprivileged (docker run --user ...): nothing to drop, just run.
|
|
exec "$@"
|
|
ENTRY
|
|
RUN chmod +x /entrypoint.sh
|
|
|
|
# Config comes entirely from environment variables (see .env.example).
|
|
# POCKETBASE_ADMIN_EMAIL / _PASSWORD are optional at startup: without them the
|
|
# server still runs and a superadmin can configure the connection from the panel.
|
|
# PLUGINS_FILE is only the one-time import path for a pre-PocketBase install;
|
|
# the settings themselves live in the database.
|
|
ENV API_ADDR=:8080 \
|
|
PLUGINS_FILE=/data/plugins.json
|
|
EXPOSE 8080
|
|
|
|
# Liveness only: /healthz answers 200 as soon as the process is serving, and
|
|
# does not depend on PocketBase, so a database outage does not mark the
|
|
# container unhealthy. Lets compose gate dependants on condition: service_healthy.
|
|
HEALTHCHECK --interval=30s --timeout=5s --start-period=20s --retries=3 \
|
|
CMD wget -qO- http://127.0.0.1:8080/healthz >/dev/null 2>&1 || exit 1
|
|
|
|
# The entrypoint drops to the unprivileged app user after fixing /data.
|
|
ENTRYPOINT ["/entrypoint.sh"]
|
|
CMD ["/usr/local/bin/api-server"]
|