基于 docker,告别本地开发中的环境问题

2020-08-07 15:32:45 +08:00
 williamfzc

痛点

当然,在正式发布时,大多数团队通常都会采用 CI 系统构建出安全的包,以此规避。

然鹅,在平时开发中我们难免遇到临时验证问题的场景出现,在很多团队里,开发人员会在本地机器里直接构建之后将产物丢给测试验证,这个过程就容易因为环境因素而遗漏问题。

根本痛点:开发环境没有标准化

想法

docker 在运维领域已经被广泛应用,很适合用于统一环境。而在本地开发里它出现得却很少。通常我们更倾向于用它负责构建与部署。本地使用 docker 最主要的障碍有两个:

如上面提到的,我们要解决的是环境标准化的问题,了解使用 docker 是一个解决过程,而不是方法。对于大多数人来说,他们的诉求只是一个容易用的标准环境,而不是多花时间去学一个新东西。

做了什么

设计这个东西,目标有三个:

解决方法:

可能有人会问,docker 已经有了 Dockerfile 与 compose,为什么还要一个配置文件。他们的关系是这样的:

设计思路很简单粗暴,但效果看起来是不错的:

而你只需要配一个简单的 json 在你的仓库里:

{
    "env": {
        "name": "hello",
        "image": "maven:slim"
    }
}

这么做之后,你的团队只需要预先构建好一个 image,配进仓库,所有人就可以统一环境啦!

项目

https://github.com/williamfzc/devcube

最后

欢迎各位一起讨论 :) 欢迎进来写 features

5524 次点击
所在节点    分享创造
30 条回复
devliu1
2020-08-07 16:08:47 +08:00
这个似乎直接预置 docker-compose 与用于启动的 makefile 就可以做到呀
xinta
2020-08-07 16:16:40 +08:00
我就觉得 debug 不方便
mmrx
2020-08-07 16:24:54 +08:00
在很多团队里,开发人员会在本地机器里直接构建之后将产物丢给测试验证,这个过程就容易因为环境因素而遗漏问题。


这应该是 CI 中单元测试环节没做到位的问题,交付测试前肯定是要远程部署并跑过单元测试的。
Jirajine
2020-08-07 16:27:26 +08:00
感觉你这种思路有点想 nix
williamfzc
2020-08-07 16:37:11 +08:00
@devliu1 求个例子
@xinta 这倒是真的
@mmrx 对,这是策略层面的;不过有些团队的现状是,CI 不够完善,但项目不能停还得往前跑
@Jirajine 有点,容器化也就是为了隔离
Alias4ck
2020-08-07 16:57:33 +08:00
你这个只能算个小工具 看了下代码 实现大部分还是拼接 docker command 的 而且功能也挺少的 比如不能设置 network 设置 Volumes 等
devliu1
2020-08-07 17:00:43 +08:00
@williamfzc 例子就是项目负责人创建 Dockerfile 和 docker-compose.yml 的同时,顺便写上“如何启动并进入容器的脚本或 makefile”。
xiangwan
2020-08-07 17:01:21 +08:00
williamfzc
2020-08-07 17:28:49 +08:00
@Alias4ck 其他设置项堆进去就行了,不是大问题; linux 跟 macos 是用 dockerpty 做的,拼 command 只是为了兼容 windows
williamfzc
2020-08-07 17:31:59 +08:00
@xiangwan 好东西.. 可以脱离 vscode 吗
williamfzc
2020-08-07 17:42:42 +08:00
@devliu1 懂你意思,不过写这个脚本还是费点事儿
顺便,楼下这个 https://code.visualstudio.com/docs/remote/containers 貌似不错
devliu1
2020-08-07 21:13:11 +08:00
@williamfzc 其实你这个思路挺好的,但是引入的复杂度(pip install ),似乎大于得到的收益。另外,还是要 IDE 支持才能正常使用,比如#2 提到的 debug 。
williamfzc
2020-08-07 21:38:59 +08:00
@devliu1
谢谢,docker 官方 sdk 有 go 跟 python,本来打算用 go 写的就不会有这个引入成本,后来觉得先简单点用 python 写个出来看看;
IDE 跟 debug 确实无解了,工作量过大,也没那么多时间
594duck
2020-08-08 08:59:05 +08:00
本地研发完后,先上 dev 开发环境自己集成了搞。然后再上 sit,再上 uat,preprod,prod

关于打包,全部是在 Jenkins 上打的,本地打什么包。生产参数不会本地配置吧。

不要什么都吹 docker 。纯敏捷开发是 sla 要求低于 95%的个人团队搞的。

稍好点都是敏捷加瀑布。一天天的吹吹吹。
dqh3000
2020-08-09 01:13:35 +08:00
@williamfzc 封装一个开发版本的 code-server,所有人远程开发
kingfalse
2020-08-09 03:25:54 +08:00
eclipse che 了解一下?
charlie21
2020-08-09 11:37:25 +08:00
为什么“本地开发中的环境问题”这个问题被解决了一遍又一遍? vagrant, docker 什么的。就是因为提问者的机子就是性能过剩
V2EX 就是提倡这种性能过剩的人的论坛,什么 1TB 硬盘 16G 内存。
而且不仅是机器性能过剩,人的精力也是性能过剩。

amazon 创立于 1995 年,web 2.0 时代的网站复杂度并不比今天高多少。20 年多前人们对这个问题的解决办法是:n 个人共用一台主机就 OK 了,直接连上去,大家都在这个环境里开发,谁也别瞎叫唤
Leigg
2020-08-09 12:27:17 +08:00
要是有个 gui 会不会更方便,在 gui 里面管理容器,不需要记命令
williamfzc
2020-08-09 13:25:29 +08:00
@594duck
看了一下是运维同学,我理解你们的场景需要;
统一打包是最合理的,但是一线工作里总是存在一些 trade off ;
没有吹 docker,但它的确是目前容器化做得比较好的;
我没有鼓吹技术,仅提 idea,不知道你这些都是从哪里读出来的?
williamfzc
2020-08-09 13:26:46 +08:00
@dqh3000
跟 @charlie21 的观点差不多,不想浪费本地办公机器的算力

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/696482

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX