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>
104 lines
4.7 KiB
Markdown
104 lines
4.7 KiB
Markdown
# DriverVault — Docker (multi-container stack)
|
|
|
|
Three containers — **PocketBase**, **API Server**, **Web App** — on one compose
|
|
network. This is the deployment to use unless you specifically want everything
|
|
in a single image; for that see [`../Docker-AIO`](../Docker-AIO).
|
|
|
|
```
|
|
Browser ─► Web App BFF (:8090) ──/api/*──► API Server (:8080) ─► PocketBase (:8070)
|
|
```
|
|
|
|
Only the Web App port is meant to be public. The API Server and the PocketBase
|
|
admin UI are published for convenience and, in the prod file, bound to
|
|
`127.0.0.1` by default.
|
|
|
|
| File | Use |
|
|
|---|---|
|
|
| `docker-compose.yml` | **builds from source** in this repo — for development and local testing |
|
|
| `docker-compose.prod.yml` | **pulls prebuilt images** from the registry — for deployment |
|
|
| `.env.example` / `.env.prod.example` | copy to `.env` for the matching compose file |
|
|
| `pocketbase/` | the PocketBase image (official release binary on alpine) |
|
|
|
|
## Run it
|
|
|
|
```bash
|
|
cd Docker
|
|
cp .env.example .env # then edit — PB_ADMIN_* have no safe defaults
|
|
docker compose up -d --build
|
|
```
|
|
|
|
Production, from the registry:
|
|
|
|
```bash
|
|
cp .env.prod.example .env # then edit
|
|
docker compose -f docker-compose.prod.yml pull
|
|
docker compose -f docker-compose.prod.yml up -d
|
|
```
|
|
|
|
Then: web app on `http://host:8090/`, the API Server's superadmin panel on
|
|
`http://host:8080/`, PocketBase admin on `http://host:8070/_/`.
|
|
|
|
## First boot
|
|
|
|
Both steps are idempotent, so restarts and upgrades are safe:
|
|
|
|
1. **PocketBase** upserts its superuser from `PB_ADMIN_EMAIL` / `PB_ADMIN_PASSWORD`.
|
|
This is the only way to create the first superuser — the REST API cannot
|
|
bootstrap it. The API Server then authenticates with the same credentials.
|
|
2. **The API Server** creates any missing collections and reconciles existing
|
|
ones, then creates the first app `superadmin` from
|
|
`DRIVERVAULT_SUPERADMIN_EMAIL` / `_PASSWORD` if no such user exists. Set
|
|
`PB_BOOTSTRAP=false` to skip once the database is established.
|
|
|
|
No manual `setup-pocketbase.mjs` step is needed here — the server runs the same
|
|
schema reconcile itself.
|
|
|
|
## Volumes
|
|
|
|
| Volume | Holds |
|
|
|---|---|
|
|
| `pb_data` | the PocketBase SQLite database and uploaded files |
|
|
| `api_data` | the `.env` the API Server panel rewrites when a superadmin retargets the PocketBase connection (plugin settings live in `pb_data`, with everything else) |
|
|
|
|
Both default to Docker-managed named volumes. In the prod file, set `PB_DATA` /
|
|
`API_DATA` to absolute host paths for bind mounts instead.
|
|
|
|
> The API Server serves as the unprivileged `app` user, so `/data` has to be
|
|
> writable by it. Its entrypoint arranges that itself: it starts as root, takes
|
|
> ownership of `/data` if `app` does not already hold it, then drops privileges.
|
|
> So a **bind mount** to a root-owned host path needs no manual `chown`, and
|
|
> neither does a **named volume** left over from an image that ran as root. The
|
|
> one case it cannot fix is a container forced to another user (`user:` in
|
|
> compose, `docker run --user`), where the entrypoint has no privileges to
|
|
> `chown` with — prepare the host directory yourself there. PocketBase runs as
|
|
> root, so `PB_DATA` is unaffected either way.
|
|
|
|
Plugin enable-state and global config used to live in a `plugins.json` on this
|
|
volume, which made them the one piece of configuration a lost volume could erase
|
|
without anyone noticing. They are now in PocketBase, backed up with `pb_data`
|
|
like everything else. An existing `plugins.json` is imported automatically on the
|
|
first boot after the upgrade and renamed to `plugins.json.migrated`; keep the
|
|
volume mounted for that boot.
|
|
|
|
## Charger control (OCPP)
|
|
|
|
Chargers in own/proxy mode dial in to `/ocpp/{serial}` **on the API Server
|
|
port**, authenticating with a per-charger control token in an OCPP Basic-auth
|
|
header. A plaintext `ws://` would put that token on the wire in the clear, so
|
|
`OCPP_REQUIRE_TLS` defaults to `true` and non-TLS connections are rejected.
|
|
|
|
This stack serves plain HTTP, so to actually use charger control you need to
|
|
terminate TLS in a reverse proxy in front of it and set `OCPP_PUBLIC_URL` to the
|
|
public `wss://` base (behind a proxy, deriving it from request headers is
|
|
unreliable). `OCPP_REQUIRE_TLS=false` is for trusted networks only. You will
|
|
also need `API_BIND` set so the proxy can reach the port.
|
|
|
|
## Notes
|
|
|
|
- `docker-compose.yml` builds the API Server and Web App from `../API Server`
|
|
and `../Web App`, so run it from this directory with the repo checked out.
|
|
- The Web App's Vue bundle is built with an empty `VITE_API_BASE`, so the
|
|
browser uses same-origin `/api` and the BFF proxies it — no CORS in play.
|
|
- `CORS_ALLOW_ORIGINS` therefore only matters if a browser calls the API Server
|
|
directly. Native mobile apps are not subject to CORS at all.
|