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

[williamfzc]

痛点

• 随着应用逐渐复杂化，构建的流程与依赖都变得越来越复杂；
• 参与的人员越来越多，大家使用的开发环境难免不一致；
• 很多时候编译环境带来的问题是潜在的（例如路径处理等等），无法在打包过程就发现；

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

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

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

想法

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

• 起步麻烦：你至少需要知道 docker 是什么，怎么运作，及一些基本的概念，这有一些学习成本；
• 使用体验：即便现在有 gui 的存在，创建容器与镜像时还是需要记住一些配置，手敲命令，这有一些记忆成本；

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

做了什么

设计这个东西，目标有三个：

• 环境标准化
• 使用门槛超低
• 易于团队协同

解决方法：

• docker
• 命令行启动，少打字
• 配置化，配置文件跟仓库走

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

• compose：描述我们需要一批什么样的容器
• Dockerfile：描述我们需要什么镜像
• 新配置：描述我们需要一个什么样的容器，如何与我们的工作区关联起来，并 check in

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

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

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

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

项目

https://github.com/williamfzc/devcube

最后

欢迎各位一起讨论 ：） 欢迎进来写 features

本来就是个 idea 而已，不是个严肃项目，也没有推广计划，仅做交流讨论

https://code.visualstudio.com/docs/remote/containers
这就是我想做成的样子，如果可以离开 vscode 的话就更好了

[devliu1]

这个似乎直接预置 docker-compose 与用于启动的 makefile 就可以做到呀

[xinta]

我就觉得 debug 不方便

[mmrx]

在很多团队里，开发人员会在本地机器里直接构建之后将产物丢给测试验证，这个过程就容易因为环境因素而遗漏问题。


这应该是 CI 中单元测试环节没做到位的问题，交付测试前肯定是要远程部署并跑过单元测试的。

[Jirajine]

感觉你这种思路有点想 nix

[williamfzc]

@devliu1 求个例子
@xinta 这倒是真的
@mmrx 对，这是策略层面的；不过有些团队的现状是，CI 不够完善，但项目不能停还得往前跑
@Jirajine 有点，容器化也就是为了隔离

[Alias4ck]

你这个只能算个小工具 看了下代码 实现大部分还是拼接 docker command 的 而且功能也挺少的 比如不能设置 network 设置 Volumes 等

[devliu1]

@williamfzc 例子就是项目负责人创建 Dockerfile 和 docker-compose.yml 的同时，顺便写上“如何启动并进入容器的脚本或 makefile”。

[xiangwan]

在用 vsc remote container
https://code.visualstudio.com/docs/remote/containers

[williamfzc]

@Alias4ck 其他设置项堆进去就行了，不是大问题； linux 跟 macos 是用 dockerpty 做的，拼 command 只是为了兼容 windows

[williamfzc]

@xiangwan 好东西.. 可以脱离 vscode 吗

[williamfzc]

@devliu1 懂你意思，不过写这个脚本还是费点事儿
顺便，楼下这个 https://code.visualstudio.com/docs/remote/containers 貌似不错

[devliu1]

@williamfzc 其实你这个思路挺好的，但是引入的复杂度(pip install )，似乎大于得到的收益。另外，还是要 IDE 支持才能正常使用，比如#2 提到的 debug 。

[williamfzc]

@devliu1
谢谢，docker 官方 sdk 有 go 跟 python，本来打算用 go 写的就不会有这个引入成本，后来觉得先简单点用 python 写个出来看看；
IDE 跟 debug 确实无解了，工作量过大，也没那么多时间

[594duck]

本地研发完后，先上 dev 开发环境自己集成了搞。然后再上 sit，再上 uat，preprod，prod

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

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

稍好点都是敏捷加瀑布。一天天的吹吹吹。

[dqh3000]

@williamfzc 封装一个开发版本的 code-server，所有人远程开发

[kingfalse]

eclipse che 了解一下？

[charlie21]

为什么“本地开发中的环境问题”这个问题被解决了一遍又一遍？ vagrant, docker 什么的。就是因为提问者的机子就是性能过剩
V2EX 就是提倡这种性能过剩的人的论坛，什么 1TB 硬盘 16G 内存。
而且不仅是机器性能过剩，人的精力也是性能过剩。

amazon 创立于 1995 年，web 2.0 时代的网站复杂度并不比今天高多少。20 年多前人们对这个问题的解决办法是：n 个人共用一台主机就 OK 了，直接连上去，大家都在这个环境里开发，谁也别瞎叫唤

[Leigg]

要是有个 gui 会不会更方便，在 gui 里面管理容器，不需要记命令

[williamfzc]

@594duck
看了一下是运维同学，我理解你们的场景需要；
统一打包是最合理的，但是一线工作里总是存在一些 trade off ；
没有吹 docker，但它的确是目前容器化做得比较好的；
我没有鼓吹技术，仅提 idea，不知道你这些都是从哪里读出来的？

[williamfzc]

@dqh3000
跟 @charlie21 的观点差不多，不想浪费本地办公机器的算力

[williamfzc]

@kingfalse 学习了

[williamfzc]

@Leigg 按我想法 gui 不如简单的命令方便呢

[firefox12]

恩 我在公司做了一个类似的，利用 k8s, 一键帮你拉起环境，然后你把自己的开发机器加入集群。需要改本地的 dns 服务器，其他没要求。现在基本上每个开发组都用这套系统拉起环境做开发和测试。

[594duck]

@williamfzc @charlie21 的观点你真的理解了，还是我的理解 有偏差了。

[xinta]

@williamfzc 我觉得 @xiangwan 的非常不错，我会去尝试下

[tfdetang]

@williamfzc vsc remote container 确实很好用，我用了很久了； 你要是不喜欢 vscode JetBrains 家也有类似解决方案；

[tfdetang]

@charlie21 并不是所有情况下都可以大家一起连到一个环境里的。比如深度学习开发，只要一调试就要占用 tensorflow 的 session 和显存，别的开发者会受到影响。 所以环境肯定要隔离，但是又要确保最后的环境一致便于部署，那就需要利用 dockerfile 统一大家的环境。

[woostundy]

听着像 vagrant

[jorneyr]

Windows 的 Docker 很慢很慢

[spider12]

我干过这个事情，8G 内存的 Mac，内存分分钟爆掉