只部署一个容器，应该用 docker-compose 还是 docker cli？
yodhcn yodhcn 2024-01-07 23:44:06 +08:00 4157 次点击这是一个创建于 693 天前的主题，其中的信息可能已经有所发展或是发生改变。
在"部署容器"上，docker-compose 是 docker cli 更好的替代吗？
在使用 docker-compose 过程中，发现一个不习惯的地方：
- 用 docker-compose 创建单个容器，总是会生成一个名为 "项目名 _default" 的 network ，即使我只想让容器运行在最简单的 bridge 类型网络，这让 network 列表看起来乱糟糟的；
- 而使用 docker cli 部署的容器就不会产生额外的命名 network 。
 | 1 whetherTsmile 2024-01-07 23:45:39 +08:00 compose 也可以添加 networks：bridge |
 | 2 liangdi 2024-01-07 23:46:02 +08:00 歪个楼，小型部署我们已经全面转向 podman 了 |
 | 3 SenLief 2024-01-08 00:02:55 +08:00 compose 你不配置网络，默认就是 bridge 的网络，生成的也是基于 bridge 的。 |
 | 4 yodhcn OP @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 |
 | 5 DKingAlpha 2024-01-08 00:13:27 +08:00  3 compose 的主要优势在于记录了容器配置细节，而不是把容器启动配置写在随风飘散的命令行里。 另外 compose 相对 cli 在概念上可以将多个容器组合成一套服务，同一个配置文件中管理，相对零散的命令行更加有条理。 至于你从 cli 里看到底层加了什么东西，我只能说，眼不见为净，不直接接触就行了。如果真的介意，compose 配置里也可以改变此表现。 |
 | 6 年纪大了, 我选 compose |
 | 7 Honkaiteio 2024-01-08 09:31:47 +08:00 compose 方便以后重新部署 |
 | 8 Hopetree 2024-01-08 10:03:15 +08:00 我无脑使用 docker-compose ，即使是一个无配置的 docker 我也会用 docker-compose 启动，因为这可以清晰的知道这个容器启动的参数 |
 | 9 mohumohu 2024-01-08 10:42:53 +08:00 compose up/down 写好了配置一劳永逸，出问题了也方便定位 |
 | 11 duzhuo 2024-01-08 10:55:51 +08:00 via Android docker-compose 搞不明白就问 gpt 呗 |
 | 12 wdoc 2024-01-08 11:30:15 +08:00 临时使用 cli ，长期使用 compose |
 | 13 julyclyde 2024-01-08 12:17:21 +08:00 如果能简单 docker run 就 run 如果需要加各种参数…… |
| 14 julyclyde 2024-01-08 12:18:32 +08:00 @DKingAlpha 但其实“对随风飘散的命令行的需求”是容器技术目前各种产品的缺陷 也就是，容器并没有包含“all things you need“，还散落了一部分在外面 |
 | 16 hefish 2024-01-08 12:52:27 +08:00 op 应该是不能忍受那个 xxx_default ， 指定一下 network_mode 应该就行了。 |
 | 17 kiritoxkiriko PRO 我选择全都要，docker cli 现在已经集成了 compose 命令 |
 | 18 mogita 2024-01-08 15:09:27 +08:00 compose 的好处就是可以用 git 管理配置，除此之外简单场景似乎和 cli 没啥区别 |
 | 19 eraserrain 2024-01-08 15:25:40 +08:00 声明式和命令式的区别，大部分情况都可以选择声明式 |
 | 20 vivisidea 2024-01-08 15:38:56 +08:00 选择 docker-compose 我碰到过一个情况，之前有个 docker 是用命令行起的，而且参数比较复杂，各种环境变量，run 起来之后没有存下来。。后来就不记得怎么启动的了，用 compose 就不会有这个问题，都在 compose 文件里 |
 | 21 fox0001 2024-01-08 15:43:41 +08:00 via Android 使用过 docker-compose ，就回不去了 |
| 22 DKingAlpha 2024-01-08 16:16:36 +08:00 via Android @julyclyde 如果没有可配置项，是希望镜像作者/容器自启时猜你想如何特化容器吗？ |
| 23 julyclyde 2024-01-08 16:24:16 +08:00 @DKingAlpha 对于有特化需求却没有合适的手段的情况，我觉得就不该用容器技术了 因为这样很难达到容器技术鼓吹的“easy” |
| 24 DKingAlpha 2024-01-08 16:32:35 +08:00 via Android @julyclyde 我觉得合适的手段就是在 README 里写清楚用哪几个参数或者哪个目录来配置/交换数据。这样已经将环境复杂性收缩到底了，因为归根结底特化使用者需要用 kv 一类的数据来指定配置内容。 容器是用来解决环境配置问题的，但不是魔法棒。easy 也需要用户理解。 |
| 25 julyclyde 2024-01-08 16:42:50 +08:00 @DKingAlpha README 放里面没人看；放外边就和主体分离了 主要是这技术一直强调的“包裹”反而成了阻碍很多事情的绊脚石 如果是 rpm/deb/自己编译，正常情况下用户都会去主动找文档；但容器的情况下就会思路较为惰性 |
| 26 DKingAlpha 2024-01-08 16:44:09 +08:00 via Android @julyclyde 那只能说 RTFM |
Select Language