將Docker用作本地開發(fā)毫無意義

jieforest

　　依托Docker運行的后端服務(wù)(如數(shù)據(jù)庫，緩存，存儲等)感覺相當(dāng)完美，但對于編譯語言，Docker卻并未本地開發(fā)的理想之選。

　　我一直在嘗試使用Docker作為本地開發(fā)環(huán)境，最近我又嘗試了一遍，結(jié)果發(fā)現(xiàn)依然行不通。但是這次嘗試我得出了進(jìn)一步的結(jié)論，那就是對于大多數(shù)的開發(fā)堆棧而言，將Docker作為本地開發(fā)環(huán)境毫無意義，除了引入更多的復(fù)雜性外，幾乎沒有任何優(yōu)勢。

　　若要實現(xiàn)高效的代碼編寫、編譯、運行周期，意味著本地開發(fā)環(huán)境的容器沒必要和生產(chǎn)環(huán)境的容器保持一致。這等于是否定了容器最重要的優(yōu)勢之一。換句話說，基于容器的開發(fā)環(huán)境根本無法達(dá)到非容器的本地開發(fā)環(huán)境的高效和流暢。

　　先看看我的要求，一個高效的coding、編譯和運行周期需要單獨的“非生產(chǎn)環(huán)境”的容器。首先，如果將生產(chǎn)環(huán)境的容器用于開發(fā)環(huán)境，容器必須包含某些預(yù)編譯的組件，或者更甚，比如在你的Dockerfile中運行編譯。這樣，每次微小改動都需要重建容器。你的E/C/R(編輯、編譯、運行周期)看起來像這樣：

1. 　　docker-compose up -d #啟動所有的容器，并運行
   
2. 　　# edit myservice
   
3. 　　make myservice # 構(gòu)建服務(wù)
   
4. 　　docker-compose build myservice
   
5. 　　docker-compose restart myservice
   

復(fù)制代碼

按這種方式，整個重建的周期要花很長時間(超過30秒，還不包括服務(wù)自身的構(gòu)建時間)來觸發(fā)無聊至極的上下文切換。這絕對是生產(chǎn)力殺手。

　　你可以說這是個實現(xiàn)上的問題，并且最終這一重建周期將會大大加快，但是對比本地環(huán)境，構(gòu)建和重啟過程需要幾乎無感。我也不覺得這會有效利用到Docker的鏡像緩存。

　　如果愿意放棄使用生產(chǎn)容器作為本地開發(fā)容器的想法，或者運行一個沒有構(gòu)建過程的解釋性堆棧，你或許可以改變游戲規(guī)則。你可將資源庫目錄裝載到容器中，進(jìn)而監(jiān)聽文件的變更，在容器內(nèi)使用實時裝載工具或刷新機制來重新編譯和發(fā)布應(yīng)用。

　　在一系列愚蠢的步驟下，這種方式也可工作的很好。比如我們將花時間尋找和設(shè)置docker-osx-dev開發(fā)環(huán)境，裝載并與源文件夾高效的同步，又將花幾個小時擺弄boot2docker以便使inotify正常工作起來，但是我們的確找到了解決方案。

　　但當(dāng)我們回顧并看看這一變態(tài)的過程，我們竟然找不到令人信服的優(yōu)勢所在。我們在本地使用foreman啟動所有服務(wù)，對比docker-compose up，foreman start速度難以置信的快。除了Docker容器本身，我們也繼承了管理boot2docker所帶來的復(fù)雜性。配置文檔長度也增加了三倍。

　　我們的初衷是使用Docker作為本地開發(fā)環(huán)境，打破在本地只能運行如Memcached和Elasticsearch的幾種關(guān)鍵服務(wù)。最終，我們得到結(jié)論，通過docker-compose運行后端服務(wù)是很有意義的，但配置和運行本地開發(fā)環(huán)境需要盡量簡單。另外，我們又回到了通過foreman來運行本地微服務(wù)的方式。從此不再回頭。

wenhq

題目有些誤導(dǎo)。。。