本文讲的是为什么Docker还不够，
【编者的话】使用Docker和Delphix我们研究了一个简单快速备份生产应用的流程，对各种应用都普遍适用的流程。
测试生产应用上的改动是艰巨的。这是因为复制是一项非常繁琐且缓慢的流程。通常的复制应用的流程是快照备份/恢复还原一个虚拟机，压缩、远程复制、解压文件，备份、还原数据库和其他可能需要通过IT执行的步骤。这个问题与数据驱动的应用混合在一起，导致需要更加频繁备份应用，以避免出现构建过旧测试状态的应用。
测试生产环境的应用看起来是不合理，但是当时间和人力紧张时，这样需求就会产生。使用Docker和Delphix，我们实践了一种简单快速的复制生产应用的处理流程，这流程通常适用于大多数的各种应用，例如：
对于我们实践，Chris Kast、Dan Tehranian、Rahul Nair、Srini Dandu和我改进了缺陷跟踪工具 JIRA 的备份流程，
概述
一个常用的JIRA安装包含三部分： PostgreSQL 数据库、JIRA_HOME目录、JIRA二进制文件。大部分的bug数据存储在数据库中，而一些bug的元数据像截图附件则是存储在JIRA_HOME目录中，还有初始化的配置文件也在该目录下。备份JIRA大体需要两步：- 建立具有jira用户和必须的二进制文件的运行环境
- 复制数据源和相关的配置文件
这需要耗时数小时。
解决方案概述
我们使用Docker和Delphix可以在几分钟内提供一个生成环境备份的JIRA。像升级测试这样艰巨的任务将会变得极其容易和可靠。除了备份，这二者结合使用的技术使我们能具有更新、快照和回滚每一个JIRA应用的能力。
Docker和数据
Docker 是一个令人称奇的工具，它面向开发者封装了友好接口的 Linx Containers（LXC） 和配置管理。它允许开发加快构建出包含所有依赖的一致运行时环境，所以应用只需在上面运行即可……而且应用还很快。所有容器共享同一个操作系统内核，并且新的容器能够在一秒内创建。简单的docker run jira
命令能构建出一个干净的JIRA测试应用的基本环境。但是一个空白的JIRA实例有多用呢？你需要真实的数据来验证应用运行时所期望的行为，并且覆盖生成环境中的边界情况，正是这些情况经常会导致一次失败的更新或者升级。
换句话说，在干净的环境中你无法测试覆盖到任何问题。Chris想在测试实例中验证他的改动，为了这个目的他需要一个有真实数据的类生产环境。
持久化存储是对于Docker开发者来说是一个活跃的区域。Docker数据既可以是私有的（存在容器内），也可以是共享的（存在主机上）。私有数据存在于 Docker统一文件系统 。Docker存储的底层抽象是基于分层的，它有好多个实现例如vfs（基于目录的实现，创建一个子层次相当于创建一个子目录并且深度拷贝父目录），btrfs（使用快照来实现分层的文件系统）。关于底层实现的一个很好的概述，参考 该链接 。
我们想在容器间共享两个数据源，并且保持与生产环境的同步。我们采用直接解决问题的方法，建立负责保持JIRA_HOME目录和PostgreSQL数据同步的容器，但是即使如此，Docker没有与其他测试容器共享数据的概念，像每一个容器获得各自进行读写的数据备份。
Delphix就是为这个而生的。
Delphix-Docker工作流
使用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 运行命令请参考附录。
问题1：NFS和Docker后台程序
在名副其实的文章《 NFS shares and volumes don’t mix 》，我们发现一个问题：Docker后台程序没有注册新建的NFS挂载点，在容器中只有一个空的挂载点。一个解决方法是重启Docker后台程序，强制解析已经存在的挂载点。然而，很幸运的是我们工作的CentOS上使用的是systemd（组成Linux系统的一个基本模块组件），当启动Docker服务时候有个MountFlag可选。我们可以使MountFlag=private来解决该问题。MountFlag选项控制Docker挂载点相对于全部挂载空间的可见性（更多信息参见 这里 ），但是通常很难找到描述这个标志的信息。
问题2：NFS和Docker权限
我们遇到在容器中挂载时的权限问题。使用Docker的特权模式，会开放很多内核功能和设备驱动给容器访问，我们在底层设备映射器上绕过这个问题（其他底层存储实现可能实现方式不同）。是的，我们在特权模式下失去了一些优雅的安全限制，但是它在测试和开发环境是完全可以的。附录
Dockerfile
Docker Command
原文链接：Why Docker Is Not Enough（翻译：姜俊厚）
原文发布时间为： 2016-06-05
本文作者：whole
本文来自云栖社区合作伙伴DockerOne，了解相关信息可以关注DockerOne。
原文标题：为什么Docker还不够
