只部署一个容器，应该用 docker-compose 还是 docker cli？
yodhcn · yodhcn · 2024-01-07 23:44:06 +08:00 · 3485 次点击这是一个创建于 367 天前的主题，其中的信息可能已经有所发展或是发生改变。
在"部署容器"上，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
miaotaizi 2024-01-08 08:49:56 +08:00
年纪大了, 我选 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
wxm1997 2024-01-08 14:58:33 +08:00
我选择全都要，docker cli 现在已经集成了 compose 命令
|
 |
18
ck65 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