如果各位是碼農或者運維，在自己的企業里，你或許會注意到即使已經配備了幾十台測試主機，資源仍然還是不夠用，各個產品小組還在不斷的提出測試機資源需求。如果你的單位已經建立了良好的控制流程，那麼恭喜你。此外，你是否思考過，建立這一流程所消耗的時間和資源？

技術棧應用現狀

1）分布式系統構建過程複雜

支撐業務服務的技術堆棧中，為了提升處理能力並避免單點故障，大部分都是分布式設計或者支持ha。前文多次提到過，當前分布式系統的拓撲結構通常是靜態的，隨著技術堆棧中的分布式服務越來越多，特別是在應用微服務之後，機房裡少則幾台，多則數十甚至成百上千台伺服器，，即使配備大量的運維人員，採用CI/CD，精準的開發流程控制，也不現實。

2）負責開發的人員通常不會考慮部署運維

作為開發人員，需要深入理解業務後創造性的將業務以代碼的形式呈現。當前，特別是互聯網應用，代碼或多或少需要運行在分布式的環境中，如果對代碼所運行的環境一無所知，開發人員實際上只理解了一半的需求，在實際項目構建中往往會出現很多扯後腿的情況。來自阿里的互聯網架構八榮八恥對這一點概括的很好：

• 以可配置為榮 ，以硬編碼為恥；

• 以可互備為榮 ，以單點為恥；

• 以可無狀態為榮 ，以有狀態為恥；

• 以可隨便重啟為榮 ，以不能遷移為恥；

• 以整體交付為榮，以部分交付為恥；

• 以標準化為榮，以特殊化為恥；

• 以自勱化運維為榮，以人肉化運維為恥；

• 以無人值守為榮，以人工值班為恥。

全流程開發需求

當前，構建軟體開發的全流程，大致涉及需求任務及缺陷管理，源代碼管理，產品開發流程，產品構件管理，持續集成/持續部署流程，代碼審查、測試，開發環境，集成環境和生產環境等。

除了這些流程、過程和環境，現代互聯網應用特別是雲原生（Cloud Native）應用的開發涉及大量的分布式基礎服務。如：Redis，Tomcat，Zookeeper，Etcd，Storm，ELK，Kafka，HDFS，Spark等等。

本文目的

本文並不是專門針對如何構建生產環境應用集群，而是探討如何藉助於DC/OS構建一個由主機伺服器，DC/OS和應用開發部署運營的三層體系，覆蓋軟體生命周期的全過程。

理想情況下，採用這個三層體系後，任何企業的內部環境和外部環境都運行在DC/OS集群之上。運維負責管理底層的主機伺服器及網路等硬體、操作系統和DC/OS；開發人員負責管理DC/OS之上的應用及開發流程。

構建過程

本文通過構建三個DC/OS集群，覆蓋企業產品開發的全流程。具體包括：DC/OS驗證集群，DC/OS研發集群和DC/OS生產集群。

• DC/OS驗證集群

  此集群僅用於驗證DC/OS相關特性，運維步驟，新服務框架的測試性搭建等。必要時，可以重置系統重新部署集群。

• DC/OS研發集群

  此集群用於支撐內部研發。上述提及的全流程開發中的內部環節都在此DC/OS集群中完成。

• DC/OS生產集群

  用於部署線上生產環境及應用。

鑒於各個企業內部的環境及軟體研發過程千差萬別，本文只討論部分關鍵環節，如果大家嘗試此種方案，請自行根據內部具體環境進行調整。

前文《微服務架構在DC/OS上的實踐落地指南》在討論微服務架構的過程式控制制時，我們提到了下述CI/CD流程：這裡，我們以此構建基於DC/OS的全流程開發體系。

Gitlab

Gitlab可以單獨部署（安全性要求），也可以直接部署在DC/OS研發集群中（如果部署在DC/OS研發集群中，可以通過Universe倉庫直接安裝）。Gitlab可以擔負以下職責：

• 需求任務及缺陷管理

• 源代碼管理

• 產品開發流程（Gitflow）

• 容器倉庫（可選）

• CI/CD（Gitlab CI）

上述職責中，除了源代碼管理和產品開發流程，其它職責都有可替代的工具。Gitlab CI有與Gitlab集成的優勢，部分CI/CD任務可以嘗試使用它，但更推薦成熟強大的Jenkins。

Jenkins

如果內部研發網路與生產環境網路之間的帶寬足夠，Jenkins可以僅部署在DC/OS研發集群中。否則，建議Jenkins在DC/OS研發集群和DC/OS生產集群均做部署。DC/OS中的Jenkins可以直接從Universe倉庫部署。

Jenkins執行Job任務時，動態的從DC/OS集群中分配資源啟動Slave主機執行任務Job。任務執行完畢後，分配的Slave主機資源會自動回收。

當開發人員將代碼提交到Gitlab的測試分支後，Gitlab自動觸發測試Jenkins中的Job任務，拉取代碼，審查，編譯，測試，打包並調用DC/OS中Marathon提供的REST介面發布到DC/OS研發集群中。

當業務功能完成集成測試後，功能代碼通過MR（Merge Request）合并到發布分支。由運維人員根據工單執行Jenkins中的生成環境部署任務。這裡的任務既可以來自研發集群中的Jenkins，也可以來自生產集群中的Jenkins。

上述過程涉及到幾個研發決策：

• 這裡假定項目構建工具為Maven，打包編譯的構件會發布到DC/OS中的Nexus；

• 採用Maven Docker Plugin將編譯的構建打包為Docker鏡像文件並上傳到容器鏡像倉庫；

• 容器鏡像倉庫可以選擇Docker Registry，Nexus或Gitlab等中的任意一個；

Nexus構件倉庫和容器鏡像倉庫（Docker Registry，Nexus或Gitlab），根據網路帶寬，既可以讓兩個DC/OS集群（研發和生產）共用一個，也可以各自獨立部署。

Nexus

Sonatype Nexus支持多種構件格式，既可以做Maven倉庫，也可以做容器倉庫。通過Universe可以直接部署Sonatype Nexus。

Docker Registry

關於如何在DC/OS集群中搭建私有容器倉庫，後續會有一篇文章進行詳細的介紹。可以通過Universe直接部署Docker Registry。

Marathon

請參考《微服務彈性計算平台DCOS的容器編排引擎—Marathon》一文。

資源規劃

運行DC/OS集群的資源需求比較高。DC/OS驗證集群可以通過一台2U4節點的二手伺服器（HPE或DELL）代替。DC/OS研發和生產集群的具體硬體配置要根據企業內部具體情況具體決定。

下述是大家構建DC/OS集群的最低硬體配置。

這是Master節點的硬體配置（Master節點在驗證集群中節點數可為1，在研發集群中節點數可以為3，在生產集群中可以為3或5）。

這是Agent節點的硬體配置。當前機器硬體通常選擇12-16核/單機，64GB內存/單機。

集群部署完成後，Agent節點可以動態添加或移除。

應用集群示例

除了上述研發過程工具之外，業務系統開發所依賴的所有第三方基礎服務，如Redis緩存，Kafka等均通過Universe安裝。DC/OS中的公共存儲也有多種方案可選，如NFS，GlusterFS，Ceph和SDN等。下述通過一個示例來演示在DC/OS中進行應用開發與部署。

1. 準備工作

定義marathon服務配置

方案一：直接由marathon啟動tomcat並部署war

定義如下json設置，並保存到app.json

方案二：將Tomcat和War包打包成Docker鏡像，部署鏡像到DCOS

假設docker鏡像名為「docker-tomcat-war」，定義如下json配置，並保存到app.json

調用DC/OS的REST介面部署APP。

根據上述兩種方案，選擇其中的一種，執行下述指令部署應用：

curl -X POST -H "Content-Type:application/json" "http://192.168.1.69:8080/v2/apps" -d @/Users/chrisrc/Dcos/Services/app.json

為服務添加心跳監測

可以為要部署的Tomcat應用增加服務心跳監測，配置如下：

完整的配置示例如下：

補充：

1）如果要在jenkins直接使用腳本配置，則可以如下定義腳本：

2）默認Tomcat安裝包是不帶Java運行環境的，如果要正確運行，一種可選的方案是添加JRE的下載URI，並修改命令腳本；一種是定製Tomcat，將JRE打包進去，下載的URI指向自定義的Tomcat下載位置。

2. 配置Jenkins任務

全局設置

通過菜單「系統管理」——「系統設置」打開系統全局配置，下拉到底部「雲」——「Mesos Cloud」配置塊部分：

點擊底部的「高級」按鈕，在展開項中可以配置啟動的Jenkins Slave節點的標籤及資源配置等信息。通過標籤，可以將任務指派給設置了特定標籤的Slave節點運行。

提示，可以添加多個Jenkins Slave節點，分別配置不同的標籤及資源配置。

構建編譯打包及部署的任務

Jenkins的任務定義通常根據Git workflow，內部管理流程及項目特點進行定義。本示例僅演示如何在Jenkins on DC/OS上構建自動化的CI/CD流程，在生產環境中應根據實際需求做出調整。

創建一個名稱為「demo_dcos_marathon_tomcat」的自由風格項目任務。

設置該任務運行於某個特定標籤的Slave主機（本示例忽略此步驟）。

配置Git源代碼庫的位置

配置構建觸發器。通過此步驟，可以在開發人員提交代碼、合并分支或標記Tag時自動觸發Jenkins任務的執行。

在構建環節，增加構建步驟：「Execute shell」，添加如下命令:

如果部署的是Docker鏡像，上述配置需要相應做一些改變。

提示：

1）Tomcat啟動時如果設置了最低和最高JVM內存，上述配置的內存配置應該高於JVM最高內存配置。

2）如果WEB應用的啟動需要耗費一定的時間，注意設置健康檢查的gracePeriodSeconds參數值。

3）此處部署調用了Marathon的POST指令的REST API，如果要重複部署，則需要調用PUT指令的API。注意，PUT指令要求APP的JSON定義存在變動，否則不會重新部署，因此可以通過添加Label並在每次編譯時動態變更標籤的值的方式，如：PROJ_BUILD_ID:"""$BUILD_NUMBER"""。

4）在Shell腳本中使用字元串環境變數替換時的寫法： """$TR_TORRENT_NAME"""保存任務配置，退出。Jenkins任務列表中可以看到根據上述配置創建的任務：

3.構建和執行

點擊右側執行圖標，立即執行。Jenkins調用介面向DCOS集群部署啟動一個mesos-jenkins slave節點，執行此任務。

4.為服務添加負載均衡

通過Marathon-LB可以實現多個Tomcat節點的負載均衡。在下述示例中，我們部署3個Tomcat應用服務，每個Tomcat應用服務公開8080埠，然後通過Marathon-LB的10010埠統一對外提供服務。

在實踐下述示例步驟之前，確保：1）集群中部署了Public Agent節點；2）Marathon-LB已經安裝在Public Agent節點上。

首先，修改前述示例中Jenkins任務的構建腳本配置，添加埠定義和HAPROXY_GROUP標籤：

保存Jenkins任務配置，重啟執行任務。

Tomcat服務在DC/OS中部署後，查看其中的一個服務實例：

在瀏覽器里調用服務並測試：

通過Marathon-LB的10010埠訪問服務：

5.小結

每一個獨立的Tomcat容器內部服務實例的埠為8080，容器對外映射到Host主機的埠是隨機的，如本例其中的一個Tomcat容器實例運行時映射的埠為11907。DC/OS將192.168.1.80:11907通過Marathon-LB（部署在192.168.1.51）進行負載並通過埠10010對外提供服務。

多個Tomcat實例通過埠portDefinitions和HAPROXY_GROUP標籤定義與Public Agent節點上的Marathon-LB進行綁定。

可以根據需要通過DC/OS控制界面動態擴展或縮減Tomcat的實例數。

6.擴展

1. 通過UNIQUE或GROUP_BY標籤限定節點上的實例數。

2. 通過自定義標籤進行實例分組和過濾。

3. 將Jenkins的$BUILD_ID參數作為生成的Docker鏡像的Tag，可以通過DC/OS WEB控制台調整服務的Tag，實現服務的降級回滾。詳細示例請參考持續集成與部署

結論

本文闡述了使用DC/OS覆蓋開發的全流程的操作綱要，對於每一環節，都可以詳細展開。後續文章會針對性的進行討論。

關於採用DC/OS的基本功能特性，請參考文章《彈性服務平台DC/OS—概覽》和《使用VAGRANT在本機體驗彈性微服務平台DC/OS的特性》。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！