OKOK大家好欢迎大家来到大鹏 AI 教育我是张大鹏。把 Django、SvelteKit、PostgreSQL、Redis 和 Celery 写进同一个docker-compose.yml只代表它们被放进了同一张配置表。真正决定开发环境是否可靠的是六个服务怎样分工、谁在等谁、初始化发生在哪个生命周期以及我们用什么证据判断“已经可用”。这篇文章沿着如意 Django CRM 当前的开发 Compose 拆解这些问题。结论先说在前面Compose 能组织启动前置条件却不会替我们证明业务已经健康。一、六个服务怎样形成开发拓扑这套环境不是一条从数据库排到前端的直线而是一张带有并行分支的依赖图。1.1 数据、应用、异步与页面服务分别负责什么当前 Compose 一共定义六个服务。先不要急着看容器名称沿着青蓝箭头观察依赖关系。哪些服务需要等待健康门哪个服务没有进入这条等待链图中六个节点可以按职责分成四组。️数据层db保存 PostgreSQL 数据redis承担缓存与 Celery broker。应用层backend运行 Django API、迁移和开发初始化流程。⚙️异步层celery-worker消费任务celery-beat产生定时调度事件。️页面层frontend运行 SvelteKit 开发服务并独立暴露页面端口。我在源码里核对到backend、worker 和 beat 都同时依赖 db 与 redis而 frontend 没有depends_on。因此这张图最重要的不是“六个容器都在”而是下面三个结构事实。职责分开Web 请求、异步执行和定时调度没有挤在同一个进程里。基础共享Django 与两个 Celery 服务复用后端镜像和同一套项目代码。️页面并行frontend 会与后端依赖链并行启动而不是等 backend 可用后才启动。1.2 depends_on 等待了什么又没有保证什么db和redis都配置了 healthcheck。backend、worker 与 beat 使用condition: service_healthy把二者首次通过健康检查作为自己的启动前置条件。这项约束能回答“上层容器什么时候开始创建”却不能回答“应用之后是否一直可用”。能够证明初次启动时三个上层服务不会抢在 db 和 redis 的健康检查之前启动。不能证明依赖后来失效时上层业务不会因此自动完成恢复或重新验收。仍需补充backend、frontend、worker 与 beat 自身没有 Compose healthcheck运行状态不等于应用健康。二、数据库首次初始化与后端每次启动为何不同最容易混淆的两个动作是 PostgreSQL 初始化目录与 backend 入口脚本。2.1 PostgreSQL 初始化脚本只在空数据卷执行观察左右两条时间轴它们的触发条件并不相同。为什么保留数据卷重启时左侧不会再走一遍左侧属于数据库首次创建生命周期。空卷首启PostgreSQL 创建数据目录后才会处理初始化目录中的 SQL 文件。开发角色当前脚本创建开发角色并授予开发所需权限用于支持本地数据访问边界。已有数据数据卷不为空时官方镜像不会重复执行这批初始化脚本。我把这一点单独画出来是因为“重启容器”与“重新初始化数据库”是完全不同的操作。由此可以得到两个直接结论。首启要测新数据卷验收负责发现初始化 SQL、角色和权限问题。♻️重启也要测保留数据卷重启负责发现幂等性、持久化和旧状态兼容问题。初始化脚本仍是开发配置。固定开发角色和较宽的 schema 权限不能被包装成生产最小权限方案正文也不应公开复制开发密码。2.2 Backend entrypoint 串起迁移、管理员、翻译与静态资源右侧时间轴属于 backend 每次启动生命周期。入口脚本先等待 PostgreSQL TCP 端口可连接再依次执行以下动作。连接等待最多尝试固定次数连接 PostgreSQL 主机与端口。结构迁移运行python manage.py migrate对齐数据库结构。开发管理员运行create_default_admin准备本地管理入口。翻译编译执行compilemessages生成运行时翻译文件。静态收集执行collectstatic汇总 Django 静态资源。应用启动最后以runserver 0.0.0.0:12151启动开发服务器。仓库脚本使用 CRLF镜像构建阶段会先把行尾归一化。因此宿主机直接执行bash -n的失败不能脱离 Dockerfile 语境解读按镜像相同方式归一化后脚本语法检查已经通过。2.3 默认管理员与开发服务器必须停在开发边界内这条入口链为了“一条命令进入开发”做了很多便利处理。便利不等于生产方案。默认密码风险缺少ADMIN_PASSWORD时开发管理员命令可能退回默认密码。️应用服务器边界Djangorunserver适合本地开发不承担生产应用服务器职责。前端服务器边界SvelteKit 当前运行 Vite dev server也不是生产构建产物的托管方式。三、容器地址、宿主机地址与持久化怎样分层同一个后端同时出现backend:12151和localhost:12151不是重复配置而是两个网络位置。3.1 容器内服务名与浏览器地址不能混用先比较门两侧的同一项服务。为什么 PostgreSQL 在左侧使用 5432在右侧却使用 12152两侧服务对象相同但访问者所在的网络不同。容器内部Compose DNS 解析db、redis、backend与frontend等服务名。端口映射Compose 把容器端口发布到项目约定的宿主机端口。浏览器侧浏览器不在 Compose 网络中只能访问宿主机公开的localhost地址。我在.env.docker中看到的两套后端地址正好体现了这个边界。服务端进程可以使用http://backend:12151浏览器公开配置则指向http://localhost:12151。这带来两个排障判断。️容器请求失败先检查服务名、容器端口和 Compose 网络。浏览器请求失败先检查公开 URL、宿主机端口和跨域配置。3.2 四个回环端口分别服务谁项目把本地开发端口集中在 12150 到 12153。12150SvelteKit 前端页面。12151Django 后端 API 与 Admin。12152PostgreSQL 暴露给宿主机工具的端口。⚡12153Redis 暴露给宿主机工具的端口。容器内部仍分别使用 PostgreSQL 5432 和 Redis 6379。把宿主机端口抄进容器连接串是本地多服务环境中非常常见的配置错误。3.3 Bind mount、PostgreSQL 卷与 node_modules 卷解决不同问题Compose 中的挂载并非都为了“保存数据”。代码挂载bind mount 让宿主机代码改动进入开发容器支持快速迭代。️数据库卷PostgreSQL 命名卷跨容器重建保留业务数据。依赖卷独立依赖卷避免宿主机目录覆盖容器里的虚拟环境或node_modules。三种挂载的失效表现也不同。代码挂载错误会让修改不生效数据库卷错误会造成数据生命周期异常依赖卷错误则常表现为包突然缺失或平台不兼容。四、Celery 为什么同时依赖 PostgreSQL 与 RedisCelery 的运行链不只有 Redis。4.1 Worker 与 Beat 共用镜像但承担不同生命周期worker 和 beat 都复用后端代码与配置但职责不同。任务投递Django 把异步消息发送到 Redis broker。任务执行worker 消费消息执行业务代码并可能通过 ORM 访问 PostgreSQL。⏰定时调度beat 按计划生成任务事件本身不替代 worker 执行任务。所以两者适合共享镜像却不应该塞进一个不可区分的进程。独立容器让日志、重启和资源问题更容易定位到具体生命周期。4.2 启动依赖不能代替异步任务运行验收db 和 redis 健康只是异步链的前置条件。即使celery inspect ping返回成功也只能证明 worker 的控制通道可响应。进程证据ping 可以确认 worker 在线并能处理控制命令。业务证据真实任务还要证明入队、执行、数据库读写与结果状态完整闭环。安全要求验收任务应无邮件、无客户数据、无外部副作用并能安全重复执行。五、怎样证明这套 Compose 真的可用验证结论必须与证据层级相匹配。5.1 静态配置、容器状态与应用健康要分层检查从阶梯底部往上看每一层只回答一个更强的问题。为什么docker compose config --quiet通过仍不能说环境已经可用七层检查对应七种证据强度。配置解析证明 YAML、字段、引用和环境变量能被 Compose 理解。️镜像构建证明依赖安装、文件复制和构建步骤能够完成。容器健康证明进程与已配置的 healthcheck 达到预期状态。Django 检查证明系统检查与迁移状态满足当前代码要求。HTTP 访问证明前后端端口可达并返回预期响应。异步检查证明 worker 可响应并用安全任务补齐业务闭环。重启复验证明日志可追溯、数据可保留、已有卷重启仍然成立。我本次实际执行了docker compose config --quiet结果通过。这只允许我确认静态拓扑可以解析不能替代尚未执行的整套隔离运行验收。最终应坚持两个结论边界。先定位层级哪一层失败就从那一层向下检查不要直接归因业务代码。不越级宣传低层通过不能替高层背书容器运行中尤其不等于业务可用。5.2 新数据卷启动与已有数据卷重启需要分别验证发布前应使用独立 Compose 项目名运行不污染日常开发环境。建议的验收顺序是构建、首次启动、容器状态、Django 检查、迁移检查、前后端 HTTP、worker ping、日志检查然后保留数据卷重启一次。首次启动覆盖初始化脚本保留数据卷重启覆盖持久化与幂等性。只有两条路径都通过才足以说明这套开发环境具备可重复启动的证据。5.3 当前方案适用于本地开发不等于生产部署当前 Compose 的价值是让开发者用统一拓扑复现多服务环境。生产化仍需要补齐一组不同的问题。正式服务使用生产级应用服务器与静态资源交付方式。️秘密治理移除默认密码和仓库内开发凭据接入可靠的秘密管理。最小权限收紧数据库角色、schema 权限与网络暴露面。运行治理增加上层服务健康探针、指标、日志、备份与恢复演练。Compose 不是问题模糊证据边界才是问题。当我们把启动依赖、初始化生命周期、网络位置和验证层级分别说清楚这套六服务开发环境才真正从“能启动”走向“可理解、可排查、可重复”。Docker 对启动顺序与网络边界的说明可以继续阅读 Compose startup order 与 Compose networking。 如意 Django CRM 容器化实战：后端、前端、数据库、Redis 的协同启动逻辑
OKOK大家好欢迎大家来到大鹏 AI 教育我是张大鹏。把 Django、SvelteKit、PostgreSQL、Redis 和 Celery 写进同一个docker-compose.yml只代表它们被放进了同一张配置表。真正决定开发环境是否可靠的是六个服务怎样分工、谁在等谁、初始化发生在哪个生命周期以及我们用什么证据判断“已经可用”。这篇文章沿着如意 Django CRM 当前的开发 Compose 拆解这些问题。结论先说在前面Compose 能组织启动前置条件却不会替我们证明业务已经健康。一、六个服务怎样形成开发拓扑这套环境不是一条从数据库排到前端的直线而是一张带有并行分支的依赖图。1.1 数据、应用、异步与页面服务分别负责什么当前 Compose 一共定义六个服务。先不要急着看容器名称沿着青蓝箭头观察依赖关系。哪些服务需要等待健康门哪个服务没有进入这条等待链图中六个节点可以按职责分成四组。️数据层db保存 PostgreSQL 数据redis承担缓存与 Celery broker。应用层backend运行 Django API、迁移和开发初始化流程。⚙️异步层celery-worker消费任务celery-beat产生定时调度事件。️页面层frontend运行 SvelteKit 开发服务并独立暴露页面端口。我在源码里核对到backend、worker 和 beat 都同时依赖 db 与 redis而 frontend 没有depends_on。因此这张图最重要的不是“六个容器都在”而是下面三个结构事实。职责分开Web 请求、异步执行和定时调度没有挤在同一个进程里。基础共享Django 与两个 Celery 服务复用后端镜像和同一套项目代码。️页面并行frontend 会与后端依赖链并行启动而不是等 backend 可用后才启动。1.2 depends_on 等待了什么又没有保证什么db和redis都配置了 healthcheck。backend、worker 与 beat 使用condition: service_healthy把二者首次通过健康检查作为自己的启动前置条件。这项约束能回答“上层容器什么时候开始创建”却不能回答“应用之后是否一直可用”。能够证明初次启动时三个上层服务不会抢在 db 和 redis 的健康检查之前启动。不能证明依赖后来失效时上层业务不会因此自动完成恢复或重新验收。仍需补充backend、frontend、worker 与 beat 自身没有 Compose healthcheck运行状态不等于应用健康。二、数据库首次初始化与后端每次启动为何不同最容易混淆的两个动作是 PostgreSQL 初始化目录与 backend 入口脚本。2.1 PostgreSQL 初始化脚本只在空数据卷执行观察左右两条时间轴它们的触发条件并不相同。为什么保留数据卷重启时左侧不会再走一遍左侧属于数据库首次创建生命周期。空卷首启PostgreSQL 创建数据目录后才会处理初始化目录中的 SQL 文件。开发角色当前脚本创建开发角色并授予开发所需权限用于支持本地数据访问边界。已有数据数据卷不为空时官方镜像不会重复执行这批初始化脚本。我把这一点单独画出来是因为“重启容器”与“重新初始化数据库”是完全不同的操作。由此可以得到两个直接结论。首启要测新数据卷验收负责发现初始化 SQL、角色和权限问题。♻️重启也要测保留数据卷重启负责发现幂等性、持久化和旧状态兼容问题。初始化脚本仍是开发配置。固定开发角色和较宽的 schema 权限不能被包装成生产最小权限方案正文也不应公开复制开发密码。2.2 Backend entrypoint 串起迁移、管理员、翻译与静态资源右侧时间轴属于 backend 每次启动生命周期。入口脚本先等待 PostgreSQL TCP 端口可连接再依次执行以下动作。连接等待最多尝试固定次数连接 PostgreSQL 主机与端口。结构迁移运行python manage.py migrate对齐数据库结构。开发管理员运行create_default_admin准备本地管理入口。翻译编译执行compilemessages生成运行时翻译文件。静态收集执行collectstatic汇总 Django 静态资源。应用启动最后以runserver 0.0.0.0:12151启动开发服务器。仓库脚本使用 CRLF镜像构建阶段会先把行尾归一化。因此宿主机直接执行bash -n的失败不能脱离 Dockerfile 语境解读按镜像相同方式归一化后脚本语法检查已经通过。2.3 默认管理员与开发服务器必须停在开发边界内这条入口链为了“一条命令进入开发”做了很多便利处理。便利不等于生产方案。默认密码风险缺少ADMIN_PASSWORD时开发管理员命令可能退回默认密码。️应用服务器边界Djangorunserver适合本地开发不承担生产应用服务器职责。前端服务器边界SvelteKit 当前运行 Vite dev server也不是生产构建产物的托管方式。三、容器地址、宿主机地址与持久化怎样分层同一个后端同时出现backend:12151和localhost:12151不是重复配置而是两个网络位置。3.1 容器内服务名与浏览器地址不能混用先比较门两侧的同一项服务。为什么 PostgreSQL 在左侧使用 5432在右侧却使用 12152两侧服务对象相同但访问者所在的网络不同。容器内部Compose DNS 解析db、redis、backend与frontend等服务名。端口映射Compose 把容器端口发布到项目约定的宿主机端口。浏览器侧浏览器不在 Compose 网络中只能访问宿主机公开的localhost地址。我在.env.docker中看到的两套后端地址正好体现了这个边界。服务端进程可以使用http://backend:12151浏览器公开配置则指向http://localhost:12151。这带来两个排障判断。️容器请求失败先检查服务名、容器端口和 Compose 网络。浏览器请求失败先检查公开 URL、宿主机端口和跨域配置。3.2 四个回环端口分别服务谁项目把本地开发端口集中在 12150 到 12153。12150SvelteKit 前端页面。12151Django 后端 API 与 Admin。12152PostgreSQL 暴露给宿主机工具的端口。⚡12153Redis 暴露给宿主机工具的端口。容器内部仍分别使用 PostgreSQL 5432 和 Redis 6379。把宿主机端口抄进容器连接串是本地多服务环境中非常常见的配置错误。3.3 Bind mount、PostgreSQL 卷与 node_modules 卷解决不同问题Compose 中的挂载并非都为了“保存数据”。代码挂载bind mount 让宿主机代码改动进入开发容器支持快速迭代。️数据库卷PostgreSQL 命名卷跨容器重建保留业务数据。依赖卷独立依赖卷避免宿主机目录覆盖容器里的虚拟环境或node_modules。三种挂载的失效表现也不同。代码挂载错误会让修改不生效数据库卷错误会造成数据生命周期异常依赖卷错误则常表现为包突然缺失或平台不兼容。四、Celery 为什么同时依赖 PostgreSQL 与 RedisCelery 的运行链不只有 Redis。4.1 Worker 与 Beat 共用镜像但承担不同生命周期worker 和 beat 都复用后端代码与配置但职责不同。任务投递Django 把异步消息发送到 Redis broker。任务执行worker 消费消息执行业务代码并可能通过 ORM 访问 PostgreSQL。⏰定时调度beat 按计划生成任务事件本身不替代 worker 执行任务。所以两者适合共享镜像却不应该塞进一个不可区分的进程。独立容器让日志、重启和资源问题更容易定位到具体生命周期。4.2 启动依赖不能代替异步任务运行验收db 和 redis 健康只是异步链的前置条件。即使celery inspect ping返回成功也只能证明 worker 的控制通道可响应。进程证据ping 可以确认 worker 在线并能处理控制命令。业务证据真实任务还要证明入队、执行、数据库读写与结果状态完整闭环。安全要求验收任务应无邮件、无客户数据、无外部副作用并能安全重复执行。五、怎样证明这套 Compose 真的可用验证结论必须与证据层级相匹配。5.1 静态配置、容器状态与应用健康要分层检查从阶梯底部往上看每一层只回答一个更强的问题。为什么docker compose config --quiet通过仍不能说环境已经可用七层检查对应七种证据强度。配置解析证明 YAML、字段、引用和环境变量能被 Compose 理解。️镜像构建证明依赖安装、文件复制和构建步骤能够完成。容器健康证明进程与已配置的 healthcheck 达到预期状态。Django 检查证明系统检查与迁移状态满足当前代码要求。HTTP 访问证明前后端端口可达并返回预期响应。异步检查证明 worker 可响应并用安全任务补齐业务闭环。重启复验证明日志可追溯、数据可保留、已有卷重启仍然成立。我本次实际执行了docker compose config --quiet结果通过。这只允许我确认静态拓扑可以解析不能替代尚未执行的整套隔离运行验收。最终应坚持两个结论边界。先定位层级哪一层失败就从那一层向下检查不要直接归因业务代码。不越级宣传低层通过不能替高层背书容器运行中尤其不等于业务可用。5.2 新数据卷启动与已有数据卷重启需要分别验证发布前应使用独立 Compose 项目名运行不污染日常开发环境。建议的验收顺序是构建、首次启动、容器状态、Django 检查、迁移检查、前后端 HTTP、worker ping、日志检查然后保留数据卷重启一次。首次启动覆盖初始化脚本保留数据卷重启覆盖持久化与幂等性。只有两条路径都通过才足以说明这套开发环境具备可重复启动的证据。5.3 当前方案适用于本地开发不等于生产部署当前 Compose 的价值是让开发者用统一拓扑复现多服务环境。生产化仍需要补齐一组不同的问题。正式服务使用生产级应用服务器与静态资源交付方式。️秘密治理移除默认密码和仓库内开发凭据接入可靠的秘密管理。最小权限收紧数据库角色、schema 权限与网络暴露面。运行治理增加上层服务健康探针、指标、日志、备份与恢复演练。Compose 不是问题模糊证据边界才是问题。当我们把启动依赖、初始化生命周期、网络位置和验证层级分别说清楚这套六服务开发环境才真正从“能启动”走向“可理解、可排查、可重复”。Docker 对启动顺序与网络边界的说明可以继续阅读 Compose startup order 与 Compose networking。