95 lines
2.5 KiB
Markdown
95 lines
2.5 KiB
Markdown
# Rollback
|
|
|
|
## Purpose
|
|
|
|
This document describes a low-risk rollback procedure for the first-stage production deployment.
|
|
|
|
## Principles
|
|
|
|
- do not delete PostgreSQL or Redis volumes during rollback;
|
|
- do not remove `.env.production`;
|
|
- prefer switching containers back to the last known-good image or revision;
|
|
- avoid ad-hoc schema downgrades during an incident;
|
|
- verify `/health` and login before declaring rollback complete.
|
|
|
|
## Safe Rollback Procedure
|
|
|
|
1. Identify the currently running revision and the last known-good revision.
|
|
2. Keep a copy of the current environment file:
|
|
|
|
```bash
|
|
cp .env.production .env.production.backup
|
|
```
|
|
|
|
3. If the issue is configuration-only, restore the previous config file versions first:
|
|
- `.env.production`
|
|
- `deploy/nginx/server-panel.conf`
|
|
- `docker-compose.prod.yml`
|
|
|
|
4. Switch the repository back to the last known-good revision.
|
|
5. Rebuild and restart the production stack without touching volumes:
|
|
|
|
```bash
|
|
docker compose \
|
|
--env-file .env.production \
|
|
-f docker-compose.prod.yml \
|
|
up --build -d
|
|
```
|
|
|
|
6. If the rollback target expects the same additive schema, keep the migrated database in place. If a future revision introduces incompatible schema changes, restore from a database backup instead of attempting an emergency manual downgrade.
|
|
7. Verify:
|
|
- `http://YOUR_HOST/health`
|
|
- frontend load at `/`
|
|
- admin login
|
|
- one read-only API flow
|
|
|
|
## If The New Frontend Is The Only Problem
|
|
|
|
If the backend is healthy and only the frontend is broken:
|
|
|
|
1. restore the previous frontend source or image tag;
|
|
2. rebuild only the frontend and reverse proxy path:
|
|
|
|
```bash
|
|
docker compose \
|
|
--env-file .env.production \
|
|
-f docker-compose.prod.yml \
|
|
up --build -d frontend reverse-proxy
|
|
```
|
|
|
|
3. re-check `/` and one authenticated UI action.
|
|
|
|
## If The Backend Or Worker Is The Problem
|
|
|
|
1. restore the previous backend revision;
|
|
2. rebuild:
|
|
|
|
```bash
|
|
docker compose \
|
|
--env-file .env.production \
|
|
-f docker-compose.prod.yml \
|
|
up --build -d backend worker bot reverse-proxy
|
|
```
|
|
|
|
3. verify:
|
|
- `/health`
|
|
- login
|
|
- queued action processing
|
|
|
|
## Do Not Do This During Rollback
|
|
|
|
- do not run `docker compose down -v`;
|
|
- do not remove `postgres_data`;
|
|
- do not remove `redis_data`;
|
|
- do not delete the database to "start clean";
|
|
- do not improvise manual `ALTER TABLE` rollback steps on production data.
|
|
|
|
## After Rollback
|
|
|
|
Capture:
|
|
|
|
- what failed;
|
|
- which revision was restored;
|
|
- whether any queued actions need manual follow-up;
|
|
- whether the reverse proxy or environment template needs a corrective update before the next deployment.
|