| 编辑推荐: |
| 来源于csdn，本文通过平台具备功能、架构设计、模块定制、安全审计、C/S结构的实现等几个方面内容来展开。 |
|
受 Reboot 邀约与大家聊聊运维自动化的议题，与大家一起探讨如何基于Python构建一个可扩展的运维自动化平台，也希望能与大家一起交流，共同成长。
此次分享将通过平台具备功能、架构设计、模块定制、安全审计、C/S结构的实现等几个方面内容来展开。
为什么选择Python？
几点优势：默认安装且跨平台、可读性好且开发效率高、丰富的第三方库（开发框架、各类API、科学计算、GUI等）、社区活跃&众多开发者。
Python在腾讯的现状，根据去年内部提交组件语言统计，除去2、3、4前端技术，Python在高级编程语言中排第3位。应用在系统运维、业务逻辑、运营平台、测试工具、数据挖掘等领域，腾讯大名鼎鼎的“蓝鲸”运维PAAS平台就是基于Python语言来构建。
一、平台介绍
OMServer 一个集中式的Linux集群管理（基础）平台（《Docker技术与最佳实践》书籍实践案例），具备业务集群管理、实时安全审计、功能模块定制、数据加密传输、支持主流Python组件、使用简单且体验好等特点，源码托管地址：https://github.com/yorkoliu/pyauto，大家可以根据企业的需求定制修改及发布。
1、平台截图：
2、平台采用到的第三方库:
1.Django -
一个开放源代码的Web应用框架，由Python写成，采用了MVC的软件设计模式；
2.rpyc -
一个 Python 实现的RPC和分布式计算的工具。支持同步和异步操作、回调等；
3.saltstack 、ansible 、func -
基本Python开发的自动化配置管理与流程控制组件；
4.Mysql -
是一个非常流行的关系型数据库管理系统。
二、平台架构设计
1、 OMServer架构图
大家对这个架构应该不会感到陌生，三层结构也是目前主流的运营平台架构。
2、
架构说明
OMServer平台为三层架构，分别为WEB交互层、分布式计算层、集群管理服务层。
1）、第一层：即为WEB交互层，典型的B/S架构，以供管理员操作的交互平台，也是OMServer的核心，基于Django开发；
2）、第二层：分布式计算层，提供与主控端的连接通道，采用的是rpyc传输协议，协议操作流程：前端模块参数->加密传输->任务执行->返回结果集->解密输出。
3）、第三层：集群管理服务层，整合Python主流的远程操作组件（支持Saltstack、Anaible、Func），对被控端（业务服务器集群）进行管理，其中主控端可以根据不同IDC环境，采用多地多点的管理方式，可提升冗余度及执行效率。主控端操作模块以不同Python文件加以区分，便于维护，可灵活定制操作逻辑及横向扩展等特点。
3、
平台架构优势
1）管理端多机支持，可按不同IDC划分；
2）安全性高，加密传输、定义私有通讯规范（TCP）；
3）支持多种管理客户端接入（WEB、桌面、移动）；
4）调用Python组件的高级特性（Playbook、State）；
5）功能扩展性能力强，模块定制化。
4、架构操作流程
p class="artcon"> 上图将三个层次的交互流程进行串连，可以清晰了解OMServer架构的操作流程，结束了传统式直连APP
Server的操作，更加规范我们的操作事件，一定程度可以避误一些潜在的误操作。
5、整合远程操作Python组件
分别两个步骤：
1、提前配置主控端与被控端的信任关系，一般为证书或SSH
认证；
2、通过OMServer主控端封装好的任务模块与API接口，实现定制化的任务下发及执行。
三、平台模块定制
1、任务模块定制的思路
1）任务模块 –
即为一个“操作事件”为颗粒的任务，如重载配置、部署缓存服务、停止Nginx服务等原子操作；
2）添加模块的步骤：
定义任务模块“输入参数”，采用HTML Form元素，可以为输入、下拉、单复选框等元素；
编写后台模块代码，其中执行部分由Saltstack或Ansible的Client_API来实现；
任务模块核心代码，只需要5行代码就可以实现一个SHELL脚本下发、执行的功能。
3）运行模块的步骤 -
选择任务模块 & 操作对象 ->
指定输入参数 ->
运行 -> 返回执行结果。
2、当我们的平台已经具备可定制、扩展操作的能力，运维的核心工作就聚焦以下几点：
1）平台功能改进、升级，需要具备DevOps能力；
2）根据业务运营需求，做任务功能模块的编写的工作；
3）日常工作梳理（标准、流程化建设），更好将原子操作串成流程。
4）系统、业务的调优，服务业务。
四、安全审计的实现
1、 安全审计技术架构
安全审计功能模块分两部分，一部分为操作事件前台展示，另部分为部署在服务器侧的采集Agent，通过CGI接口上报至数据库存储，可对上报的数据作关键字监控，发现异常可以触发告警。
2、Agent上报实现原理
实现原理非常简单，通过修改Linux系统环境配置文件/etc/profile，定义history事件相关环境变量，捕捉所有Linux登录用户会话中的操作事件及指令，实时通过OMAudit_agent.py中的HTTP
GET CGI向数据库写操作事件流水。
管理前台页面通过定时刷新，获取最新的操作事件。
五、C/S结构的实现
1、 OMServer桌面版截图
2、OMServer桌面版架构
桌面版OManager基于Wxpython + XRC构建，为两层结构，一层为桌面客户端，另一层为集群管理端，同时兼容OMServer管理端，通讯依然采用rpyc协议，与OMServer有以下几点区别：
3、后续优化
1）整合ansible或saltstack高级功能，如ansibleplaybook；
2）将多个任务模块打包成模板对列，实现原子操作与运维变更流程的结合；
3）引用任务调度Celery，支持更大并发；
4）任务对列支持暂停、中止、重运行功能，实现操作可控。
5）提供与CMDB访问对接，通用性更强。
Q&A
Q1:个人可以完成运维自动化平台吗，需要哪些技术？
当然可以，腾讯内部对运维人员都有一个要求，就是要具备开发能力。Python简单，容易入手，强烈推荐。
Q2:分享中有提到 CS 架构中安全性高，请问具体高在哪些方面，是什么原因呢？
一般CS客户端部署在管理员电脑，通过私有网络、协议与主控端效互，B/S部署在节点与业务集群同区域，不一样同网段，另外黑客对WEB层的攻击远高于桌面客户端，网络隔离在这时候显得尤为重要了。
Q3：自行研发tglog对于海量日志传输是否主要走的udp协议？如果是走的udp协议，怎么去解决一些数据包传输中数据乱序以及数据反序列化问题，或者做了哪些协议层面的优化？
是的，主要走的是UDP协议。tglog同时也是一套数据日志的规范，约束开发人员打日志的标准。
目前未碰到数据乱序以及数据反序列化问题，以前面临一个比较大的问题是丢包情况，尤其在流量高峰期时段更为明显。
后面在内核、IO优化得到缓解，但无法规避，所以我们对比较重要的日志采用TCP传输。比如玩家消费流水。
Q4：规范化、标准化遇到最大问题是什么？我们遇到就是无法行政干涉开发如何写代码？有什么好的方式去引导规范？尤其是开发有很繁重的开发任务.
这已经不是运维层面推动的事情，必须升级到运维及开发的上层领导，开发任务繁重不是理由，上线后出问题一样得不偿失，提前抛出风险，让开发人员认真做好上线前的评估。
Q5：运维管理系统安全性这块有什么好的思路？
1、网络的隔离，避免直接暴露在公网；
2、办公电脑需要有一套标准的日常安全规范，尤其是运维办公机；
3、平台编码人员需要有较好的安全意识；
4、多关注业界安全、漏洞事件。 |
