使用Docker SDK替代Docker Compose编排服务有哪些弊端？

我自己在搭建内部DevOps平台时踩过这个方向的坑，核心问题有几个：

• 无意义的重复开发量极大。Docker Compose本身已经把多服务编排的通用逻辑全部做了生产级实现：包括跨环境的配置覆盖、隔离网络自动创建与回收、存储卷和服务生命周期绑定、服务依赖顺序控制（含健康检查等待）、资源配额批量下发、异常退出的资源回滚等等。你用SDK从0写编排逻辑的话，这些能力全部要自己重新实现，写个能跑通单环境的Demo可能花不了一下午，但要覆盖到生产环境会碰到的所有边缘场景，工作量会翻十几倍，完全是重复造轮子。
• 长期维护成本极高。Docker SDK本质是对接Docker Engine的底层API，它本身不会封装Docker Compose的上层语义——比如Compose现在支持的配置profiles、服务扩展字段、secret/config批量挂载、多compose文件合并优先级这些特性，底层API都没有直接对应的封装，每次Docker Compose迭代实用的新特性，你自己写的编排层都要跟进适配，用不了半年你维护的这套自定义编排逻辑就会和社区生态脱节。
• 运维兼容性极差。目前整个容器运维生态对Compose的适配都是基于标准Compose YAML和compose命令行做的：不管是批量日志采集、资源状态排查、自动化清理工具、第三方部署面板，运维人员平时用惯的docker compose ps、docker compose logs、docker compose down这些命令，在你自定义的SDK编排逻辑上全部没法直接用。出故障的时候，运维没法用熟悉的工具快速定位问题，还要额外熟悉你写的自定义逻辑，排查成本会高很多。
• 配置一致性没有保障。你现在已经有不同环境对应的多套YAML配置，如果转用SDK做编排，要么把配置硬编码到业务代码里，要么自己写一套YAML解析、合并、变量替换的逻辑——这等于你自己重新实现了一遍Compose的配置解析层，而这套逻辑没有经过社区海量场景的验证，很容易出现同一份配置，用原生Compose跑和用你的SDK跑行为不一致的问题，这类隐式bug排查起来非常耗时间。

如果你只是觉得纯手动敲docker-compose命令管理多套环境不方便，完全没必要从零重写编排逻辑，更落地的方案是做薄封装：
核心的服务创建、更新、销毁动作还是通过代码调用本地的docker-compose命令执行，你只需要用代码帮你自动完成多环境配置文件筛选、环境变量注入、批量操作的流程串联，省掉手动敲长串命令的麻烦；所有服务定义、网络、存储配置完全沿用标准Compose YAML格式，保证和现有工具链兼容。只有碰到Compose命令确实覆盖不到的定制化需求——比如部署前的配置合法性校验、部署后的自定义健康检查、对接内部告警系统这类场景，再单独用Docker SDK调用底层接口做补充即可，不要用SDK重写整个编排流程。

内容的提问来源于stack exchange，提问作者janetatomas11