使用 Docker 容器应该避免的 10 个事情 已翻译 100%

oschina 投递于 2016/02/25 10:30 (共 6 段, 翻译完成于 03-01)
阅读 25622
收藏 153
8
加载中

当你最后投入容器的怀抱,发现它能解决很多问题,而且还具有众多的优点:

  1. 第一:它是不可变的 – 操作系统,库版本,配置,文件夹和应用都是一样的。您可以使用通过相同QA测试的镜像,使产品具有相同的表现。

  2. 第二:它是轻量级的 – 容器的内存占用非常小。不需要几百几千MB,它只要对主进程分配内存再加上几十MB。

  3. 第三:它很快速 – 启动一个容器与启动一个单进程一样快。不需要几分钟,您可以在几秒钟内启动一个全新的容器。

社会主义好
翻译于 2016/02/28 14:35
1

但是,许多用户依然像对待典型的虚拟机那样对待容器。但是他们都忘记了除了与虚拟机相似的部分,容器还有一个很大的优点:它是一次性的

容器的 准则 :

“容器是临时的”。

RH_Icon_Container_with_App_Flat

这个特性“本身”促使用户改变他们关于使用和管理容器的习惯;我将会向您解释在容器中不应该做这些事,以确保最大地发挥容器的作用。

社会主义好
翻译于 2016/02/29 19:11
2

1) 不要在容器中存储数据 –  容器可能被停止,销毁,或替换。一个运行在容器中的程序版本1.0,应该很容易被1.1的版本替换且不影响或损失数据。有鉴于此,如果你需要存储数据,请存在卷中,并且注意如果两个容器在同一个卷上写数据会导致崩溃。确保你的应用被设计成在共享数据存储上写入。

2) 不要将你的应用发布两份 –  一些人将容器视为虚拟机。他们中的大多数倾向于认为他们应该在现有的运行容器里发布自己的应用。在开发阶段这样是对的,此时你需要不断地部署与调试;但对于质量保证与生产中的一个连续部署的管道,你的应用本该成为镜像的一部分。记住:容器应该保持不变

skyvoice7
翻译于 2016/02/29 20:49
3

3) 不要创建超大镜像 – 一个超大镜像只会难以分发。确保你仅有运行你应用/进程的必需的文件和库。不要安装不必要的包或在创建中运行更新(yum更新)。

4) 不要使用单层镜像 – 要对分层文件系统有更合理的使用,始终为你的操作系统创建你自己的基础镜像层,另外一层为安全和用户定义,一层为库的安装,一层为配置,最后一层为应用。这将易于重建和管理一个镜像,也易于分发。

5) 不要为运行中的容器创建镜像 – 换言之,不要使用“docker commit”命令来创建镜像。这种创建镜像的方法是不可重现的也不能版本化,应该彻底避免。始终使用Dockerfile或任何其他的可完全重现的S2I(源至镜像)方法。

skyvoice7
翻译于 2016/02/29 21:09
2

6) 不要只使用“最新”标签 – 最新标签就像Maven用户的“快照”。标签是被鼓励使用的,尤其是当你有一个分层的文件系统。你总不希望当你2个月之后创建镜像时,惊讶地发现你的应用无法运行,因为最顶的分层被非向后兼容的新版本替换,或者创建缓存中有一个错误的“最新”版本。在生产中部署容器时应避免使用最新。

7) 不要在单一容器中运行超过一个进程 – 容器能完美地运行单个进程(http守护进程,应用服务器,数据库),但是如果你不止有一个进程,管理、获取日志、独立更新都会遇到麻烦。

skyvoice7
翻译于 2016/03/01 10:10
3

8) 不要在镜像中存储凭据。使用环境变量 –不要将镜像中的任何用户名/密码写死。使用环境变量来从容器外部获取此信息。有一个不错的例子是postgres镜像

9) 使用非root用户运行进程 – “docker容器默认以root运行。(…)随着docker的成熟,更多的安全默认选项变得可用。现如今,请求root对于其他人是危险的,可能无法在所有环境中可用。你的镜像应该使用USER指令来指令容器的一个非root用户来运行。”(来自 Docker镜像作者指南

10) 不要依赖IP地址 – 每个容器都有自己的内部IP地址,如果你启动并停止它地址可能会变化。如果你的应用或微服务需要与其他容器通讯,使用任何命名与(或者)环境变量来从一个容器传递合适信息到另一个。

skyvoice7
翻译于 2016/03/01 10:27
2
本文中的所有译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接。
我们的翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们。
加载中

评论(28)

黑传说
黑传说

引用来自“_Elvis”的评论

一直有个疑问,为什么经常看到有人把数据库也放Docker中?

引用来自“zhenruyan”的评论

我们公司就是不知道上一任运维怎么想的

引用来自“巴林的狗尾草”的评论

docker有那种专门做数据存储的镜像,把数据库程序跟数据存储部分分别放在两个不同的容器里面,然后这样升级数据库的时候存储不会受到影响,而备份恢复数据的话不需要哭咔咔的去跑sql,只要定时commit数据存储container,到时候重新拉起来以前版本的commit的镜像即可,还是很方便的。

引用来自“黑传说”的评论

但是数据量大的时候还是要等着哭吧

引用来自“巴林的狗尾草”的评论

数据量大会导致什么问题?备份的镜像比较大?加硬盘啊。还是说别的什么问题?数据量大并不代表是什么压力,真正的环境的不适应带来的问题才是压力,数据量大不能叫做问题。
数据量大,跨硬盘,跨机器……还不如直接脱离容器来得简单。
巴林的狗尾草
巴林的狗尾草

引用来自“_Elvis”的评论

一直有个疑问,为什么经常看到有人把数据库也放Docker中?

引用来自“zhenruyan”的评论

我们公司就是不知道上一任运维怎么想的

引用来自“巴林的狗尾草”的评论

docker有那种专门做数据存储的镜像,把数据库程序跟数据存储部分分别放在两个不同的容器里面,然后这样升级数据库的时候存储不会受到影响,而备份恢复数据的话不需要哭咔咔的去跑sql,只要定时commit数据存储container,到时候重新拉起来以前版本的commit的镜像即可,还是很方便的。

引用来自“黑传说”的评论

但是数据量大的时候还是要等着哭吧
数据量大会导致什么问题?备份的镜像比较大?加硬盘啊。还是说别的什么问题?数据量大并不代表是什么压力,真正的环境的不适应带来的问题才是压力,数据量大不能叫做问题。
黑传说
黑传说

引用来自“_Elvis”的评论

一直有个疑问,为什么经常看到有人把数据库也放Docker中?

引用来自“zhenruyan”的评论

我们公司就是不知道上一任运维怎么想的

引用来自“巴林的狗尾草”的评论

docker有那种专门做数据存储的镜像,把数据库程序跟数据存储部分分别放在两个不同的容器里面,然后这样升级数据库的时候存储不会受到影响,而备份恢复数据的话不需要哭咔咔的去跑sql,只要定时commit数据存储container,到时候重新拉起来以前版本的commit的镜像即可,还是很方便的。
但是数据量大的时候还是要等着哭吧
巴林的狗尾草
巴林的狗尾草

引用来自“_Elvis”的评论

一直有个疑问,为什么经常看到有人把数据库也放Docker中?

引用来自“zhenruyan”的评论

我们公司就是不知道上一任运维怎么想的

引用来自“巴林的狗尾草”的评论

docker有那种专门做数据存储的镜像,把数据库程序跟数据存储部分分别放在两个不同的容器里面,然后这样升级数据库的时候存储不会受到影响,而备份恢复数据的话不需要哭咔咔的去跑sql,只要定时commit数据存储container,到时候重新拉起来以前版本的commit的镜像即可,还是很方便的。

引用来自“zhenruyan”的评论

但是我们公司是一个日访问量不过百的公司
解决方案高大上啊
wffger
wffger
现在开发环境就是装了数据库和大型应用软件的虚拟机,每次出问题都要重新拷贝原始虚拟机。如何应用容器使得开发更友好?
glassprog
glassprog

引用来自“魏曼奇”的评论

oracle-xe-11g安装要读物理设备的,然后做设置。docker环境下,能否读到,这个不清楚了。
可以试试这个 https://github.com/thinkbase/Dockerfiles/tree/master/09-Apps/11-OracleXE
美人胚子
美人胚子
docker已死。
eechen
eechen
@zyuyou 嗯.其实Apache和Nginx以及MySQL都可以像PHP那样做,并且共享那些依赖库.
zyuyou
zyuyou

引用来自“eechen”的评论

我自己编译打包的便携式PHP,自带依赖库,适用于所有Linux发行版,一个Linux系统上跑多少个版本都没有问题.Nginx和Apache也是同理,所以我从来就对Docker这种容器部署的技术不感兴趣.
http://my.oschina.net/eechen/blog/411534
你的做法是正确,也是可取的。但是你仅仅做了一个PHP的工作,docker的目标是将你这种打包PHP的方式运用到所有软件,所有环境。
魏曼奇
魏曼奇
oracle-xe-11g安装要读物理设备的,然后做设置。docker环境下,能否读到,这个不清楚了。
返回顶部
顶部
返回顶部
顶部