Docker Workflow（一）：一個可用于生産環境的Docker工作流

本文講的是<b>Docker Workflow（一）：一個可用于生産環境的Docker工作流</b>，【編者的話】作者工作于墨西哥IIIEPE研究院，他将通過一系列文章，為我們逐一講述他們在Docker實際應用過程中的經驗與教訓，給後來者提供一些參考。本文主要介紹了他基于Docker的開發工作流，包括GitLab、Jenkins、Registry、Nginx。

我們運作着多個使用Drupal、PHP和Node.js的網站，我們的目标是使用Docker運作所有的應用，是以我們設計了以下工作流：

所有開發人員使用Docker來建立應用。

我們的GitLab執行個體配置了Webhook，當檢測到一個新的推送時，它将指令Jenkins運作一個任務。

每個Jenkins任務都包含相同的布置：從GitLab中克隆最新代碼，運作測試，登入到我們的私有Docker Registry，使用最新代碼建構一個新的鏡像，然後将鏡像推送上去。

最後，我們的編排軟體Maestro-NG将部署新版本的鏡像。

我們的負載均衡器将檢測這些變化，并重載新的配置。

每一個步驟都需要幾天的規劃、測試和工作來設計基本準則。

建立完鏡像之後，我們需要為所有應用定義一個标準結構。我們所有的應用都使用以下結構來組織：

/application目錄是應用的根目錄。

/logs和 /files目錄用于開發，以便應用可以寫入日志和檔案。這兩個目錄會被Git忽略，并在生産環境中完全排除。

Dockerfile是Jenkins用于建構鏡像的檔案，開發人員幾乎不需要接觸這個檔案，後面詳述。

fig.yml.example和docker-compose-yml.example是開發人員用于啟動應用的檔案。這二者均不用于生産環境，當開發人員克隆一個項目時，他需要複制這個example檔案并填入他/她的值。

Makefile是拼圖的最後一塊，通過它我們可以擁有一個标準的指令集用于所有應用，并對開發人員隐藏各種各樣的複雜性。

每個應用的Dockerfile與其它應用非常類似，這個檔案的最重要工作就是建構包含所有待部署代碼的最終鏡像。我們來看一個例子：

Dockerfile依賴于我們建構的基礎鏡像，在此之上，它隻是設定了一些環境變量預設值、聲明要暴露的端口，并将應用代碼添加到<code>/var/www</code>。

正因為我們建構鏡像的這種方式，在Jenkins和開發人員之間唯一的差别是，Jenkins将添加整個應用目錄到<code>/var/www</code>中，而開發人員隻是映射一下目錄。

接下來這個是Docker Compose，他非常酷。

Docker Compose用此檔案來初始化。在本例中，我們定義了一個應用，它包括兩個容器：一個MySQL容器和一個Web容器。

MySQL容器定義了mysql鏡像要使用的環境變量。同時将宿主的3307端口映射到視窗的3306端口上。這允許我們使用任何用戶端通路MySQL伺服器。

web容器使用了與Jenkins建構最終鏡像時使用的相同鏡像（見上述Dockerfile），但它同時共享了一些資料卷。在宿主和容器間共享的卷有應用、檔案和日志。這實際是開發環境和生産環境間最大的改變：在生産環境中，容器的代碼是在鏡像中的，這允許我們在任何伺服器上啟動容器；而在開發環境中，目錄隻是共享的，是以在應用目錄裡，任何新的檔案或對檔案的修改都将即時地反映到容器裡。

我的Mac上的/etc/hosts是這樣的：

在一台Linux機器上，看起來是這樣的：

最後，我們定義了兩個環境變量來決定應用的配置檔案的一些設定。

Drupal需要一個settings.php來存儲資料庫資訊，包括密碼。該檔案将被Git忽略，以免将你的密碼送出上去，我們決定修改這個檔案，讓它使用環境變量并将其送出。

以下是一個Drupal 6網站的settings.php裡的重要部分：

正如你所看到的，沒有密碼會被送出。密碼和其它敏感值将通過ENV變量注入。

有些網站使用Apache Solr作為搜尋引擎，但在開發時，我們不希望能寫入到Apache Solr，是以需要一個類似DRUPAL_ENVIRONMENT的ENV變量，完成類似下面的settings.php檔案的事情：

由于指令很長，使用Docker非常不便，是以Docker Compose（fig）對此很有幫助。我們更進一步嘗試讓事情變得更簡單一些。

這是我們使用在一個Drupal網站上的Makefile：

使用Makefile比使用Docker Compose或Fig簡單得多，因為我們可以建立類似<code>make cc</code>的快捷方式來運作類似<code>drush cc all</code>這樣頻繁使用的指令。

有關Makefile的最後一點說明是：我們依然使用Fig。因為在我們設計這個工作流時，Docker Compose還不可用，而且我們團隊裡的一些開發人員還在使用它，我們決定為Docker Compose建立名為Fig的符号連接配接，名稱更短且更實用。安裝Docker Compose後，你可以删除fig并建立符号連接配接：

我們走過一些彎路，我将在别的文章中做介紹，不過有一個我想特别說一下。使用Docker最大的好處是，開發人員可以在與生産環境相同的環境上運作應用，且隻損失一點點性能。

我看過一些文章，說他們在Docker之外做開發，然後在需要部署時建構鏡像并發送到生産環境。如果你這麼做，那你就錯了，因為你開發所用的環境與生産機上運作的不一緻。不要每次都建構鏡像，相反的，在宿主和容器間共享卷，讓别人在你每次推送時建構鏡像。

未完待續……

文章還遠未結束，不過它已經太長了。我們依然需要說明我們是如何整合Maestro-NG、配置Jenkins以及負載均衡器是如何工作的。咱們回見！

原文釋出時間為：2015-03-26

本文作者：sean

本文來自雲栖社群合作夥伴DockerOne，了解相關資訊可以關注DockerOne。

原文标題：Docker Workflow（一）：一個可用于生産環境的Docker工作流