这是一个创建于 837 天前的主题，其中的信息可能已经有所发展或是发生改变。
Docker 有很多优点：
- 不依赖操作系统，怎么升级系统都不怕
- 由于第 1 点，方便运行一些操作系统已经不支持的软件版本
- 因为隔离性，很方便同时运行一个软件的不同版本（开发不同项目时经常需要）
但是 Docker 也有一些缺点：
- 配置太繁琐，新人需要了解一堆新概念：volume, publish, export
不知道有没有用户有跟我一样的需求：就是想在电脑上用 Docker 跑起来一个服务比如 MySQL ，但不需要处理太多容器的细节和配置，你跑的跟原生 MySQL 一样就行了，跑完就能用 3306 端口，日志和数据在固定的路径能找到。
总结来说这个工具用户接口很像包管理工具，比如 Homebrew:
brew services start mysql
但是底层用的是 Docker ，并帮忙我们配置好了启动命令。
我自己没找到这类工具，就搞了一个原型版本： https://github.com/songhuangcn/dpm
大家有这类工具推荐吗？
第 1 条附言 · 2022-08-28 20:45:47 +08:00
增加个例子解释该工具，暂定该工具为 dpm，执行以下命令：
dpm start mysql
结果是你电脑会启动一个跟原生软件 MySQL 一样的进程：
- 直接通过 3306 端口可以连接该进程
- 可以在系统特定目录找到该进程的配置文件
- 可以在系统某个目录找到该进程的日志
- 其他你原生安装 MySQL 时能做的事情
用户用起来跟其他方式安装的 MySQL 完全一致，用户甚至都不需要知道 Docker 的存在。
可能有用户会提到这个浪费了容器的很多功能，没错，这个工具不关心 Docker 提供的其他功能，只是解决软件依赖操作系统的问题。至于应用场景，就存粹是代替你电脑直接安装的软件。
这个跟你继续在 “项目中使用 docker-compose.yml 配置”，以及 “使用 Docker GUI 软件更方便改配置” 这些需求完全不冲突，他们分别做的是不同的事情。
 |
1
vinsony 2022-08-27 15:40:43 +08:00
docker-compose
|
 |
2
xaplux 2022-08-27 15:43:16 +08:00
这不就是 Docker Compose 么。。。
|
 |
3
songhuangcn OP docker-compose 还是要用户来写配置，只是从写 docker 的配置换成写 docker-compose 的配置吧
那我改个问发，有没有配置好 docker-compose 封装项目，让我跑起一个软件不需要写 docker-compose.yml ? |
 |
4
sky96111 2022-08-27 15:58:32 +08:00 via Android
@songhuangcn 最合理的应该是开发者自己维护一个 compose.yaml
|
 |
5
nutting 2022-08-27 16:00:34 +08:00
估计么有，所以现在都在搞 web 界面的 CI/CD 系统，底层就是通过各种参数实现
|
 |
6
cxtrinityy 2022-08-27 16:08:52 +08:00
用户不维护那至少开发者也要提供一个默认的带参命令或者 compose 文件, 不管哪个, 总有人要去维护, 维护好了用 alias 不就可以不用敲那么长的命令了么, 或者像 zsh 这种自带历史命令提示补全的, 打个 docker 就可以在所有 docker 历史命令里快速选择
|
|
7
songhuangcn OP @sky96111 docker-compose.yml 我理解更贴近项目的玩法，同一个 docker-compose.yml 的服务网络共享。
我现在的需求更像是要装一个原生软件，装好后开发机里所有项目共享这种。 |
|
8
songhuangcn OP @cxtrinityy 嗯嗯，你说的对，大家还是会有维护需求。所以这个工具应该提供的是默认配置，但支持覆盖他的配置。
我理解这类工具的作用除了搞定默认配置，还可以约定好一种 docker 配置组织方式吧，不会有些人用 bash function ，有些人用 bash alias |
|
9
cxtrinityy 2022-08-27 16:23:02 +08:00  1
@songhuangcn 那你这个需求我没理解错的话应该是收集通用服务的默认 docker 配置, 然后普通用户一键点击下载镜像启动容器一条龙, 同时提供 GUI 修改默认配置吧
如果没理解错的话, 感觉应该挺少见的但的确适合小白用户的最后一米, 大部分 docker 在 hub 上其实已经提供了默认启动配置, 可以爬一下快速丰富下你的 repo |
 |
10
oott123 2022-08-27 16:23:43 +08:00
看看 nix
|
|
11
songhuangcn OP @cxtrinityy 对，你理解完全正确。爬 docker hub 是一个好建议，非常感谢
|
 |
12
anubu 2022-08-27 16:45:30 +08:00
似乎主要用于仅仅是快速启动，跑一跑验证的场景，类似宝塔面板一类的工具。
docker 和 docker-compose 常用的命令和字段非常有限，很低的学习投入就能覆盖大部分场景，遇到特别的需求再翻文档也够用。 |
|
13
songhuangcn OP @anubu 不是快速启动，你要跳出 docker 范围来看。你用包管理工具安装并运行 mysql ，你会做什么配置吗？这些配置在跑起来后在做也来得及不是吗。
|
|
14
anubu 2022-08-27 17:46:18 +08:00 1
@songhuangcn 我说的“快速启动”可能表达有误，本意是说“快速安装，几乎零配置启动”，就是在说包管理器类似工作。
我想说的是，在类似包管理器场景下，如果不调整默认配置，那么就可以“快速启动”，如果要调整默认配置，很多时候还是要了解包分发运行的基本逻辑。 比如使用包管理器 apt 安全 docker ，想要调整 docker 的 remote api ，很多时候还是要看官方文档，了解以 apt 分发时的配置逻辑是什么样的，进而可能需要了解 systemd 的基本配置逻辑等等。 dpm 作为包管理器应该有类似的问题，即如果要调整默认配置，那么需要了解学习这种包管理的分发运行逻辑。虽然理解配置逻辑并不麻烦，但考虑到通用性，似乎直接学习通用性更高的 docker 、docker-compose 更“划算“，毕竟 docker 的入门成本真的很低，收益却特别高。 |
|
15
songhuangcn OP @anubu 封装工具都有这个问题吧，一般也不会走到这一步（如果 docker 本身是约定大于配置的话）。但是现在实在是满足不了，我想解决的是 brew 这些包用户从迁移到 docker 服务最后一公里的事。
现在基本自己和周边朋友先用着了，要解决封装后多余的学习成本问题，那就只能靠后期良好的文档啥的了，不过好在这个工具功能成本不大，大部分时间应该就是花在整理通用的包配置和文档上。 感谢你的回复。 |
 |
16
wunonglin 2022-08-27 19:02:11 +08:00
那不就是 helm 么
|
 |
17
avenger 2022-08-27 20:29:45 +08:00
`laravel/sail` 可以看看
|
 |
18
zhouwb 2022-08-27 22:06:46 +08:00 via iPhone
其实对于小白和技术爱好者来说，还真需要这么个东西，他们不是搞技术的，但是偶尔需要弄个 docker 服务，比如自家安个 homebridge 、aliyunwebdav 等等，他们不需要高需求，只要能运行就 ok ，因为服务基本上只有自己用，所以我精神上支持楼主
|
|
19
songhuangcn OP @zhouwb 感谢支持，看了大家的回复，应该真是没有这类工具了。这个个人维护只能做成小众工具了，能找到个开源社区来做就好了
|
 |
20
baobao1270 2022-08-28 09:44:43 +08:00
vagrant ？比 docker 重，但是似乎更符合你的需求
|
 |
21
Jzdoxc 2022-08-28 12:15:32 +08:00 via iPhone
docker portainer 了解一下， 网页管理容器，先直接 run 容器在进行修改容器的各项参数就会显示
|
 |
22
nosugar 2022-08-28 12:35:46 +08:00 via iPhone
这个不是每次都要手动敲的，放脚本自动化
|
 |
23
glamoroGG 2022-08-28 13:17:46 +08:00
貌似大家都是手敲命令
|
 |
24
ByteCat 2022-08-28 14:34:15 +08:00
docker compose 完全可以满足你说的这些东西，就算不是项目也行啊，单个容器，按 yaml 写你的 docker 启动参数就行了
|
 |
25
winglight2016 2022-08-28 15:22:10 +08:00
lz 的标题是 docker 命令太长，需要短版本，仔细一看内容，又变成了配置繁琐，新人需要了解一堆概念。
其实，lz 需要的是一个运维，能帮你把容器装好，对吧？ |
 |
26
onetown 2022-08-28 15:45:03 +08:00
我们现在的应用基本上都是以容器方式交付的， 但是启动的方式还是试用的 systemd ， 因为需要符合客户自己平时运维的系统， 以及他们自己也有一些运维工具， 例如通过 systemctl status $service_name 来判断服务的运行状况
所以我们在交付的时候， 提供了 systemd 的描述文件， 也提供了 docker-compose, 用 systemd 也会用 After, Requires 来控制不同容器的启动顺序。 [Unit] Description=Redis Container After=docker.service Requires=docker.service [Service] TimeoutStartSec=0 Restart=always ExecStartPre=-/usr/bin/docker stop %n ExecStartPre=-/usr/bin/docker rm %n ExecStartPre=/usr/bin/docker pull redis ExecStart=/usr/bin/docker run --rm --name %n redis [Install] WantedBy=multi-user.target |
 |
27
night98 2022-08-28 16:55:00 +08:00
portnaier ，里面有个应用市场，直接填参数就能运行
|
Select Language