这是一个创建于 2143 天前的主题，其中的信息可能已经有所发展或是发生改变。
不怎么了解 docker，也没使用过，请教下各位大佬使用 docker 有什么好处呢？
因为 go 最终是编译为一个二进制文件，丢到服务器上就可以直接运行，如果使用 docker 的话，还得在服务器上装 docker，那么把最终程序打包成 docker 有什么好处呢？
因为 go 最终是编译为一个二进制文件，丢到服务器上就可以直接运行，如果使用 docker 的话，还得在服务器上装 docker，那么把最终程序打包成 docker 有什么好处呢？
 |
1
boris1993 2019-01-21 12:09:05 +08:00 via Android
我猜......用 k8s 做容器编排，方便弹性伸缩？
|
 |
2
yuyang 2019-01-21 12:28:24 +08:00  5
容器大体上有三个功能, 环境统一, 环境隔离, 资源限制, 你只说到了第一个
|
 |
3
sakeven 2019-01-21 12:33:51 +08:00
即使是环境统一，只用 go 也没有完全做到，因为机器情况是很复杂的，比如各种各样的系统、内核版本、依赖库，除非你自己在 go 里处理这些问题，或者说只有那么几台服务器。
|
 |
4
ivyliner 2019-01-21 12:36:55 +08:00 via Android
如果没有用 k8s golang 用 docker 的优势不明显。namespace 会导致问题追查相对比较困难
|
 |
5
yuikns 2019-01-21 12:37:32 +08:00
二楼总结完毕。
第一个也不完全。 比如我们可以在独占的容器里面往 /tmp/my-app.sock 里写东西，两个同样的程序起起来就会冲突。 |
 |
6
rayingecho 2019-01-21 12:53:16 +08:00
从开发的角度来说, 我认为主要是应用交付层面的 Separate of Concern:
无论什么应用, 都会至少依赖 kernel 与 library, 楼上已经说了 kernel 和依赖库的多样性问题. 而再往上还可能依赖环境变量, 外部脚本或 Binary (比如 imagemagick). 在容器化的交付方式之前, dev 只交付代码, 后面的一切 ops 来做. 但是 ops 发现自己 hold 不住了, 毕竟只有 dev 才最理解自己的应用需要怎样的环境与依赖. 因此我们需要一个 docker (容器)这样的交付抽象, 一切外部依赖与环境都由 dev 定义好, 再交给 ops 一方 (ops 团队或者 PaaS 厂商) 来统一编排. |
 |
7
hilbertz 2019-01-21 13:03:01 +08:00
确实没啥用，因为以后都是 serverless 的，就是直接扔上去
|
 |
8
janxin 2019-01-21 14:16:06 +08:00
要看公司整体情况，比如说我们的情况是就只有 Ubuntu LTS，上一个 LTS 版本的机器会滚动升级到最新的 LTS，这种情况下，基本上环境统一对我们基本是没什么影响的。资源限制什么之类的 systemd 也能达到部分功能。
我们之所以没用 docker，主要原因在于没有人力搭建容器相关生态，想要的编排、伸缩等等功能是需要集群才有的功能 |
 |
9
flyingheart 2019-01-21 14:19:29 +08:00
docker 自带的网络功能可以很方便的实现多个网络的隔离
|
 |
10
wenzhoou 2019-01-21 14:32:55 +08:00 via Android
用了 golang，打包发现依赖 libc，然后还要加 locale，好麻烦。
再就是，想要支持 hot reload 发现最终还得带着 go 的编译环境一起发布。 当然这都不是 docker 的问题。 二楼说的还是挺好。 就是自己做自己用的东西就懒得去折腾。 |
 |
11
reus 2019-01-21 14:36:55 +08:00
如果只是需要环境隔离，用 systemd-nspawn 就行了
|
 |
12
diferent 2019-01-21 16:38:51 +08:00
遵循传统的管理和部署,可以说是没有任何区别.
容器化要解决的问题是宏观上的运维问题. 从微观上去讨论,没有什么优势. 举个例子,图书馆管理员在管理书,学生去图书馆借书. 只有从管理员的视角才能看到管理的优势和升级的欲望, 从学生的角度永远都是最简单,最质朴的方式最好. |
Select Language