今天利用了大概一小時的時間翻看完了《自動化運維軟體設計實戰》
這本書在思路上面給我提供了很大的幫助和借鑑，最近打算搭建一套運維平台。這本書開篇前三章介紹了ansible，puppt以及saltstack，這三個運維工具都是可以單點主機操作多點客戶端，就是操作多個機器像操作單台主機一樣。ansible的思想即使無入侵式的，同時ssh協議，來操作目標主機，而且是主動通知各個目標主機做事情；puppet則是需要部署agent，而且下發操作的思想是我把宣告寫好後公開，各個agent定時過來取；puppet在管理海量節點的時候會有效能問題；第三個就是saltstack，集合了ansible和puppet的長處：既可以ssh，也可以agent，另外saltstack相比較於ansible和puppet是重量級集中式運維工具：因為他引入了zeromq，master和minion之間通訊是zeromq，實現前後台解耦，同時還保證了任何一點掛掉，都不影響訊息被後續執行。
貌似有著各種強大的集中運維工具，但是筆者最終還是決定了自研一套運維系統，因為專案需求比較坑：window+linux混搭，裝ansible被over了，部分機器沒有安裝gcc，沒有安裝python和ruby，這樣puppet和saltstack被over了（puppet採用ruby編寫，saltstack採用ruby編寫，saltstack採用都需要gcc進行編譯安裝元件）；安裝也不太現實，因為機器數量太大，而且有的機器還連不了外網。於是筆者實現了一套類似於saltstack的工具；採用osgi技術開發，容器選用的是karaf（我之前使用的是fliex），採用的理由是熱部署可以完全自動進行（felix需要通過命令列來搞），但是代價就是這個krafa的元件竟然達到了30m，要知道flex才10m。訊息中介軟體選用的是activemq（為什麼不是rabbitmq呢？）
最後一章，作者祭出zabbix。運維其實是分三個層次，了解，決策以及執行；其中了解就是獲知資訊，決策就是根據獲知的資訊決定下一步做什麼（條件分支），執行就是來執行決策；zabbix就是做了解層和決策層的，集中式運維工具就是做執行層的內容。和zabbix互動的方式就是在zabbix中做配置，當觸發了某個呼叫osgi條件，將會通過指令碼向activemq中傳送一條訊息，這個時候osgi作為消費者來監聽activemq的主題，發現有告警，則會觸發相應的操作。
（一）自動化運維架構實戰
一 前言 現在中小型企業運維有一下特點 1.開發人員兼職完成，監控不及時 2.各式各樣的指令碼，重複性高 3.人工參與度高，瑣碎易犯錯 現在網上有很多自動化運維的經驗，有講概念的，有講架構圖的，有講方向的，由此看來，自動化運維是乙個必然的趨勢，那麼怎麼做呢，寫乙個指令碼？安裝乙個軟體？配置一堆東西？...
運維自動化
1，cobbler安裝環境準備 安裝epel epel release 6 8.noarch.rpm x86 64 epel release 6 8.noarch.rpm x86 安裝系列依賴環境 要是區域網用，建議關閉iptables 或是放行25151 80 69埠 和關閉selinux 檢視狀...
自動化運維
考慮的因素 源 打包為映象 發布到映象庫 利用k8s發布到物理機器執行，以服務的形式對外提供服務 目前的做法 0 建立乙個執行遠端命令的框架 1 每個應用建立乙個部署檔案指令碼 a 指定元 位址 c 同步源 到目標主機 d 接受指令碼引數 vername 2 版本號，映象tag fromport 3...