【IT168评论】Docker自2013年成立以来一直主导DevOps对话，引发了对容器驱动管道的兴趣，并帮助组织通过转移到容器上的全栈部署来转换应用程序。按照市场兴趣，许多云供应商也急于支持Docker在他们的服务，预计未来的开发团队，将与今天的团队有明显的不同。无论如何，容器将改变应用程序的构建，测试和部署方式。
尽管关于容器技术的探讨层出不穷，但是没有一个关于容器如何适应现有应用程序和开发团队的共识。 Devs是Docker的狂热粉丝，但仅倾向于将它用于沙盒和原型。 QA没有看到Docker如何影响他们的工作流。而ops对于Docker的安全问题很担心，宁愿选择传统的VM。即使devop旨在使这三个函数更接近。
Docker的区别
作为组织中的质量保证领导者，可能无意中听到了开发人员对Docker在构建应用程序时产生的差异的世界。从他们的角度来看，他们可以将他们的代码部署到本地容器，进行本地测试，制作图像并传递。
但是领导者还是不能相信Docker对QA很重要。毕竟，大多数Docker实现只是dev。还没有建立在集装箱中测试应用的系统。
无论你对Docker的印象如何，很明显容器革命不会局限于开发。 Docker公司正在迅速发布工具来平息对操作的恐惧，许多第三方解决方案使得Docker容器的安全性和监督性与任何其他基础设施一样简单。但是如果dev采用容器，就像ops一样，当集成环境中有更多版本的应用程序，并且每个实例都有一个容器时，在哪里会有QA?
随着集装箱驱动的管道出现，质量保证对包容集装箱的压力 - 并确保质量保证流程跟上新的架构和发布实践 - 将是不可避免的。但这不是坏消息。事实上，如果你意识到Docker给QA带来的好处，你就会迫切地想要立即开始。
与虚拟机不同的是，每个虚拟机都包含一个完整的客户操作系统，并且可以运行许多千兆字节，Docker容器共享一个通用的操作系统内核，并且只有几兆字节。这使得它们容易移动，快速启动，运行和缩放。容器为每个服务器包装了比VM更多的应用程序或版本的应用程序，因此它们是负载和性能测试的理想选择。新的Docker容器可以在几秒钟内在云中启动，非常适合测试应用程序以防现实世界的用户行为。
对于QA，Docker解决了确保您测试同一个应用程序的经典问题。因为应用程序需要运行的一切都包装在容器中，所以它可以在整个流水线中可预测地一致地运行，并且具有不同的配置 - 没有更多的困难变量来追踪。如果配置问题是错误的来源，那么正在使用的容器映像是应该被寻址的点。
Docker和微服务
容器技术不仅影响了交付链和发布流程，而且还会影响应用程序架构本身。微服务架构允许应用程序被拆分为互斥的服务，甚至可以用不同的语言编写并由不同的团队管理。微服务架构支持，甚至要求一个分散的团队结构。这意味着团队是跨职能的，能够开发，测试和部署他们构建的应用程序而不依赖于任何其他团队。
这种分散式方法可以轻松地监控和解决问题。你可以很容易地在发生故障的服务。对于单片应用程序，每次小的更改都需要部署整个应用程序。使用微服务，您只能部署需要更改的服务，并保持应用程序的其余部分不变。
微服务架构是未来的趋势，但许多组织还没有做好准备。在过去十年里，由谷歌，亚马逊和Netflix等公司开创的微型服务并不是“小型开发商店”的必需品。然而，Web应用程序变得越来越复杂。它们不能再在单个服务器或整体上扩展。当你的团队成长超过50或75名成员时，情况尤其如此，生产率由于发生了孤岛而受到影响。微服务架构正在成为构建软件团队和应用程序的首选方式。
虽然并不是每个组织都准备好立即采用微服务架构，但是开始向这个方向发展是永远不会太晚的。您可以采取小步骤，打破您的应用程序的一部分作为服务，并处理额外的块，随着时间的推移，最终覆盖整个应用程序。
无论多么快速或慢慢地转换到微服务架构，您都需要Docker来独立地包装服务。拥有整个流程的分散团队将需要一个一致和可靠的方法来将应用程序移动到整个流程中，并改善协作。这正是Docker使之成为可能。
在容器环境中实施QA
为了适应快速独立的微服务部署，QA必须从线性过程切换到支持非线性部署。换句话说，虽然QA可以忽略容器，但只是在成为瓶颈的风险。部署应用程序后，它可作为任何应用程序寻址，无论是微服务还是单片机。从那时起，应用程序可以像任何其他的测试。然而，如果QA不改变其过程，则用新的或旧的容器替换旧的基础设施的目标变得更难以实现。
例如，可以每天部署用户配置文件服务，可以每周部署购物车服务，并且每三个月仅部署一次登录服务。但实际的发布日期可能不可预测。毕竟，部分目标是在您有业务需求时发布。需要有一个足够动态的QA策略，以支持在任何时间点测试任何服务。
如果QA成为瓶颈，它相当于只有容器与开发人员而不是在产品中。但它不只是关于保持领先。容器还通过以下方式支持质量检查：
共享容器，而不是错误。如果出现问题，您可以共享图像，而不是错误报告。图像是应用程序，可能甚至在测试失败的时刻。有了现代测试工具，给你截图甚至视频，你可以提供整个应用程序。
系统级错误是最难捕获的，可能很难发现它们的根本原因。但是对于容器，过程更容易，因为系统配置基于在部署期间使用的映像。如果使用编排工具来创建映像，应该很容易显示出进行了哪些系统级更改，以及为什么会出现错误。
固定框架，库和工件版本更容易。因为无论你做多少次发布，你知道图像包含什么，并且任何复制的图像将是一致的。
更快地运行更多测试。由于部署是容器，因此您可以同时部署相同的容器，并针对它们运行整个测试套件的不同部分。如果你以这样一种方式构建你的测试套件，你有很多较小的测试，这意味着你可以同时运行整个测试套件的子集。但它也意味着你可以运行测试与微小的变化。这是一种新的方法来进行探索性测试，并帮助运营和开发团队找出改进的领域。
容器的好处增加了支持QA沟通问题的能力，支持进一步上下游的交付链，并建立在测试人员一直设法打击系统级问题的恐怖的一致性。
没有单一的方法来运行QA与容器驱动的应用程序。但有一个标准，那就是自动化。由于现代发展的速度和越来越多的东西要测试，测试自动化是必须的。
测试容器的基础架构
由于容器的性质，测试基础架构需要与容器(包括主机操作系统和数据中心)相互排斥。这里有三个基本选项。
您可以利用现有的测试基础架构，但大多数时候，它没有设置为对寿命相对较短的容器运行测试。并且ad-hoc基础设施将给QA团队带来更多的操作负担，因为操作可能拒绝为与生产中发现的环境显着不同的环境提供一次性支持。
您还可以考虑对测试网格进行容器化以匹配应用程序体系结构。但是，容器不是设计为支持多个应用程序安装，例如多个浏览器。也许更重要的是，容器缺乏支持操作系统的能力，而不是它们正在运行的主机操作系统，目前只有组织选择的Linux的分发。
为了保持灵活性和减少操作开销和复杂性，最终和非常好的选择是使用基于云的测试自动化工具。基于云的自动化工具允许您在部署到集成环境时触发测试运行。在这种情况下，集成环境充当整个应用程序的数据中心，无论是单个容器还是多个微服务。
通过此设置，您可以针对所需的所有操作系统和浏览器组合测试应用程序，而无需构建一个完全独立且独特的基础架构来进行测试。并行测试和结果可视化的力量使QA团队能够跟上高速测试和发布周期，不会在快速交付链的压力下绊脚。
成长的烦恼
尽管有这些优点，Docker还是通常只被用于沙盒，在某些情况下用于开发，但很少在QA中使用，甚至在生产中更少见。这是因为大多数组织对容器提供的安全级别持怀疑态度。由于多个容器共享相同的操作系统内核，所以操作系统的妥协影响所有容器。由于其定义的边界和僵化的逻辑，VM在安全性方面更成熟。
这就是说，DockerCon和其他Docker相关的事件和会议提供了大量的例子，在生产中使用Docker的公司。随着这些用例的兴起，只有时间问题，Docker才能越来越多地使用它的生产环境。 Docker从行业的每个角落都得到广泛的支持，并且有望迅速成熟。很容易看到，Docker不会被限制在沙箱和开发环境中很长时间。
