saltstack案例 自助机

qqwe

　　红色字体为需要考虑的问题
　　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 左右的带宽，所以如果需要做实时的展示大屏，需要考虑这块的瓶颈。