使用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的變化

(1)在dbconfig.xml文件中更新JDBC連接，數據庫名字，用戶和虛擬數據庫的密碼

(2)刪除.jira_home.lock文件

4.運行Docker容器(通過工具箱鉤子自動運行)

(1)掛載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的特權模式，會開放很多內核功能和設備驅動給容器訪問，我們在底層設備映射器上繞過這個問題(其他底層存儲實現可能實現方式不同)。是的，我們在特權模式下失去了一些優雅的安全限制，但是它在測試和開發環境是完全可以的。