構建Docker鏡像兩種方式的比較－Dockerfile方式和S2I方式

前言

寫Dockerfile是構建Docker鏡像最一般的方式，接觸過Docker的童鞋多少了解一些。前段時間研究OpenShift(paas的一種)，發現了另一種構建Docker鏡像的方式：S2I。

S2I介紹

S2I是Source-to-Image的縮寫。

S2I是一套工具包和工做流程，用於從源代碼構建重複性Docker鏡像。

S2I是一個框架，它使寫鏡像變得簡單。它把程序源代碼做爲輸入，生成一個運行已組裝應用程序的新鏡像並做爲輸出。

S2I的詳細介紹以及使用方法能夠參考如下官方文檔。本文就不復述(fan yi)了。

• Source-To-Image (S2I)
• S2I Requirements
• How to Create an S2I Builder Image

兩種構建方式的過程

Talk is Cheap, Show me the Picture.
先上圖。

源代碼只是構建鏡像的多種輸入的一種，還有二進制文件等其它輸入。鏡像構建的過程也比較複雜。下圖是爲了清晰地進行對比，因此畫得簡單一些。

由上圖能夠看出，Dockerfile方式的構建過程比較直接：

• 根據Dockerfile定義的步驟，讀取源代碼，生成鏡像(成品)。

而S2I方式的構建過程比較「曲折」：

• 根據Dockerfile定義的步驟，準備鏡像環境、讀取S2I腳本，構建鏡像(中間)<又稱構建器鏡像 Builder Image>。
• 基於上一步生成的鏡像(中間)，讀取源代碼，根據S2I腳本定義的步驟編譯源代碼、部署二進制程序、八戒影院預備服務啓動，構建鏡像(成品)。

從上述過程能夠看出，S2I方式比Dockerfile方式多了一步，多了兩樣東西：S2I腳本和鏡像(中間)。

S2I腳本介紹

S2I腳本有4種。

• assemble: 負責構建程序，即編譯、部署程序。
• run: 負責啓動應用。
• save-artifacts: 負責增量構建(鏡像)，目前還沒有使用。
• usage: 負責打印構建器鏡像的使用說明。

S2I方式的好處

關於引入S2I構建鏡像的好處，書面類的描述能夠參考官方文檔，這裏談談實踐下來我的的感覺和理解。

首先，要了解爲何要引入S2I。

若是必定要把構建鏡像分爲兩部分，能夠分爲

1. 環境準備

   • 定義基礎鏡像；
   • 安裝所需部件，如Maven、Java JDK；
   • 拷貝/移動文件/目錄；
   • 定義用戶；
   • 暴露端口等。

2. 源代碼相關

   • 編譯源代碼；
   • 部署二進制程序；
   • 定義服務啓動方式等。

引入S2I的目的就是爲了分離這兩部分的工做。

其中環境準備工做交給了構建器鏡像，

構建器鏡像一旦生成將保持不變，可理解爲靜態部分。

而源代碼相關工做交給了S2I腳本。

在構建鏡像(成品)過程當中，S2I將根據S2I腳本定義的步驟進行源代碼編譯、二進制程序部署、服務啓動預備，能夠理解爲動態部分。

這樣的分離帶來了以下好處。

1. 對於環境依賴相近、構建部署啓動過程類似的程序，因爲有構建器鏡像的存在，構建過程不須要再次進行環境準備工做，從而節省了構建鏡像(成品)的時間。
2. 分工明確。構建工做的分離容許應用程序開發人員對他們的代碼進行更改，而不用知道Dockerfile或Docker鏡像的細節。若是鏡像構建交付給S2I或PaaS(platform as a service)平臺，開發工程師不須要理解Docker來對項目做出貢獻。第九影院這在一個由不少人組成的企業環境中是很是有用的，這些人都有不一樣的專業方向，並且並不直接涉及到他們項目的構建過程。