saltstack案例 自助機

紅色字型為需要考慮的問題

http://jaseywang.me/2017/01/06/%E9%80%9A%E8%BF%87-novnc-%E5%AE%9E%E7%8E%B0%E6%95%B0%E5%8D%83%E5%8F%B0%E8%87%AA%E5%8A%A9%E6%9C%BA%E7%9A%84%E5%AE%9E%E6%97%B6%E5%8F%AF%E8%A7%86%E5%8C%96/

需求

1.日常變更

2.更新管理

3.開關機

Wake-on-LAN 完爆 AMT

樹莓派 Wake-on-LAN 不支援跨網段的喚醒

salt 初始化，zabbix/freeipa 注冊

開關機時間都不同 頻繁修改

bangkok 上面的 KioskScheduler ->一套開放平台(open)->将其寫入到 MySQL

底層通過 APScheduler 這個任務架構來排程，使用 BackgroundScheduler 排程器，預設的 MemoryJobStore 作業存儲

KioskScheduler 根據以上優先級的不同，優先執行高優先級的規則

部署在院内的 4 台樹莓派通過 syndic 機制收到請求後同時向目标機器發起喚醒的請求

如何有效實作自助機的變更操作

saltstack master/syndic/minion

中心端一台 master（存在單點的問題），每家院區 4 台部署了 syndic 的樹莓派，同時跑 master/syndic，向中心端注冊，底層的自助機部署有 minion 向其中一台 syndic 注冊，目前 minion 到 syndic 同樣存在單點問題，後續考慮将 syndic 更新成 MultiSyndic。

對于第一種變更方式，我們将要更新的版本庫檔案打包上傳至 git，通過 jenkins 将資料從打包機 git pull 下來之後，在打包機通過 salt 将更新的檔案分發到 salt syndic 上，syndic 上會起 http 服務，自助機每次開機的時候會自動的向 http 服務檢查是否有最新的版本，如果有的話則會更新，對于復原，我們将版本号遞增内容復原至上一版本重新開機機器即可。

如果是傳輸檔案的變更，跟第一種方式類似，不同的是，檔案落地到 syndic 之後，我們會直接通過 master/minion 的方式 push 到每台自助機，而不是主動 pull 的方式。同時為了确認檔案的完整，每次從 master 到 syndic，從 syndic 到 minion 的兩個關鍵步驟都會做一次 md5 校驗，最終實作的效果可以參考早期的 saltpad 版本，下圖是 bangkok 中變更的頁面展示

在這之前，我們嘗試直接通過 salt master/minion 的方式進行日常的變更管理，這種方式對于線下的實施同僚來說非常的不友好，其靈活性以及友善性遠低于目前的方案，遂未在團隊内推廣使用。上面介紹的系統是目前線上的穩定系統，使用了一段時間整體回報還不錯，後續會優化版本控制以及更加自動的復原等操作。

監控

為了確定 KioskScheduler 運作正常，應用層面通過 monit 實作程序的監控，業務層面的規則執行與否以及是否達到預計，我們通過 python-nmap 實作了一個批量掃描的腳本，每次開關機時間點觸發後的 5min/10min/15min 三個階段，對命中規則的自助機進行批量的存活性掃描，對于未達到期望的自助機會觸發報警到我們的自助機運維同僚那邊進行人工處理

為了及時發現這類問題，我們後續在所有樹莓派上全部引進了溫度、濕度以及煙霧的傳感器，成本非常低，一個 DHT11 的溫濕度傳感器加上一個 MQ-2 的煙霧傳感器成本在 20RMB 以内，加上現成的 Adafruit_DHT/RPi.GPIO 的庫直接調用，完美解決此類問題。通過分散在不同地點的四台樹莓派，我們能夠推斷出目前院内的實體環境，這對改進目前自助機的實體位置有非常重要的意義。

通過 noVNC 實作數千台自助機的實時可視化

由于 TightVNC 預設不支援 WebSockets， noVNC 提供了 websockify 這個工具來做 TCP socket 的代理，接受 WebSockets 的握手，轉化解析成 TCP socket 流量，然後在 CS 兩端傳遞。由于我們涉及到較多的機器資訊需要維護管理，我們将所有的機器資訊，比如自助機的編碼，機器名，IP/MAC 相關的資訊預先存儲到 MySQL 裡面，接着按照 token: host:port 既定格式生成每家院區的連接配接資訊配置檔案，這一步可以在 jenkins/rundeck 上建個 job 友善每次增删改查。接着就可以啟動了轉發了。

noVNC 預設情況下會以互動式的方式連接配接，在這個過程中會做身份權限校驗(賬号連接配接、讀寫控制)，是否是 true color 等，這個對于生産不是很适用，我們後來将授權這塊做在 Django 上，結合 LDAP 做登入認證。考慮到專線帶寬的限制，預設關閉了 true color 開啟了壓縮。VNC 對帶寬的消耗還是比較厲害的，平均下來，每開一個新連結，會消耗 1Mbps 左右的帶寬，是以如果需要做實時的展示大屏，需要考慮這塊的瓶頸。

本文轉自 liqius 51CTO部落格，原文連結：http://blog.51cto.com/szgb17/1932435，如需轉載請自行聯系原作者