Automatisch 常用命令与运维实战

目标：面向已按部署篇完成 Automatisch v0.15.0 安装的运维人员，给出服务进程运维、BullMQ 队列观测、认证与内部 API 全流程实测、flow 触发端到端验证、备份恢复与排障速查。本文全部命令输入与输出回显均为 2026-10-28 在 Docker 环境模拟真实服务器上的实测记录，逐行照抄。

一、环境信息

项目	实测值
Automatisch 版本	0.15.0（官方镜像方式部署，见《Automatisch Docker Compose 部署实战》）
服务入口	http://127.0.0.1:8140（宿主 8140 → 服务 3000）
进程角色	main（Web/API/接入）+ worker（执行器），PostgreSQL 14.5 + Redis 7.0.4
演示账号	user@automatisch.io / sample（官方内置，详见第二章）

先盘点栈的整体状态，确认四进程健康：

$ docker compose ps --format 'table {{.Name}}\t{{.Status}}\t{{.Ports}}'
NAME                          STATUS                   PORTS
automatisch-0.15.0-main       Up 45 seconds            0.0.0.0:8140->3000/tcp, [::]:8140->3000/tcp
automatisch-0.15.0-postgres   Up 2 minutes (healthy)   5432/tcp
automatisch-0.15.0-redis      Up 2 minutes             6379/tcp
automatisch-0.15.0-worker     Up 45 seconds            3000/tcp

main 对外暴露 8140（宿主映射），postgres/redis 只在栈内网络互通（无宿主端口），这是生产应有的暴露面。worker 的 3000/tcp 是镜像声明但未映射的端口，实际不对外。

二、服务进程运维命令

2.1 日志查看

$ docker logs automatisch-0.15.0-main | tail -5
2026-10-28 04:12:11:1211 [info]: Server is listening on http://localhost:3000
$ docker logs automatisch-0.15.0-worker | tail -5
2026-10-28 04:12:10:1210 [info]: Workers are ready!

main 的就绪标志是 Server is listening on ...，worker 的就绪标志是 Workers are ready!。默认 LOG_LEVEL=info 下执行期日志很安静（worker 消费任务不打逐条日志），需要观测任务流转细节时把 main/worker 两个服务的 LOG_LEVEL 调到 debug 后重建（配置见《Automatisch 配置参数详解》第七章）。

跟随日志实时输出：

$ docker logs -f automatisch-0.15.0-worker

2.2 重启与重建

$ docker compose restart worker         # 仅重启 worker（执行器，重启无损 flow 状态）
worker Restarting
$ docker compose up -d --force-recreate worker   # 环境变量变更后需重建而非 restart

注意：restart 不会重读编排文件中修改的环境变量——改配置（如 LOG_LEVEL、WEBHOOK_URL）后必须 up -d --force-recreate（或直接 up -d，Compose 检测到配置变化会自动重建）。这一差异在部署篇第六章的 WEBHOOK_URL 实测中已实际应用。

2.3 数据库就绪探针

$ docker exec automatisch-0.15.0-postgres pg_isready -U automatisch_user
/var/run/postgresql:5432 - accepting connections

pg_isready 也是编排中 postgres 健康检查的探针命令，排障时手动执行可快速区分「数据库挂了」与「应用连不上」。

三、BullMQ 队列运维

Automatisch 的任务队列基于 BullMQ（Redis 之上），main 投递、worker 消费。队列状态通过官方内置的 bull-board 仪表盘观测：路径 /admin/queues，需在编排中同时设置 ENABLE_BULLMQ_DASHBOARD=true 与 BULLMQ_DASHBOARD_USERNAME/PASSWORD（三个变量缺一不生效，生效条件与安全提示见配置篇第六章）。

实测仪表盘访问（admin/q1w2e3r4 为实测演示账号）：

$ curl -s -o /dev/null -w 'no-auth: %{http_code}\n' http://127.0.0.1:8140/admin/queues
no-auth: 401
$ curl -s -u admin:q1w2e3r4 http://127.0.0.1:8140/admin/queues -o /dev/null -w 'with-auth: %{http_code}\n'
with-auth: 200

未认证 401（Basic 认证挑战生效）、认证后 200（仪表盘 UI）。仪表盘中可观测的队列（源码固定注册）：flow（工作流执行主队列）、email（邮件通知）、delete-user（用户数据清理）；生产观测重点在 flow 队列的 waiting/active/failed 三个计数——waiting 持续增长说明 worker 消费能力不足（考虑加 worker 副本），failed 堆积说明 flow 步骤存在持续性错误（结合执行历史定位）。

四、认证与内部 API 实测

Automatisch 0.15.0 的 API 面分两层，社区版与付费版的边界在这里，务必认清：

API 层	路径	认证	社区版可用性
内部 API（前端同款）	`/internal/api/v1/*`	登录换发的 access token（Authorization 头）	✅ 完整可用
公开 REST API	`/api/v1/*`	企业许可 + x-api-token	❌ 无许可一律 404
触发入口	`/webhooks/flows/<flowId>[ /sync]`	无（flow 自带地址）	✅ 可用
健康检查	`/healthcheck`	无	✅ 可用

公开 REST API 的企业版守卫实测：对 /api/v1/* 任意路径的访问在无商业许可的社区版上统一返回 404（源码 checkIsEnterprise 中间件：hasValidLicense() 为假时直接 404，连认证环节都不进入）。实测：

$ curl -s -o /dev/null -w 'HTTP %{http_code}\n' http://127.0.0.1:8140/api/v1/users/signup
HTTP 404
$ curl -s -o /dev/null -w 'HTTP %{http_code}\n' http://127.0.0.1:8140/api/v1/flows
HTTP 404

这是 0.15.0 相对早期版本的重大行为变化（早期社区版提供 token 化 REST API），「用脚本驱动 flow 管理」的选型务必据此评估（见《Automatisch 介绍与选型指南》第四章）。社区版自动化替代路径：内部 API（本章实测）或 Webhook 直触发（第五章）。

4.1 登录换发 token

$ curl -s -X POST http://127.0.0.1:8140/internal/api/v1/access-tokens \
    -H 'Content-Type: application/json' \
    -d '{"email":"user@automatisch.io","password":"sample"}'
{"data":{"token":"5f2e6f6c820dce5941784ff2b351a079c7fa8a192fdd5b69a9adff690df1ef25515b4eb1a7a0539436a9b9a4ce005282"},"meta":{"type":"Object","count":1,"isArray":false,"currentPage":null,"totalPages":null}}

响应包裹在 data 字段。token 有时效（服务端 access-token 过期机制），过期后重新 POST 换发即可。后续所有请求把 token 放入 Authorization 头（裸 token，不加 Bearer 前缀，前端源码即此格式）。

4.2 当前用户信息

$ TOKEN=5f2e6f6c820dce5941784ff2b351a079c7fa8a192fdd5b69a9adff690df1ef25515b4eb1a7a0539436a9b9a4ce005282
$ curl -s http://127.0.0.1:8140/internal/api/v1/users/me -H "Authorization: $TOKEN"
{"data":{"id":"e11b6e20-3bde-48af-8efd-592181401e98","email":"user@automatisch.io","createdAt":1793160730721,"updatedAt":1793160730721,"status":"active","fullName":"Initial admin","role":{"id":"4b947f29-d11c-4c82-890f-ea7b4aed3ba1","name":"Admin","description":null,"createdAt":1793160729340,"updatedAt":1793160729340,"isAdmin":true},"permissions":[{"id":"88324ac3-9137-46ca-a264-13e1ecc1d790","roleId":"4b947f29-d11c-4c82-890f-ea7b4aed3ba1","action":"read","subject":"Connection","conditions":[],"createdAt":1793160729340,"updatedAt":1793160729340},{"id":"58aada4e-b1df-4877-a26f-cbafc4f6e6c3","roleId":"4b947f29-d11c-4c82-890f-ea7b4aed3ba1","action":"read","subject":"Execution","conditions":[],"createdAt":1793160729340,"updatedAt":1793160729340},{"id":"8490c442-3f81-427d-a438-e468af258aef","roleId":"4b947f29-d11c-4c82-890f-ea7b4aed3ba1","action":"read","subject":"Flow","conditions":[],"createdAt":1793160729340,"updatedAt":1793160729340},{"id":"923aa78f-514a-4dd9-aa1f-99a50304eb23","roleId":"4b947f29-d11c-4c82-890f-ea7b4aed3ba1","action":"read","subject":"User","conditions":[],"createdAt":1793160729340,"updatedAt":1793160729340},{"id":"dc1aad72-d0ee-4a57-a335-10d48aae82ca","roleId":"4b947f29-d11c-4c82-890f-ea7b4aed3ba1","action":"manage","subject":"Connection","conditions":[],"createdAt":1793160729340,"updatedAt":1793160729340},{"id":"d97d7624-375c-40b1-9572-f56668be9d87","roleId":"4b947f29-d11c-4c82-890f-ea7b4aed3ba1","action":"manage","subject":"Flow","conditions":[],"createdAt":1793160729340,"updatedAt":1793160729340},{"id":"afa88cc0-2a12-47e2-82ff-89a8d2f33989","roleId":"4b947f29-d11c-4c82-890f-ea7b4aed3ba1","action":"manage","subject":"User","conditions":[],"createdAt":1793160729340,"updatedAt":1793160729340}]},"meta":{"type":"User","count":1,"isArray":false,"currentPage":null,"totalPages":null}}

回显要点：Admin 角色（isAdmin: true）携带 7 项权限——Connection/Execution/Flow/User 四类资源的 read 权限加 Connection/Flow/User 三类的 manage 权限。token 无效或过期时该接口返回 401 空响应体，是脚本里最常用的会话探针。

五、Flow 端到端实测（建 flow → 触发 → 执行记录）

本章完成一条真实 flow 的全生命周期：创建 → 配置 Webhook 触发器 + Formatter 动作（两步）→ 激活 → 触发 → 查询执行记录与步骤数据回放。这是社区版「无 REST API」前提下做自动化交付的完整闭环。

5.1 创建 flow 与初始结构

$ curl -s -X POST http://127.0.0.1:8140/internal/api/v1/flows \
    -H "Authorization: $TOKEN" -H 'Content-Type: application/json' \
    -d '{"name":"webhook-formatter-demo"}'
{"data":{"id":"438ba068-5018-49f8-a60e-1018c9450566","name":"Name your flow","active":false,"status":"draft","executionInterval":15,"createdAt":1793160988930,"updatedAt":1793160988930},"meta":{"type":"Flow","count":1,"isArray":false,"currentPage":null,"totalPages":null}}

两个细节：创建请求中的 name 未生效（返回默认名 Name your flow），需要随后 PATCH 改名；响应中 executionInterval: 15 是轮询类触发器的默认间隔（分钟）。改名并查看 flow 自动生成的初始步骤：

$ FLOW=438ba068-5018-49f8-a60e-1018c9450566
$ curl -s -X PATCH http://127.0.0.1:8140/internal/api/v1/flows/$FLOW \
    -H "Authorization: $TOKEN" -H 'Content-Type: application/json' \
    -d '{"name":"webhook-formatter-demo"}' -o /dev/null -w 'HTTP %{http_code}\n'
HTTP 200
$ curl -s http://127.0.0.1:8140/internal/api/v1/flows/$FLOW -H "Authorization: $TOKEN" | python3 -m json.tool | head -32
{
    "data": {
        "id": "438ba068-5018-49f8-a60e-1018c9450566",
        "name": "webhook-formatter-demo",
        "active": false,
        "status": "draft",
        "executionInterval": 15,
        "createdAt": 1793160988930,
        "updatedAt": 1793160996660,
        "isOwner": true,
        "steps": [
            {
                "id": "e89b9bc3-84d3-460d-a32a-46b843af5eaf",
                "type": "trigger",
                "key": null,
                "name": null,
                "appKey": null,
                "iconUrl": null,
                "webhookUrl": null,
                "status": "incomplete",
                "position": 1,
                "parameters": {}
            },
            {
                "id": "31addb17-ef7b-4a60-9c1e-49ff7a4e7061",
                "type": "action",
                "key": null,
                "name": null,
                "appKey": null,
                "iconUrl": null,
                "webhookUrl": null,
                "status": "incomplete",
                "position": 2,
                "parameters": {}
            }
        ]
    }
}

新 flow 自动带两个空步骤：position 1 的 trigger 与 position 2 的 action，状态 incomplete。后续配置围绕这两个 stepId 展开。

5.2 配置 Webhook 触发器（步骤一）

触发器选内置 webhook 应用的 catchRawWebhook（Catch raw webhook，无需任何第三方凭据）：

$ curl -s -X PATCH http://127.0.0.1:8140/internal/api/v1/steps/e89b9bc3-84d3-460d-a32a-46b843af5eaf \
    -H "Authorization: $TOKEN" -H 'Content-Type: application/json' \
    -d '{"appKey":"webhook","key":"catchRawWebhook","name":"Catch raw webhook","parameters":{"workSynchronously":true}}'
{"data":{"id":"e89b9bc3-84d3-460d-a32a-46b843af5eaf","type":"trigger","key":"catchRawWebhook","name":"Catch raw webhook","appKey":"webhook","iconUrl":"http://localhost:3000/apps/webhook/assets/favicon.svg","webhookUrl":"http://localhost:3000/webhooks/flows/438ba068-5018-49f8-a60e-1018c9450566/sync","status":"incomplete","position":1,"parameters":{"workSynchronously":true}},"meta":{"type":"Step","count":1,"isArray":false,"currentPage":null,"totalPages":null}}

配置成功后系统下发该 flow 的专属触发地址 webhookUrl。注意此处返回的是 http://localhost:3000/...——这正是部署篇第六章排障的场景：对外部署需设 WEBHOOK_URL 让该地址可被外部回调（本实测栈修正后为 http://192.168.146.128:8140/webhooks/flows/438ba068-5018-49f8-a60e-1018c9450566/sync）。参数 workSynchronously: true 表示触发请求同步等待流程执行完再返回，便于端到端验证。

5.3 配置 Formatter 动作（步骤二）

动作选内置 formatter 应用的 text 动作（capitalize 转换，同样零凭据），入参引用触发器收到的 body.message 字段（变量模板 {{step.<triggerStepId>.<字段路径>}}）：

$ curl -s -X PATCH http://127.0.0.1:8140/internal/api/v1/steps/31addb17-ef7b-4a60-9c1e-49ff7a4e7061 \
    -H "Authorization: $TOKEN" -H 'Content-Type: application/json' \
    -d '{"appKey":"formatter","key":"text","name":"Capitalize text","parameters":{"transform":"capitalize","input":"{{step.e89b9bc3-84d3-460d-a32a-46b843af5eaf.body.message}}"}}'
{"data":{"id":"31addb17-ef7b-4a60-9c1e-49ff7a4e7061","type":"action","key":"text","name":"Capitalize text","appKey":"formatter","iconUrl":"http://localhost:3000/apps/formatter/assets/favicon.svg","webhookUrl":null,"status":"incomplete","position":2,"parameters":{"input":"{{step.e89b9bc3-84d3-460d-a32a-46b843af5eaf.body.message}}","transform":"capitalize"}},"meta":{"type":"Step","count":1,"isArray":false,"currentPage":null,"totalPages":null}}

两步配置完成。此时 flow 仍是草稿（active: false），直接激活会被 422 拒绝（见 5.4 排障实录）。

5.4 激活 flow（含 422 排障实录）

直接激活的真实回显：

$ curl -s -X PATCH http://127.0.0.1:8140/internal/api/v1/flows/$FLOW/status \
    -H "Authorization: $TOKEN" -H 'Content-Type: application/json' -d '{"active":true}'
{"errors":{"flow":["All steps should be completed before updating flow status!"]},"meta":{"type":"incompleteStepsError"}}

HTTP 422，原因 incompleteStepsError：步骤虽已配置参数，但状态仍是 incomplete——每个步骤必须先「测试通过」或显式跳过测试（Continue without test）才算完成。对两个步骤依次调用跳过测试接口：

$ for STEP in e89b9bc3-84d3-460d-a32a-46b843af5eaf 31addb17-ef7b-4a60-9c1e-49ff7a4e7061; do
>   curl -s -X POST http://127.0.0.1:8140/internal/api/v1/steps/$STEP/continue-without-test \
>     -H "Authorization: $TOKEN" -H 'Content-Type: application/json' -d '{}' -o /dev/null -w "step $STEP: HTTP %{http_code}\n"
> done
step e89b9bc3-84d3-460d-a32a-46b843af5eaf: HTTP 200
step 31addb17-ef7b-4a60-9c1e-49ff7a4e7061: HTTP 200
$ curl -s -X PATCH http://127.0.0.1:8140/internal/api/v1/flows/$FLOW/status \
    -H "Authorization: $TOKEN" -H 'Content-Type: application/json' -d '{"active":true}' \
    | python3 -c "import json,sys; d=json.load(sys.stdin)['data']; print('active:', d['active'], '| status:', d['status'])"
active: True | status: published

激活成功，flow 从 draft 进入 published。发布激活是一个容易踩坑的幂等点：任何步骤后续被修改回 incomplete 后，需要重新走一遍测试/跳过流程才能再次发布。

5.5 触发执行

向触发地址 POST 数据（同步模式，请求挂起至流程执行完成）：

$ curl -s -X POST http://127.0.0.1:8140/webhooks/flows/$FLOW/sync \
    -H 'Content-Type: application/json' \
    -d '{"message":"hello automatisch from quzuo"}' -w '\nHTTP %{http_code}\n'

HTTP 204

HTTP 204 表示已受理（同步模式下流程执行完成但不回传执行数据——raw webhook 触发器的同步响应体为空）。连续触发多次以积累执行记录。

5.6 执行记录与数据回放

$ curl -s "http://127.0.0.1:8140/internal/api/v1/executions?flowId=$FLOW" -H "Authorization: $TOKEN" \
  | python3 -c "
import json,sys
d=json.load(sys.stdin)['data']
print('executions:', len(d))
for e in d: print(e['id'][:8], 'status:', e['status'], 'testRun:', e['testRun'])"
executions: 3
6934870a status: success testRun: False
0de09edb status: success testRun: False
a7d87e63 status: success testRun: True

三条执行记录全部 success。testRun 字段是值得注意的机制细节：a7d87e63 产生于 flow 激活之前的触发（草稿态的 webhook 请求被记为测试执行），后两条产生于激活后（正式执行）。也就是说草稿态 flow 收到 webhook 并不会报错丢弃，而是以测试语义执行并留痕——排障时可用 testRun 区分测试流量与生产流量。

查单次执行的逐步数据（以 6934870a 为例）：

$ EXEC=6934870a-c118-4570-88fc-643d9fb92f5e
$ curl -s "http://127.0.0.1:8140/internal/api/v1/executions/$EXEC/execution-steps" -H "Authorization: $TOKEN" \
  | python3 -c "
import json,sys
for s in json.load(sys.stdin)['data']:
    print('==', s['step']['name'], '| status:', s['status'])
    print('   dataIn :', json.dumps(s['dataIn'], ensure_ascii=False))
    print('   dataOut:', json.dumps(s['dataOut'], ensure_ascii=False))"
== Catch raw webhook | status: success
   dataIn : {"workSynchronously": true}
   dataOut: {"body": {"message": "second execution test"}, "query": {}, "headers": {"host": "127.0.0.1:8140", "accept": "*/*", "user-agent": "curl/8.5.0", "content-type": "application/json", "content-length": "35"}}
== Capitalize text | status: success
   dataIn : {"input": "second execution test", "transform": "capitalize"}
   dataOut: {"output": "Second Execution Test"}

端到端链路完全验证：触发器步骤 dataOut.body 完整回放了 webhook 请求（body/query/headers），动作步骤把变量模板解析后的 second execution test 经 capitalize 转换输出 Second Execution Test——变量引用 {{step.<id>.body.message}} 的解析、Formatter 转换、执行留痕三环节全部工作正常。

六、备份与恢复实测

备份对象是三个数据卷（卷名中的 . 已被 Compose 规范化为 -，见部署篇第五章）：

$ docker volume ls --format '{{.Name}}' | grep automatisch
automatisch-0150-stack_automatisch_storage
automatisch-0150-stack_postgres_data
automatisch-0150-stack_redis_data

三卷的备份价值分级：postgres_data 是唯一必选项（全部业务数据）；storage 卷在镜像方式部署下为空、仓库源码方式下存密钥 .env（备份价值随部署方式而定）；redis_data 存队列瞬时状态，不值得备份（重启后由 PostgreSQL 中的 flow 定义重建语义）。

6.1 逻辑备份（推荐日常使用）

$ docker exec automatisch-0.15.0-postgres pg_dump -U automatisch_user -d automatisch > automatisch_pg_$(date +%Y%m%d).sql
$ ls -la automatisch_pg_20261028.sql
-rw-r--r-- 1 root root 46353 Oct 28 12:19 automatisch_pg_20261028.sql
$ head -5 automatisch_pg_20261028.sql
--
-- PostgreSQL database dump
--

-- Dumped from database version 14.5 (Debian 14.5-2.pgdg110+2)

46 KB 的纯 SQL（含建表与全部数据）。恢复到全新库：cat automatisch_pg_20261028.sql | docker exec -i automatisch-0.15.0-postgres psql -U automatisch_user -d automatisch（目标库需先建空库；跨大版本恢复前先核对 pg_dump 与目标库版本兼容性）。

密钥与备份的绑定关系：备份 SQL 中的凭据是 ENCRYPTION_KEY 加密后的密文，恢复时必须使用同一把密钥——把编排文件（含密钥）与 SQL 备份纳入同一恢复单元管理，否则恢复出的实例打不开任何连接。

6.2 物理快照（配合停机窗口）

$ docker run --rm -v automatisch-0150-stack_postgres_data:/data \
    -v /opt/backup:/backup alpine tar czf /backup/postgres-volume.tgz -C /data .
$ docker run --rm -v automatisch-0150-stack_automatisch_storage:/data \
    -v /opt/backup:/backup alpine tar czf /backup/storage-volume.tgz -C /data .
$ ls -la /opt/backup/
-rw-r--r-- 1 root root 46353 Oct 28 12:19 automatisch_pg_20261028.sql
-rw-r--r-- 1 root root 6756596 Oct 28 12:19 postgres-volume.tgz
-rw-r--r-- 1 root root      87 Oct 28 12:19 storage-volume.tgz

postgres 卷快照 6.7 MB、storage 卷 87 字节（空卷的印证）。物理快照要求一致性问题：运行中对 postgres 数据目录打 tar 存在文件级不一致风险，严格做法是先 docker compose stop main worker（停应用写入）再快照，或直接采用 6.1 的 pg_dump（逻辑一致性天然保证）——生产日常备份以 pg_dump 为主，物理快照仅用于迁移整栈。

七、常用排障速查（FAQ）

Q1：worker 就绪但 flow 不执行？ 按链路查：① flow 是否 published（GET /internal/api/v1/flows/<id> 看 active 字段，草稿态触发只记 testRun）；② Redis 是否可达（docker exec automatisch-0.15.0-redis redis-cli ping）；③ BullMQ 仪表盘 flow 队列是否堆积（waiting 增长 = worker 消费异常）。本次实测中三处均正常。

Q2：激活 flow 报 422 incompleteStepsError？ 所有步骤先「测试通过」或「Continue without test」（POST /internal/api/v1/steps/<stepId>/continue-without-test）置为 completed 再激活（5.4 节实录）。

Q3：webhook 外部系统调不通？ 查触发地址的实际形态：GET /internal/api/v1/flows/<id> 看 trigger 的 webhookUrl。若是 http://localhost:3000/...，设置 WEBHOOK_URL（main+worker 双侧）后重建并让系统重新下发地址（部署篇第六章实录）；若地址正确但外部不可达，查端口映射与防火墙。

Q4：登录接口返回什么算成功？token 失效什么表现？ POST /internal/api/v1/access-tokens 返回 {"data":{"token":"..."}} 即成功；token 失效时内部 API 一律 401 空响应体，重新换发即可。

Q5：公开 API 404 是故障吗？ 不是。0.15.0 社区版无商业许可时 /api/v1/* 全部 404（企业版守卫，第四章实测），只有 /internal/api/v1/* 可用。排查公开 API 前先确认手上有有效企业许可。

Q6：如何区分测试执行与正式执行？ 执行记录的 testRun 字段（5.6 节实录）：激活前的触发记为 true，激活后为 false。界面上对应「Test run」与正式执行两类历史。

八、参考链接

官方安装文档（双进程模型与密钥警示）：https://automatisch.io/docs/guide/installation （查询日期 2026-10-28）
官方配置文档（LOG_LEVEL/仪表盘变量）：https://automatisch.io/docs/advanced/configuration （查询日期 2026-10-28）
内部 API 路由源码（本文接口路径的权威依据）：https://github.com/automatisch/automatisch/tree/main/packages/backend/src/routes/internal/api/v1
本专栏配套篇：《Automatisch 介绍与选型指南》、《Automatisch Docker Compose 部署实战》、《Automatisch 配置参数详解》