一、目标架构
部署一个具备以下能力的自动化系统：
- Docker Compose 部署
- PostgreSQL 数据库
- 反向代理 + HTTPS
- 自定义域名访问
- 与本地 LLM 服务互通
- 数据持久化
- 支持未来扩展
整体逻辑结构如下：
浏览器
↓
HTTPS 反向代理
↓
主机端口映射
↓
n8n 容器
↓
PostgreSQL 容器
并额外接入：
n8n 容器
↓
Docker 外部网络
↓
LLM 容器
二、数据库初始化陷阱
问题表现
- 修改数据库密码后启动失败
- 日志提示数据库目录已存在
- 认证错误
原因
PostgreSQL 在首次启动时会根据环境变量初始化数据库。
之后即使修改密码，容器也不会重新初始化。
解决方式
删除数据库数据卷后重新启动。
关键原则：
数据库初始化仅进行一次。
三、数据库角色冲突问题
错误示例：
role already exists
产生原因：
- 管理员用户与应用用户设置为同一名称
- 初始化脚本重复创建角色
正确结构：
- 一个 root 初始化用户
- 一个应用专用用户
两者必须分离。
四、反向代理导致的两个典型问题
1️⃣ 邀请链接错误指向 localhost
现象：
新用户邀请链接使用 localhost
原因：
未正确设置外部访问环境变量。
必须显式配置：
- 主机名
- 协议
- Webhook 基址
- 编辑器基址
否则系统默认生成本地地址。
2️⃣ X-Forwarded-For 报错
日志示例：
The 'X-Forwarded-For' header is set but trust proxy is false
原因：
反向代理转发了客户端 IP
但应用未信任代理
解决方式：
设置 trusted proxies。
是否可以忽略？
- 个人使用可以暂时忽略
- 生产环境不建议忽略
五、浏览器安全提示差异
现象：
- 多数浏览器访问正常
- 某旧版本浏览器提示“危险网站”
分析：
- 证书有效
- HTTPS 正常
- 其他浏览器无异常
结论：
多半为浏览器本地安全数据库或版本问题。
更新浏览器即可解决。
六、容器间网络通信（LLM 接入）
LLM 服务运行在独立 Docker 网络中。
为使自动化系统访问 LLM：
- 将自动化容器加入该网络
- 声明为 external 网络
- 通过容器名访问
无需暴露额外公网端口。
七、Python Task Runner 警告
日志提示：
Failed to start Python task runner
说明：
- 容器中未安装 Python
- 内部调试 runner 启动失败
影响：
- 不影响核心功能
- JS runner 正常运行
生产环境推荐 external runner。
八、健康部署判断标准
系统正常应满足：
- 数据库 healthy
- Migration 全部完成
- 无认证错误
- HTTPS 正常
- 邀请链接不再使用 localhost
- 容器网络互通
九、架构思考
本次部署暴露出三个重要原则：
1️⃣ 容器初始化不可逆
数据库环境变量仅在首次启动生效。
2️⃣ 反向代理必须显式信任
现代 Web 框架默认不信任代理头。
3️⃣ 预留扩展空间，但避免过度工程化
- 外部网络能力
- Worker 扩展能力
- LLM 接入能力
提前预留，但不提前复杂化。
十、最终系统特征
当前系统具备：
- HTTPS 访问
- 独立数据库
- 反向代理隔离
- LLM 可接入
- 数据持久化
- 可横向扩展
属于稳定、可长期运行架构。