Docker 根本不適合用於本地開發環境

【編者的話】依託Docker執行的後端服務（如資料庫，快取，儲存等）感覺相當完美，但對於編譯語言，Docker卻並未本地開發的理想之選。

我一直在嘗試使用Docker作為本地開發環境，最近我又嘗試了一遍，結果發現依然行不通。但是這次嘗試我得出了進一步的結論，那就是對於大多數的開發堆疊而言，將Docker作為本地開發環境毫無意義，除了引入更多的複雜性外，幾乎沒有任何優勢。

若要實現高效的程式碼編寫、編譯、執行週期，意味著本地開發環境的容器沒必要和生產環境的容器保持一致。這等於是否定了容器最重要的優勢之一。換句話說，基於容器的開發環境根本無法達到非容器的本地開發環境的高效和流暢。

先看看我的要求，一個高效的coding、編譯和執行週期需要單獨的“非生產環境”的容器。首先，如果將生產環境的容器用於開發環境，容器必須包含某些預編譯的元件，或者更甚，比如在你的Dockerfile中執行編譯。這樣，每次微小改動都需要重建容器。你的E/C/R（編輯、編譯、執行週期）看起來像這樣：

docker-compose up -d #啟動所有的容器，並執行
# edit myservice
make myservice # 構建服務
docker-compose build myservice
docker-compose restart myservice

按這種方式，整個重建的週期要花很長時間（超過30秒，還不包括服務自身的構建時間）來觸發無聊至極的上下文切換。這絕對是生產力殺手。

你可以說這是個實現上的問題，並且最終這一重建週期將會大大加快，但是對比本地環境，構建和重啟過程需要幾乎無感。我也不覺得這會有效利用到Docker的映象快取。

如果願意放棄使用生產容器作為本地開發容器的想法，或者執行一個沒有構建過程的解釋性堆疊，你或許可以改變遊戲規則。你可將資源庫目錄裝載到容器中，進而監聽檔案的變更，在容器內使用實時裝載工具或重新整理機制來重新編譯和釋出應用。

在一系列愚蠢的步驟下，這種方式也可工作的很好。比如我們將花時間尋找和設定docker-osx-dev開發環境，裝載並與原始檔夾高效的同步，又將花幾個小時擺弄boot2docker以便使inotify正常工作起來，但是我們的確找到了解決方案。

但當我們回顧並看看這一變態的過程，我們竟然找不到令人信服的優勢所在。我們在本地使用foreman啟動所有服務，對比docker-compose up，foreman start速度難以置信的快。除了Docker容器本身，我們也繼承了管理boot2docker所帶來的複雜性。配置文件長度也增加了三倍。

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