一个应用往往不只有长期运行的 Web 服务和数据库。上线前要迁移表结构，演示前要导入数据，排查问题时又要临时跑一段脚本。这些事情执行完就该退出，却常常散落在开发者的命令历史里。Docker Compose 把应用的多个容器写进同一份配置，而它这周的新版本，开始给这类短任务更明确的位置。
10 月 2 日发布的 Compose 5.6.0 加入了对 jobs 的部分支持。这里的"部分"得说清楚：当前支持的是手动触发的任务，定时任务还不可用，完整能力仍取决于 Docker Engine 后续支持。它不是一个已经完工的工作流平台，但对长期用 Compose 管理开发环境的人来说，这一步值得跟进。
这次变化的意义，在于把"应用需要什么"描述得更完整。常驻服务追求持续可用，一次性任务追求明确完成；如果两者都被当作永远不退出的服务，重启行为和成功条件就容易混在一起。迁移脚本执行成功后退出，通常是一件好事，而不是需要赶紧拉起的故障。这就是任务模型值得单独存在的理由。至于具体任务如何表达、与服务如何配合，仍应以当前版本支持范围为准。
Compose 本来就适合保存这种团队共识。官方说明里强调的一个价值，是用同一份定义组织环境。新同事拿到项目后，不必先问数据库怎么启动、缓存叫什么名字，再翻聊天记录找参数。镜像、网络和挂载关系留在文件里，也就能随代码一起讨论和修改。
已有项目想重新理解这个工具，不必从新语法开始。装好 Docker 与 Compose 插件，进入放有应用配置的目录，仓库快速入门里的启动命令仍然是：
docker compose up
这条命令的前提是目录中已有有效的 Compose 文件；使用本地构建的服务还需要相应的构建文件。它不是空目录里凭空生成应用的魔法。先把现有服务正常启动，再在独立测试环境评估新任务能力，比直接把生产迁移脚本搬过去更稳妥。
5.6.0 还有一些不显眼却实用的修正：文件集中变化时，watch 会合并触发的重新构建；遇到不受支持的配置属性，会给出警告。前者对频繁保存和批量改文件的开发过程有帮助，后者则能减少"配置写了，工具却没有照做"的误判。它们没有新概念那么醒目，但更贴近日常使用中的摩擦。
当然，把容器放进同一份文件，并不意味着备份、权限和故障恢复就自动完成了。对单机自托管、小型测试环境和开发联调来说，Compose 的吸引力是部署关系直观；当需求变成跨机器调度和复杂任务依赖，评估范围也要随之扩大。不能因为出现 jobs 这个词，就把它理解成另一套大型编排平台。
那些原本需要口口相传的临时操作，终于有机会成为应用定义的一部分，这是这次更新最值得关注的地方。如果你也在日常开发中跟这类容器编排工具打交道，欢迎来云栈社区一起交流。先记住它已经走到哪一步，比替它宣布更大的未来更有用。
项目地址：https://github.com/docker/compose | 
发表于 昨天 23:25
|
查看: 2|
回复: 0
