關於雲與持續集成雜談

　　在網上看到了一款號稱雲時代的操做系統：數人云，簡單看了一下其產品Demo：https://dashboard.shurenyun.com/cluster/listclusters ，瞬間以爲很眼熟，有種似曾相識的感受，原來和我2012~2013年時候，在EISOO平臺研發部門時候，爲當時的雲存儲後端系統設計的那個管理後臺第一版有點像。不過那時候還涉及到集羣管理，節點管理等等，比這個更復雜一些，那個是供IT管理員使用的後臺系統；

　　我2011年時候接觸到Openstack，轉眼之間，已是時隔四年多了。那時候的IaaS有OpenStack、CloudStack、Eucalyptus和OpenNebula，固然AWS另說。我當時經歷過Openstack的D~G版本的迭代，不過目前Openstack已是L版本了，當時頗有興趣繼續深刻研究OpenStack，但惋惜，公司的決策層戰略方向與定位決定了，最終主要作傳統的私有云存儲系統，當時對於像UCloud、七牛、UpCloud、青雲等等互聯網式的雲服務並沒有太多興趣；EISOO註定了是一個相對傳統和保守的公司，不過穩紮穩打也是其優點；與我的而言，對於感興趣的東西，在當時的工做機會過程當中，不曾深刻研究，有點遺憾。

　　扯遠了，回來，其實經歷過雲計算，也不算遺憾。我從08年接觸到雲計算的概念，就認爲他在將來將會頗有用處，事實也確實如此，雲計算的應用場景將愈來愈普遍。

　　雲不只僅整合了物理資源、使得計算、存儲、網絡等資源獲得虛擬化和更高效的使用，也節省了資源，固然這是IaaS。

　　而如今PaaS、SaaS也大行其道，當平臺、軟件等等都逐漸以服務化的方式提供出來的時候，這其實也是整個科技發展的一次大的重構。

　　雲時代，服務化、少耦合，架構演進，毫無疑問，將在將來創造很是多的精彩，極大的改善人們的生活，創業環境，讓一切變得簡化，高效。

架構與測試的重要性

　　記得之前剛畢業的時候，參加過CMMI3過程改進事宜，接觸過 RUP，統一軟件過程的理念。RUP的理念對個人架構有很深的影響，RUP實際上是再講下面這三個特色：

1. 用例和風險驅動Use Case and risk driven

2. 架構中心Architecture centric

3. 迭代和增量Iterative and incremental

　　RUP很注重架構，提倡以架構和風險驅動，該開始必定要作端到端的原型prototype；經過壓測驗證架構可行性，而後在原型基礎上持續迭代和增量式開發，開發->測試->調整架構->開發，循環，以下圖所示：

 

　　架構師作好框架以後，開發人員寫代碼，測試人員須要儘快對架構進行驗證。紙上談兵式作架構然後丟給團隊的做法很是不靠譜（除非是已經很是清晰成熟的領域）。另外，作技術架構的都有點完美主義傾向，一開始每每喜歡求大求全，忽視架構的演化和迭代性，這種傾向易造產品和用戶之間不能造成有效快速的反饋，產品不知足最終用戶需求。

　　其實，架構一直在演進、代碼一直在重構，測試一直在優化，纔是一個好的循環。

　　看看下面的這些，摘錄了部分熟人云的描述(參考：http://doc.shurenyun.com/get-started/vocabulary.html)，部分文檔以下：

微服務

微服務是一種新興的應用軟件架構，它經過一組服務的方式來構建一個應用，服務獨立部署在不一樣的進程中，不一樣服務經過一些輕量級交互機制來通訊，例如 REST。每一個服務可獨立擴展伸縮，而且定義了明確的邊界，不一樣的服務甚至能夠採用不一樣的編程語言來實現，由獨立的團隊來維護。

微服務架構有不少好處:

1. 經過將巨大的單體式應用分解爲多個服務,解決了複雜性問題。在功能不變的狀況下，應用被分解爲多個可管理的分支或服務。每一個服務都有一個用 REST API 定義清楚的邊界。微服務架構給採用單一編碼方式很難實現的功能提供了模塊化的解決方案，而單個服務很容易開發、理解和維護。
2. 這種架構使得每一個服務均可以由專門的開發團隊進行開發。開發者能夠自由選擇開發技術，提供API服務。固然，許多公司試圖避免混亂，只提供某些技 術選擇。而後，這種自由意味着開發者不須要被迫使用項目初期所採用的過期技術，他們能夠選擇最新的技術。由於服務都是相對簡單，因此即便用如今技術重寫以 前代碼也不是很困難的事情。
3. 微服務架構要求每一個微服務作到獨立部署。開發者再也不須要協調其它服務部署對本服務的影響。這種改變能夠加快部署速度。微服務架構模式使得持續化部署成爲可能。
4. 微服務架構模式使得每一個服務能夠獨立地擴展。你能夠根據每一個服務的業務量來部署知足其需求的規模。

服務發現

服務發現的基本思想是，任何一個應用的實例可以以編程的方式獲取當前環境的細節，而新的實例能夠嵌入到現有的應用環境而不須要人工干預。服務發現工 具一般是用全局可訪問的存儲信息註冊表來實現，它存儲了當前正在運行的實例或者服務的信息。大多數狀況下，爲了使這個配置具備容錯與擴展能力，這個工具以 分佈式形式存儲在多個節點上。

服務發現減小或消除了組件之間的「手動」鏈接。當你把你的應用程序推送進生產環境的時候，全部的這些事情均可以配置：數據庫服務器的主機和端 口，REST 服務的 URL 等等。在一個高可擴展的架構中，這些鏈接能夠動態改變。一個新的後端能夠被添加，一個數據庫節點也能夠被中止，你的應用須要適應這種動態環境。

數人云爲用戶提供了完備的服務發現能力：

1. TCP/HTTP
   根據服務端口協議的不一樣，能夠選擇 TCP 轉發或 HTTP 轉發；

2. 對內/對外
   數人云不只提供傳統的對外服務發現，還爲分佈式服務提供了對內服務發現；對外服務發現經過外部網關對外提供服務，若是是 HTTP 服務，須要配置域名或外網 IP；對內服務發現經過內部代理，將多實例的微服務端口映射爲統一暴露的端口；

示例

搭建 wordpress 站點的過程當中，須要部署一個 Mysql server 和一個 Wordpress server。

• Mysql 自己的服務端口爲3306，協議類型爲 TCP；Mysql 服務須要對內部模塊開放，開放端口仍然沿用3306。所以，對 Mysql 的應用地址配置以下所示。

數人云對內服務發現機制會自動將應用實例的地址映射爲內部網關的地址。圖中的「地址」一欄，即爲訪問 Mysql 所用的地址，其中 IP 爲內部網關 IP。

• Wordpress 自己是一個 web 服務，其端口爲默認 80，協議類型爲 HTTP；Wordpress 服務須要對外部訪問開放。
  若是外部網關配有可訪問域名，則經過域名訪問服務，開放端口爲 80，不可修改。

若是外部網關沒有配置域名，則經過 IP 訪問服務，開放端口可選，這裏爲防止端口衝突，設爲81。

數人云對外服務發現機制會自動將應用實例的地址映射爲外部網關的地址。圖中的「地址」一欄，即爲訪問 Wordpress 所用的地址，其中 IP 爲外部網關 IP或域名。

容器服務

容器採用沙箱機制，相互之間不會有任何接口（相似 iPhone 的 app），幾乎沒有性能開銷，能夠很容易地在機器和數據中心中運行。最重要的是，他們不依賴於任何語言、框架以及系統。

Docker是一個開源的應用容器引擎，讓開發者能夠快速打包應用以及依賴包到一個可移植的容器中，而後發佈到任何主流的 Linux 主機上。

數人云採用目前流行的Docker容器，基於 Mesos 集羣調度工具，能輕鬆管理和調度成千上萬個容器，作到秒級啓動，秒級銷燬，而且能作到大規模的負載均衡。

數人云提倡客戶採用微服務架構，將微服務架構應用的服務進行容器化，做爲雲計算應用交付的標準。這樣的好處是，不只能保持應用環境的一致性，讓開發和運維等從煩雜的環境構建中解脫出來，還能夠輕鬆作到容錯性、高可用、橫向擴展等特性。  

 

藉助熟人云快速大件Jenkins儲蓄集成環境，測試人員能夠用獲得：

Jenkins

Jenkins 是基於 Java 開發的一種持續集成 (CI) 工具，使用數人云部署 Jenkins 可以在作到快速搭建的同時，實現資源的動態調度，提升資源利用率。

下面講述一下數人云上搭建 Jenkins 的架構和工做流程：

• Jenkins Master

  它負責提供整個 Jenkin 的設置、webui、工做流控制定製等。首先，將Jenkins-Master使用數人云發佈，數人云會對其進行程序管理和健康檢查，從而在應用程序因爲 某些意外崩潰後自動恢復，保證了Jenkins-Master構建系統的全局高可用，使用數人云部署Jenkins使您的Jenkins應用運行在一個資 源池中，進一步實現了資源共享，提升了資源利用率。

• Jenkins Slave

  Jenkins利用在數人云上創建的集羣資源，主要的目的是利用彈性資源分配來提升資源利用率，經過配置Jenkins-mesos-plugin 插件，Jenkins Master能夠在做業構建時根據實際須要動態的申請Jenkins-Slave節點，並在構建完成後的一段時間後，將節點歸還。

• Jenkins-mesos-plugin

  Jenkins-mesos-plugin是用插件模式掛載到Jenkins Master上的。主要目的是要把Jenkins-Master看成集羣的調度器使用，能夠調度用數人云創建的集羣資源爲Jenkins服務。

數人云註冊&登陸&建立集羣

由於數人云迭代很快，因此這裏就不進行詳細描述，最新數人云操做文檔會在數人云用戶手冊中，須要參考的用戶請點擊：數人云用戶手冊

使用數人云部署 Jenkins

部署 Jenkins 應用很簡單，下面是具體操做步驟：

選擇應用管理，點擊"新建應用"，按照以下提示，新建 Jenkins 應用：

• 填寫應用名稱：jenkins
• 選擇集羣：demo
• 添加應用鏡像地址：testregistry.dataman.io/centos7/mesos-0.23.0-jdk8-jenkins1.628-master
• 填寫鏡像版本：app.v0.3
• 選擇應用模式：HOST模式
• 選擇應用類型：有狀態應用
• 選擇主機：主機下拉列表中選擇任一合適IP便可
• 主機/容器目錄配置： 數據掛載目錄：/data/jenkins 容器目錄：/var/lib/jenkins
• 選擇容器規格：CPU：0.2 內存：512MB

高級設置：

• 點擊添加環境變量，填寫環境變量參數：

  Key: JAVA_OPTS      Value: -Xmx512M -Xms512M
    key: JENKINS_PORT   Value: 8002

填寫完成以後，點擊建立便可，建立完成後可看到應用部署狀態等信息：

稍等片刻可看到應用已正常運行：

打開瀏覽器，在內部代理配置好的狀況下訪問 Jenkins，訪問地址爲：yourip:JENKINS_PORT，看到以下頁面，則說明 Jenkins 應用已經成功運行。

Jenkins 數人云設置

若是咱們想要將Jenkins做爲mesos的一個framework註冊到mesos上，須要在成功啓動 Jenkins以後對其插件進行設置。

設置 Jenkins-Mesos 分三層，點擊左上角"系統管理"，而後在系統管理頁面點擊"系統設置"。

1. Jenkins 調用 Mesos 集羣設置

2. Mesos native library path 設置 Mesos lib 庫路徑，通常在/usr/lib/libmesos.so，拷貝無效，必須安裝 Mesos。

3. Mesos Master [hostname:port] 設置 Mesos-Master 地址加端口，若是單 Mesos-Master 模式，使用 mesos-master-ip:5050格式，若是是多 Mesos-Master 使用 zk://zk1:2181,zk2:2181,zk3:2181/mesos 格式
4. Framework Name 設置 Mesos Master 查看到的應用框架名稱
5. Slave username 設置 Slave的名字
6. Checkpointing 設置檢查
7. On-demand framework registration 設置是否在無任務的狀況下，從 Mesos-Master 註銷應用框架

1. Jenkins Slave 調用 Mesos-Slave 類型設置(可按資源)

2. Label String 設置 Slave 標籤

3. Maximum number of Executors per Slave 每一個 Slave 能夠同時執行幾個任務
4. Mesos Offer Selection Attributes 選擇在那些 Mesos Slave 標籤資源上運行，格式{"clusterType":"標籤"}

1. Jenkins Slave 調用 Docker 鏡像設置

2. Docker Image 設置 Jenkins Slave 使用鏡像

3. Networking - Bridge 設置網絡模式，這裏必定要設置網橋模式
4. Port Mapping -Container Port & Host Prot 設置容器端口關係，必須設置不然會致使 Mesos-DNS 因找不到端口映射崩潰，Host Port 默認設置爲空(自動取)，不然必須設置在39000之後的Mesos Slave 選定端口內。
5. Volumes 掛載目錄，必須掛載 slave.jar 和 docker in docker

後續

所使用的 Dockerfile 和啓動腳本所有開源，並上傳到熟人科技的GitHub，若是有興趣的話，卻是能夠參與一下，https://github.com/Dataman-Cloud/OpenDockerFile/tree/master/jenkins。

 

一個基於 Jenkins 的持續集成集羣環境已搭建完成，讓咱們一塊兒快速迭代產品吧，給用戶不斷帶來一個個的小驚喜。