作者 11:11系统运维工程师, 互联网关注310Docker Workflow（一）：一个可用于生产环境的Docker工作流字数 5513阅读 482评论 0赞 0作者工作于墨西哥IIIEPE研究院，他将通过一系列文章，为我们逐一讲述他们在Docker实际应用过程中的经验与教训，给后来者提供一些参考。本文主要介绍了他基于Docker的开发工作流，包括GitLab、Jenkins、Registry、Nginx。Docker现在已经两岁了（译者注：Docker于日首次发布），已经在生产环境中使用Docker3个来月。在此，我分享一些我们的经验和设计的工作流。我们运行着多个使用Drupal、PHP和Node.js的网站，我们的目标是使用Docker运行所有的应用，因此我们设计了以下工作流：所有开发人员使用Docker来创建应用。我们的GitLab实例配置了Webhook，当检测到一个新的推送时，它将命令Jenkins运行一个任务。每个Jenkins任务都包含相同的布置：从GitLab中克隆最新代码，运行测试，登录到我们的私有Docker Registry，使用最新代码构建一个新的镜像，然后将镜像推送上去。最后，我们的编排软件Maestro-NG将部署新版本的镜像。我们的负载均衡器将检测这些变化，并重载新的配置。每一个步骤都需要几天的规划、测试和工作来设计基本准则。我们做的第一件事是构建满足自己要求的基础镜像。镜像发布到中，它们包含了除了应用本身之外所有用于运行应用的东西。每次修改其中一个基础镜像，我们就会运行一个Jenkins任务来拉取新镜像，并触发后续任务来重新构建依赖此基础镜像的所有镜像。创建完镜像之后，我们需要为所有应用定义一个标准结构。我们所有的应用都使用以下结构来组织：/application
Dockerfile
fig.yml.example
docker-compose.yml.example
/application目录是应用的根目录。/logs和&/files目录用于开发，以便应用可以写入日志和文件。这两个目录会被Git忽略，并在生产环境中完全排除。Dockerfile是Jenkins用于构建镜像的文件，开发人员几乎不需要接触这个文件，后面详述。fig.yml.example和docker-compose-yml.example是开发人员用于启动应用的文件。这二者均不用于生产环境，当开发人员克隆一个项目时，他需要复制这个example文件并填入他/她的值。Makefile是拼图的最后一块，通过它我们可以拥有一个标准的命令集用于所有应用，并对开发人员隐藏各种各样的复杂性。Dockerfile每个应用的Dockerfile与其它应用非常类似，这个文件的最重要工作就是构建包含所有待部署代码的最终镜像。我们来看一个例子：FROM&iiiepe/nginx-drupal6
ENV&MYSQL_ENV_MYSQL_DATABASE&somedb&&
ENV&MYSQL_ENV_MYSQL_USER&root&&
ENV&MYSQL_ENV_MYSQL_PASSWORD&123&&
ENV&MYSQL_PORT_3306_TCP_ADDR&localhost&&
ENV&MYSQL_PORT_3306_TCP_PORT&3306&&
ENV&BASE_URL&&&
ENV&DRUPAL_ENVIRONMENT&production
RUN&usermod&-u&1000&www-data&&
RUN&usermod&-a&-G&users&www-data
ADD&./application&/var/www&&
RUN&chown&-R&www-data:www-data&/var/www&&
Dockerfile依赖于我们构建的基础镜像，在此之上，它只是设置了一些环境变量默认值、声明要暴露的端口，并将应用代码添加到/var/www。正因为我们构建镜像的这种方式，在Jenkins和开发人员之间唯一的差别是，Jenkins将添加整个应用目录到/var/www中，而开发人员只是映射一下目录。接下来这个是Docker Compose，他非常酷。mysql:&&
image:&mysql:latest
environment:
MYSQL_DATABASE:&database
MYSQL_USER:&root
MYSQL_PASSWORD:&admin123
MYSQL_ROOT_PASSWORD:&admin123
image:&iiiepe/nginx-drupal6
-&application:/var/www
-&logs:/var/log/supervisor
-&files:/var/www/sites/default/files
-&mysql:mysql
environment:
BASE_URL:&http://local.iiiepe.net
DRUPAL_ENVIRONMENT:&development
Docker Compose用此文件来初始化。在本例中，我们定义了一个应用，它包括两个容器：一个MySQL容器和一个Web容器。MySQL容器定义了mysql镜像要使用的环境变量。同时将宿主的3307端口映射到窗口的3306端口上。这允许我们使用任何客户端访问MySQL服务器。web容器使用了与Jenkins构建最终镜像时使用的相同镜像（见上述Dockerfile），但它同时共享了一些数据卷。在宿主和容器间共享的卷有应用、文件和日志。这实际是开发环境和生产环境间最大的改变：在生产环境中，容器的代码是在镜像中的，这允许我们在任何服务器上启动容器；而在开发环境中，目录只是共享的，因此在应用目录里，任何新的文件或对文件的修改都将即时地反映到容器里。BASE_URL变量指向了，这不是个真实的地址，只是用于标准化应用访问的一个方式。因为我们有些人使用Mac和Boot2Docker，我们需要一个标准的地址以便所有人可以将其写入到/etc/hosts文件中。我的Mac上的/etc/hosts是这样的：127.0.0.1&&&&localhost
192.168.59.103&&&&local.iiiepe.net
在一台Linux机器上，看起来是这样的：127.0.0.1&&&&localhost&local.iiiepe.net
最后，我们定义了两个环境变量来决定应用的配置文件的一些设置。自定义设置Drupal需要一个settings.php来存储数据库信息，包括密码。该文件将被Git忽略，以免将你的密码提交上去，我们决定修改这个文件，让它使用环境变量并将其提交。以下是一个Drupal 6网站的settings.php里的重要部分：$username&=&getenv("MYSQL_ENV_MYSQL_USER");
$password&=&getenv("MYSQL_ENV_MYSQL_PASSWORD");
$host&=&getenv("MYSQL_PORT_3306_TCP_ADDR");
$port&=&getenv("MYSQL_PORT_3306_TCP_PORT");
$database&=&getenv("MYSQL_ENV_MYSQL_DATABASE");
$db_url&=&'mysql://'&.&$username&.&':'&.&$password&.&'@'&.&$host&.&'/'&.&$
正如你所看到的，没有密码会被提交。密码和其它敏感值将通过ENV变量注入。有些网站使用Apache Solr作为搜索引擎，但在开发时，我们不希望能写入到Apache Solr，因此需要一个类似DRUPAL_ENVIRONMENT的ENV变量，完成类似下面的settings.php文件的事情：$conf&=&array();
if(getenv("DRUPAL_ENVIRONMENT")&===&"development")&{&&
//&Disable&apache&solr&writting
$conf["apachesolr_read_only"]&=&1;
Makefile由于命令很长，使用Docker非常不便，因此Docker Compose（fig）对此很有帮助。我们更进一步尝试让事情变得更简单一些。这是我们使用在一个Drupal网站上的Makefile：CURRENT_DIRECTORY&:=&$(shell&pwd)
@fig&up&-d
@fig&rm&--force
@fig&run&--rm&web&bash
@tail&-f&logs/nginx-error.log
@fig&run&--rm&web&drush&cc&all
restart:&&
@fig&stop&web
@fig&start&web
@tail&-f&logs/nginx-error.log
.PHONY:&clean&start&stop&status&cli&log&cc&restart
使用Makefile比使用Docker Compose或Fig简单得多，因为我们可以创建类似make cc的快捷方式来运行类似drush cc all这样频繁使用的命令。有关Makefile的最后一点说明是：我们依然使用Fig。因为在我们设计这个工作流时，Docker Compose还不可用，而且我们团队里的一些开发人员还在使用它，我们决定为Docker Compose建立名为Fig的符号连接，名称更短且更实用。安装Docker Compose后，你可以删除fig并创建符号连接：sudo&rm&/usr/local/bin/fig&&
sudo&ln&-s&/usr/local/bin/docker-compose&/usr/local/bin/fig&&
走的弯路我们走过一些弯路，我将在别的文章中做介绍，不过有一个我想特别说一下。使用Docker最大的好处是，开发人员可以在与生产环境相同的环境上运行应用，且只损失一点点性能。我看过一些文章，说他们在Docker之外做开发，然后在需要部署时构建镜像并发送到生产环境。如果你这么做，那你就错了，因为你开发所用的环境与生产机上运行的不一致。不要每次都构建镜像，相反的，在宿主和容器间共享卷，让别人在你每次推送时构建镜像。如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！相关文章评论 0 · 赞 0评论 0 · 赞 0评论 0 · 赞 0评论 0 · 赞 1评论 0 · 赞 0Docker为何未在生产环境中取得广泛成功？_Linux新闻_Linux公社-Linux系统门户网站
你好，游客
Docker为何未在生产环境中取得广泛成功？
来源：51CTO &
作者：布加迪编译
Docker的发展势头一天比一天强劲，它显然在试图解决实际的问题。然而，对如今许多的生产环境用户来说，没有出现优点压倒缺点的局面。在开 发、测试和持续性集成等环境下，Docker在让容器吸引广大开发人员方面确实有上佳的表现，不过它还没有颠覆生产环境。按照DockerCon 2015的&生产环境下的Docker&这一主题，我想公开讨论Docker想在生产环境使用场合下得到广泛采用还没有克服的种种挑战。这里提到的问题没 有一个是新问题，它们都以某种形式出现在GitHub上。大多数问题我已经在大会演讲中或与Docker团队交流中讨论过。本文倒不是要明确指出什么不再 是问题：比如说，新注册中心(registry)克服了旧注册中心的许多不足。本文并没有提到仍然问题重重的许多方面，不过我认为下面这些问题是近期内需 要解决的最重的问题;只有解决了这些问题，更多的企业组织才能够迈出一大步，在生产环境中运行容器。我在电子商务公司Shopify运行Docker的经 历对本文有很大的影响;一年多来，我们一直在容器上大规模运行核心平台。由于像Docker这样发展这么迅猛的技术，不可能一切都保持现状。如果你发现不 正确之处，务必联系我。
15.04下安装Docker&
配置 Docker 镜像下载的本地 mirror 服务&
Docker安装应用( 6.5_x64) &
在 Docker 中使用 MySQL
在Ubuntu Trusty 14.04 (LTS) (64-bit)安装Docker &
Docker安装应用(CentOS 6.5_x64) &
Ubuntu 14.04安装Docker& &
阿里云CentOS 6.5 模板上安装 Docker &
为大型应用程序构建容器映像依然是个挑战。如果我们要依赖容器映像用于测试、持续性集成和紧急部署，就需要在不到1分钟的时间内将映像准备就绪。 Docker文件(Dockerfile)让这对大型应用程序来说几乎不可能。虽然Docker文件易于使用，但是位于过高的抽象层，无法支持复杂的使用 场合：
带外缓存，面向特别错综复杂的、针对特定应用程序的依赖项;
在构建时访问密文(密码、密钥和相关内容)，又不将它们提交给映像
全面控制最终映像中的层
并行处理构建层
大多数人并不需要这些功能，但是对大型应用程序而言，其中许多功能是快速构建映像的先决条件。Chef和Puppet等配置管理软件使用广泛，但 是让人觉得用于构建映像过于笨拙。我打赌，在今后十年内，现有形式的这类系统会因容器而逐渐退出历史舞台。然而，许多应用程序依赖它们来配置、部署和编 排。Docker文件无法真实地记录下现在由配置管理系统管理的复杂性，但这种复杂性需要在某个地方加以管理。在Shopify，我们最后使用 docker commit API，从头开始构建了自己的系统。这个过程很麻烦，我希望这一幕不会出现在任何人身上，我很想摆脱这种局面，但是我们又不得不扫除障碍。很少有人会花这 么大的力气去管理用于生产环境的容器。
这个领域会出现什么情况不得而知;目前在这个领域，开展的研究工作并不多(一个例子是dockramp，这是另一种打包器)。Docker引擎会 在将来有所改进，将构建基本步骤(添加文件和设置入口点等)与客户端(Docker文件)分开来。为版本1.8所做的合并工作已经让这变得更容易，为配置 管理工具厂商、业余爱好者和公司进行试验尝试创造了条件。考虑到配置系统的历史还很短，认为一种标准有望搞定这个问题(就像运行时标准那样)是不切实际 的。什么时候可以实现可扩展的映像构建，相当不明朗。据我所知，没人在积极迭代，很遗憾这种现状已维持一年多了。
每个部署的重大Docker系统到头来要编写垃圾收集器，以便清除主机上的旧映像。使用了各种启发式方法，比如清除超过X天的旧映像，在主机上最 多执行Y个映像。Spotify最近开放了其系统的源代码。我们还在很久以前就编写自己的垃圾收集器。我能明白为此设计一种易预测的用户界面(UI)有多 难，但是这又是核心中绝对需要的。当生产环境的机器嚷着要存储空间时，大多数人无意中发现要求收集垃圾。最后，你会遇到同一映像，Docker注册中心因 庞大映像而溢出，不过这个问题已列在了发行版路线图上(详见/docker/distribution/blob /master/ROADMAP.md#deletes)。
迭代速度和核心状态
Docker引擎致力于1.x版本的稳定性。在版本1.5之前，降低准入门槛以便在生产环境得到采用方面所做的工作不多。开发容器的公众心理模式 对Docker的成功而言必不可少，Docker害怕破坏这种模式是有其道理的。如果用户体验(UX)方面的每个变化经历的过程时间过长，迭代速度难免受 到影响。自版本1.7起，Docker开始发布试验性版本，以网络和存储插件带头。这些功能特性被明确标为&未准备用于生产环境&，可能会从核心中取出或 者随时经历重大变化。对于早已看好Docker的公司来说，下面这个是好消息：它让核心开发团队可以更快速地迭代开发新功能，不用担心本着最佳设计的精神 而破坏次要版本之间的向后兼容性。公司仍然很难改动Docker核心，因为它需要分支――这是导致最终失败的行为和维护负担，或者需要得到上流接受;对于 值得关注的补丁来说，这常常很耗费人力。自版本1.7起，宣布插件后，解决这个问题的策略就很明确：让每一个固执己见的的组件都可以插入，最后显示了&带 电池而且可以更换&这种理念的成果，这种理念最早是在2014年的DockerCon欧洲大会上提出来的(不过相当模糊)。在6月份的DockerCon 大会上，很高兴听到这归入到&管道&(Plumbing)这个大主题来探讨，作为核心开发团队的重中之重。虽然未来终于大有希望，但是这在今天仍然是个痛 点，就跟过去两年一样。
日志是表明有望得益于之前变化的一个方面的例子。这并不是引起强烈关注的问题，却是普遍性的问题。目前没有理想的、普通的解决方案。日志到处都 是：尾部日志文件、容器里面的日志、通过挂载发送到主机的日志、发送到主机syslog的日志，通过fluentd(开源数据采集器)等工具来暴露日志， 从应用程序直接发送到网络的日志，或者发送到文件的日志，让另一个进程将日志发送到Kafka。在版本1.6中，支持日志驱动程序的功能已并入到核心中 (/2015/04/docker-release-1-6/);然而，驱动程序在核心中必须得到接受 (这并非易事)。在版本1.7中，已并入了试验性支持进程外插件的功能，但是让我失望的是，它并不随带日志驱动程序。我认为，版本1.8会计划添加这项功 能，但是在官方记录中找不到这项。到那时，厂商们就能够编写自己的日志驱动程序。社区内部的共享将轻而易举，大型应用程序再也不必求助于设计定制的解决方 案。
迁移到容器的人大多数依赖配置管理，在机器上安全地配置密文;然而，继续沿着配置管理这种老路子配置容器中的密文很笨拙。另一个办法就是将密文与 映像一同分发，但是这带来了安全风险，而且很难在开发、持续性集成和生产环境之间安全地回收映像。最纯粹的解决办法就是通过网络访问密文，让容器的文件系 统保持无状态。就在不久前，这方面还没有任何面向容器的机制;不过最近，两家颇令人关注的密文代理系统 Valut(https://vaultproject.io)和Keywhiz(/square /keywhiz)开放了源代码。在Shopify，我们一年半前开发了ejson(ejson是一种简单的库，用嵌入在JSON文件中的公钥加密该文件 中的所有值，详见/technology/-secrets-at-shopify- introducing-ejson)，以解决这个问题，从而管理JSON文件中非对称加密的密文文件;然而，它就所运行的环境有一些假设，因而让它与密 文代理系统相比，不是很理想的一般性解决方案(如果你很好奇，可以参阅这篇文章/technology /-secrets-at-shopify-introducing-ejson)。
更多详情见请继续阅读下一页的精彩内容：
相关资讯 & & &
& (昨 09:28)
& (02月13日)
& (昨 09:42)
& (02月24日)
& (02月11日)
　　　同意评论声明
　　　发表
尊重网上道德，遵守中华人民共和国的各项有关法律法规
承担一切因您的行为而直接或间接导致的民事或刑事法律责任
本站管理人员有权保留或删除其管辖留言中的任意内容
本站有权在网站内转载或引用您的评论
参与本评论即表明您已经阅读并接受上述条款Docker生产环境架构讨论_Go中国_传送门
你是真实用户吗(Are you a robot)?
我们怀疑你不是真实用户，已对你的访问做了限制。如果您是真实用户，非常抱歉我们的误判对您造成的影响，您可以通过QQ()或电子邮件()反馈给我们，并在邮件和QQ请求信息里注明您的IP地址：220.177.198.53，我们会尽快恢复您的正常访问权限。另外，如果您不是在访问的当前页面，我们建议您移步
或者 在浏览器中输入以下地址：http://chuansong.me/n/ 访问，您所访问的网站是从抓取的数据，请直接访问，会有更好的体验和更及时的更新。We suspect you are a robot.We are really sorry if you are not,and you can email us () with your current IP address: 220.177.198.53 to get full access to .If you are not accessing
for the current page,you'd better visit
for better performance,as the current website you are accessing is just spam.
觉得不错，分享给更多人看到
Go中国 微信二维码
分享这篇文章
Go中国 最新头条文章
Go中国 热门头条文章}