Docker 部署 Super Productivity 教程：5 分钟跑起来，再构建 amd64/arm64 多架构镜像

Docker 部署 Super Productivity 教程：5 分钟跑起来，再构建 amd64/arm64 多架构镜像

【免费下载链接】super-productivitySuper Productivity is an advanced todo list app with integrated Timeboxing and time tracking capabilities. It also comes with integrations for Jira, GitLab, GitHub and Open Project.项目地址: https://gitcode.com/GitHub_Trending/su/super-productivity

Super Productivity 是一款内置时间盒管理与时间跟踪的进阶待办应用，并带 Jira、GitLab、GitHub、Open Project 等集成。本文带你实战完成 Super Productivity 部署：先把最小配置跑起来，再用 Buildx 完成一次 Docker 多架构构建，产出 amd64 与 arm64 双架构镜像，最后处理配置、持久化与常见故障。

先跑起来：最小可运行的 Docker 部署

为什么用容器跑它？Super Productivity 本体是个静态构建产物，同步又涉及 WebDAV、数据库等多个配套服务。如果在你机器上手工装依赖、调服务，环境不一致的问题会不断冒出来；而容器化之后，构建和运行环境被锁死在同一份镜像里，换台 Linux、macOS 或 Windows（带 Docker Desktop）的机器，行为完全一致，部署也退化成了"起几个容器"。

前提是装好 Docker 和 Docker Compose（Ubuntu 上apt install docker.io docker-compose-v2即可），然后拉取代码：

git clone https://gitcode.com/GitHub_Trending/su/super-productivity cd super-productivity

接着一条命令拉起整套环境：

docker compose up -d

默认 Compose 文件 里其实一次性编排了四个服务：Super Productivity 应用本身、一个 WebDAV 同步服务器、PostgreSQL 数据库，以及 SuperSync 同步服务。端口约定很直白——应用对外是 8080（映射容器内 80），WebDAV 是 2345，数据库是 55432，SuperSync 是 1900。

验证部署：浏览器里应该看到什么

先用这条命令确认应用在响应，返回 200 即说明 Nginx 已经在工作：

curl -I http://localhost:8080

浏览器打开http://localhost:8080，首次访问会进入引导页，跟着提示设置好一天可投入的时间、时区等：

建一条任务、打开详情面板，能看到时间盒、子任务、时间跟踪入口都在：

到这里，部署这一步就算过关了。

构建 amd64 与 arm64：Buildx 多架构镜像实操

现在把"拉现成镜像"换成"自己构建"。先搞清楚仓库里三个 Dockerfile 的分工：根目录Dockerfile是生产镜像，node 构建阶段产出静态文件，运行阶段由 Nginx 提供，监听 80 端口；Dockerfile.e2e.dev与Dockerfile.e2e.dev.fast则只服务端到端测试，跑的是 Angular 开发服务器，端口 4242，日常部署用不到它们。

生产Dockerfile的构建阶段特意写了FROM --platform=$BUILDPLATFORM，意味着可以在 x86 机器上交叉编译出 arm64 的产物，这正是用 Buildx 做多架构镜像的底气。

先建一个 buildx 构建器（🐳 第一次构建需要）：

docker buildx create --use

再指定双平台构建。这条命令会分别为 amd64 和 arm64 各跑一遍构建流程：

docker buildx build --platform linux/amd64,linux/arm64 \ -t super-productivity:local .

如果要推送到镜像仓库供其他机器拉取，把结尾换成--push并换成仓库地址即可；仅本地使用就保持上面的-t加--load（或--output type=docker）落到本地镜像列表。构建完成后，同一份 manifest 会在 x86 服务器和 ARM 设备（比如 Mac M 系列）上被拉成各自架构的层，这就是多架构镜像的价值。

进阶配置：环境变量预置与 Nginx 反向代理

应用启动脚本docker-entrypoint.sh有个贴心设计：它会把WEBDAV_BASE_URL、WEBDAV_USERNAME、SYNC_INTERVAL、IS_COMPRESSION_ENABLED等环境变量在容器启动时拼进assets/sync-config-default-override.json，等于给所有访问者预置了一套同步默认值。比如想让新用户开箱就连上同栈里的 WebDAV：

services: app: environment: WEBDAV_BASE_URL: http://webdav:2345/ SYNC_INTERVAL: 15

注意这是运行期注入的默认值；编译期常量则维护在src/environments/environment.ts（开发）与src/environments/environment.prod.ts（生产），改动后需要重新构建镜像。

反向代理方面，镜像里的 Nginx 模板（nginx/default.conf.template）监听APP_PORT（默认 80），/路径服务静态文件，而/webdav/前缀的请求会被转发到WEBDAV_BACKEND指向的后端并剥掉前缀——所以如果你要接第三方 WebDAV（Nextcloud 之类），只需给容器注入WEBDAV_BACKEND变量，无需自己写反代规则。

数据卷持久化与资源限制

默认 Compose 已经为数据库和 WebDAV 数据建了命名卷db_data、webdav_data，删容器重建不会丢数据，这点可以放心。若要为自己的数据目录追加持久化，写法类似：

volumes: app-data: services: app: volumes: - app-data:/app/data

跑在低配机器或家用服务器上时，建议顺手加上资源上限，防止同步高峰把宿主机吃满：

services: app: deploy: resources: limits: cpus: '0.5' memory: 512M

排错：容器起不来、同步服务异常

⚠️ 出问题时别猜，先按这个顺序查：

1. 应用容器起不来：看日志，90% 的端口冲突、环境变量拼写错误都能在这里现形：

docker compose logs -f app

2. 同步服务异常：docker compose ps检查supersync与db是否都处于 healthy（后者依赖数据库健康检查通过才启动，首启可能多等几秒），再直接探活：

curl -fsS http://localhost:1900/health

3. 端口被占用：8080 或 2345 被占时，改 Compose 里映射的宿主机端口即可，容器内端口不用动。

另外提醒一句：仓库里那份docker-compose.supersync.yaml是 E2E 测试用的覆盖层（把 SuperSync 挪到 1901 端口方便测试与开发服务器并存），生产部署用默认文件就行，别误加。

镜像推到自己的仓库之后，换任何一台 amd64 或 arm64 主机，docker pull加同一条docker compose up -d就能复刻这套环境；想深入构建细节，可以再翻 环境构建文档。

【免费下载链接】super-productivitySuper Productivity is an advanced todo list app with integrated Timeboxing and time tracking capabilities. It also comes with integrations for Jira, GitLab, GitHub and Open Project.项目地址: https://gitcode.com/GitHub_Trending/su/super-productivity