關於在項目中有沒有必要使用docker的一點感悟

1、背景

    筆者在一家供應鏈公司，主要業務是跨境商品，公司研發部門成立於2016年4月，仍是比較年輕的，項目開發採用傳統的MVC架構，平臺交易量不是很大不大。

2、使用docker帶來的好處

一、應用打包

    之前咱們發佈應用一般把應用打成war包而後交付給運維，由運維統一上線，可是會出現這麼一個狀況，就是運維對應用的配置不是很清楚，有可能出現配置不當或者由於某些環境差別致使應用發佈失敗，而採用docker後，開發只須要提交代碼到Jekins，而後Jekins檢測到版本庫是否有更新，若是有代碼更新則自動構建打包成image鏡像，而後上傳至docker registry，運維要作的就是在docker registry獲取最新的image而後發佈就好了，這樣就避免了上訴狀況的發生。

二、快速回滾能力

    筆者之前犯過這樣一個錯誤，一個商品搜索系統由於修改了某些代碼，上線後Elasticsearch拋出了異常，由於沒有備份上一個war包，因此就需找出問題所在而後從新編譯源代碼及修改配置，最終生成war而後再從新上傳，致使咱們搜索服務癱瘓了2個小時，當時就想，若是把war包打成docker鏡像，而後上傳至docker registry ，這樣若是線上出問題，就能夠拉取上一個image，由於上一個版本的鏡像就存在本地，因此回滾到上一個版本就是分分鐘的事了，固然也能夠寫一些腳本自動化完成。

三、橫向擴展能力

    當項目設計高併發，這時項目須要橫向擴展，傳統作法就是加機器，可是一些公司申請機器是很是耗時的工做，就拿筆者公司來講，要申請一臺機器最起碼要3天時間，時間太慢，這時候就可使用docker來解決這個問題，就是使用公用CASS平臺或自建CASS平臺，這樣當併發來時，就能夠在分鐘級別啓動多個容器來承載更多的併發，當峯值過去了，就能夠動態縮容，避免資源浪費。

3、我司爲何沒有采用Docker

1.項目不涉及高併發

2.項目規模較小，人工徹底能夠應付

3.對於代碼回滾能力，咱們能夠實現備份war包，當出現問題時可使用替換war包的形式，而不是使用 Docker，由於若是採用docker，還有搭建私有docker registry，太過於重量級。

4、總結

項目要儘量簡單化，不必爲了技術而技術，適合本身才是作好的。

5、注意

在使用docker時要思考下下面幾項。

1.使用docker後日志咱們該如何採集，有朋友會說能夠在image裏放一個agent用於收集日誌，而後上傳至日誌處理中心，可是想一想，是否符合docker的原則呢（一個容器只負責一件事）

2.容器多了咱們該如何管理？

是使用 docker自帶的調度仍是k8s又或者是mesos？學習成本如何？

3.如何作容器的監控

以上是個人一點總結，系統大神們斧正。