cmdb

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

(深度好文)重构CMDB，避免运维之耻 CMDB，几乎是每个运维人都绕不过去的字眼，但又是很多运维人的痛，因为CMDB很少有成功的，因此我也把它称之为运维人的耻辱。 那么到底错在哪儿了？该如何去重构它？ 今天我想从我的角度来和大家探讨一下业务失败的原因，基于失败再去看重构的逻辑，也许会成功。 从失败中寻找成功的逻辑，往往是最有效的，那我们就来逐一看看： 1、组织的设计问题 我必须把核心原因归结成这一条，很多公司把CMDB的建设责任放到基础设施建设部门，由他们主导承建。最后他们梳理出来的核心逻辑是面向基础设施资源的管理，你在他们的CMDB中都能看到如下菜单，AIX主机是哪些，中间件有哪些，大小机有哪些，Oracle有哪些等等，这些都是和公司的IT运维部门组织结构是一一对应的。组织的隔离是CMDB失败的核心原因！ 这个里面能看到一些CMDB管理能力错位，拿两个例子来说一下： A、中间件。 一直搞不明白为什么中间件要作为一个单独的对象来管理，“皮之不存，毛将附焉”。没有主机，没有业务这个皮，哪来的中间件。把他单独拿出来管理，纯粹就是为了满足组织的一个管理视角。从来没人想过，这是主机上的一个资源对象，应该是一个附属资源，其实对他的信息管理和机器上的CPU、网卡一样。 B、进程对象，比如说数据库 这个是另外一种管理错位，是专业的管理平台应该去履行的管理职责，结果放到CMDB平台中了

CMDB之数据库表设计 1.开发CMDB的背景 很多公司还在用Excel维护资产信息，当服务器数量变多时，难以保证excel表格的正确性，而且不同部门之间交换信息不方便。实现自动采集资产，自动汇报，并自动保存变更记录。 2.CMDB架构 - 资产采集（资产采集） - API（接受数据保存入库，对外提供数据接口） - 后台管理 3.资产采集方式 三种方案 - agent - paramiko - saltstack 4.服务器的唯一标识 a.不需要采集虚拟机 - 采用主板的SN号作为唯一标识。 b.需要采集虚拟机 - 对服务器进行标准化，唯一标识选用hostname 5.CMDB流程 - 装机同时，主机名在CMDB中设置 - 第一次采集，将主机名写入文件，发送到API - 第N次采集，主机名从直接从文件名中获取。 6.表结构图示 7.django-models结构 from django.db import models class UserProfile(models.Model): """ 用户信息 """ name = models.CharField(u'姓名', max_length=32) email = models.EmailField(u'邮箱') phone = models.CharField(u'座机', max_length=32) mobile =

CMDB的全称解释为:配置管理系统 企业中实现CMDB的四种实现方式: 1. 使用agent脚本 缺点: 每台服务器都要放置agent 优点: 速度快 使用场景: 服务器比较多的时候 2. 使用ssh类完成(在python中使用paramiko模块来实现) 缺点: 有一个中控机, 速度慢 使用场景: 服务器比较少的时候 3. 使用salt-stack完成 使用场景: 公司已经使用salt-stack软件 安装salt-master: yum install salt-master 配置配置文件: interface : 本机IP service salt-master start 安装 salt-minion: yum install salt-minion 配置文件配置: master: 10.0.0.51 salt-key -L: 列出所有的minion主机 salt "主机名" cmd.run "命令" : 4. 使用puppet实现 (不怎么使用) 代码实现: 这里使用到类中的反射用法,拿到想要的数据 from conf import config from . import global_settings class Settings(): def __init__(self): ##整合全局配置文件 for k in dir(global_settings):

背景： 　　在现网环境中服务器多了每天服务器的配置 情况我们很难记住，当某台服务器硬件配置变化后可以第一时间了解，某台服务器出现问题时可以快速定位机架位置，之前都是excel文档，要查某项数据时极不方便。历时半个多月终于鼓捣出了一个简易的CMDB资产管理系统，很多功能都还没有写，例如邮件报警等功能，以后用到了再写吧----------------------------------- 架构： 　　采用C/S架构，客户端收集资产数据后上传给服务器，服务器收到数据后入库，客户端有两种工作模式：SSH模式和AGENT模式，linux环境中两种模式都可以用，windows环境中只能用agent模式。 语言： 　　后端采用Python Django 前端框架使用nifty-v2.9.1 说明： 软件在我所在的环境中使用没有任何问题，但是没有在其他环境测试过，因为我所在的环境是云计算，所有机器都是品牌机，且配置都是相同的。 使用时最好不使用SQLITE 而直接使用MYsql，因为如果是ssh模式下，客户端是采用多线程汇报数据，这时可能会出现database is locked 错误，mysql环境下不会出现。 如果正好你也想开发CMDB而不想从头开发的话可以拿去鼓捣鼓捣 。。。。。。。。。。。。。Qq:792903546 软件界面： 来源： https://www.cnblogs.com

目录 ： 1.为啥要做cmdb👀 2.开发cmdb的思路和大概做法👀 3.cmdb的四套方案👀 一、为啥要做CMDB a.项目发开和上线场景🎆 流程： 产品经理调研需求 ===》定一个时间开发 ===》测试 ===》产品项目上线（运维） 传统做法： 运维解压文件（以邮件的形式发给运维），将代码部署到相对应的服务器目录下面。如果是由100等的话就是写shell脚本，后面跟着一串服务器的列表，然后把项目代码部署分发到每个服务器上，然后再用一个命令进行解压 存在问题： --效率不高 --不能实现覆盖Bug的代码（代码需要完bug之后就要重新走一套流程，效率极低） 解决方法： 代码上线系统： 前端展示给用户页面，用户可选择要上传的代码，页面还展示了公司所有的服务器和对应的ip地址可以进行勾选，然后点击上传即可。 这样就不需要交给运维人员了，运维只要告诉你有什么权限，然后分配了哪几台机器，再去选择需要发布的服务器，上传交给后端（使用django去改写shell脚本的那一套） 如果需要修改代码的话，也是直接发布提交，然后后台会自动的进行代码之间的比较 -------------------必要的条件：服务器的IP地址，硬盘空间，CPU的使用率，内存等 b.监控服务器🎪 （🔯监控服务器的报警信息：公司的服务器运行好多程序，会有好多的图表，就是监控这个服务|应用|网址的状态码等的一些变化信息♍）

CMDB项目: 技术： Django + python + saltstack + html + css + Js 架构： 后台管理，API，数据采集（agent,ssh,salt) 数据采集 ==》 API ==》 后台管理 认证： 数据采集 - API ： 传输验证， key + time.time(), 超时时间限制，维护已经访问过的列表验证 保证资产唯一： 安装系统在系统目录写入带有主机名的文件，每次验证通过该主机名。 数据库数据更新，删除，插入： 新数据 和 老数据进行对比，求交集。 新数据 - 交集 = 插入 老数据 - 交集 =删除 交集的每一项进行对比 = 更新 来源： https://www.cnblogs.com/yuxiaohao/p/10474400.html

TIL即IT基础架构库(Information Technology Infrastructure Library, ITIL，信息技术基础架构库)由英国政府部门CCTA(Central Computing and Telecommunications Agency)在20世纪80年代末制订，现由英国商务部OGC(Office of Government Commerce)负责管理，主要适用于IT服务管理（ITSM）。ITIL为企业的IT服务管理实践提供了一个客观、严谨、可量化的标准和规范。 1、事件管理（Incident Management） 事故管理负责记录、归类和安排专家处理事故并监督整个处理过程直至事故得到解决和终止。事故管理的目的是在尽可能最小地影响客户和用户业务的情况下使IT系统恢复到 服务级别协议 所定义的服务级别。 目标是：在不影响业务的情况下，尽可能快速的恢复服务，从而保证最佳的效率和服务的可持续性。事件管理流程的建立包括事件分类，确定事件的优先级和建立事件的升级机制。 2、问题管理（Problem Management） 问题管理是指通过调查和分析IT基础架构的薄弱环节、查明事故产生的潜在原因，并制定解决事故的方案和防止事故再次发生的措施，将由于问题和事故对业务产生的负面影响减小到最低的服务管理流程。与事故管理强调事故恢复的速度不同

参考： https://blog.csdn.net/shaw_young/article/details/78730724 资源： 官方主页：http://www.onecmdb.org/wiki/index.php?title=Main_Page 官方下载：http://sourceforge.net/projects/onecmdb/files/ 环境： centos 7.5 x64 mariadb 5.5.56 ip:192.168.3.5 安装linux64位系统32位支持包glibc.i686 yum list glibc* yum install glibc.i686 解压到目录： tar -xzvf onecmdb-2.1.0-linux.i386.tar.gz -C /opt 引入mysql jar包： 下载mysql-connector-java-5.1.48.tar.gz tar -xzvf mysql-connector-java-5.1.48.tar.gz cd mysql-connector-java-5.1.48 cp mysql-connector-java-5.1.48.jar /opt/onecmdb/tomcat/webapps/ROOT/WEB-INF/lib 编辑配置文件： 修改连接端口 cd /opt/onecmdb/tomcat/conf

#实现是通过时间戳+秘钥进行 MD5 加密处理from django.shortcuts import render,HttpResponse,redirect,reverse from django.views.decorators.csrf import csrf_exempt import json #使用rest_framework ，首先要安装pip去安装Djangorestframework ，这个模块 # 在Django的settings中注册app import hashlib import time from django.conf import settings from rest_framework.views import APIView from rest_framework.response import Response from api import models from api import service #服务端临时测试 KEY = 'alksdgjaldks' #解密 def gen_key(key,ctime): key_str = '{}|{}'.format(key,ctime) md5 = hashlib.md5() md5.update(key_str.encode('utf-8')) return md5.hexdigest()