bermudalamb
0cec9b3c1f
Step 7 listed a missing `ADMIN_GATE_SECRET` — a warning the container starts through — and said nothing about the three PayPal secrets, which are a hard error that crash-loops it. That is backwards: the secrets are the likeliest thing to be missing after a stack replacement, because Portainer stack variables belong to the stack and are discarded with it, and `DEMO_MODE` is false in production so the app refuses to start without them. Hit for real following the runbook. The verify section now shows the actual log block, says what it means, and gives the way to tell a missing variable from a misnamed one: a hardcoded value cannot be missing, so its absence from the error list proves nothing, while an interpolated variable that stays quiet while others complain proves substitution works and those others are simply unset. That is the reading that turns the log into a diagnosis instead of a list. It also says the loop is harmless while the values are fetched — the container refuses before it serves anything or touches data — and where the values live if the old stack is already gone, since the webhook id in particular is readable rather than only recreatable. Step 2 now names every interpolated variable rather than describing them in general, and states the consequence of each class going missing. A general instruction to record the environment is easy to read as already done.
227 lines
13 KiB
Markdown
227 lines
13 KiB
Markdown
# Cutting production over to the committed compose file
|
|
|
|
A one-time migration: production stops running from a stack definition that exists only in Portainer's web editor and starts running from `docker-compose.prod.yml` in this repository, deployed as a git repository stack.
|
|
|
|
This is not the routine deploy. For promoting a reviewed change to a stack that is already in this form, use [Promoting a reviewed change to production](../../README.md#promoting-a-reviewed-change-to-production) instead. Do that one often; do this one once.
|
|
|
|
## What this actually changes
|
|
|
|
Nothing about how production runs. Same image, same containers, same data, same port, same proxy in front of it. What changes is where the definition lives, and therefore whether anything can check it — `backend/tests/unit/composeEnvironment.test.ts` reads every compose file in this repository and hands its environment to the real validator. A stack in the web editor is invisible to that. On 2026-08-23 production refused to boot because `UPLOADS_DIR` had no line in it, and no test could have caught that. See #118.
|
|
|
|
After the cutover, changing production means changing this file and merging it.
|
|
|
|
## The two facts that decide whether this is safe
|
|
|
|
**Your data is not in Docker.** Both services bind-mount from the NAS filesystem:
|
|
|
|
```
|
|
/volume1/configs/redefined-designs/postgres → the database
|
|
/volume1/configs/redefined-designs/uploads → product images
|
|
```
|
|
|
|
Those are paths on the NAS, not named Docker volumes. Deleting the stack removes containers; it does not touch either directory. This is why the cutover is recoverable at all — but step 2 verifies it rather than trusting it, because the whole procedure rests on it being true of the stack you have *now*.
|
|
|
|
**Container names are fixed.** `redefined-designs-syn` and `redefined-designs-db-syn` are set explicitly in the compose file, so two stacks cannot hold them at once. The old stack must be gone before the new one comes up, or the deploy fails with a name collision that reads like a Portainer bug rather than a sequencing mistake.
|
|
|
|
## Before you start
|
|
|
|
Production will be down for the length of this, which is a few minutes if nothing surprises you. Pick a time when that is fine.
|
|
|
|
You need SSH to the NAS and Portainer access.
|
|
|
|
Read [backup-and-restore.md](backup-and-restore.md) first if you have not. The scheduled backups in the compose file do **not** cover this operation — they run while the stack runs, so they cannot cover a deploy that recreates it.
|
|
|
|
---
|
|
|
|
## 1. Back up
|
|
|
|
Not optional, and not the nightly dump. This is the one deploy that recreates everything, so take a backup that is seconds old rather than up to a day old.
|
|
|
|
```bash
|
|
# Database
|
|
sudo docker exec -t redefined-designs-db-syn pg_dump -U redefined -d redefined \
|
|
> /volume1/configs/redefined-designs/cutover-$(date +%Y%m%d-%H%M).sql
|
|
ls -lh /volume1/configs/redefined-designs/cutover-*.sql
|
|
```
|
|
|
|
The size must be plausible — a dump of a few kilobytes means it dumped an empty database and you should stop and find out why before going further.
|
|
|
|
```bash
|
|
# Uploads
|
|
sudo tar -czf /volume1/configs/redefined-designs/cutover-uploads-$(date +%Y%m%d-%H%M).tar.gz \
|
|
-C /volume1/configs/redefined-designs uploads
|
|
```
|
|
|
|
Copy both somewhere that is not `/volume1`. A backup on the same disk as the thing it protects is a convenience, not a backup.
|
|
|
|
## 2. Record what exists today
|
|
|
|
Everything here is lost when the stack is deleted, and the rollback in step 8 is only credible if you have it. Write it down somewhere outside Portainer.
|
|
|
|
**The stack name**, exactly as Portainer shows it. If it is not `redefined-designs`, note that — the new stack must be created with that name, because the stack name becomes the compose project name and reusing QA's would make Compose reconcile the two against each other.
|
|
|
|
**Every stack environment variable, name and value.** These are all secrets, they belong to the stack, and deleting it discards them. This is the step whose omission is felt hardest: the compose file interpolates `DB_PASSWORD`, `SMTP_USER`, `SMTP_PASSWORD`, `SMTP_FROM`, `ADMIN_GATE_SECRET`, `PAYPAL_CLIENT_ID`, `PAYPAL_CLIENT_SECRET` and `PAYPAL_WEBHOOK_ID`, and an unset one substitutes to an empty string rather than failing. A missing `DB_PASSWORD` cannot authenticate against its own data directory; a missing PayPal secret crash-loops the container, because `DEMO_MODE` is false here and the app refuses to pretend it can take payments. Neither is recoverable from anything in this repository.
|
|
|
|
Copy them somewhere before you delete anything.
|
|
|
|
**The image the app container is running:**
|
|
|
|
```bash
|
|
sudo docker inspect --format '{{.Config.Image}}' redefined-designs-syn
|
|
sudo docker images | grep redefined-designs
|
|
```
|
|
|
|
**The mounts** — this is the verification that the whole procedure rests on:
|
|
|
|
```bash
|
|
sudo docker inspect --format '{{range .Mounts}}{{.Type}} {{.Source}} -> {{.Destination}}{{"\n"}}{{end}}' \
|
|
redefined-designs-db-syn redefined-designs-syn
|
|
```
|
|
|
|
Every line must say `bind`, and the sources must be under `/volume1/configs/redefined-designs`. If any line says `volume`, **stop**. Your data is in a Docker-managed volume that stack deletion may remove, and this runbook does not cover that case — you would need to migrate that volume onto the bind-mount path first.
|
|
|
|
**A record of what is in the database**, so step 7 can prove nothing was lost:
|
|
|
|
```bash
|
|
sudo docker exec -it redefined-designs-db-syn psql -U redefined -d redefined \
|
|
-c "SELECT count(*) FROM items;" \
|
|
-c "SELECT count(*) FROM customers;" \
|
|
-c "SELECT name, run_on FROM pgmigrations ORDER BY run_on DESC LIMIT 3;"
|
|
```
|
|
|
|
## 3. Reconcile the variable names
|
|
|
|
`docker-compose.prod.yml` reads a specific set of names. The authoritative list is in the header comment of that file, under "Required stack environment variables". If the stack you recorded in step 2 uses different names for any of them, the new stack must use the names the file reads.
|
|
|
|
This matters more than it looks. Portainer's stack variables are substituted into the compose file as `${VAR}`; they are not handed to the container. A variable whose name does not match anything in the file is silently substituted nowhere, and the failure reads as "I set it and the app says it is not set".
|
|
|
|
Write out the mapping now, while the old stack still exists to check against.
|
|
|
|
## 4. Make sure the image exists
|
|
|
|
The new stack has no `build:`. It runs `redefined-designs:latest`, which must already be on the NAS, or the deploy fails with "image not found" rather than quietly building one (#146).
|
|
|
|
```bash
|
|
sudo docker images | grep 'redefined-designs.*latest'
|
|
```
|
|
|
|
If it is missing, or if you want production to run the image QA reviewed rather than whatever `latest` currently points at:
|
|
|
|
```bash
|
|
sudo docker tag redefined-designs:qa redefined-designs:latest
|
|
sudo docker inspect --format '{{.Config.Cmd}}' redefined-designs:latest
|
|
# must print: [sh -c node migrate.js up && node dist/server.js]
|
|
```
|
|
|
|
That `Cmd` check is worth doing. It is what makes the container migrate before serving, so deployed code can never be ahead of the schema.
|
|
|
|
## 5. Remove the old stack
|
|
|
|
In Portainer: **Stacks → the stack from step 2 → Delete**.
|
|
|
|
This removes the containers. It does not remove `/volume1/configs/redefined-designs/postgres` or `.../uploads`, which you verified as bind mounts in step 2.
|
|
|
|
Confirm the names are actually free, because the next step fails on a collision:
|
|
|
|
```bash
|
|
sudo docker ps -a | grep redefined-designs
|
|
```
|
|
|
|
Anything still listed for production must be removed before continuing:
|
|
|
|
```bash
|
|
sudo docker rm -f redefined-designs-syn redefined-designs-db-syn
|
|
```
|
|
|
|
Leave QA's containers alone — they are `redefined-designs-qa-*` and are a different stack.
|
|
|
|
## 6. Create the git repository stack
|
|
|
|
Portainer: **Stacks → Add stack → Repository**.
|
|
|
|
| Field | Value |
|
|
| --- | --- |
|
|
| Name | `redefined-designs` — not `redefined-designs-qa` |
|
|
| Build method | Repository |
|
|
| Repository URL | `https://gitea.bermudalamb.synology.me/bermudalamb/redefined-designs` |
|
|
| Reference | `refs/heads/main` |
|
|
| Compose path | `docker-compose.prod.yml` |
|
|
|
|
Add the environment variables from steps 2 and 3, under the names the compose file reads.
|
|
|
|
**Leave any "pull latest image" or re-pull option OFF.** There is no registry to pull this image from; it exists only on the NAS. Turning it on makes a present image report itself as a registry authentication failure.
|
|
|
|
Deploy the stack.
|
|
|
|
## 7. Verify
|
|
|
|
In this order. Each step answers a different question, and the later ones are meaningless if an earlier one failed.
|
|
|
|
```bash
|
|
# Did it start, and start once?
|
|
sudo docker logs redefined-designs-syn | head -40
|
|
```
|
|
|
|
Migration output must appear *before* `listening on 3000`, and `listening on 3000` must appear exactly once. Repeats mean a crash loop.
|
|
|
|
**Expected warnings.** These are correct and must not be silenced:
|
|
|
|
- `MAIL_ALLOWLIST is not set` — production is the one environment that has to reach real customers.
|
|
- `UPLOADS_BASE_URL is not set` — the uploads origin is not configured yet (#103). Expected until an NPM host exists for it.
|
|
|
|
**What a crash loop looks like, and it is the likeliest outcome of a missed step 2.** A `[config] refusing to start` block, then the whole boot sequence again, repeating:
|
|
|
|
```
|
|
[config] refusing to start — 3 problem(s) with the environment:
|
|
[config] - PAYPAL_CLIENT_ID is required when DEMO_MODE=false, because real payments are enabled.
|
|
[config] - PAYPAL_CLIENT_SECRET is required when DEMO_MODE=false, because real payments are enabled.
|
|
[config] - PAYPAL_WEBHOOK_ID is required when DEMO_MODE=false, because real payments are enabled.
|
|
```
|
|
|
|
That is a secret that did not reach the container, and it is what happens when the stack variables recorded in step 2 were not carried across — they belong to the stack and were discarded with the old one. An unset stack variable substitutes to an empty string rather than failing, so the container receives `PAYPAL_CLIENT_ID=` and refuses it.
|
|
|
|
Read the list against the compose file to tell a missing variable from a misnamed one. Anything hardcoded there — `PAYPAL_ENV`, `DEMO_MODE`, `UPLOADS_DIR` — cannot be missing, so its absence from the error list proves nothing. What is diagnostic is an *interpolated* variable that is NOT in the list: if `ADMIN_GATE_SECRET` is quiet while the PayPal three complain, substitution is working and those three specifically are unset, rather than something being wrong with the stack.
|
|
|
|
Fix it in the stack's environment, under exactly the names the compose file reads, and redeploy. If the values are gone with the old stack, the client id and secret are in the PayPal developer dashboard under the live app, and the webhook id is on the webhook entry for `PUBLIC_URL/webhooks/paypal` — readable rather than only recreatable.
|
|
|
|
The loop is harmless while you fetch them. The container refuses before it serves anything and before it touches data. The site is down, which is the cost, and nothing is being damaged.
|
|
|
|
**Warnings that mean something is wrong:**
|
|
|
|
- `ADMIN_GATE_SECRET is not set` — a warning rather than an error, so the container starts. The admin API is then protected only by the proxy. Same cause as above: a variable that did not reach the container.
|
|
- Any other `[config]` error, which stops the container rather than warning.
|
|
|
|
```bash
|
|
# Is the data the same data?
|
|
sudo docker exec -it redefined-designs-db-syn psql -U redefined -d redefined \
|
|
-c "SELECT count(*) FROM items;" \
|
|
-c "SELECT count(*) FROM customers;" \
|
|
-c "SELECT name, run_on FROM pgmigrations ORDER BY run_on DESC LIMIT 3;"
|
|
```
|
|
|
|
The counts must match what you recorded in step 2. If they are zero, the container came up against a fresh data directory rather than the existing one — stop, and check the mount paths before doing anything else.
|
|
|
|
```bash
|
|
# Are the images still served?
|
|
sudo docker exec redefined-designs-syn ls /app/uploads | head
|
|
```
|
|
|
|
Then load the storefront in a **private window** — aggressive bundle caching on this project has produced false "still broken" reports after correct deploys. Check that product images render, sign in, and open `/admin` to confirm authentik and the admin gate still agree.
|
|
|
|
## 8. If it goes wrong
|
|
|
|
Nothing has been destroyed. The data directories were never touched, and you recorded the old definition in step 2.
|
|
|
|
Delete the new stack, recreate the old one from that record with its original variables, and deploy it. Production comes back on the same data.
|
|
|
|
Restoring the step 1 dump is a last resort, not a first move — reach for it only if the database itself is damaged, and follow [backup-and-restore.md](backup-and-restore.md).
|
|
|
|
## After
|
|
|
|
The compose file in this repository is now what production runs. Changing it means changing it here and merging, and `composeEnvironment.test.ts` checks it on every push.
|
|
|
|
Two things worth doing while you are in there:
|
|
|
|
- Confirm `ADMIN_GATE_SECRET` is genuinely set, rather than assumed. It is the application-layer half of the admin boundary (#63), and the boot log tells you plainly.
|
|
- Portainer will now show the stack as out of date when `main` moves. That is the point, but note that redeploying from git does **not** repull or rebuild the image — promoting a new image is still the separate, deliberate step the README documents.
|