匿名用户不能发表回复！|
每天回帖即可获得10分可用分！小技巧：
你还可以输入10000个字符
(Ctrl+Enter)
请遵守CSDN，不得违反国家法律法规。
转载文章请注明出自“CSDN（www.csdn.net）”。如是商业用途请联系原作者。中国领先的IT技术网站
51CTO旗下网站
Docker实战警示：此处大坑小洼，请绕行
Docker成为云计算领域的新宠儿已经是不争的事实，作为高速发展的开源项目，难免存在这样或那样的瑕疵。笔者最近在开发实战中曾经跌进去一些坑，有些坑还很深，写出来分享，相当于是在坑边挂个警示牌，避免大家重蹈覆辙。话不多说，一起来领略Docker的大坑小洼。
作者：佚名来源：dockerone| 13:30
Docker成为云计算领域的新宠儿已经是不争的事实，作为高速发展的开源项目，难免存在这样或那样的瑕疵。笔者最近在开发实战中曾经跌进去一些坑，有些坑还很深，写出来分享，相当于是在坑边挂个警示牌，避免大家重蹈覆辙。话不多说，一起来领略Docker的大坑小洼。
1.Docker中同种类型不同tag的镜像并非可互相替代
Docker 中同种类型的镜像，一般会用tag来进行互相区分。如Docker中的mysql镜像，镜像tag有很多种，有5.6.17，5.6.22，latest 等。用户的环境中若已经熟练使用mysql:5.6.17,并不代表用户如果使用mysql:5.6.22，环境依旧工作。
不同tag同种类型的Docker镜像，会因为以下的原因导致镜像差异。 (1).Docker镜像内容不同。同种类型Docker镜像的tag不同，很大程度上是因为镜像中应用版本的差异。Dockerfile代表 Docker镜像的制作流程，换言之是Dockerfile的不同，导致Docker镜像的不同。 (2).Docker镜像的entrypoint.sh不同。entrypoint.sh代表容器中应用进程按照何种形式启动，entrypoint.sh的差异直接导致应用容器的使用差异。举例说明：mysql:5.6.17和mysql:5.6.22的 entrypoint.sh存在很大差异，两者对于隔离认为重要的环境变量的定义就不一致，使用的差异自然存在。
不同tag的同类型镜像作为替代品时，需谨慎。查看Docker镜像layer层的差异，查阅Dockerfile与entrypoint.sh的差异，可以提供起码的保障。
2.不同时间段使用tag为latest的镜像，效果不尽相同
在一个时间点使用latest镜像，应用容器运行正常;之后的另一个时间点按照相应的Dockerfile，build出镜像再运行应用容器，失效。
Docker 官方关于同种类型Docker镜像的latest标签，并未永久赋予某一指定的Docker镜像，而是会变化。举例说明：某一个时间点ubuntu镜像的 latest标签属于ubuntu:12.04，之后的另一时间点，该latest标签属于ubuntu:14.04，若Dockerfile在这两个时间点进行build时，结果必然相异。原因回归至上文的第一个坑。
慎用latest标签，最好不用，Docker镜像都使用指定的tag。
3.使用fig部署依赖性强的容器时出错
使用fig部署两个有依赖关系的容器A和B，容器A内部应用的启动依赖于容器B内应用的完成。容器A内应用程序尝试连接容器B内部应用时，由于容器B内应用程序并未启动完毕，导致容器A应用程序启动失败，容器A停止运行。
容器的启动分为三个阶段，依次为dockerinit、entrypoint.sh以及cmd，三个阶段都会消耗时间，不同的容器消耗的时间不一，这主要取决于docker容器中entrypoint和command到底做了什么样的操作。如mysql容器B的启动，首先执行然后通过 dockerinit执行entrypoint.sh，由于entrypoint.sh执行过程中需要执行mysql_install_db等操作，会占据较多时间;最后由entrypoint.sh来执行cmd，运行真正的应用程序mysqld。综上所述，从启动容器到mysqld的运行，战线拉得较长，整个过程docker daemon都认为mysql容器存活，而mysqld正常运行之前，mysql容器并未提供mysql服务。如果fig中的容器A要访问mysql容器 B时，虽然fig会简单辨别依赖关系，让B先启动，再启动A，当fig无法辨别容器应用的状态，导致A去连接B时，B中应用仍然未启动完毕，最终A一场退出。
对自身环境有起码的预估，如从容器B的启动到容器B内应用的启动完毕，所需多少时间，从而在容器A内的应用程序逻辑中添加延时机制;或者使得A内应用程序逻辑中添加尝试连接的机制，等待容器B内应用程序的启动完毕。 笔者认为，以上解决方案只是缓解了出错的可能性，并未根除。
4.Swarm管理多个Docker Node时，Docker Node注册失败
笔者的Docker部署方式如下：在vSphere中安装一台ubuntu 14.04的虚拟机，在该虚拟机上安装docker 1.4.1;将该虚拟机制作vm使用的镜像;创建虚拟机节点时通过该镜像创建，从而虚拟机中都含有已经安装好的docker。如果使用Swarm管理这些虚拟机上的docker daemon时，仅一个Docker Node注册成功，其他Docker Node注册失败，错误信息为：docker daemon id已经被占用。
如果多个Docker Host上的Docker Daemon ID一样的话，Swarm会出现Docker Node注册失败的情况。原理如下： (1).Docker Daemon在启动的时候，会为自身赋一个ID值，这个ID值通过trustKey来创建，trustkey存放的位置为~/.docker /key.json。 (2).如果在IaaS平台，安装了一台已经装有docker的虚拟机vm1，然后通过制作vm1的镜像，再通过该镜像在IaaS平台上创建虚拟机 vm2，那么vm1与vm2的key.json文件将完全一致，导致Docker Daemon的ID值也完全一致。
(1) 创建虚拟机之后，删除文件~/.docker/key.json ,随后重启Docker Daemon。Docker Daemon将会自动生成该文件，且内容不一致，实现多Docker Host上Docker Daemon ID不冲突。 (2)创建虚拟机镜像时，删除key.json文件。 建议使用方案二，一劳永逸。
5.Docker容器的DNS问题
Dockerfile在build的过程中只要涉及访问外网，全部失效。
用户在创建docker容器的时候，不指定dns的话，Docker Daemon默认给Docker Container的DNS设置为8.8.8.8和8.8.4.4。而在国内这个特殊的环境下，这两个DNS地址并不提供稳定的服务。如此一来，只要 Docker Container内部涉及到域名解析，则立即受到影响。
docker run命令dns失效的解决方案
使用docker run命令启动容器的时候，设定&dns参数，参数值为受信的DNS地址，必须保证该DNS地址Docker Container可访问。
以上解决方案的弊端
如果按以上做修改，仅适用于docker run命令。而使用docker build的时候其实是多个docker run的叠加，由于docker build没有dns参数的传入，因此docker container不能保证域名的成功解析。
docker build命令dns失效的解决方案
启动Docker Daemon的时候设定DOCKER_OPTS，添加&dns参数，这样可以保证所有的docker run默认使用这个DNS地址。
以上这些坑深浅不一，但基本上还都集中在Docker外围的配置，行为模式等方面。最近虽然在Docker的坑里摔得鼻青脸肿，但是&Docker虐我千百遍，我待Docker如初恋&的情怀始终不变，这货一定是云计算的未来，我坚信。前方的大坑，我来了，duang。。。 。。。
【编辑推荐】
【责任编辑： TEL：（010）】
大家都在看猜你喜欢
头条专题热点热点热点
24H热文一周话题本月最赞
讲师：273人学习过
讲师：1514人学习过
讲师：1478人学习过
精选博文论坛热帖下载排行
本书选择经典的开放源代码，全面系统地分析了Linux安全机制。本书共有17章，前10章着重介绍了Linux操作系统的安全机制及实现方法，阐述了公...
订阅51CTO邮刊比特客户端
您的位置：
详解大数据
详解大数据
详解大数据
详解大数据
Docker实战警示：此处大坑小洼,请绕行
关键字：Docker
　　Docker成为领域的新宠儿已经是不争的事实，作为高速发展的开源项目，难免存在这样或那样的瑕疵。笔者最近在开发实战中曾经跌进去一些坑，有些坑还很深，写出来分享，相当于是在坑边挂个警示牌，避免大家重蹈覆辙。话不多说，一起来领略Docker的大坑小洼。
　　1.Docker中同种类型不同tag的镜像并非可互相替代
　　问题描述
　　Docker 中同种类型的镜像，一般会用tag来进行互相区分。如Docker中的镜像，镜像tag有很多种，有5.6.17，5.6.22，latest 等。用户的环境中若已经熟练使用mysql:5.6.17,并不代表用户如果使用mysql:5.6.22，环境依旧工作。
　　原因剖析
　　不同tag同种类型的Docker镜像，会因为以下的原因导致镜像差异。 (1).Docker镜像内容不同。同种类型Docker镜像的tag不同，很大程度上是因为镜像中应用版本的差异。Dockerfile代表 Docker镜像的制作流程，换言之是Dockerfile的不同，导致Docker镜像的不同。 (2).Docker镜像的entrypoint.sh不同。entrypoint.sh代表容器中应用进程按照何种形式启动，entrypoint.sh的差异直接导致应用容器的使用差异。举例说明：mysql:5.6.17和mysql:5.6.22的 entrypoint.sh存在很大差异，两者对于隔离认为重要的环境变量的定义就不一致，使用的差异自然存在。
　　解决方案
　　不同tag的同类型镜像作为替代品时，需谨慎。查看Docker镜像layer层的差异，查阅Dockerfile与entrypoint.sh的差异，可以提供起码的保障。
　　2.不同时间段使用tag为latest的镜像，效果不尽相同
　　问题描述
　　在一个时间点使用latest镜像，应用容器运行正常;之后的另一个时间点按照相应的Dockerfile，build出镜像再运行应用容器，失效。
　　原因剖析
　　Docker 官方关于同种类型Docker镜像的latest标签，并未永久赋予某一指定的Docker镜像，而是会变化。举例说明：某一个时间点镜像的 latest标签属于ubuntu:12.04，之后的另一时间点，该latest标签属于ubuntu:14.04，若Dockerfile在这两个时间点进行build时，结果必然相异。原因回归至上文的第一个坑。
　　解决方案
　　慎用latest标签，最好不用，Docker镜像都使用指定的tag。
　　3.使用fig部署依赖性强的容器时出错
　　问题描述
　　使用fig部署两个有依赖关系的容器A和B，容器A内部应用的启动依赖于容器B内应用的完成。容器A内应用程序尝试连接容器B内部应用时，由于容器B内应用程序并未启动完毕，导致容器A应用程序启动失败，容器A停止运行。
　　原因剖析
　　容器的启动分为三个阶段，依次为dockerinit、entrypoint.sh以及cmd，三个阶段都会消耗时间，不同的容器消耗的时间不一，这主要取决于docker容器中entrypoint和command到底做了什么样的操作。如mysql容器B的启动，首先执行然后通过 dockerinit执行entrypoint.sh，由于entrypoint.sh执行过程中需要执行mysql_install_db等操作，会占据较多时间;最后由entrypoint.sh来执行cmd，运行真正的应用程序mysqld。综上所述，从启动容器到mysqld的运行，战线拉得较长，整个过程docker daemon都认为mysql容器存活，而mysqld正常运行之前，mysql容器并未提供mysql服务。如果fig中的容器A要访问mysql容器 B时，虽然fig会简单辨别依赖关系，让B先启动，再启动A，当fig无法辨别容器应用的状态，导致A去连接B时，B中应用仍然未启动完毕，最终A一场退出。
　　解决方案
　　对自身环境有起码的预估，如从容器B的启动到容器B内应用的启动完毕，所需多少时间，从而在容器A内的应用程序逻辑中添加延时机制;或者使得A内应用程序逻辑中添加尝试连接的机制，等待容器B内应用程序的启动完毕。 笔者认为，以上解决只是缓解了出错的可能性，并未根除。
　　4.Swarm管理多个Docker Node时，Docker Node注册失败
　　问题描述
　　笔者的Docker部署方式如下：在vSphere中安装一台ubuntu 14.04的虚拟机，在该虚拟机上安装docker 1.4.1;将该虚拟机制作vm使用的镜像;创建虚拟机节点时通过该镜像创建，从而虚拟机中都含有已经安装好的docker。如果使用Swarm管理这些虚拟机上的docker daemon时，仅一个Docker Node注册成功，其他Docker Node注册失败，错误信息为：docker daemon id已经被占用。
　　原因剖析
　　如果多个Docker Host上的Docker Daemon ID一样的话，Swarm会出现Docker Node注册失败的情况。原理如下： (1).Docker Daemon在启动的时候，会为自身赋一个ID值，这个ID值通过trustKey来创建，trustkey存放的位置为~/.docker /key.json。 (2).如果在IaaS平台，安装了一台已经装有docker的虚拟机vm1，然后通过制作vm1的镜像，再通过该镜像在IaaS平台上创建虚拟机 vm2，那么vm1与vm2的key.json文件将完全一致，导致Docker Daemon的ID值也完全一致。
　　解决方案
　　(1) 创建虚拟机之后，删除文件~/.docker/key.json ,随后重启Docker Daemon。Docker Daemon将会自动生成该文件，且内容不一致，实现多Docker Host上Docker Daemon ID不冲突。 (2)创建虚拟机镜像时，删除key.json文件。 建议使用方案二，一劳永逸。
　　5.Docker容器的DNS问题
　　问题描述
　　Dockerfile在build的过程中只要涉及访问外网，全部失效。
　　原因剖析
　　用户在创建docker容器的时候，不指定dns的话，Docker Daemon默认给Docker Container的DNS设置为8.8.8.8和8.8.4.4。而在国内这个特殊的环境下，这两个DNS地址并不提供稳定的服务。如此一来，只要 Docker Container内部涉及到解析，则立即受到影响。
　　docker run命令dns失效的解决方案
　　使用docker run命令启动容器的时候，设定Cdns参数，参数值为受信的DNS地址，必须保证该DNS地址Docker Container可访问。
　　以上解决方案的弊端
　　如果按以上做修改，仅适用于docker run命令。而使用docker build的时候其实是多个docker run的叠加，由于docker build没有dns参数的传入，因此docker container不能保证域名的成功解析。
　　docker build命令dns失效的解决方案
　　启动Docker Daemon的时候设定DOCKER_OPTS，添加Cdns参数，这样可以保证所有的docker run默认使用这个DNS地址。
　　以上这些坑深浅不一，但基本上还都集中在Docker外围的配置，行为模式等方面。最近虽然在Docker的坑里摔得鼻青脸肿，但是“Docker虐我千百遍，我待Docker如初恋”的情怀始终不变，这货一定是云计算的未来，我坚信。前方的大坑，我来了，duang。。。 。。。
[ 责任编辑：李桢君 ]
HPE Octane为开发者和…
甲骨文的云战略已经完成第一阶段…
软件信息化周刊
比特软件信息化周刊提供以数据库、操作系统和管理软件为重点的全面软件信息化产业热点、应用方案推荐、实用技巧分享等。以最新的软件资讯，最新的软件技巧，最新的软件与服务业内动态来为IT用户找到软捷径。
商务办公周刊
比特商务周刊是一个及行业资讯、深度分析、企业导购等为一体的综合性周刊。其中，与中国计量科学研究院合力打造的比特实验室可以为商业用户提供最权威的采购指南。是企业用户不可缺少的智选周刊！
比特网络周刊向企业网管员以及网络技术和产品使用者提供关于网络产业动态、技术热点、组网、建网、网络管理、网络运维等最新技术和实用技巧，帮助网管答疑解惑，成为网管好帮手。
服务器周刊
比特服务器周刊作为比特网的重点频道之一，主要关注x86服务器，RISC架构服务器以及高性能计算机行业的产品及发展动态。通过最独到的编辑观点和业界动态分析，让您第一时间了解服务器行业的趋势。
比特存储周刊长期以来，为读者提供企业存储领域高质量的原创内容，及时、全面的资讯、技术、方案以及案例文章，力求成为业界领先的存储媒体。比特存储周刊始终致力于用户的企业信息化建设、存储业务、数据保护与容灾构建以及数据管理部署等方面服务。
比特安全周刊通过专业的信息安全内容建设，为企业级用户打造最具商业价值的信息沟通平台，并为安全厂商提供多层面、多维度的媒体宣传手段。与其他同类网站信息安全内容相比，比特安全周刊运作模式更加独立，对信息安全界的动态新闻更新更快。
新闻中心热点推荐
新闻中心以独特视角精选一周内最具影响力的行业重大事件或圈内精彩故事，为企业级用户打造重点突出，可读性强，商业价值高的信息共享平台；同时为互联网、IT业界及通信厂商提供一条精准快捷，渗透力强，覆盖面广的媒体传播途径。
云计算周刊
比特云计算周刊关注云计算产业热点技术应用与趋势发展，全方位报道云计算领域最新动态。为用户与企业架设起沟通交流平台。包括IaaS、PaaS、SaaS各种不同的服务类型以及相关的安全与管理内容介绍。
CIO俱乐部周刊
比特CIO俱乐部周刊以大量高端CIO沙龙或专题研讨会以及对明星CIO的深入采访为依托，汇聚中国500强CIO的集体智慧。旨为中国杰出的CIO提供一个良好的互融互通 、促进交流的平台，并持续提供丰富的资讯和服务，探讨信息化建设，推动中国信息化发展引领CIO未来职业发展。
IT专家新闻邮件长期以来，以定向、分众、整合的商业模式，为企业IT专业人士以及IT系统采购决策者提供高质量的原创内容，包括IT新闻、评论、专家答疑、技巧和白皮书。此外，IT专家网还为读者提供包括咨询、社区、论坛、线下会议、读者沙龙等多种服务。
X周刊是一份IT人的技术娱乐周刊，给用户实时传递I最新T资讯、IT段子、技术技巧、畅销书籍，同时用户还能参与我们推荐的互动游戏，给广大的IT技术人士忙碌工作之余带来轻松休闲一刻。
微信扫一扫
关注Chinabyte2505人阅读
Exception（16）
系统信息：
3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64 GNU/Linux
按官方Debian 。
在第二步出现
docker-engine : Depends: init-system-helpers (&= 1.18~) but it is not installable
Recommends: aufs-tools but it is not going to be installed
Recommends: cgroupfs-mount but it is not installable or
cgroup-lite but it is not installable
E: Unable to correct problems, you have held broken packages.
dpkg -i init-system-helpers_1.18_all.deb
docker 版本信息
Docker version 1.11.1, build 5604cbe
在第四步，出现：
docker: Error response from daemon: rpc error: code = 2 desc = “shim error: invalid argument”.
google下，结果并不多：
在这个页面中， 也有人有相同的问题。
We didn’t drop support for 3.2 as this kernel was never supported: it just happens that 1.11 is the first “obviously” incompatible release. @crosbymichael confirmed that this is due to containerd-shim usage of PR_SET_CHILD_SUBREAPER (introduced in 3.4).
就是没有对3.2放弃支持，但它是一个明显不兼容的版本。所以建议你升级系统内核。然后关了这个主题。
但安装指南上没说3.2不兼容。所以搞不懂了。
记录下来，也让越到相同问题的人少走些弯路。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：78100次
积分：1475
积分：1475
排名：千里之外
原创：71篇
转载：12篇
评论：23条
(4)(4)(1)(1)(1)(1)(1)(5)(1)(1)(1)(3)(1)(7)(2)(3)(1)(1)(2)(7)(3)(6)(14)(1)(1)(4)(7)(1)如何开始入门docker - 简书
如何开始入门docker
docker的出现,极大的改变了我们的软件发布模式.就好像集装箱对于现代运输业的影响, 可能是我们无法估量的. 那么如何开始呢?
首先需要如果是mac机器,可以使用brew进行安装, 这里推荐使用Boot2dcoker:
brew install boot2docker
安装后, 还需要初始化:
boot2docker init
在初始化结束后, 会提示你设置docker需要的环境变量, 你可以运行提示中的命令,也可以将提示中的环境变量放到你的 /etc/zshrc 或者bashrc中
国内访问docker的仓库 hub是会时常连接不上. 市面上已经有很多服务商提供镜像加速服务.
boot2docker ssh sudo "sh -c \"echo EXTRA_ARGS=\'--registry-mirror=[http://hub-mirror.\'](http://hub-mirror./') &&/var/lib/boot2docker/profile\""
DaoCloud, 阿里云, 网易蜂巢都有相应的免费服务. 但是Dao Cloud是需要自己登入一个系统然后接入镜像, 而阿里云和网易蜂巢都可以通过设置镜像链接的方式完成. 这里推荐使用网易蜂巢, 速度比较快.
为了镜像加速生效, 需要重新启动
boot2docker restart
docker search [字符串]
例如, docker search php
docker pull [镜像名]:[镜像tag]
例如, docker pull doctorq/infer:v1.1
查看已经拉取到本地的镜像
dock images
运行一个镜像(使用一个container装载一个image)
docker run [参数] [镜像id/镜像名] [初始命令]
常用的参数有:-d 代表以后台进程的方式运行-i 代表交互方式-P 代表container的端口会映射到宿主机器-t 代表tty
在前台,运行一个镜像, 加载成功后运行/bin/bash:
docker run -t -i -P d9fe /bin/bash
运行后, 我们可以通过docker 的ps命令查看运行状态:
~ docker ps
CONTAINER ID
"/bin/bash"
6 seconds ago
Up 5 seconds
0.0.0.0:32771-&22/tcp, 0.0.0.0:32770-&80/tcp
grave_mestorf
注意, 0.0.0.0:32770-&80 表示container的80端口是docker的32770.通过boot2docker的ip命令得到docker的ip
~ boot2docker ip
192.168.59.103
通过如下的地址就可以访问到container上的服务器:
http://192.168.59.103:32770/
人生就是需要一种踏鳄逐浪的淡定