在以AWS、Google、阿里等為代表的公有云發展的同時，很多大大小小的公司由于一些客觀、主觀的原因只能采用傳統的硬件環境架構，我們北京盛學成長科技有限公司就是這樣一家公司。由于業務性質的限制，不能采用例如阿里云這樣的開箱即用的主機資源。我公司現有硬件資源在很早以前就實現了esxi+vcenter這樣的虛擬機私有云平臺。百分九十的業務都是運行在虛擬機之上的，利用虛擬化基礎架構技術，可以不斷整合工作負載，從而充分利用服務器并降低運營成本。該基礎架構技術不但使系統管理員能夠管理更多的服務器，而且在置備新的軟件服務和維護現有軟件服務時，具有更高的靈活性，響應也更快速。最重要的是，它實現了各種基于 x86 的環境下管理工作的標準化和簡化，這包括 Microsoft Windows、Linux、及Solaris x86 等操作系統。
虛擬機主要是解決了系統資源的靈活運用，這樣看起來很美妙。
那么我們為什么需要容器化?
第一是我們之前的業務系統隨著時間的發展越來越多，不同的組件需要協同去做不同的工作，給運維帶來了巨大的挑戰，有 JAVA 寫的程序，還有些程序制定了必須用 JDK7，有的需要JDK8，還有些業務是用 PHP 寫的，這對運維來講是一個挑戰，我們必須要給各種各樣的程序準備各種各樣的環境，維護，遷移都非常麻煩。
配置混亂，當你應用的服務器數量越來越多，每個應用的管理程序都不一樣 , 有些程序可能只是個定時任務。最終的結果是操作系統中的配置文件和各種黑科技補丁腳本散落在系統的各個角落，沒人能找得到，也沒人搞得懂。
環境不匹配導致測試跟生產環境不一樣，比如生產環境是 JDK8 跑的，某一個開發者本地用 JDK7 測試的程序，上去發現這個東西根本不對，雖然 JDK7 和 JDK8 的兼容性已經是99%以上，但是一個嚴謹的業務系統必須要做到測試環境跟生產環境是一致的。
所以我們需要容器，但是對于一個企業來說，使用容器并不是簡單的使用docker把環境裝上，把代碼放進去，然后把程序跑起來。我們更應該從分布式、代碼快速構建、快速部署、秒級遷移、代碼灰度發布這些角度去考慮我們的平臺。
簡而言之我們更希望我們的應用是：
1.高可用的：應用的可用性不依賴某一個容器主機節點的存活性。
2.持續集成、快速部署：從源碼到環境部署的自動化。
3.遷移方便：應用快速遷移。
理想很美好，但是需要達成這些目標，我們需要做的很多。我們前期對容器化進行了調研，例如容器編排、監控方案、日志收集、網絡方案等等。出于成本的考慮，我們決定前期使用rancher+cattle作為我們的容器平臺。容器間互聯采用了rancher自帶的網絡解決方案，私有倉庫采用wmware的harbor。監控采用了業界比較流行的prometheus。至于持續集成我們決定使用Jenkins，沒有使用rancher自帶的流水線，因為公司的代碼都是放在svn上。
平臺的架構規劃圖：
項目示意圖：
prometheus監控圖：
這些遠遠不夠，例如日志的自動收集與呈現，容器的服務注冊與自動發現、代碼的持續集成還需要后期完善。當然在kubernetes統治一切的時代，切換到kubernetes只是時間問題。