为什么Docker还不够

本文讲的是<b>为什么Docker还不够</b>，【编者的话】使用Docker和Delphix我们研究了一个简单快速备份生产应用的流程，对各种应用都普遍适用的流程。

测试生产应用上的改动是艰巨的。这是因为复制是一项非常繁琐且缓慢的流程。通常的复制应用的流程是快照备份/恢复还原一个虚拟机，压缩、远程复制、解压文件，备份、还原数据库和其他可能需要通过IT执行的步骤。这个问题与数据驱动的应用混合在一起，导致需要更加频繁备份应用，以避免出现构建过旧测试状态的应用。

测试生产环境的应用看起来是不合理，但是当时间和人力紧张时，这样需求就会产生。使用Docker和Delphix，我们实践了一种简单快速的复制生产应用的处理流程，这流程通常适用于大多数的各种应用，例如：

建立具有jira用户和必须的二进制文件的运行环境

复制数据源和相关的配置文件

这需要耗时数小时。

<a href="http://dockerone.com/uploads/article/20160605/3eeed5734a5ab32b68789abd824c1518.png" target="_blank"></a>

我们使用Docker和Delphix可以在几分钟内提供一个生成环境备份的JIRA。像升级测试这样艰巨的任务将会变得极其容易和可靠。除了备份，这二者结合使用的技术使我们能具有更新、快照和回滚每一个JIRA应用的能力。

换句话说，在干净的环境中你无法测试覆盖到任何问题。

Chris想在测试实例中验证他的改动，为了这个目的他需要一个有真实数据的类生产环境。

<a href="http://dockerone.com/uploads/article/20160605/2a8e90870a5c51816b37a530b7e7c831.png" target="_blank"></a>

我们想在容器间共享两个数据源，并且保持与生产环境的同步。我们采用直接解决问题的方法，建立负责保持JIRA_HOME目录和PostgreSQL数据同步的容器，但是即使如此，Docker没有与其他测试容器共享数据的概念，像每一个容器获得各自进行读写的数据备份。

Delphix就是为这个而生的。

使用Delphix，我们把生产环境的PostgreSQL数据库和JIRA_HOME目录都通过拉取数据方式连接到Delphix引擎。我们然后将这些数据源分区为新主机上的虚拟数据库（VDB）和虚拟文件（vFiles）。使用我们的关联工具套件，我们自动化构建了一个JIRA容器，而且配置变化跟这些紧密结合在一些。

单独使用Delphix界面即可将耗时数小时的备份流程降至仅仅3分钟，而且其中两分钟是在等待JIAR应用启动！开发人员需要做的是使用Delphix界面提供VDB（可以在任何网络上通过JDBC url访问的主机上），并且提供JIRA_HOME vFiles给Docker主机。

大多数处理流程都是通过使用自定义的数据平台工具箱来实现自动化的。最终的处理流程如下：

通过Delphix界面工具提供PostgreSQL虚拟数据库

通过Delphix界面工具提供JIRA_HOME目录的虚拟文件（vFiles）给Docker主机

通过工具套件的钩子自动配置虚拟JIRA_HOME的变化

在dbconfig.xml文件中更新JDBC连接，数据库名字，用户和虚拟数据库的密码

删除.jira_home.lock文件

运行Docker容器（通过工具箱钩子自动运行）

挂载vFiles到容器中作为JIRA_HOME目录

使用的Dockerfile和docker 运行命令请参考附录。

我们遇到在容器中挂载时的权限问题。使用Docker的特权模式，会开放很多内核功能和设备驱动给容器访问，我们在底层设备映射器上绕过这个问题（其他底层存储实现可能实现方式不同）。是的，我们在特权模式下失去了一些优雅的安全限制，但是它在测试和开发环境是完全可以的。

原文发布时间为： 2016-06-05 

本文作者：whole 

本文来自云栖社区合作伙伴DockerOne，了解相关信息可以关注DockerOne。

原文标题：为什么Docker还不够