為什么Ruby程序員應該了解和掌握Docker

Docker技術在ruby社區是有影響力的，我所知道的一些創業團隊很早就在運用它來解決環境管理、持續集成以及部署的問題了。但是，也有一些同學尚未注意到這個技術，或者了解過后認為它不是很重要，所以我想討論一下Docker對Ruby系技術的幫助。

有的人可能對Docker技術不太了解，不妨參考論壇里的 這篇文章 以及孫宏亮同學寫的 系列文章

Docker 與 Vagrant

我一直很喜歡Vagrant這個工具，兩三年前就用它來進行自己項目的環境維護，那時候主要是做測試，由于Vagrant將操作系統環境進行了標準化，我很容易就能讓自己的應用系統以及相關的測試結果保持穩定。

Vagrant還有一個好處，Ruby社區比較偏愛Mac，但是線上的系統基本都是Linux，所以開發環境所做的測試是有疑問的，特別是遇到一些有so依賴的gem，這時一個和線上完全一樣的環境就特別重要。

其實上面的表述不太準確，vagrant也有各種provider，我所說的場景，基本上都是virtualbox的provider，所以這些地方正確的說法是 vagrant/virtualbox。

和Docker相比，vagrant/virtualbox組合的成本還是很高的，無論是setup一個環境還是reset一個環境，都需要一段時間的等待，vagrant只是把virtualbox的操作DSL了而已，底層的做法沒有變化。而Docker由于本質上就是一個進程，因此天生就是輕量級的。對于運行時間在分鐘級別的自動化測試工作，docker顯然有很大的優勢。

當然，也有人會認為docker不能模擬完整的操作系統，不過這恐怕是一個優點而不是缺點。我在 以前的文章 中已經說過了，這里概述一下主要觀點——

docker簡化了操作系統這個基礎設施，讓應用精簡為其最核心的形態——攜帶有限資源的進程，在此基礎上更有利于架構上的最佳實踐

微服務

Ruby工程師中有很多就是Rails工程師，而Rails實際上更傾向于單體架構，因此后來社區的工程師們才需要在實際工作中總結 1 to 30 這樣的實踐。

其實微服務本身不是個教條，即使沒有人教，我們也常常自發的去進行服務化改造，但是這個工作并不容易，主要是會受到一些問題的掣肘，比如運維復雜度和系統測試成本會大幅度上升等等。

處理這些困難，首先當然是看是否必要，一些簡單場景我們也可以用單體架構直接搞定，但是我們很容易會注意到，這兩年大家越來越多的提到了微服務或者服務化，這背后其實是有趨勢的——各種業務形態都在朝著互聯網級的用戶規模推進，同時大家都在努力從每一個用戶的各種維度上挖掘價值（這導致了大數據的需求），這些場景變得越來越常見，單體架構是難以支持的。

既然微服務或者服務化不可避免，那么就要有相應的對策，雖然Ruby社區也有很多人在不同問題點上針對微服務進行改進（比如完善異步化框架，以及對服務協議的探索等），但是在基礎設施層面，Docker是最重要的武器，沒有之一！

對Ruby工程師來說，Docker能做兩件事：約束邊界和建立通用基礎服務。

約束服務邊界

Ruby項目Docker化，并不是簡單換個虛擬機那么簡單，我們會面對拆分的壓力，相信很多人嘗試用Dockerfile來描述自己的項目的時候都會覺得束手束腳，但這些地方其實是促使我們想清楚——這個應用到底要做什么？它和外界是什么關系？對于外界的變化它如何響應？失敗后怎樣恢復？

這類的問題對系統架構非常重要。比如應用到底要做什么，這是讓工程師去思考系統的目標，無論是提供web服務，管理調度后臺任務，還是提供實時分析，它們都應該有一個盡可能單一的目標，在這個基礎之上，我們建立的服務才有可能是易測試、易擴展和易維護的。

其它問題也類似，這些地方以前如果沒有留意，很可能不是沒問題，而是沒意識到，使用Docker有助于我們意識到這些問題。

另外補充一點，由于Ruby項目不能完全脫離動態庫依賴（java大都可以），本身的打包機制又沒有自包含結構（gem+bundle不包括動態庫，相比之下，Golang是靜態聯編的），在分布式環境中的交付和軟件包分發其實是有著先天不足的，Docker的Image恰好補上了這一塊，簡直是睡覺時候有人送枕頭了。

建立通用基礎服務

當我們將應用系統分裂為各種服務并明確其邊界以后，就出現了“分久必合”的問題，這很自然，服務化改造并不是各行其是，應用之間還是要協作，而對應用的運維——服務發現、水平擴展、容錯等等——都需要基礎設施的支持。

以前，對于這種運維基礎設施，各公司甚至同一個公司的各個團隊的做法都千差萬別，

但是借助Docker以及周邊的生態圈，我們可以很容易的得到通用的服務發現框架，享受自動的部署和彈性擴展。

更好的消息是，這些基礎服務是通用的——不但不關心是rails還是sinatra，甚至根本不關心是不是ruby。

這也很好理解，Docker是對進程這個操作系統工作單元進行了簡化約束，而進程的概念本來就是與語言和框架無關的

這使得Ruby工程師以及Ruby項目可以更為自由的選擇合適的技術去擴展公司的產品線。

延伸技術框架

Ruby 剛出來的時候，有很多來自 Java 社區的工程師加入其中（我也算是其中之一吧），很多人最大的感受是——視野被打開了。曾經象口號一樣的“all in java”變成了落后的標志，大家意識到，一把鑰匙開一把鎖，用最合適的技術針對性的解決問題才是聰明的做法，單純排斥某種技術或者語言框架并不明智。

這個道理在Ruby/RoR應用開發中也不例外，但是不少人在使用了幾年ruby以后都會遇到一個問題——“ruby確實很適合開發Web，但是現在有些問題需要使用XX技術，而我們的系統嚴重依賴ruby環境，這該怎么辦呢？”

我認為問題就出在“系統嚴重依賴ruby環境”上，研發的基礎設施，比如配管、自動化測試、打包、部署，不應該僅滿足一種技術或是語言，它一開始就要考慮到通用性，否則我們就只能“手里拿著錘子，看誰都像釘子”。

Docker本身和語言無關，它唯一的約束大概就是要運行在Linux上，這個對互聯網服務端系統來說也算是標準了，問題不大。所以，我們應該以Docker為核心打造研發的基礎設施，這將是未來的一筆重要投資。

當然，為未來畫餅是危險的，不過還好，Docker領域的創業很活躍，有很多團隊和公司已經做了相當多的基礎工作，對于Ruby工程師和Ruby創業團隊，去用現成的基礎設施其實更方便。 加粗文字