Compose、容器面板与更新管理

1. 用一个目录管理一个应用#

Compose 把镜像、端口、卷和环境变量写在 YAML 文件里，方便重建和审查。先按Docker 安装教程确认 docker compose version 可用。现代插件命令是 docker compose，不要混用旧版 docker-compose 的安装步骤。

每个应用建立独立目录，例如 /opt/web-demo，保存 compose.yaml 和必要配置。密钥放在受限文件中，版本库只保留不含真实秘密的示例配置。

2. 从一个可检查的服务开始#

新建 compose.yaml，以下示例仅把网页服务开放在主机本地 8080，便于后续接反向代理。

services:
  web:
    image: nginx:stable-alpine
    ports:
      - "127.0.0.1:8080:80"
    volumes:
      - ./html:/usr/share/nginx/html:ro
    restart: unless-stopped
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"

在同目录创建 html/index.html 并写入测试页面。:ro 表示容器只读访问该目录。正式使用时记录镜像版本或 digest，避免同一标签后来指向不同内容。

3. 检查配置，再启动并验证#

sudo docker compose config --quiet
sudo docker compose pull
sudo docker compose up -d
sudo docker compose ps
sudo docker compose logs --tail 50 web
curl -I http://127.0.0.1:8080/

配置检查通过只表示格式与变量展开有效，不代表数据库密码、业务权限和外部接口都正确。完整的 compose config 输出可能包含展开后的秘密，排错时不要随意公开。

4. 数据库、网络和管理面板怎么安排#

数据库通常只需要 Compose 内部网络，不必在主机发布 3306/5432。应用用服务名连接数据库；localhost 在容器里指当前容器自己，不是宿主机或另一个服务。

Portainer、宝塔 Docker 等面板只是另一种管理入口。给面板挂载 Docker socket 会授予主机级控制能力，应限制访问、启用认证并及时更新。同一个应用尽量保留一份清晰的配置来源，避免面板修改与手工 YAML 互相覆盖。

5. 更新前备份，更新后检查业务#

阅读目标版本发布说明，备份数据库、上传目录和配置，记录旧镜像摘要，再拉取并重建。up -d 可以重建需要更新的容器，通常不必先把整个项目关闭。

sudo docker compose pull
sudo docker compose up -d
sudo docker compose ps
sudo docker compose logs --since 5m

回退镜像不一定能回退数据库结构；出现数据库迁移时，要按应用说明使用匹配的备份恢复。docker compose down 与 down -v 不同，后者会移除相关命名卷，可能删除业务数据。

6. 完成部署的验收清单#

从外部访问 HTTPS 域名，验证登录、上传、任务执行和重启后恢复；从主机查看磁盘增长与日志保留。应用启动但健康检查失败时，先看依赖和日志，不要无限循环重启。

后续可按应用阅读n8n、Dify或WordPress，通用恢复流程见备份教程。