數人云工程師手記 | 雙劍合璧，分佈式部署兩步走

今天小數給你們帶來的是數人云工程師金燁的分享，有關於自動快速部署DCOS服務相關組件的一些實踐。
當Ansible與Docker相遇，雙劍合璧，一切變得如此簡單有趣。

本次分享將包括如下內容：

• 雲平臺部署使用的服務、組件

• Docker化服務組件

• 初始化安裝控制主機

• 集羣主機系統檢測

• 使用Ansible初始化集羣主機

• 使用Ansible安裝、檢測DCOS相關服務

1、使用的服務、組件簡介

• Ansible 批量管理配置服務

• 初始化主機、批量安裝各服務使用

• test yum repo 部署軟件包源

• 啓動一個簡單 http 服務，把安裝使用的軟件包全放到這個項目中

• Docker 輕量級容器服務

• Cadvisor 監控服務

• test-registry 組件安裝使用鏡像倉庫

• Haproxy 負載均衡組件

• Keepalived 高可用組件

部署在master1 和 master2 兩臺主機，經過檢查這兩臺主機部署的haproxy進行VIP 漂移。

• MySQL數據庫

• 自研組件

• Consul 服務發現、健康檢查、健值存儲外訪問的切換

• Zookeeper Mesos Marathon

• DCOS 核心組件，負責集羣資源管理，應用調試

2、主要服務的功能說明及邏輯架構

上面簡單介紹了安裝整個 DCOS 服務的完整過程，在安裝各組件前，咱們都會先檢測是否已經安裝了該服務，若是已經存在會停止安裝，人工檢查後，再進行後續操做。

一、test yum repo

test-yumrepo 是一個簡單的 yum 源服務，裏面放置了安裝 DOCS 須要使用的全部 rpm 包，使用 createrepo 命令進行建立和更新yum 源。

二、test registry

在安裝 DCOS 前會把組件鏡像全 push 到 registry ,不設置認證用戶，配置申請好的證書。

使用這個 registry 時，只須要添加域名解析就能夠。

registry 的數據目錄，直接複製目錄到其它主機。

再啓動 registry 服務容器就能夠直接使用，而不須要導入導出浪費時間。

由於 docker 鏡像是分層的，不一樣的鏡像，也會共用一些公共的鏡像層。

使用這個原理，鏡像大多數的服務都使用相同的 base 鏡像，這樣全部的鏡像都放置到 registry 中，就能夠減小佔用磁盤的容量。

三、自研組件

DCOS 自研的控制界臺

四、Consul

用它來作各服務的健康檢查、服務發現、MySQL主從切換等。

consul 分爲server 和 client ，咱們註冊、註銷服務都是經過 client API 進行,這樣的好處是 client 上的主機服務都綁定在 client 端，健康檢查也都是經過 client 端進行本地檢查。

服務自己的狀態查詢查詢則是經過 Server 端。

consul 的服務發現

consul 有多種服務發現機制，咱們使用的是比較簡單的 dns 模式，經過 consul 自帶的 DNS 解析功能實現的。

各服務安裝好後，經過調用 consul 的 API 註冊服務。

須要服務發現的組件經過 docker run 參數 添加 --dns , 在容器內部就能夠解析到 consul 中註冊的服務地址 , 例如： 訪問數據庫的配置就能夠設置爲 mysql.service.consul:3306, 這樣的配置。(固然支持srv 服務能夠直接用)

五、Haproxy

haproxy作爲平臺服務的負載均衡服務，對外服務配置服務時，配置的是 consul 中的服務域名。

這裏有個坑，原來使用 haproxy 1.5 版本, 後端服務使用域名時，啓動後只解析一次(和nginx相似)，這時若是解析到的服務掛掉，訪問haproxy頁面時會503.
查詢官網得知 haproxy 1.6 支持了動態 dns 域名解析的配置，後升級爲 haproxy 1.6。

下面是動態 dns 解析相關的配置內容：

六、MySQL 基於 Consul 的主從切換

最初的MySQL主從切換是基於 haproxy+keepalived 來作高可用的。

這種機制下，MySQL主從切換的簡單需求須要引入2個開源組件，架構上也很是複雜。

爲了減輕架構複雜度和可維護性，咱們將主從切換改成了使用 Consul 進行主從切換。MySQL是安裝了兩臺，一主一從，設置權限時，主是讀寫的，從是普通用戶只讀權限。

經過將服務註冊到 consul 來作健康檢查。

MySQL Master 和 Slave 註冊到一共註冊四個服務到Consul, 以下代碼：

正常狀況 mysql-vip.service.consul 解析到 主mysql ip。

這裏會分兩種狀況切換到從解析：

• 主MySQL掛掉後，ip解析到從mysql ip，mysql-vip 切換到從Mysql IP

• 主庫的 consul 掛掉也會致使服務沒法解析，即便 mysql-master 正常，因此若是 consul 掛掉也會被激活切換。

請注意：由於MySQL從是隻讀的，至關於降級服務。

七、Zookeeper Mesos Marathon

參考之前寫的文章：容器公司如何用容器進行產品迭代
http://blog.dataman-inc.com/s...

3、Docker化服務

一、dockerfile語法

dockerfile 的語法比較簡單，相似shell， 經常使用的命令主要有：

• FROM 依賴的基礎鏡像

• RUN 執行的shell命令

• ADD 添加本地文件目錄或下載網絡中的文件而且解壓到鏡像中

• COPY 複製本地文件或目錄到鏡像中

• ENTRYPOINT docker容器啓動時的默認命令

• CMD docker容器啓動時的默認參數

參考：https://docs.docker.com/engin...

下面是dockerfile的示例

二、dockerfile 的一些小技巧

docker 鏡像的默認啓動命令能夠是一個自定義的 shell 腳本，例如咱們編寫一個 entrypoint.sh 腳本，能夠在啓動腳本中作不少事情，好比初始化服務、拉取配置、替換變量等等。

三、Dockerfile示例：Zookeeper

Dockerfile

Zookeeper啓動腳本：
cat /data/run/dataman_zookeeper.sh

四、docker build

五、docker run

參考 https://docs.docker.com/engin...

六、數人云開放的一些服務的 Dockerfile

https://github.com/Dataman-Cl...

4、初始化安裝控制主機

一、啓動test yum repo

啓動test yum repo，把 test yum repo 配置到當前主機的/etc/yum.repos.d/test.repo

配置內容以下：

而後就能夠很方便的安裝一些必要的工具服務。

test yum repo的使用方法

其中 --disablerepo=* 是禁用其它 yum repo, --enablerepo=repo 是開啓數人云 testrepo ,這樣作是爲了防止其它 的yum repo 影響 yum 安裝 的過程，減小出錯。

二、安裝須要使用的基礎服務

安裝須要部署DOCS須要使用的服務,和一些調試工具
yum --disablerepo=* --enablerepo=testrepo install -y net-tools iptables ansible 等。

修改 NTP server 的配置。

三、啓動安裝集羣組件使用的鏡像倉庫test-registry服務

5、集羣主機系統安裝前配置及檢測

安裝機準備好 yum repo 和 test registry, 咱們就能夠準備安裝 DCOS集羣了。

安裝前咱們會先檢測當前安裝機的服務是不是咱們要求的主機狀態，檢查包括：

• yum repo 狀態正常

• test registry 狀態正常

• NTP server 狀態正常

而後修改ansible 配置ansible/inventory/hosts。

規劃好主機列表及角色，內容示例以下：

修改自定義的主配置文件config.cfg，這個配置中主要包含了，集羣使用的 DCOS master 列表，mysql 主機、用戶、初始密碼，Keepalived 主機、VIP地址，之後面各服務就從這兩個配置中讀取內容生成最終配置，再進行安裝。

在安裝服務前會檢測各主機：

• 系統版本、內核版本檢測

• 文件系統檢測

• 磁盤容量檢測

若是檢測到的結果異常會跟停止安裝。

6、初始化集羣主機

前面的初步檢測步驟經過後，咱們就會對集羣主機進行初始化操做。

包含的內容有：

• 基礎操做
  防火牆、selinux 等

• 主機名
  設置主機機名解析

• NTP 客戶端
  設置 ntp 服務

• Docker
  安裝配置等

• 安裝運維調試工具
  出問題檢查的各類工具，好比 netstatdig等

• 主機初始化後的環境檢查
  以上初始化的檢查

7、總結

最終咱們經過 Ansible 完成了將整套的分佈式部署抽象成了兩步完成：

• 在一個配置文件中配置整套安裝方案的服務；

• 執行安裝腳本。

這個服務並非完美的，還有不少能夠優化的，好比大數量主機安裝的效能問題等，咱們會持續對其進行改進。

歡迎你們一塊兒交流、探討經驗。謝謝你們。

Q&A

Q1：如今Docker的版本更新也很快，那數人云是怎麼來考慮這個版本的，每次跟着更新，仍是延後多少個小版本？
A1：每次Docker更新咱們都在在內部進行測試，通過一段時間的驗證，沒有什麼大坑的時候，就更新。沒有特定的，延後固定幾個版本。

Q2：此前看到一篇文章說，Docker是沒有後向兼容的，每次更新版本都會很是痛苦。大家是怎麼處理這個問題？
A2：這個問題咱們也很煩惱，咱們是一臺一臺主機的升級，不會影響業務的正常使用。DCOS集羣自己是高可用的，因此宕機一、2臺也不會有問題。

（承接上一問）
Q3：通常來講，DCOS集羣咱們都建議上百臺主機，那一個DCOS集羣升級一次大概要耗時多久？
A3：升級的話，提早規劃，按應用或集羣的角色劃分好批次 好比說 Master不能同時升級，兩個MySQL主從不能同時升級，Elasticsearh 集羣不能同時升級等 提早進行docker pull 預熱 100臺主機，完整升級一次預計要半小時左右。這個半小時不包含準備時間。

Q4：大家docker volume怎麼解決的？
A4：例如MySQL這種須要持久化數據 的服務，咱們是發到固定主機。若是是Elasticsearch，這種自己已經有數據同步的服務，咱們是直接掛載出來，指定一個主機範圍。

Q5：能分享下數人云在DCOS+DevOps方面的經驗麼？A5：此次分享的集羣安裝就是咱們DevOps的一部分，咱們的應用和組件都是Docker化的，使用ansible docker run或調用marathon api 進行、更新發布應用，平時的工做主機就是Docker化服務和把這些服務發到DCOS集羣中。