2017年是容器領域交戰非常激烈的一年，容器編排領域逐漸形成一超多強的局面，各種容器解決方案變得越來越成熟，傳統的中間件（監控、日志、報警）對容器化場景支援逐漸完善。到了今年，如果一家公司還沒有開始對Docker進行關注，真的不好意思說是在網際網路的圈子裡了。
越來越多的企業開始在生産環境中使用容器技術進行架構，在各種網際網路大會上，也有越來越多的嘉賓開始分享他們在使用容器上的心得。但是選擇容器技術進行整體的技術架構轉型實際上需要極大勇氣的，在幾年前，容器的解決方案還不完善，第一批吃螃蟹的企業和開發者都頭破血流的搭建容器的叢集、修改可選項不多的開源工具、适應着整個流程的變更。今天，容器架構的技術債務已經基本還清，k8s、swarm、prometheus、grafana等等一系列容器相關的開源工具都被越來越多的企業與開發者證明他們的穩定，選擇容器化已經沒有那麼痛苦。但是，我們發現依舊有很多大型的企業在進行容器化轉型前有所猶豫，那麼大家的猶豫的點在什麼。
很多大型企業對容器的認知是清晰的，容器能夠帶來的好處是顯而易見的，但是同樣也會帶來一些成本。如果投入和産出的邊際效益并不可觀，那麼會讓很多企業沒有動力使用容器。總結起來這些根本的因素并不是架構的變更帶來的技術成本，而是使用容器後對于現有流程的沖擊，而這個沖擊并不是指技術的投入，真正的沖擊是對人的沖擊，是使用容器後對于人的學習成本與習慣成本的沖擊。如果使用容器需要讓所有的開發者都成為Docker的專家，這樣的成本我想大部分的公司都無法接受。容器技術或者容器平台缺乏一個橋梁，可以無縫将提供的服務與開發者的本地代碼連接配接起來，這個才是對于容器化而言的最大痛點。
為了解決這個問題我們萌發了建構一個自動化工具的想法，通過自動化工具将一些預定好的Dockerfile挖坑，通過探測或者開發者填寫資訊，然後轉變為Dockerfile。最開始的思路比較簡單，隻需要一個類似yeoman的工具，可以将不同的語言或者架構定義成模闆，然後開發者自己填寫參數進而進行預定的Dockerfile以及相關檔案的渲染，再通過封裝Docker指令屏蔽開發者本地驗證的學習成本。按照這個想法做出了雛形之後，我們發現真實的情況是有所出入的，一個從零開始的項目會能夠快速的進行容器化流程開發，但是對于大部分企業而言如何遷移一個應用是更常見的場景。是以，就按照這個想法借鑒Buildpack的思維，建構了現在的Derrick，目前支援NodeJs與Java兩種語言，通過代碼的探測、分析可以在幾秒鐘内完成一個應用高品質的容器化過程。
Derrick是一個Python語言的本地工具，目前支援NodeJs、Python、Java，開發者可以通過pip在本地進行安裝
下面我們通過一個簡單的NodeJs進行舉例
首次執行<code>derrick init</code>的結果如下
此時在項目的根目錄下已經生成了Dockerfile、docker-compose.yml等檔案了，而這些配置檔案則會成為後續整個DevOps流程的基礎配置資訊，此時執行<code>derrick up</code>的結果如下。
通過 <code>docker ps</code>，我們可以找到此時映射的端口，通過通路端口，即可在本地驗證應用容器化的效果。
通路浏覽器localhost:32774，一個NodeJs的應用已經容器化完畢了。
Derrick目前暫時隻支援NodeJs、Python、Java三種語言，但是Derrick的強大之處在于他的插件體系，開發者可以定義自定義插件的方式來實作自己特定場景的探測。在下一篇文章中會講解下如何通過自定義插件的方式來實作自定義業務的容器化。