內容：

• 背景介紹
• 手動發布的階段
• 自動化階段---腳本
• puppet
• 自主研發支持
• 支持容器化
• 持續集成

主講師：蘿蔔

• 多年 go 語言開發經驗
• 從事自動化運維和基礎架構相關工作

背景

管理什麽？

• 用戶
• 權限
• 配置文件
• 軟件包
• 服務
• 機器
• cron

特色

• 支持異構系統，linux、windows
• 支持多種語言，java、php、c++、web
• 大規模部署
• 跨 IDC
• 與其它運維工具無縫集成
• 支持全量與增量發布
• 支持健康檢查
• 支持各種並發控制
• 支持各種數據統計
• 實時性要求高

手動發布階段

人肉發布流程

人肉發布優點

• 最直接
• 簡單可信賴
• 小規模，適合創業公司
• 天然支持異構環境，不同語言

人肉發布缺點

• 效率，人力浪費，(@ο@) 哇～，排隊了
• 容易出錯，特別是緊急上線，文件拷少了
• Check考慮不全（經驗總結自動化）
• 流程好長
• 好慢。。。
• 怎麽回滾？
• 人肉並行嗎？

自動化初始階段

• scp、rsync、python
• 依賴運維腳本，需要修改腳本？參數傳少了？別人寫的？
• 嚴重依賴中控機（ACL）
• 腳本缺乏統一管理，散落在各機器上
• 發布的中間數據、結果丟失
• 如何進行回滾、並發控制？

puppet

• puppet 解決的問題
• 自動化部署
• 資源管理
• 系統初始化

puppet 架構

puppet 工作步驟

• 客戶端 puppetd 調用 facter ，facter 會探測出這臺主機的一些變量如主機名、內存大小、IP 地址等。然後 puppetd 把這些信息發送到服務器端。
• 服務器端的 puppetmaster 檢測到客戶端的主機名，然後會到manifest 裏面對應的 node 配置，然後對這段內容進行解析，facter 送過來的信息可以作為變量進行處理的，node 牽涉到的代碼才解析，其它的代碼不不解析，解析分幾個過程：語法檢查、然後會生成一個中間的偽代碼，然後再把偽代碼發給客戶機。
• 客戶端接收到偽代碼之後就會執行，客戶端再把執行結果發送給服務器。
• 服務器再把客戶端的執行結果寫入日誌。

問題

• 二次開發成本
• 機器數量持續增加效率
• 與其他系統集成

自主研發之路

• 設計考量
• 用戶權限、安全管理
• 管理機器
• 管理軟件包
• 跨平臺支持
• 數據統計
• 並發控制、性能
• 持續集成

業務領域

基本架構

機器管理

• 運維手動添加
• 靜態分配
• 按照產品線（分組）
• 權限
• 心跳、存活
• 資源

包管理

• 支持多語言
• 高可用
• 多版本
• 自動構建、打包
  

任務管理

• 調度系統
• Agent 執行器
• 資源中心
• 依賴子系統

Agent 設計考量

• 分布式部署
• 自升級
• 多賬號執行支持
• 任務冪等性
• 各種 agent 如何管理

容器化支持

創建服務的流程

• docker 中部署服務構建鏡像（用 docker build 構建鏡像）
• 發布鏡像（push 到共享的鏡像倉庫中）
• 下載鏡像（使用者將鏡像下載到客戶端本地）
• 運行容器（將鏡像不環境變量相結合，運行容器）
• 訪問服務（通過端口映射或獨立IP的方式訪問服務）
  
  步驟
• 制作鏡像（打包）
• 部署服務
• 啟動容器
• 健康檢查
  鏡像
• 自動構建鏡像
• 鏡像倉庫

• 鏡像大小
  網絡方案
  
  健康檢查

• 配置中心
• 監控告警接入
• 服務自動拉起

開源解決方案

• Mesos+Marathon
• Kubernetes

Mesos+Marathon解決方案

Kubernetes 方案

加小助手微信：1902433859（進入直播分享群）

明晚九點|發布系統演進與持續集成