本文根据DBAplus社群第133期线上分享整理而成。俗话说利用开源可以避免重复造轮子，自研是当开源已经满足不了实际的业务需求的时候就要自行编程开发。两者的共同目标就是实现自动化目的。

 

讲师介绍  
随着业务规模的逐渐增大，IT运维的环境变得庞大而复杂。传统的运维手段已无法满足我们的要求，而自动化运维能把周期性、重复性、规律性的工作交给平台去处理，通过标准化、自动化、过程优化来降低运维成本，从而提高运维效率。

​

当前市场上有不少商业和开源的运维产品工具，各有特色也各有利弊，这造成一个尴尬局面：产品工具很多，却很难找出一个可以很好适应自身企业持续变化的需求的产品。毕竟不同的企业其管理规模、实施环境和安全规定都不尽相同。

 

本文主要围绕我们在建设自动化运维平台的过程中所遇到的困难挑战和踩过的坑，并就开源和自主研发的方向选择聊聊我们在尝试过程中的看法和做法。

 

我们的平台建设主要分为以下三个阶段：

基于Ansible的尝试验证

 

当时内部其它部门有使用Ansible来做一些场景的运维操作的经验，并在此累积了一定量的运维脚本库，有复用的价值。同时Ansible也是一款非常优秀的工具，具备以下优点：

 

• SSH by default ：安全，agentless无需安装客户端

• 配置简单、功能强大、扩展性强

• 通过Playbooks来定制强大的配置、状态管理

• Stupied Simple：上手简单，学习曲线平滑

 

基于以上考虑，我们初步选定了Ansible作一个尝试。这里用图例描述下Ansible的工作机制：

 

 

但在验证阶段，发现Ansible在场景应用压测上暴露了下面的缺点：

 

• 效率不高，容易挂起，不太适合中大规模环境（例如500台以上）的应用

• 难以进行大批量的耗时业务操作。

 

我们通过求助并不断尝试去优化性能，期望能支撑起中大规模的托管设备量。但针对一些复杂的场景应用，特别是耗时的操作，效率还是无法接受。

 

Ansible暂不能很好地满足中大型规模的运维管理场景。当然，在百台以内的环境，使用Ansible做一些小规模的简单运维场景，还是有它的优势：非常简洁，基于SSH，容易落地。

 

小插曲过后，经过一段时间的重新选型和验证，我们敲定了使用SaltStack来作为我们的技术选型。

基于SaltStack全而稳的快速建设阶段

 

相比Ansible的小巧，SaltStack更加大而全，同时在应用上也更加灵活，可以轻松应对更加多复杂的场景。

 

SaltStack的master和minion通过ZeroMQ传输数据，而Ansible是默认通过标准ssh进行数据传输。得益于架构上的差异，SaltStack的响应速度要比Ansible快很多，同时ZeroMQ也起到了很好缓冲的作用。

 

SaltStack的异步执行模式可以很好地应对上千台设备（甚至更多）的任务执行，特别适合耗时场景的应用。下面是SaltStack的简单通信架构图：

 

 

在此后时间，我们主要投入开发扩展模块以实现一些常用的运维场景，同时也改造了SaltStack的入库逻辑，把相关的event等数据转换为我们需要的数据写入存储中。

 

平台开发过程中一切顺利，很快进入了上线阶段，这里描述下上线背景：

 

• 托管设备规模庞大，超5000台以上

• 所有托管设备不能通过ssh进行通信，22端口对外是被禁用的，且用户的密码是定期变更。

• 仅且只能基于某指定端口进行通信

 

基于以上特殊要求，我们的接入方案是：所有托管机器都统一安装minion，基于端口通信；通过我们研发的WEB统一管理平台来批量部署和升级等管理。

 

上线初期，我们根据业务划分的顺序进行纳入管理，很快接入了大量的主机，一切看起来进行得比较顺利。但在接入一个老业务平台的时候，我们遇到了困难：处理平台的兼容性比我们预想的复杂得太多。

 

（1）设备繁杂

 

形色各异的服务器，有IBM小机、SUN服务器、HP服务器、浪潮服务器等。还存在大量的网络设备（路由器、交换机等）需要托管。

 

（2）系统平台标准杂乱

 

操作系统版本混乱，存在了大批量的AIX5、AIX6、SunOS、HP-Unix、RedHat5、PowerLinux、Window(Server 2000、2003、2008等)等系统平台。

 

（3）权限认证

 

很多设备不提供Root管理员权限，agent更是不允许以Root运行。

 

（4）禁止外网访问的局域网

 

导致的结果是我们的minion无法安装，在官网中，我们找到了SaltStack支持的所有平台的列表：

 

 

期间，我们尝试与运维团队负责人沟通，是否可以升级操作系统的版本，调整部分安全的规定，负责人表示很理解但也很无奈，安全规定无法改变。

 

此时,我们更深刻认识复杂的IT环境、历史负担是必须首要面对的问题，很多在互联网中玩得转的方案，在这个环境里面变得步步艰辛，难以推进。

 

同时权限管控也是一个大问题，部分实施环境对托管主机agent运行的权限更加严格，资源访问上也更加严格，有大量切换用户增强权限的方式来进行运维操作。

 

一路走来，深感不易，作为技术通用型的代表，基于开源运维管理技术（Ansible、SaltStack等）的产品工具多多少少都存在着某方面的局限性，无法涵盖不同行业的企业需求，不能很好适应不同行业的特殊实施环境。

 

基于上述经验的累积，我们的意见愈发统一：要很好地解决这些问题，或者说要把主动权握在自己手中，必须得走上开源+自主研发整合的道路。

 

基于开源并整合自主研发应需而变的平台建设阶段

 

一路磕碰，一路踩坑的同时也为我们在建设自动化运维平台提供了最真实的反馈，让我们得以不断调准方向。

 

 平台建设方向 

 

目前我们正处于开源整合自主研发阶段，已无需再去论证这样做是否正确、是否有必要，实践已出真知。吸收经验后，平台的建设方向明确了以下几点：

 

（1）开源整合自主研发

 

拥抱开源，针对不可控和无法满足的部分，我们进行了自主研发，最后整合开源以满足实施环境的需求。

 

（2）平台部署能应需而变

 

针对托管设备既能以agentless也可以以agent的模式，要能很好地应对复杂的网络拓扑要求。支持分布式集群部署，能快速地扩容以支撑海量的托管设备。

 

（3）agent必须支持以下系统平台，并能以非Root用户运行

 

linux/unix/ aix (aix5/6/7)/windows/ppc等。

 

我们自主研发的agent，增加了对AIX5、AIX6、SunOS、HP-Unix、Power Linux、Windows Server(2000及以上)等系统的支持，弥补SaltStack在系统支持上的不足。

 

在操作执行过程中，可以支持用户切换增强权限，避免直接以Root运行agent，权限过大。

 

（4）提供完备的凭证管理

 

例如针对上面提及的服务器用户密码定期更换这个情况，需要细化到支持每台托管设备的凭证更新管理，方便用户使用。

 

（5）提供统一管理web平台，批量安装和升级等管理。

 

（6）提供统一易用的运维API给上层业务，上层业务无需关注底层实现。

 

 平台简述 

 

整合后的自动化运维平台分为三层：业务层、运维管理层、托管层，如下图：

 

 

• 业务层：指各个运维业务的合集。运维业务调用运维API，通过运维管理层进行运维操作

• 运维管理层：运维管理层并不涉及任何的业务逻辑，只提供通道和任务分派、结果回传处理。

• 托管层：被托管的服务器、网络设备、中间件、数据库等。

 

平台提供了以下常用的运维场景：

 

• 应用安装：Tomcat、Weblogic等中间件的安装；MySQL、Oracle等数据库的安装。

• 配置管理：日常运维涉及的一些配置文件管理，例如基线对比、批量更新等。

• 运行监控：监控相关进程的运行状态，例如Zabbix的运行状态检测等。

• 定时调度：支持定时调度，任何操作/作业编排都可定时执行。

• 日常运维：登录服务器、单机、批量等日常运维巡检操作，支持流程编排。

• …

 

平台的基本操作流向：

 

 

平台的运维基本单位是“操作”，通过定时调度+资源+操作可以组合成不同的巡检或者流程编排。巡检和编排最后通过解析转化为具体的作业任务。作业任务由agent或者代理agent解析后执行。

 

“操作”支持版本管理和流程审核，此外平台还提供了更加细致的权限控制和分级管理。根据业务需要可以指定操作执行用户，提供权限增强。

 

为了弥补minion在兼容性上的不足，我们研发了自己的agent端。

 

 自研agent的设计理念 

 

为应对复杂多变的运维业务，在agent设计上我们一致认同：原子化的插件式功能模块是基本，稳定高效的通道是保障。

 

1. 只有拥有大量原子化的插件式功能组件，才能大规模重用和组装。每一个上层的运维业务都可以分解成原子化的操作集合。

2. 业务运维的操作组合是无限的，原子化的组件是有限的，原子化后更加方便管理维护，从而提供稳定可靠的服务。

3. 稳定高效的通道是整个平台可靠运行的最重要的保障。要求能接入上万台规模的设备。

 

agent的核心功能可以总结为两大块：管控通道和插件服务调用。

 

• 管控通道：所有的运维操作最终都会转化为命令发送给snc-agent。这里会有相应的用户权限控制、操作审计、高危命令拦截、流量管控等能力。

• 原子化服务调用：每一个命令组合都会被snc-agent 的解析引擎转化为最基本的原子操作集合并调用执行。

 

 

下图是平台在生产环境中执行的统计数据，从四个维度展示了整个系统的操作数据量：巡检、编排、操作和原子任务。

 

 

 

 平台架构 

 

 

除了兼容Ansible和SaltStack环境外，增加了snc-agent集群环境，用于弥补SaltStack在非主流系统支持上的不足。

 

下面针对snc-agent描述两个工作主流程：

 

1. snc-agent会有一个默认的配置文件，启动后会自动连接到ZooKeeper，在ZooKeeper上维护一个节点，节点中记录了agent的配置信息，包括服务器的ip、硬件等相关信息。基于该节点可以实时地监控agent的状态和主机对应的一些不常变化的信息。

2. 下发命令并执行。业务系统调用运维公用API，把命令发送至消息队列。snc-agent从消息队列中拉取属于自己的命令，通过解析引擎分解为最基本的原子操作集合，所有操作执行完毕后，把结果合并后回送到消息队列。snc-agent具备流量管控能力，因为不同的设备其运算能力有所不同，需要针对其性能适当地消费，避免影响生产业务的正常运行。

 

 部署架构 

 

• SaltStack环境：兼容接入原有的基于SaltStack构建的环境。

• Ansible环境：兼容接入原有的基于Ansible构建的环境。

• snc-agent环境：可用于接入SaltStack无法兼容的设备。除此以外，agentless和云环境上的托管接入均可由snc-agent进行统一管理。

 

两者搭配部署，可覆盖不同的实施环境要求。平台提供了统一管理Web界面，以方便批量安装和升级，针对不同的系统能做到一键部署、一键安装、一键启停和重启。大大提高了管理效率。

 

 

 

 总结 

 

人无完人，技术亦如此，不同的开源技术各有优缺点，要成为一个好平台，必须要能做到应需而变。开源和自主研发不应该是对立的矛盾体，不应该是非黑即白。针对部分不可控的范围采取自主研发的模式，整合一切可以团结的力量，能让我们做得更全、做得更好、走得更远。我的分享到此结束，谢谢！

 

Q&A  

 

Q1：agent采用什么需要开发的？C或Python？

A1：agent框架部分基于Java实现的，agent插件部分可以是C、Python、Go以及其它语言。

 

Q2：agent能集成到OS镜像中吗？

A2：可以的，在制作OS镜像的时候，可提前打包进去。

 

Q3：想问下你们的平台是私有部署，还是SaaS部署？

A3：目前是本地部署的，但设计上也支持SaaS模式部署。

 

Q4：运维操作支持操作系统安装吗？

A4：可以的，可通过调用Cobbler命令进行安装。

 

Q5：运维具备哪些基本的知识？

A5：平台化后，降低了运维人员的运维技术门槛，普通的运维都可以直接使用平台。

 

Q6：如何实现服务器密钥更新后通知agent？如何让agent 在非root运行，又在需要的时候用root运行？

A6：在自研agent环境中，是基于端口方式加解密通信的，不受系统密钥变更影响。如果agent在非root下运行，但又需要以root运行，可传输root加密凭证到agent端切换用户后执行。

 

Q7：这个平台在上线初期，如何实现agent批量安装？

A7：通过平台的批量部署功能(基于SSH、Power Shell、Yum、FTP等方式)进行批量自动化安装。

 

直播链接  

https://m.qlchat.com/topic/details?topicId=2000000574308299