只部署一个容器，应该用 docker-compose 还是 docker cli？

[yodhcn]

在"部署容器"上，docker-compose 是 docker cli 更好的替代吗？

在使用 docker-compose 过程中，发现一个不习惯的地方：

• 用 docker-compose 创建单个容器，总是会生成一个名为 "项目名 _default" 的 network ，即使我只想让容器运行在最简单的 bridge 类型网络，这让 network 列表看起来乱糟糟的；
• 而使用 docker cli 部署的容器就不会产生额外的命名 network 。

[whetherTsmile]

compose 也可以添加 networks：bridge

[liangdi]

歪个楼，小型部署我们已经全面转向 podman 了

[SenLief]

compose 你不配置网络，默认就是 bridge 的网络，生成的也是基于 bridge 的。

[yodhcn]

@whetherTsmile #1 谢谢提醒，这下清净多了

添加 network_mode: bridge 到您的每项服务 docker-compose.yml 将阻止 compose 创建网络。
如果任何服务未配置此网桥（或主机），则会创建一个网络。
https://stackoverflow.com/questions/43754095/how-to-join-the-default-bridge-network-with-docker-compose-v2

[DKingAlpha]

compose 的主要优势在于记录了容器配置细节，而不是把容器启动配置写在随风飘散的命令行里。

另外 compose 相对 cli 在概念上可以将多个容器组合成一套服务，同一个配置文件中管理，相对零散的命令行更加有条理。

至于你从 cli 里看到底层加了什么东西，我只能说，眼不见为净，不直接接触就行了。如果真的介意，compose 配置里也可以改变此表现。

[miaotaizi]

年纪大了, 我选 compose

[Honkaiteio]

compose 方便以后重新部署

[Hopetree]

我无脑使用 docker-compose ，即使是一个无配置的 docker 我也会用 docker-compose 启动，因为这可以清晰的知道这个容器启动的参数

[mohumohu]

compose up/down 写好了配置一劳永逸，出问题了也方便定位

[zhlxsh]

@liangdi 咨询一下，是在非 root 模式下吗

[duzhuo]

docker-compose 搞不明白就问 gpt 呗

[wdoc]

临时使用 cli ，长期使用 compose

[julyclyde]

如果能简单 docker run 就 run
如果需要加各种参数……

[julyclyde]

@DKingAlpha 但其实“对随风飘散的命令行的需求”是容器技术目前各种产品的缺陷
也就是，容器并没有包含“all things you need“，还散落了一部分在外面

[liangdi]

@zhlxsh 是的

[hefish]

op 应该是不能忍受那个 xxx_default ， 指定一下 network_mode 应该就行了。

[wxm1997]

我选择全都要，docker cli 现在已经集成了 compose 命令

[ck65]

compose 的好处就是可以用 git 管理配置，除此之外简单场景似乎和 cli 没啥区别

[eraserrain]

声明式和命令式的区别，大部分情况都可以选择声明式

[vivisidea]

选择 docker-compose

我碰到过一个情况，之前有个 docker 是用命令行起的，而且参数比较复杂，各种环境变量，run 起来之后没有存下来。。后来就不记得怎么启动的了，用 compose 就不会有这个问题，都在 compose 文件里

[fox0001]

使用过 docker-compose ，就回不去了

[DKingAlpha]

@julyclyde 如果没有可配置项，是希望镜像作者/容器自启时猜你想如何特化容器吗？

[julyclyde]

@DKingAlpha 对于有特化需求却没有合适的手段的情况，我觉得就不该用容器技术了
因为这样很难达到容器技术鼓吹的“easy”

[DKingAlpha]

@julyclyde 我觉得合适的手段就是在 README 里写清楚用哪几个参数或者哪个目录来配置/交换数据。这样已经将环境复杂性收缩到底了，因为归根结底特化使用者需要用 kv 一类的数据来指定配置内容。

容器是用来解决环境配置问题的，但不是魔法棒。easy 也需要用户理解。

[julyclyde]

@DKingAlpha README 放里面没人看；放外边就和主体分离了
主要是这技术一直强调的“包裹”反而成了阻碍很多事情的绊脚石

如果是 rpm/deb/自己编译，正常情况下用户都会去主动找文档；但容器的情况下就会思路较为惰性

[DKingAlpha]

@julyclyde 那只能说 RTFM

[512357301]

@vivisidea hub 里有专门获取容器启动参数的容器，可以输出 docker run 格式的启动命令，不过输出的参数有些冗余，真正用的时候可以删减一下。