cmdb

前言 本文仅是对以前写的小示例进行一次梳理，由于本人菜鸟一枚，后端代码写的很渣，前端页面也不好看，还请大家多多海涵。 一、程序简介 程序分为cmdb_server，cmdb_client两部分，以运维为核心开发的简易框架，cmdb_client主要负责资产信息采集，采集到数据后将数据进行清洗，汇总.使用POST的方式将数据发给cmdb_server，cmdb_server将接收到的数据写入数据库。通过前端展现给用户。 cmdb_server实现的主要功能如下（目前部分功能仅支持centos 7）： 1、用户登录认证。’ 2、将采集到的资产信息以前端页面展示给用户，并可以将资产信息以Excel的形式导出。 3、机房信息维护。 4、业务线信息维护。 5、记录主机资产信息的变更记录。 6、执行用户任务（批量执行命令，执行脚本，文件下发。提取客户端文件到本地） 7、实时监控主机硬件资源。 8、webssh。 9、docker服务器管理。 cmdb_client主要实现了通过agent或者SSH的方式对windows7以上版本，centos7版本的资产信息采集。 程序目前主要针对centos 7进行的开发 二、程序目录简介 [root@localhost CMDB]# tree -L 1 cmdb_server/ cmdb_server/ ├── asset_API # 负责接送cmdb

什么是 CMDB? “CMDB 即配置管理数据库，通过获取、维护，检查企业的IT资源，从而高效控制与管理不断变化的 IT 基础架构与 IT 服务，并为其它系统，例如任务调度、运维工单、发布管理等系统提供准确的配置信息。” 早期 CMDB 是以数据存储为驱动来进行建设的，现在比较主流的 CMDB 的建设方式，是以应用和业务驱动的，需要什么数据，就创造什么数据，通过灵活数据建模，来实现以需求为导向的 CMDB 建设。 通过完善的 Web API 来进行各个流程或应用之间的数据通信，例如：数据上报，验证，获取，更新等等。 CMDB 建设中需要做到的几点要求： 01、灵活性 灵活配置数据字段，现在的系统或者平台多样化，例如：云平台、Docker、物理机、虚拟机等等，这些在数据存储上字段都是有区别的，因此需要灵活配置字段可以兼容这些系统或平台。 02、安全性 对于 CMDB来说，数据的安全是非常重要的，不能随意的去更改，因此一定要注意安全保障，如：设定严格的权限访问控制。 03、准确性 CMDB是数据存储的集合，是建设其他系统的数据基石，因此就需要保证CMDB的数据的准确性，否则会引起一些不必要的问题。 04、实时性 其实这个事项，在有些人里面觉得不太重要，甚至认为以天级来收集、更新数据即可，但是我认为，虽然 CMDB 对数据的实时性要求不高，但是还是需要达到最优的实时性。 CMDB

什么是 CMDB? “CMDB 即配置管理数据库，通过获取、维护，检查企业的IT资源，从而高效控制与管理不断变化的 IT 基础架构与 IT 服务，并为其它系统，例如任务调度、运维工单、发布管理等系统提供准确的配置信息。” 早期 CMDB 是以数据存储为驱动来进行建设的，现在比较主流的 CMDB 的建设方式，是以应用和业务驱动的，需要什么数据，就创造什么数据，通过灵活数据建模，来实现以需求为导向的 CMDB 建设。 通过完善的 Web API 来进行各个流程或应用之间的数据通信，例如：数据上报，验证，获取，更新等等。 CMDB 建设中需要做到的几点要求： 01、灵活性 灵活配置数据字段，现在的系统或者平台多样化，例如：云平台、Docker、物理机、虚拟机等等，这些在数据存储上字段都是有区别的，因此需要灵活配置字段可以兼容这些系统或平台。 02、安全性 对于 CMDB来说，数据的安全是非常重要的，不能随意的去更改，因此一定要注意安全保障，如：设定严格的权限访问控制。 03、准确性 CMDB是数据存储的集合，是建设其他系统的数据基石，因此就需要保证CMDB的数据的准确性，否则会引起一些不必要的问题。 04、实时性 其实这个事项，在有些人里面觉得不太重要，甚至认为以天级来收集、更新数据即可，但是我认为，虽然 CMDB 对数据的实时性要求不高，但是还是需要达到最优的实时性。 CMDB

今天要和大家阐述一个新的思路——建立面向应用的运维管理新思维，带着这个思路去寻找运维新的解决方案，因此把面向应用管理抽象总结如下： 在ITIL时代，大家都知道一个概念，CMDB是IT服务系统的元数据中心，而现在应用更应该是CMDB的元数据。把运维的能力建立在面向应用的维度上，把面向应用的IT能力分成三部分： CMDB即IT资源管理系统 支撑一个应用运行到底占用了哪些资源?应用占用的服务器是一种资源、占用的内存是一种资源、占用的存储是一种资源、占用的负载均衡是一种资源。但大家一定要注意，这个资源不是更多是一种后端服务出现，比如说IaaS服务或者是PaaS服务。 动作 应用的变更有很多种场景，按照角色来归类，比如说应用交付、应用升级等场景，这些场景是面向Dev/Test/Ops的。还有一种应用在日常维护过程中的变更，面向纯Ops场景的，比如说应用的迁移、应用的扩容。动作是作用于资源的，比如说应用升级是版本发生变化，应用扩容是让应用的资源新增等等。过去的传统式运维，总是聚焦碎片式的运维自动化能力理解上。 状态 为了实现对应用的健康状况或者质量的度量，我们需要采集各类状态数据，从而支撑各类场景的应用，比如说监控故障发现的需求，故障恢复的需要，应用服务优化的需要等等。 CMDB建设的不成功，部分是系统的原因，但更多是方法论的问题。我们总以为找到了很强的驱动力来建设资源维护的流程和场景

运维自动化内容的层级划分 服务管理 高层 运维总体支撑 流程规范 人力与成本 技术决策 中层 规划技术架构和方案 运营环境管理 技术执行 最底层 // <== 自动化的首要目标 线上业务部署 线上业务日期维护 构建思路 分析运维场景和痛点 深入运维一线，识别业务场景和痛点 对同类痛点抽象，形成模型 规划 起步阶段着眼全局，分层设计和开发 对运维事务流程提前规划对外接口，保证数据一致性 通用性 横向：方案适应多部门多平台 纵向：支持业务流程编排，单步动作解耦 与流程联动 联动职能部门、人员角色、操作执行各环节 框架分层 服务层：业务流程引擎 功能层：各应用组件接口 基础层：进程管控工具、cmdb、任务调度平台 运营环境：os、各类中间件 实施要求 os层面 采集和输入的信息精准 统一管控入口 能远程批量管控主机 应用层面 应用接口 + 流程引擎 = 自动化 实施路线 前提条件：数据标准化 cmdb 实施目标：信息数据统一维护，统一查询入口 功能块 基础架构信息 idc节点管理 网络管理 服务器管理 ip资源管理 业务信息 业务管理 公共接口管理 权限管理 审计 操作日志 使用者 web用户 api调用 关键点 ci及其属性需要结合实际，同时兼顾长远规划 维护ci的属性值，ci间的关系和状态转换机 可扩展性，允许添加新属性 任务调度平台 实施目标：批量执行运营环境的变更部署 功能点

要点: import importlib import traceback from lib.config.settings import settings ##插件管理类 class PluginsManager(): def __init__(self, hostname=None): self.pluginSettings = settings.PLUGINS_DICT self.mode = settings.MODE self.hostname = hostname self.debug = settings.DEBUG if self.mode == 'ssh': self.ssh_port = settings.SSH_PORT self.ssh_username = settings.SSH_USERNAME self.ssh_pwd = settings.SSH_PWD self.ssh_hostname = settings.SSH_HOSTNAME def execute(self): # 1. 获取配置 # 2. 循环执行 response = {} #获取PLUGINS_DICT这个字典的 key与 values的值 for k,v in self.pluginSettings.items(): ret = {'code': 1000, 'data':

IT运维,指的是对已经搭建好的网络,软件,硬件进行维护.运维领域也是有细分的,有硬件运维和软件运维 硬件运维主要包括对基础设施的运维，比如机房的设备，主机的硬盘，内存这些物理设备的维护 软件运维主要包括系统运维和应用运维，系统运维主要包括对OS，数据库，中间件的监控和维护，这些系统介于设备和应用之间，应用运维主要是对线上业务系统的运维 我们现在讨论的主要是软件运维的自动化,包括系统运维和应用运维的自动化 自动化运维平台的特性 运维自动化最重要的就是标准化一切 1 os的选择统一化,同一个项目使用同样的OS系统部署器所需要的各类软件 2 软件安装标准化,例如JAVA虚拟机,php,nginx,mysql等各类应用需要的软件版本,安装目录,数据存放目录,日志存放目录等 3 应用包目录同意标准化,即应用命名标准化 4 启动脚本统一目录和名字,需要变化的部分通过参数传递 5 配置文件标准化,需要变化的部分通过参数传递 6 日志输出,日志目录,日志名字标准化 7 应用生成的数据实现统一的目录存放 8 主机/虚拟机命名标准化.虚拟机管理使用标准化模板 9 使用docker比较容易实现软件运行环境的标准化 资产管理系统(CMDB) CMDB是所有运维工具的数据基础 CMDB包含的功能 1 用户管理，记录测试，开发，运维人员的用户表 2 业务线管理，需要记录业务的详情 3 项目管理

CMDB和运维自动化 一、运维 运维，指的是对已经搭建好的网络，软件，硬件进行维护。运维领域也是细分的，有硬件运维和软件运维 硬件运维 主要包括对基础设施的运维，比如机房的设备，主机的硬盘，内存这些物理设备的维护 软件运维 主要包括系统运维和应用运维，系统运维主要包括对OS，数据库，中间件的监控和维护，这些系统介于设备和应用之间，应用运维主要是对线上业务系统的运维 讨论的主要是软件运维的自动化，包括系统运维和应用运维的自动化 二、软件运维 传统运维 日常工作繁琐 日常运维工作是比较繁琐的，研发同学会经常需要到服务器上查日志，重启应用，或者是说今天上线某个产品，需要部署下环境。这些琐事是传统运维的大部分工作 应用运行环境不统一 在部署某应用后，应用不能访问，就会听到开发人员说，在我的环境运行很好的，怎么部署到测试环境后，就不能用了，因为各类环境的类库不统一 还有一种极端情况，运维人员习惯不同，可能凭自己的习惯来安装部署软件，每种服务器上运行软件的目录不统一 运维及部署效率低下 想想运维人员需要登陆到服务器上执行命令，部署程序，不仅效率很低，并且非常容易出现人为的错误，一旦手工出错，追溯问题将会非常不容易 无用报警信息过多 经常会收到很多报警信息，多数是无用的报警信息，造成运维人员经常屏蔽报警信 另外如果应用的访问速度出了问题，总是需要从系统、网络、应用、数据库等一步步的查找原因

CMDB概述 自动化运维特性 OS的选择统一化，同一个项目使用同样的OS系统部署其所需要的各类软件 软件安装标准化，例如JAVA虚拟机，php，nginx，mysql等各类应用需要的软件版本，安装目录，数据存放目录，日志存放目录等 应用包目录统一标准化，及应用命名标准化 启动脚本统一目录和名字，需要变化的部分通过参数传递 配置文件标准化，需要变化的部分通过参数传递 日志输出，日志目录，日志名字标准化 应用生成的数据要实现统一的目录存放 主机/虚拟机命名标准化，虚拟机管理使用标准化模板 使用docker比较容易实现软件运行环境的标准化 CMDB架构 CMDB设计模式 Agent方式 可以将服务器上面的Agent程序作定时任务（ crontab ），定时将资产信息提交到指定API录入数据库 本质上就是在各个服务器上执行 subprocess.getoutput() 命令，然后将每台机器上执行的结果，返回给主机API，然后主机API收到这些数据之后，放入到数据库中，最终通过web界面展现给用户。 优点：速度快 场景：适合机器多的情况 缺点：每个机器都要部署脚本 SSH方式（paramiko模块） 中控机通过paramiko模块登录到各个服务器上，执行命令获取服务器信息。 import paramiko # 创建SSH对象 ssh = paramiko.SSHClient() #

CMDB项目： cmdb包含的功能： 1、用户管理，记录测试，开发，运维人员的用户表 2、业务线管理，需要记录业务的详情 3、项目管理，指定此项目用属于哪条业务线，以及项目详情 4、应用管理，指定此应用的开发人员，属于哪个项目，和代码地址，部署目录，部署集群，依赖的应用，软件等信息 5、主机管理，包括云主机，物理机，主机属于哪个集群，运行着哪些软件，主机管理员，连接哪些网络设备，云主机的资源池，存储等相关信息 6、主机变更管理，主机的一些信息变更，例如管理员，所属集群等信息更改，连接的网络变更等 7、网络设备管理，主要记录网络设备的详细信息，及网络设备连接的上级设备 8、IP管理，IP属于哪个主机，哪个网段, 是否被占用等 1、自动化运维：分类：基础运维和应用运维 2、为什么需要 自动化运维 1. 项目上线: 流程: 产品经理调研(画出原型图) ---> 定需求 ---> 三方会谈(产品经理, 研发,老大们) ---> 定日期--->测试项目---> 最终上线---> 应用运维 目前: 是把代码打包给运维, 运维解压上线 问题: 随着机器数量的线性增加,运维的工作量也是线性增加, 重复而且是无意义的劳动 解决: 1. 写一个shell脚本, 进行部署 2. 搞一个自动化代码上线系统 必要条件: 服务器的各种信息 (主机名, cpu, 硬盘大小等) ​ 2. 监控系统: