基於Docker的開發實踐案例分享

當下，容器已成為一個非常熱門的趨勢，而只要談到容器大家也通常都會說到Docker。 甚至，容器已經有了自己的動詞形式containerizing，用以描述使用Docker將應用程式打包。

在熱烈爭論之後，Docker領域的重點遷移到如何在現實生產環境中使用容器，人們紛紛將「containerization」的哲學運用到存儲、網路，亦或是管理。

毫無疑問，在這個強勁的勢頭下，Docker可以在生產環境穩定使用肯定不會太遙遠。 而這裡將分享一些基於Docker的用例，它們已經得到了工程師的驗證。

首先，在另一篇博客中我已經簡單的提到了這些，而本文則是基於和同事交流的擴展。 當然，這些並不是對Docker只是一個市場趨勢說法的辯駁。

在這裡，我不想繼續去重複解釋功能測試以及不同類型的軟體測試。 當下已經有很多文章解釋為什麼單元測試前必須基於真正的服務和運行環境。

當下，基於單元測試的測試驅動開發已經被證明是一個很好的應用程式開發途徑，整個開發過程將與單元測試密不可分。 通常，你會同時開始寫單元測試和代碼，並以反覆運算的方式不停的填補代碼和單元測試。

當代碼運行正常後，在評審和合併之前，它通常會被提交到CI環境以運行單元測試，也許在review和merge之前，還會做一些功能測試。

針對某個功能的功能測試並不會在同時提交，因為功能測試進行起來並不容易，同時也會花費很多時間。 你必須正確配置所有東西，比如資料庫的初始建立，比如測試所需的上下文中如何進行通信。

同時，即使你以這種方式搭建了測試環境，運行的也還算良好，大部分人仍然只是簡單地將它放在幾個同事共用的一個虛擬機器中進行，而不是設置一個一整套的環境，實現類似DB、APP和Web Server那樣的交互。 你肯定也不會去測試應用程式的擴充性，因為它的開銷更加昂貴。

而這些，你使用Docker和Fig搭配就可以輕鬆實現。 你可以指定不同的環境，並快速的進行部署。 你可以直接在CI中運行不同的目標和內容；更重要的是，你可以非常便捷的將之與同事共用。 這一切都是因為Docker，它可以為鏡像構建一些非常智慧的緩存，並且在數秒內運行這些鏡像。

在構建Dockerfile時，你會指定應用程式的構建途徑，以及配置的具體內容。 同樣，你可以向使用者表達它是如何工作的。 鑒於你並不具備專業複雜軟體部署從業者的經驗和技術，結果可能不會盡善盡美，但是最低限度的，你可以告訴使用者工作是如何進行的，而不是讓他們自己絞盡腦汁。

在另一篇博客中，我為大家介紹了Dox。 如果你玩過OpenStack，你會發現OpenStack經常需要運行眾多非常複雜的測試，因此我們需要一個系統簡化這個過程中的複雜度。 然而，並不是只有OpenStack才有這些非常複雜的測試，比如你需要運行Sqlalchemy，同時你需要在後端的sqlite，以運行你的單元測試。 但是最終你可能因為一些非常奇怪的狀態終止，比如foreign keys不能正常工作，以及一些其他SQL功能不能實現。 但是通過容器，你可以輕鬆的將配置好的DB打包，從而輕鬆的完成這些測試。 以此類推，在你需要依賴某個系統，或者某些配置/檔時，Docker可以輕鬆地將它們打包。

希望在瞭解這些點後，你能更加堅定容器是開發流程中必不可少的一環。 同時，我也希望有更多的內容會添加到這些工作流程中，而未來也會出現更多強大的工具讓開發更加便捷。

原文連結：Use cases for Docker driven development.（編譯/童陽 審校/周小璐）