可以停止假裝Docker是最棒的開發環境了吧？
依托Docker運行的后端服務（如數據庫，緩存，存儲等）感覺相當完美，但對于編譯語言，Docker卻并未本地開發的理想之選。
每隔六個月我都嘗試使用Docker作為本地開發環境。最近我又嘗試了一遍，結果再次發現依然行不通。但是這次嘗試我得出了進一步的結論，那就是對于大多數的開發堆棧而言，將Docker作為本地開發環境是毫無意義的。它引入了復雜性并且幾乎沒有任何優勢。
問題的癥結在于：若要實現高效的編輯、編譯、運行周期，意味著本地開發環境的容器沒必要和生產環境的容器保持一致。這等于是否定了容器最重要的 優勢之一。此外，你也無法使編輯、編譯、運行周期達到沒有容器的本地環境下的高效和萬無一失。這意味著付了集裝箱運輸稅，但卻毫無獎勵。
先看看我的要求，一個高效的編輯、編譯和運行周期需要單獨的“非生產環境”的容器。首先，如果將生產環境的容器用于開發環境，容器必須包含某些預編譯的組件，或者更加瘋狂，比如在你的 Dockerfile 中運行編譯。這樣，每次微小改動都需要重建容器。你的E/C/R（編輯、編譯、運行周期）看起來像這樣：
docker-compose up -d # start all your containers, and leave them running edit myservice
make myservice # or whatever you do to build 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 來運行本地微服務的方式。從此不再回頭。
原文鏈接： Can we stop pretending that Docker is great for development environments? （翻譯：Andrew）
譯者介紹
Andrew，云計算從業者，PPTV技術總監，樂于分享對于云計算的一些想法和對未來科技的猜想。