2476人阅读
DevOps（11）
Docker（4）
参考资料：《The Docker Book》- Testing with Docker《Docker从入门到实践》– 标准化开发测试和生产环境构建基于 Docker + Jenkins + Sahi 的 Web UI 自动化测试环境利用 Docker 构建高度集成化的 Chef 开发测试环境深入浅出Docker（四）：Docker的集成测试部署之道Move fast and don’t break things! Testingwith Jenkins, Ansible and DockerTesting Made Awesome with DockerContainer Technology: Integration Testingwith DockerECS Docker实践文档&1、Docker目前有以下应用场景：测试：Docker很适合用于测试发布，将 Docker 封装后可以直接提供给测试人员进行运行，不再需要测试人员与运维、开发进行配合，进行环境搭建与部署。测试数据分离：在测试中，经常由于测试场景变换，需要修改依赖的数据库数据或者清空变动 memcache、Redis 中的缓存数据。Docker 相较于传统的虚拟机，更轻量与方便。可以很容易的将这些数据分离到不同的镜像中，根据不同需要随时进行切换。开发：开发人员共同使用同一个 Docker 镜像，同时修改的源代码都被挂载到本地磁盘。不再因为环境的不同而造成的不同程序行为而伤透脑筋，同时新人到岗时也能迅速建立开发、编译环境。PaaS云服务：Docker 可以支持命令行封装与编程，通过自动加载与服务自发现，可以很方便的将封装于 Docker 镜像中的服务扩展成云服务。类似像 Doc 转换预览这样的服务封装于镜像中，根据业务请求的情况随时增加和减少容器的运行数量，随需应变。使用 Docker 来做分布式集群模拟&2、Docker在测试领域的应用：1）快速搭建兼容性测试环境（各类Web服务器、中间件、数据库的组合环境）2）快速搭建复杂分布式测试环境3）持续集成（快速创建和撤销容器）&3、Docker对测试方式的影响：1）、容器级测试2）、测试前移（功能模块-容器）3）、集成测试4）、自动化测试、并行测试5）、可扩展性测试6）、兼容性测试（例如验证兼容MySQL和Postgres）&标准化容器开发和测试环境Docker就像工厂中的流水线，将一个个集装箱（模块化的功能）传输到发货区（上线发布）。&传统模式和Docker模式在测试方式上的区别：基于Docker的测试场景：在开始测试之前，测试工程师需要确保自己的测试机上已经安装了Docker并处于运行状态，必要时需保证Docker的版本与最终生产环境一致。&测试环境搭建好之后，根据测试请求说明的镜像地址拉取镜像，并按要求运行，根据镜像的目的测试所实现的业务。&如果在测试过程中发现bug或不符合需求，应尽快反馈给开发人员，开发人员修正后，重新将镜像推送到注册服务器，测试人员从镜像库拉取最新修改的镜像继续测试。反复几轮直到达到可发布的版本。最后，测试人员发布测试合格报告，并注明最终的镜像版本。&如果多个测试工程师同时测试，各自使用自己的测试容器，还能保证测试之间不被干扰。&&Docker模式下，开发-测试-运维的协作模式：以一个简单的应用开发、测试和发布来说明 Dock er 在阿里云 E CS 上的运用：1) 运维人员在 ECS 上搭建私有 Docker Registry。2) 开发人员在开发 ECS 上从阿里云或私有 Docker Registry 获取应用需要的基础镜像。3) 开发人员开发 ECS 上构造应用容器，自测后?交容器为新的镜像并推送到私有 Docker Registry，通知 QA 测试。4) QA 在自己的测试 ECS 上启动容器，测试后，有问题则 a)，没问题则 b)。& a) 通知开发修复，回到步骤 3)。& b) 交到私有 Docker Registry，准备发布。5) 发布人员下载最新版本镜像并在生产ECS 上启动容器。&&Docker时代，对测试的技能要求：1、基于Docker的测试环境搭建能力2、微服务架构的测试能力3、基于容器与开发、运维的协作能力&&最后，关于Docker在测试领域的应用，我们还缺乏比较多的尝试和实践，例如：基于容器的应用，对其实施自动化测试与传统应用有哪些差异？基于容器的应用，在性能上与传统方式的部署，差异有多大？基于容器的应用，在安全测试方面，跟传统应用有哪些差异？&
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：3318668次
积分：44838
积分：44838
排名：第53名
原创：925篇
转载：197篇
译文：96篇
评论：1015条
(1)(1)(1)(1)(1)(2)(2)(7)(1)(1)(2)(1)(2)(1)(4)(5)(5)(12)(2)(3)(6)(13)(13)(28)(14)(20)(13)(12)(8)(17)(22)(20)(16)(28)(20)(22)(11)(27)(14)(9)(4)(1)(7)(5)(10)(15)(6)(16)(17)(28)(25)(28)(17)(19)(7)(11)(10)(12)(8)(4)(1)(5)(3)(3)(4)(5)(11)(23)(53)(36)(107)(19)(8)(2)(6)(7)(1)(2)(2)(16)(10)(28)(51)(43)(8)(13)(8)(32)(21)(6)(21)(49)(17)(7)比特客户端
您的位置：
详解大数据
详解大数据
详解大数据
详解大数据
生产环境下的Docker：成功、挫败和教训
关键字：Docker
　　Docker在2014年迎来了迅猛的发展，不过在年底传出了围绕Docker的一些声音，声称容器服务基础设施已达到了准备用于生产环境的程度。今年，Gartner等调研公司已经列出了Docker部署到中分布式应用程序中的安全挑战，不过都相当支持Docker总体的发展方向。新年伊始，已经出现了好几个例子，它们证明了使用容器以便持续改进和日常部署在生产环境中的准备就绪状况。
　　用户们的体验不一而足：有的用户坚信可以使用Docker大规模部署分布式Web应用程序;有的用户已把Docker整合到生产环境中;有的用户决定还没有这么做，而有的用户则拒绝Docker，认为它太过复杂或不够稳定，无法用于实际的使用场合。
　　下面不妨看一下这四个例子，它们证明了用户如何考虑Docker用于生产环境：
　　Battlefy：交付新的功能特性
　　师Jaime Bueza最近撰写的一篇博文表明了初创公司Battlefy如何使用Docker和Jenkins工具，在其eSports平台上发布新的功能特性时，迅速构建并发布Docker映像，然后将映像部署到AWS Elastic Beanstalk上，或者修复软件错误。在过去的五个月，Battlefy的访客数量已从100个猛增到400000个，它所在的行业预计全球收入有望增长24%;国际用户群数量已经超过了7000万。
　　Battlefy从功能特性或软件错误的GitHub合并请求(pull request)入手，连接到JIRA工单，然后利用测试版工具Screener来检测每个版本的DOM变化，并将差异做入屏幕截图。结果被发送到团队的Slack频道，队成员给代码打上两个大拇指表情符号后，Jenkins就向AWS S3交付新的代码;Docker容器被用来构建生产前环境。在生产前环境中完成另一轮的Screener前端测试后，Jenkins随后得以自动将合并请求并入到主生产环境中。
　　Battlefy生怕遇到生产环境中的任何故障，于是使用AWS Elastic Beanstalk，那样如果构建、推送和部署的Docker映像有错误，Battlefy就能迅速恢复到前一个版本。
　　Iron.io：在微服务环境中运用Docker
　　Iron.io是IronMQ消息队列系统和IronWorker异步任务处理工具的开发商，它自豪地自认为是Docker的早期采用者;对它来说，微服务架构已俨然成为运行时环境的标准化模式。
　　在近日的一篇博文中，渠道和整合主管Ivan Dwyer解释，对Iron.io来说，它们之所以能避免生产环境在安全、发现和故障方面的重大挑战，就是因为它们在容器层面把Docker整合到系统中：
　　“我们把每一个任务容器视作一种暂时的计算资源。持续性、冗余性和可用性，我们在服务层面扩建产品时非常注重这一切要素，未必适用于单个的任务容器层面。我们在这方面关注的问题实际上局限于确保本该运行时运行，好让我们确信如今在充分利用Docker。”
　　IronWorker在块中拥有超过15套的Docker映像，它们为运行中的代码提供了语言和库环境。IronWorker的客户随后只能利用编写代码所需的库，并上传到Iron.io的S3文件环境，他们的消息队列将底层的Docker映像与用户的代码程序包在新的容器里面合并起来，运行进程，然后销毁容器。
　　Iron.io在微服务环境下工作，许多遗留的企业生产环境无法使用这种环境，因为它们的可组合性根本不如Iron.io支持的环境。但是就较新的应用开发环境而言，Iron.io可以在生产环境中使用Docker，帮助最终用户管理成本，并且根据需要在编排基础设施里面扩展进程。
　　Mikamai：开发公司期望Docker与Opsworks一并部署
　　来自开发商Mikamai的开发人员Giovanni Intini总结了许多成熟的开发人员在Docker方面的几个常见问题：乍一看，大家这个概念;他们也喜欢其潜力。不过他们也都有过前车之鉴，不敢过于仓促地采用新技术，因为那样会导致他们在部署到生产环境后不得不通宵达旦地工作或者放弃为期三天的周末。对二十出头的编程新手来说，这可能很好玩;但是对于三四十岁的人来说，工作不是生活的全部，在生产就绪的环境中采用新技术面临的风险是更重大的决定性因素。
　　Intini仍然看好Docker的潜力;由于基于云的开发运维(DevOps)生态系统还没有足够成熟起来，他构建了一些新的开源项目，以便使用亚马逊的Opsworks(目前还无法支持Docker)等既有服务，能够将Docker化的容器服务部署到生产环境中。
　　Intini的应用架构需要负载均衡系统、前端、避免任何故障时间的haproxy、应用容器、Redis、PostgreSQL、计划任务(cron)和异步处理。他想把将其应用程序构建成具有可扩展性的docker化的应用程序。问题在于，当他开发的应用程序在亚马逊网络服务云上运行时，Docker其实并不是一种选择。Intini在近日的博文中分享了用来构建扩展其应用程序的生产就绪的环境的代码和进程，现在他声称其应用程序在部署环境中的停运时间为零。
　　XMLDirector：反对使用Docker
　　Andreas Jung是XMLDirector的项目负责人，而XMLDirector是一个XML内容管理系统和工作流平台，旨在支持企业XML环境，其工具可以转换发布格式以及管理文档集合。
　　两周前，他撰文描述了如何试图在生产环境中使用Docker，将特定的XML类型放入到容器中，以便它们可以迅速地安装和管理;将Plone企业内容管理系统应用程序放入到容器中，以便它可以用于XML的演示;以及将众多XML特有的数据库放入到容器中，以便它们可用于对照处理其他XML数据库后端的方法，测试XML Director的后端。
　　可惜Docker没有给Jung留下深刻的印象。他发现，通常的构建过程比使用外壳还要慢5倍至10倍;几个进程需要重启D由于Docker创建多个映像和容器，测试后删除系统上的副本需要一番“捣鼓”。
　　试图使用Docker无果后，Jung只好回到“老式的部署环境”，尽管他也承认Docker背后的理论和概念确实不错(不过他表示“Docker的架构和实施一团糟。Docker在生产环境中完全不稳定。它不可靠，无法预测，靠不住。”)
　　准备好用于生产环境吗？视情况而定
　　Docker已得到了巨大的发展，生态系统在不断扩大，而且容器化系统在金融机构、媒体及其他大规模跨国企业领域当中得到了采用。虽然Docker的容器技术迅速被认为是构建投入到生产环境的分布式应用程序的标准，但早期采用者发觉它最适合这种使用场合：企业已经深思熟虑了如何为其应用程序构建微服务架构。
[ 责任编辑：李桢君 ]
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技术人士忙碌工作之余带来轻松休闲一刻。
微信扫一扫
关注Chinabyte你的浏览器禁用了JavaScript, 请开启后刷新浏览器获得更好的体验!
各位好，我在一家在线游戏的开发公司供职。目前我正在尝试把公司内部的开发测试环境切换到自建的Docker云上。其他一切都还顺利，现在碰到一个问题。
游戏开发中，会有一些时间相关的脚本，例如开服n天后，发放某个礼品之类的。我们之前的操作模式是把虚拟机的时间调整到这个时间，然后看礼品发放是否正确执行。
但是现在Docker的话，容器内无法自行修改时间，在Docker主机上修改的话，又会影响这台主机上所有的容器的时间。
考虑的资源复用，我们可能也无法在一台主机上只跑这个测试相关的进程。
所以。。。。想问问大家，是否碰到过类似问题，大家都是怎么解决的？
不用非得该系统时间吧，可以考虑EVN传时间差，曲线救国。
你想让container1中获取的系统时间是now-1m，可以docker run -e TIME_DIFF=-60 ...，container中calc脚本获取container系统当前时间为：${now}-${TIME_DIFF}
当然肯定还有其它办法。
如果要改获取时间的脚本，可能你的改动量比较大。我的建议是：
在准备测试的时候，执行date强制把容器时间修改了（当然主机时间也被修改）
然后做测试，验证，验证完毕之后使用ntpdate或者date把时间更正回来。
这个过程可以用脚本完成，也可以用容器来做（就是把date命令作为容器的CMD）。
这个的弊端就是会影响到主机内的其他容器。不过既然是测试环境，应该不会有大问题（因为测试验证完又改回来了）。你可以自己评估下。
哥们，找到好的方式解决了吗？
要回复问题请先或
浏览: 3436
关注: 7 人收藏（253）
作者：心如止水
原文链接：//Jenkins-Docker搭建持续集成测试环境/
本文将重点讨论在Jenkins管理的持续集成以及测试的环境中，我们如何通过引入Docker来优化资源的配置，提高整个环境的性能以及稳定性。
关于Jenkins
Jenkins是被广泛应用的持续集成、自动化测试、持续部署的框架，甚至有些项目组顺便将其用来做流程管理的工具。根据任务的多寡，Jenkins通常有两种典型的部署方式。
单节点（Master）部署
这种部署适用于大多数项目，其构建任务较轻，数量较少，单个节点就足以满足日常开发所需。
多节点(Master-Slave)部署
通常规模较大，代码提交频繁（意味着构建频繁），自动化测试压力较大的项目都会采取这种部署结构。在这种部署结构下，Master通常只充当管理者的角色，负责任务的调度，slave节点的管理，任务状态的收集等工作，而具体的构建任务则会分配给slave节点。一个Master节点理论上可以管理的slave节点数是没有上限的，但通常随着数量的增加，其性能以及稳定性就会有不同程度的下降，具体的影响则因Master硬件性能的高低而不同。
关于Docker
Docker是一款针对程序开发人员和系统管理员来开发、部署、运行应用的一款虚拟化平台。Docker 可以让你像使用集装箱一样快速的组合成应用，并且可以像运输标准集装箱一样，尽可能的屏蔽代码层面的差异。Docker 会尽可能的缩短从代码测试到产品部署的时间。简单来说Docker提供了一种技术，可以让开发人员方便地将应用代码已经运行时的环境一并打包到一个镜像中，然后将这个镜像上传至镜像仓库。在测试或者产品环境只需要下载这个镜像然后将其启动就完成了部署（就好比打开一个集装箱那么简单）。关于Docker更详细的内容请参考。
当前Jenkins遇到的困难
随着敏捷开发的普及，自动化测试成为每个项目的必须。一个经过多年开发的项目，其累积的自动化测试数量是惊人的。为了保证每次的部署都是正确的，就需要每次回归所有的自动化测试用例。根据项目的不同，有些需要每周跑一轮回归测试，而有些项目则需要每天一轮。所以我们会把所有的测试用例进行分组，同时在多台测试机上运行，以减少一轮测试所需要的时间。而这就要求我们有足够多的硬件资源来满足这需求。下图展示了一个典型的通过Jenkins来管理自动化测试的拓补结构。一台Master主机管理多台测试机，Master将测试任务分配给测试机。
当前Jenkins（Master-Slave）结构当前Jenkins（Master-Slave）结构
这种结构存在一些缺陷：
自动化的测试通常都是通过捕捉屏幕控件来模拟用户的行为以达到测试的目的，这就意味着一台测试机上只能同时运行一组测试用例，否则用例之间就会相互干扰。这就存在资源浪费，因为测试机的配置往往可以支持多组测试用例。
维护人员得确保测试机都保持在线，当测试机器数量较多的时候，比如100台甚至1000台的时候，这维护的压力就比较大。
通常回归测试是在晚上运行（如此就能在开发组第二天上班时发现前一天提交的代码是否正确），但这上百台测试机不论白天晚上都在工作状态，这是另一维度的浪费。
很重要的一点，测试机器会因为各种原因导致测试环境被污染，导致测试不能顺利进行，而此时除了维护人员手工处理外，没有特别好的方案。
之前我们提到过，当slave数量达到一定程度的时候，作为Master的节点就会出现性能变差，稳定性下降。
每个Slave节点在开始跑测试之前都需要从中央库下载最新的分发包，解压，设定运行环境。这个过程通常也占用不少时间，想象一下，突然间上百个slave开始下载最新的库，这对中央库是一个极大的冲击。
如何引入docker来解决这些问题
很自然的一个想法就是将测试机全部替换成Docker容器（container），而管理这些容器的工作交给更专业的工具，如google的Kubernetes或者Docker官方提供的Swarm。所有构建的环境都打包进Docker的镜像文件中，自动化测试是一个镜像，编译单元测试是一个镜像等等。改进后的拓扑结构如下图所示：
在这个方案中唯一的技术问题是自动化测试需要桌面系统，而通常Docker容器中运行的都是无图形界面的应用。解决的方法也非常直接，我们在容器中提供桌面系统（VNC服务）。根据不同的linux发行版本，我们可以选择tightvnc或者tigervnc。不论选择哪种vnc服务，他们都提供一个虚拟桌面，可以通过vnc的客户端远程连接到该桌面进行操作。
对应前文提到的6个不足，在这种结构下悉数得到了解决。
每个测试机可以同时运行多组自动化测试用例，也就是说跑原来相同数量的回归测试，这种方案下可以至少节省一半的测试机。
通过Kubernetes或者swarm，我们可以实现对容器的自动化管理，从而减轻维护人员的工作。
Docker容器可以根据需要动态增减，又因为构建所需的一切环境都被封装在Docker的镜像中，这些测试机器可以被方便的用于其他任务的构建，而不需要进行额外的配置。只需要下载其他构建任务的镜像，然后将其启动。
每次测试启动一个全新的容器，所以环境是完全干净的。当某个容器出现问题的时候，这个容器就会被销毁，同时新起一个容器完成相同的测试工作。
在这种结构下Jenkins只需要管理一个slave节点，而Kubernetes和swarm则可以管理成千上万个容器。
在同一个Docker环境中（同一台测试机）只需要下载一次最新的自动化测试的镜像就能起多个容器，而在这种结构下，测试机数量已经大大减少，从而对中央库（私有镜像仓库）的冲击也明显减轻了。
更多的思考
一个项目开发了5年，就累积了上万回归测试，需要几十台测试机不间断的运行8、9个小时才能完成；设想下，这个项目还要继续运行5年甚至10年呢？我们的测试机的数量将会是多少，我们的测试反馈周期还是8、9个小时么？根据我们的观察，经过多年的维护，很多功能模块已经是非常完善，基本很少有代码的修改。那么这些功能对应的测试用例是否有必要每次都跑呢？答案我想是否定的，但问题是怎么来判断当前代码的修改是否会影响到这些功能模块呢？按照现在的设计，我想没有人敢百分百的肯定。我们是否有必要对现有代码做些调整，依照微服务的思想，把我们的分发包拆分下，每次只需要发布有更新的模块。如此一来我们递归的自动化测试用例也只需要包含有改动的那些模块。那时候，很可能我们可以在每次代码提交就运行一次回归测试。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：88194次
积分：1337
积分：1337
排名：千里之外
转载：258篇
(4)(3)(4)(2)(4)(5)(3)(19)(6)(10)(31)(4)(11)(20)(5)(4)(11)(2)(8)(2)(13)(14)(21)(16)(10)(6)(5)(2)(9)(5)}