一、自動化運維發展歷程及技術應用
- 打個比喻：
二、自動化運維應用場景
- 文件傳輸
- 命令執行
應用部署
配置管理
任務流編排
三、企業實際應用場景分析
3.1 企業應用場景
-
1 Dev開發環境
使用者：程序員
功能：程序員開發軟件，測試BUG的環境
管理者：程序員 -
2 測試環境
使用者：QA測試工程師
功能：測試經過Dev環境測試通過的軟件的功能
管理者：運維
說明：測試環境往往有多套,測試環境滿足測試功能即可，不宜過多
（1）測試人員希望測試環境有多套,公司的產品多產品線並發，即多個版本，意味着多個版本同步測試
（2）通常測試環境有多少套和產品線數量保持一樣 -
3 發布環境：代碼發布機，有些公司為堡壘機（安全屏障）
使用者：運維
功能：發布代碼至生產環境
管理者：運維（有經驗）
發布機：往往需要有2台（主備） -
4 生產環境
使用者：運維，少數情況開放權限給核心開發人員，極少數公司將權限完全開放給開發人員並其維護
功能：對用戶提供公司產品的服務
管理者：只能是運維
生產環境服務器數量：一般比較多，且應用非常重要。往往需要自動工具協助部署配置應用。 -
5 灰度環境（生產環境的一部分）
使用者：運維
功能：在全量發布代碼前將代碼的功能面向少量精准用戶發布的環境,可基於主機或用戶執行灰度發布
案例：共100台生產服務器，先發布其中的10台服務器，這10台服務器就是灰度服務器
管理者：運維
灰度環境：往往該版本功能變更較大，為保險起見特意先讓一部分用戶優化體驗該功能，待這部分用戶使用沒有重大問題的時候，再全量發布至所有服務器
3.2程序發布
- 預發布驗證：
- 新版本的代碼先發布到服務器（跟線上環境配置完全相同，只是未接入到調度器）
- 程序發布：
不能導致系統故障或造成系統完全不可用
不能影響用戶體驗 - 灰度發布：
- 發布路徑：
/webapp/tuangou-1.1
/webapp/tuangou
/webapp/tuangou-1.2 - 發布過程：在調度器上下線一批主機(標記為maintanance狀態) --> 關閉服務 --> 部署新版本的應用程序 --> 啟動服務 --> 在調度器上啟用這一批服務器
- 自動化灰度發布：腳本、發布平台
四、常用自動化運維工具
Ansible:python,Agentless,中小型應用環境
Saltstack:python，一般需部署agent，執行效率更高
Puppet:ruby, 功能強大,配置復雜，重型,適合大型環境
Fabric：python，agentless
Chef: ruby,國內應用少
Cfengine
func