cmdb

安装部署iTOP 1、在官网下载iTOP： https://wiki.openitop.org/doku.php 2、将压缩包上传，安装数据库和http,并安装php的相关插件： unzip iTop-2.4.0-3585.zip yum install httpd php php-gd php-xml mariadb-server php-mysql php-soap php-mcrypt php-ldap -y mv web /var/www/html/ cd /var/www/html/ chown -R apache:apache web/ systemctl start httpd 3、配置数据库： yum install mariadb-server php-mysql php-mysqli -y 4、修改数据库配置文件： [root@itop-cmdb ~]# cat /etc/my.cnf [mysqld] datadir=/data/mysql socket=/data/mysql/mysql.sock max_allowed_packet=2097652 symbolic-links=0 [mysql] socket=/data/mysql/mysql.sock [mysqld_safe] log-error=/var/log/mariadb/mariadb

原文： https://www.cnblogs.com/xuecaichang/p/10265936.html 目录 传统运维与自动化运维的区别 CMDB包含的功能 CMDB实现的四种方式 1、agent方式： 2、 ssh类（parmiko, frbric,ansible) 3、saltstack方式 saltstack的安装和配置 1安装和 配置 2、授权 3、执行 命令 AES介绍： CMDB数据表的设计： 图表的设计 前端代码的实现 1、相关文件的引入 2、代码初始化 3、Js代码 CMDB https://lupython.gitee.io/2018/05/05/CMDB%E4%BB%8B%E7%BB%8D/ 尚泽凯博客地址 Top 传统运维与自动化运维的区别 传统运维： ​ 1、项目 上线： ​ a.产品经理前期调研（需求分析） ​ b.和开发进行评审 ​ c.开发进行开发 ​ d.测试进行测试 ​ e.交给运维人员进行上线 上线： ​ 直接将代给运维人员，让业务运维人员把代码放到服务器上 痛点 ： ​ 曾加运维人员的成本 改进： ​ 搞一个自动分发代码 的系统 ​ 必须的条件： ​ 1、服务器的信息（ip,hostname等 ) ​ 2、 能不能把报警自动化 ​ 3、 装机系统： ​ 传统的装机和布线： idc运维： ​ 用大量的人力和物力，来进行装机 自动化运维：

一、传统的运维痛点 1.1 日常工作繁琐 　　日常运维工作是比较繁琐的，研发同学会经常需要到服务器上查日志，重启应用，或者是说今天上线某个产品，需要部署下环境。这些琐事是传统运维的大部分工作 1.2 应用运行环境不统一 　　在部署某应用后，应用不能访问，就会听到开发人员说，在我的环境运行很好的，怎么部署到测试环境后，就不能用了，因为各类环境的类库不统一 还有一种极端情况，运维人员习惯不同，可能凭自己的习惯来安装部署软件，每种服务器上运行软件的目录不统一 1.3 运维及部署效率低下 　　想想运维人员需要登陆到服务器上执行命令，部署程序，不仅效率很低，并且非常容易出现人为的错误，一旦手工出错，追溯问题将会非常不容易 1.4 无用报警信息过多 　　经常会收到很多报警信息，多数是无用的报警信息，造成运维人员经常屏蔽报警信 　　另外如果应用的访问速度出了问题，总是需要从系统、网络、应用、数据库等一步步的查找原因 1.5 资产管理和应用管理混乱 　　资产管理，服务管理经常记录在excel、文本文件或者wiki中，不便于管理，老员工因为比较熟，不注重这些文档的维护，只有靠每次有新员工入职时，资产才能够更正一次 二、自动化运维平台特性 运维自动化最重要的就是标准化一切 OS的选择统一化，同一个项目使用同样的OS系统部署其所需要的各类软件 软件安装标准化，例如JAVA虚拟机，php，nginx

万合ITGo是一款虚拟化运维管理工具，为虚拟化管理员提供虚拟化环境的监控、操作和管理功能。而CMDB是企业的配置管理数据库，讲的是配置项和配置项之间的关系，和传统运维工具不太搭界，可是今天偏偏要说说ITGo和CMDB这两者之间的关系： ITGo可以为CMDB提供虚拟化（例如VMware）环境完整的配置项 ITGo可以为CMDB提供虚拟化环境的配置项之间的关系 企业数据中心，虚拟机的数量可以几百台到几千台，这样对于CMDB项目建设来说，虚拟化CI项的采集是面临的第一个问题，CI之间的关系梳理是第二个问题，CMDB项目建设完成，如何保证虚拟化环境CI和CIR的实时准确性是第三个问题。 有了ITGo，这些都不是问题，这些数据都是实时更新的。ITGo有API接口，可以将梳理出来的配置项和配置关系提供给CMDB使用，降低CMDB建设和维护的难度。 来源： https://blog.51cto.com/031028/2432923

CMDB成功和失败，关于掌握的CMDB套路的多与少、深与浅！ 前几天在对一个项目进行总结，编写CMDB的配置管理规范，发现还是有很多套路，本文就是老王总结的CMDB套路！ 套路1：CMDB名字应该改一下了，叫IT资源管理 什么叫配置?的确现在很多配置管理的工具，这些东西也是沿袭下来，但我更喜欢puppet里面提到的资源概念。资源几乎可以和对象的概念对等，对象有属性，资源也有属性；对象有方法，资源也有动作，额外增加一点，资源还有状态。记住一些，可以把一切对象当成资源来看。 我为什么坚持要改名？从现实的情况来说，大家一说CMDB都是那些传统的讨论，自动发现、配置项、配置属性。另外动不动就是一些一些表单的设计和管理，而忽略一个真正的CMDB是什么？ 真正的CMDB就是要把内部所有的IT资源管理起来！ 套路2：CMDB模型有层次 在下图的模型中，CMDB的模型是有层次的，我把他定义成核心模型和扩展模型。 核心模型。核心模型是记录了业务、应用和主机Host的关系，其他的关系都可以不记录。有了这个模型基本上可以运转后续的自动化和监控系统了；其次还可以有效的管理公有云上的主机信息。 核心模型绝不是基础设施级的资源模型！ 扩展模型。扩展模型就是依赖核心模型扩展出来的，比如说基于应用需要找到关联的一些资源信息；基于主机找到它关联的一些依赖设备信息，比如说机柜、存储和交换机等等，不断的扩展对象模型。

salstack的安装和配置 　　1安装和配置 master端： """ 1. 安装salt-master yum install salt-master 2. 修改配置文件：/etc/salt/master interface: 0.0.0.0 # 表示Master的IP 3. 启动 service salt-master start4. 检查 master 运行状态 service salt-master status """ slave端： """ 1. 安装salt-minion yum install salt-minion 2. 修改配置文件 /etc/salt/minion master: 10.211.55.4 # master的地址 或 master: - 10.211.55.4 - 10.211.55.5 random_master: True id: c2.salt.com # 客户端在salt-master中显示的唯一ID 3. 启动 service salt-minion start """ 　　2 授权 """ salt-key -L # 查看已授权和未授权的slavesalt-key -A　　　　　　　　　 # 未授权的slave 全部授权 salt-key -a salve_id # 接受指定id的salve salt-key -r salve_id

一、为什么要做CMDB a.项目开发和上线场景： 流程： 产品经理调研需求 =====> 定一个时间开发 ======> 测试() ====> 产品项目上线（运维） 传统做法： 运维解压文件， 部署到相对应的服务器目录下面 存在问题： 效率不高 不能实现覆盖有Bug的代码 解决方法： 代码上线系统 必要条件： 服务器的IP地址， 硬盘空间， CPU的使用率， 内存等 b.监控服务器： 传统做法： shell脚本来去做 问题： 不能实时 不能自动化 现在做法： 后台用Python去做， 收集一下服务的元信息（IP地址， 硬盘大小， 内存） 前台配合kibana c. 装机服务： 服务器装操作系统 （centos） 现在做法： 自动装机服务 也得知道一下， 服务的元信息 IP地址 d. 年底统计： 之前做法： 使用excel统计 存在问题： 不能实时， 需要对变更进行记录 现在做法： 统计资产的系统 还得需要收集服务器的各种信息， 需要实时的汇报变更记录 二、CMDB：资产管理系统 1、本质：收集服务器的各种信息 2、开发CMDB的思路和大概做法： 　　使用Python代码执行linux的命令， 并且获取服务器上的对应信息 　　使用Http协议发送执行好的数据 3、CMDB的四套方案 ①agent模式 优点：速度快 缺点：每次都需要部署 适用的场景：服务器数量特别多的情况 架构：

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

　　Agent方式实现 　　　　agent方式，可以将服务器上面的Agent程序作为定时任务，定时将资产信息提交到指定API录入到数据库中 　　　　 本质就是在各个服务器上执行 可以使用python3模块subprocess.getoutput('shell命令')，在本地机器上执行，获取执行结果返回给主机api，然后主机api收到这些数据之后，放入到数据库中，最终通过web界面展示给用户 　　SSH实现方式（基于Paramiko模块） 　　　　中控机通过Paramiko(py模块)登录到各个服务器上，然后执行命令的方式去获取各个服务器上的信息 　　　　 　　Saltstack方式 　　　　此方案本质上和ssh实现方式大致一样，中控机在发送命令给服务器执行，服务器将结果放入另一个队列中，中控机获取将服务器信息发送到api，api将数据整理后录入数据库 　　　　 Agent实现方式 　　优点：速度快 　　缺点：需要为每台服务器部署一个Agent程序 ssh实现方式 　　优点：不需要在需要在服务器上安装Agent 　　缺点：速度慢 saltstack方式： 　　优点：快、开发成本低 　　缺点：依赖第三方工具 　　　　 来源： https://www.cnblogs.com/yangzhaon/p/11396236.html

新增资产 现在api服务端已经能获取到我们要做的操作了。接下来应该是补充获取操作后对应的程序编写 我们要做的是把post请求发过来的数据保存到数据库。我们创建repository 名字的app，并设计models创建表来存储数据。后面可以从数据库获取信息并展示出来 from django.db import models class BusinessUnit(models.Model): """ 业务线 """ name = models.CharField('业务线', max_length=64, unique=True) class Meta: verbose_name_plural = "业务线表" def __str__(self): return self.name class IDC(models.Model): """ 机房信息 """ name = models.CharField('机房', max_length=32) floor = models.IntegerField('楼层', default=1) class Meta: verbose_name_plural = "机房表" def __str__(self): return self.name class Server(models.Model): """ 服务器信息 主机 """ device