只部署一个容器，应该用 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 文件里