老肖語錄 | 使用 Docker 做 CI 解惑

我今天看到一篇網友分享的 php 環境下的Docker持續集成案例。筆者大膽的試用后嘗到了容器技術的甜頭，也在文中提出了一個沒有解決的困惑。 原來他是把代碼放在容器外面，通過掛載目錄的方法把代碼加到容器里面運行的。這樣雖然跑起來很快，但筆者感覺這和 Docker 的口號 build、ship、run 還是有很大的區別。當然，他把代碼放在鏡像里，每次變動都需要花上十幾分鐘等鏡像build，push 到倉庫后才能run發布，這個過程筆者也接受不了。這個網友的疑惑是構建鏡像本身拖慢了集成的速度，這和一般情況下采用新技術能提高生產力的故事在直覺上是說不通的。

我想提提自己的看法。首先，Docker鏡像本身是一個壓縮包，每次即使只改幾個文件，也需要把整個項目壓縮一遍，沒法增量壓縮。所以，如果你的開發過程中需要頻繁的改內容的時候，用 Docker 先打鏡像再發布的流程就是一種反作用力，直接降低你的生產力。這個時候，你巧借 Docker 容器的環境一致性，直接把源碼掛載到容器里面運行的做法應該是一個好辦法。

我也意識到 Docker 對 CI這一塊并沒有考慮那么周到，還是需要我們自己來解決遇到的問題。比如本地的測試，可以考慮使用 vagrant 來解決，如下面的例子，很巧妙：

如果我們把 CI 的問題再擴展到 CD，上面源碼是否放到鏡像里面，仍然有很多可以討論的地方。對于 Docker 的 build，ship，run一樣有很多沖突，我是這么理解的：

1. build過程，從Docker 宣傳的口號來說，源碼作為服務組件的組成部分，確實應該放在鏡像當中。但是，在沒有 Docker之前，我們的源碼也是打包的，這方面系統方面的安裝包已經足夠強大。但之前的安裝包一定是需要你編寫依賴環境的，每一種系統要寫一個 spec。在有了 Docker 之后，這個困難就沒有了。因為，你的依賴環境就在鏡像里面，不需要額外的考慮環境的變化。所以，代碼掛載進來也不會影響環境。
2. ship 是為鏡像倉庫為中心，你可以把 鏡像存到倉庫里面，也可以把鏡像拉在主機上。代碼作為經常變化的部分，并不能把鏡像作為不可變的組件特性給發揮到極致。所以，源碼在鏡像里面打包分發也不一定是好事。
3. run 的部分是秒開應用以及依賴的環境。把源碼打包到鏡像里面后，Run 新版本的鏡像，就需要 stop 老鏡像。畢竟有一個停起的過程，如果沒有灰度發布的過程，這個更新鏡像的過程就是中斷服務的。

上面的困惑雖然小，也能讓我們看到 Docker 的使用是需要花心思的。盲從的亂用 Docker 并不能給你帶來甜頭，反而會讓你更煩惱。希望大家一起探討起來，一起發現一些困惑，一起來探討解決。