针对生产应用程序测试更改是很困难的。这是因为克隆是一个非常繁琐和缓慢的过程。克隆应用程序的常见过程包括快照/还原虚拟机、tar/scp/untar文件和备份/还原数据库，这些步骤中的任何一个都可能需要您完成。这个问题在数据驱动的应用程序中更为复杂，这些应用程序必须更频繁地进行克隆，以防止过时测试状态的累积。针对生产进行测试似乎没有道理，但当时间和人力紧张时，就会发生这种情况。使用Docker和Delphix，我们研究了一种简单而快速的克隆生产应用程序的过程，该过程通常适用于各种应用程序，例如：持续集成服务器（Jenkins、TeamCity、Travis等）ERP应用程序（Oracle EBS、SAP ERP等）自定义应用程序在我们的调查中，购物返现，chriskast、Dan Tehranian、Rahul Nair、Srini Dandu和我改进了JIRA的克隆工作流程，JIRA是一种缺陷跟踪工具。概述一个常见的JIRA安装包括三个部分：PostgreSQL数据库、JIRA_主目录和JIRA二进制文件。大多数bug数据存储在数据库中，而一些bug元数据（如屏幕截图附件）存储在JIRA_HOME目录中，以及初始配置文件。克隆JIRA需要两大步骤：使用JIRA用户和必要的二进制文件设置环境复制两个数据源并将配置缝合在一起这花了几个小时。一言以蔽之有了Docker和Delphix，我们可以在几分钟内提供一个JIRA克隆产品。升级测试等困难的任务变得非常简单和可靠。除了克隆之外，这种技术组合使我们能够刷新、快照和回滚每个虚拟JIRA应用程序。Docker和Data Docker是一个了不起的工具，大数据分析，它用开发人员友好的API和配置管理来包装Linux容器（LXC）。它允许开发人员利用所有的依赖关系来启动一致的运行时环境，这样应用程序就可以工作了……而且速度很快！所有容器共享同一个操作系统内核，点云，允许在不到一秒钟的时间内创建新容器。一个简单的"docker run jira"用一个干净的jira测试应用程序构建一个基本环境。但是一个空白的JIRA实例有多有用呢？您需要真实的数据来验证预期的行为，并且在生产中遇到边缘情况通常会导致更新/升级失败。换句话说，你不会在一个干净的安装中碰到bug！Chris希望通过一个测试实例来验证他的更改，而要做到这一点，他需要一个具有真实数据的类似产品的环境。持久存储是Docker开发的一个活跃领域。Docker数据可以是私有的（在容器中实时的）或共享的（在本地主机上）。私有数据存在于Docker的联合文件系统中。Docker的存储后端抽象基于层，有几种实现，比如vfs（基于目录的实现，其中创建子层相当于创建子目录并深度复制父目录）到btrfs（一种使用快照实现层的文件系统）。您可以在这里找到后端实现的良好概述。我们有两个数据源，我们希望在容器之间共享，同时也与生产保持同步。我们本可以跳出圈套来创建负责保持JIRA_HOME directory和PostgreSQL数据库同步的容器；但即便如此，Docker也没有与其他测试容器共享这些数据的概念，这样每个容器都可以获得自己的数据读写副本。Delphix就是为这个而生的。Delphix Docker工作流使用Delphix，我们链接生产PostgreSQL数据库和JIRA_HOME目录，将数据拉入引擎。然后我们将这些源作为虚拟数据库（VDB）和虚拟文件（vFiles）配置到一个新主机上；使用我们的工具箱钩子，我们自动构建JIRA容器，并对其进行必要的配置更改以将其缝合在一起。小时到分钟仅使用DelphixGUI，克隆过程就花了几个小时，只需3分钟。。。然后花2分钟等待JIRA应用程序启动！开发人员的体验是使用delphixgui配置VDB（对于任何主机，可以通过jdbcurl通过网络访问），并将JIRA_HOME vFiles提供给Docker主机。对于好奇者：我们是如何做到的以及沿途的问题工具箱内部大部分过程是通过使用自定义数据平台工具包实现自动化的。结果是：通过DelphixGUI提供PostgreSQL虚拟数据库（VDB）通过delphixgui向Docker主机提供JIRA_HOME目录的虚拟文件（vFiles）对虚拟JIRA_HOME的配置更改（通过Toolkit hook实现自动化）更新中PostgreSQL VDB的JDBC连接url、数据库名称、用户和密码数据库配置.xml文件移除.jira_家.锁文件运行Docker容器（通过Toolkit Hooks自动执行）将vFiles挂载到容器中作为JIRA_HOME目录。使用的Dockerfile和docker run命令见附录。问题1:NFS和Docker守护进程在名为"NFS shares and volumes don not mix"的文章中，我们发现Docker守护进程没有注册新创建的NFS挂载，在容器中留下一个空的bind挂载。一种解决方案是重新启动Docker守护进程，工业物联网，什么是物联网工程，强制解析现有的挂载。然而，由于我们有幸在使用systemd（Linux系统的一套基本构建块）的CentOS上，所以在启动Docker服务时有一个MountFlag选项。我们选择了MountFlag=private fix。MountFlag选项控制Docker挂载相对于全局挂载名称空间的可见性（这里有更多信息），但是通常很少找到描述这个标志的信息。问题2:NFS和Docker权限我们使用容器中的绑定装载来解决权限问题。使用Docker的特权模式，它公开了许多内核特性和对容器的设备驱动程序访问，我们可以在devicemapper后端解决这个问题（其他后端存储实现可能表现不同）。是的，我们在特权模式下失去了一些很好的安全优势，但是对于test/dev来说这一切都很好。附录durdn/atlassian基地的Dockerfile维修人员Coen Hyde<；科恩海德@gmail.com>ENV JIRA_版本6.3.15运行curl-Lks${JIRA_版本}。焦油gz-o/根/吉拉.塔尔.gz运行/usr/sbin/useradd--create home--home dir/opt/jira--groups atlassian--shell/bin/bash jira运行tar zxf/root/吉拉.塔尔.gz--条带=1-C/opt/jira RUN chown-R吉拉：吉拉/奥特/吉拉运行回显"吉拉。家=/opt/atlassian home">；/opt/jira/atlassian jira/WEB-INF/classes/jira-应用程序.属性WORKDIR/opt/jira EXPOSE 8080用户jira CMD/opt/jira/bin/start-吉拉·什-前景"]Docker命令docker run--privileged=true-p${PORT}:8080-v${vJIRA_HOME}:/opt/atlassian HOME jira/jira