我想我已經找到了一個非常不錯的Docker使用案例。你是不是會覺得這是一篇寫Docker有多好多好的文章，開始之前我想和你確認，這篇文章會介紹如何把文件系統作為持久性的數據結構。

因此，這篇文章的見解同樣適用于其他的 copy-on-write文件系統，如BTRFS和ZFS。
問題

讓我們從這個我試圖解決的問題開始。我開發了一個會運行很長時間的構建腳本，這個腳本中包含了很多的步驟。

    這個腳本會運行1-2個小時。
    它會從網絡下載比較大的文件（超過300M）。
    后面的構建步驟依賴前期構建的庫。

但最最煩人的是，運行這個腳本真的需要花很長的時間。
文件系統是固有狀態

我們一般是通過一種有狀態的方式與文件系統進行交互的。我們可以添加、刪除或移動文件。我們可以修改文件的 權限或者它的訪問時間。大部分獨立的操作都可以撤銷，例如將文件移動到其它地方后，你可以將文件恢復到原來的位置。但我們不會通過快照的方式來將它恢復到 原始狀態。這篇文章我將會介紹如何在耗時較長的腳本中充分利用快照這一特性。
使用聯合文件系統的快照

Docker使用的是聯合文件系統叫做AUFS（譯者注：簡單來說就是支持將不同目錄掛載到同一個虛擬文件系統下的文件系統）。聯合文件系統實現了Union mount。顧名思義，也就是說不同的文件系統的文件和目錄可以分層疊加在單個連貫文件系統之上。這是通過分層的方式完成的。如果一個文件出現在兩個文件系統，那最高層級的文件才會顯示（該文件其它版本也是存在于層級中的，不會改變，只是看不到的）。

在Docker中，每一個在Union mount轉哦給你的文件系統都被稱為layers（層）。使用這種技術可以輕松實現快照，每個快照都是所有層的一個Union mount。
生成腳本的快照

使用快照可以幫助構建一個長時運行的腳本。總的想法是，將一個大的腳本分解為許多小的腳本（我喜歡稱之為 scriptlets），并單獨運行這些小的腳本，腳本運行后為其文件系統打一個快照 （Docker會自動執行此操作）。如果你發現一個scriptlet運行失敗，你可以快速回退到上次的快照，然后再試一次。一旦你完成腳本的構建，并且 可以保證腳本能正常工作，那你就可以將它分配給其它主機。

回過頭來再對比下，如果你沒有使用快照功能了？當你辛辛苦苦等待了一個半小時后，腳本卻構建失敗了，我想除了少部分有耐心的人外，很多人是不想再來一次了，當然，你也會盡最大努力把系統恢復到失敗前的狀態，比如可以刪除一個目錄或運行make clean。

但是，我們可能沒有真正地理解我們正在構建的組件。它可能有復雜的Makefile，它會把把文件放到文件系統中我們不知道的地方，唯一真正確定的途徑是恢復到快照。
使用快照構建腳本的Docker

在本節中，我將介紹我是如何使用Docker實現GHC7.8.3 ARM交叉編譯器的構建腳本。Docker非常適合做這件事，但并非完美。我做了很多看起來沒用的或者不雅的事情，但都是必要的，這都是為了保證將開發腳本的總時間降到最低限度。構建腳本可以在這里找到。
用Dockerfile構建

Docker通過讀取Dockerfile來構建鏡像。Dockerfile會通過一些命令來具體指定應該執行哪些動作。在我的腳本中主要用到WORKDIR、ADD和RUN。ADD命令非常有用因為它可以讓你在運行之前將外部文件添加到當前Docker鏡像中然后轉換成鏡像的文件系統。你可以在這里看到很多scriptlets構成的構建腳本。
設計

1. 在RUN之前ADD scriptlets

如果你很早就將所有的scriptletsADD在Dockerfile，您可能會遇到以下問題：如果你的腳本構建失敗，你回去修改scriptlet并再次運行docker build。但是你發現，Docker開始在首次加入scriptlets的地方構建！這樣做會浪費了大量的時間并且違背了使用快照的目的。

出現這種情況的原因是由于Docker處理它的中間鏡像（快照）的方式。當Docker通過Dockerfile構建鏡像時，它會與中間鏡像比較當前命令是否一致。然而，在ADD命令的情況下被裝進鏡像的文件里的內容也會被檢查。如果相對于現有的中間鏡像，文件已經改變，那么Docker也別無選擇，只能從這點開始建立一個新的鏡像。因為Docker不知道這些變化會不會影響到構建。

此外，使用RUN命令要注意，每次運行時它都會導致文件系統有不同的更改。在這種情況下，Docker會發現中間鏡像并使用它，但是這將是錯誤的。RUN命令每次運行時會造成文件系統相同的改變。舉個例子，我確保在我的scriptlets我總是下載了一個已知版本的文件與一個特定MD5校驗。

對Docker 構建緩存更詳細的解釋可以在這里找到。

2.不要使用ENV命令來設置環境變量，請使用scriptlet。

它似乎看起來很有誘惑力：使用ENV命令來設置所有構建腳本需要的環境變量。但是，它不支持變量替換的方式，例如 ENV BASE=$HOME/base 將設置BASE的值為$HOME/base著很可能不是你想要的。

相反，我用ADD命令添加一個名為set-env.sh文件。此文件會包含在后續的scriptlet中：

如果你沒有在第一時間獲取set-env.sh會怎么樣呢？它很早就被加入Dockerfile并不意味著修改它將會使隨后的快照無效？

是的，這會有問題。在開發腳本時，我發現，我已經錯過了在set-env.sh添加一個有用的環境變量。解決方案是創建一個新的文件set-env-1.sh包含：

然后，在所有后續的scriptlets文件中包含了此文件。現在，我已經完成了構建腳本，我可以回去解決這個問題了，但是，在某種意義上，它會破壞最初的目標。我將不得不從頭開始運行構建腳本看看這種變化是否能成功。
缺點

一個主要缺點是這種方法是，所構建的鏡像尺寸是大于它實際需求的尺寸。在我的情況下尤其如此，因為我在最后刪除了大量文件的。然而，這些文件都仍然存在于聯合掛載文件系統的底層文件系統內，所以整個鏡像是大于它實際需要的大小至少多余的是刪除文件的大小。

然而，有一個變通。我沒有公布此鏡像到Docker Hub Registry。相反，我：

    使用docker export導出內容為tar文件。
    創建一個新的Dockerfile簡單地添加了這個tar文件的內容。

產生尺寸盡可能小的鏡像。
結論

這種方法的優點是雙重的：

    它使開發時間降至最低，不再做那些已經構建成功的子組件。你可以專注于那些失敗的組件。
    這非常便于維護構建腳本。構建可能會失敗，但只要你搞定Dockerfiel，至少你不必再從頭開始。