CMDB和运维自动化

CMDB和运维

一、传统运维和自动化运维

1、传统运维

  • 日常工作繁琐
  • 应用运行环境不统一
  • 运维及部署效率低下
  • 无用报警信息过多
  • 资产管理和应用管理混乱

2、自动化运维

  • OS的选择统一化,同一个项目使用同样的OS系统部署其所需要的各类软件
  • 软件安装标准化,例如JAVA虚拟机,php,nginx,mysql等各类应用需要的软件版本,安装目录,数据存放目录,日志存放目录等
  • 应用包目录统一标准化,及应用命名标准化
  • 启动脚本统一目录和名字,需要变化的部分通过参数传递
  • 配置文件标准化,需要变化的部分通过参数传递
  • 日志输出,日志目录,日志名字标准化
  • 应用生成的数据要实现统一的目录存放
  • 主机/虚拟机命名标准化,虚拟机管理使用标准化模板
  • 使用docker比较容易实现软件运行环境的标准化

二、项目

1、项目上线

a. 产品经理前期调研 (需求分析)
b. 和开发进行评审
c. 开发进行开发
d. 测试进行测试
e. 交给运维人员进行上线

2、收集服务器元信息

a. excel表格
    缺点:
        - 人为干预太严重
        - 统计的时候也会有问题

b. 一个系统(CMDB)
    作用: 自动的帮我收集服务器的信息,并且自动的记录我们的变更信息

三、CMDB(资产管理系统)

CMDB是所有运维工具的数据基础

1、CMDB的功能

1. 用户管理,记录测试,开发,运维人员的用户表
2. 业务线管理,需要记录业务的详情
3. 项目管理,指定此项目用属于哪条业务线,以及项目详情
4. 应用管理,指定此应用的开发人员,属于哪个项目,和代码地址,部署目录,部署集群,依赖的应用,软件等信息
5. 主机管理,包括云主机,物理机,主机属于哪个集群,运行着哪些软件,主机管理员,连接哪些网络设备,云主机的资源池,存储等相关信息
6. 主机变更管理,主机的一些信息变更,例如管理员,所属集群等信息更改,连接的网络变更等
7. 网络设备管理,主要记录网络设备的详细信息,及网络设备连接的上级设备
8. IP管理,IP属于哪个主机,哪个网段, 是否被占用等

2、CMDB的四种实现方式

(1)agent采集

agent方式,可以将服务器上面的Agent程序作定时任务,定时将资产信息提交到指定API录入数据库

# agent方式本质:
在各个服务器上执行 subprocess.getoutput() 命令,然后将每台机器上执行的结果,返回给主机API,然后主机API收到这些数据之后,放入到数据库中,最终通过web界面展现给用户

# 优缺点:
优点:速度快
缺点:需要为每台服务器部署一个agent脚本

# 使用场景
服务器较多的场景

(2)ssh方式(基于Paramiko模块)

中控机通过 Paramiko(py模块) 登录到各个服务器上,然后执行命令的方式去获取各个服务器上的信息

# ssh方式本质:
中控机获取主机列表,登录服务器主机,利用paramiko模块获取服务器信息。中控机将信息发给API,API将结果写入数据库。后台管理可以从数据库中将服务器的信息数据从数据库中读出。

# 优缺点:
优点:不用再服务器上部署agent脚本
缺点:速度慢,需要一台中控机登录服务器

# 使用场景
服务器较少的场景

(3)salt-stack方式

# 本质
中控机将命令放在ZeroMQ队列中;服务器从队列中取通过执行:salt.cmd(‘主机地址‘, ‘ifconfig命令‘)。服务器执行完命令,将结果(服务器信息)放进另一个队列中;中控机从结果队列中取出结果。中控机将服务器信息发给API,后台管理可以从数据库中将服务器的信息数据从数据库中读出。

# 优缺点
优点:速度快, 开发成本低
缺点:每一台需要部署salt-stack

# 使用场景
企业的服务器以前就装好了salt-stack

(4)Puppet方式(很少用)

Ruby语言开发。
每隔30分钟,通过RPC消息队列将执行的结果返回给用户

四、salt-stack的安装和配置

1、安装和配置

‘‘‘master主机端‘‘‘
# 1. 安装salt-master
    yum install salt-master
# 2. 修改配置文件:/etc/salt/master
    interface: 0.0.0.0    # 表示Master的IP
# 3. 启动
    service salt-master start

‘‘‘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                # 查看已授权和未授权的slave
salt-key -a  salve_id      # 接受指定id的salve
salt-key -r  salve_id      # 拒绝指定id的salve
salt-key -d  salve_id      # 删除指定id的salve

3、执行命令

在master服务器上对salve进行远程操作

salt ‘c2.salt.com‘ cmd.run  ‘ifconfig‘

参考安装:http://www.cnblogs.com/tim1blog/p/9987313.html

原文地址:https://www.cnblogs.com/zhangbingsheng/p/10242097.html

时间: 2024-10-24 14:35:37

CMDB和运维自动化的相关文章

18页PPT带你深度解读运维自动化【转】

来自地址:[http://www.opsers.org/tech/18-pages-ppt-show-you-depth-interpretation-operations-automation.html] 说实话,一个运维团队的运维能力如何,其实看一个自动化管理系统便知! ********文章较长,索引目录如下******* 一.概述 二.运维自动化的三重境界 三.运维自动化的多维解读 ******第一.基于应用变更场景的维度划分 ******第二.基于系统层次的维度划分 ******第三.基

【有感而发】从中华武术谈运维工程师以及运维自动化

从中华武术谈运维工程师以及运维自动化 任何事物都没有完美一说,但是我们可以死磕自己,追求极致... 无论我们现在是搬砖呢,砌墙呢,还是在逗自己混日子,我们需要关注的是自己的方向在哪里,而不是过于在意自己当前的所站的位置,人生不能受限于自己的意识. 平时和小伙伴们聊人生谈理想的时候,我会经常和别人讲我所认为的专业化运维工程师和运维工作的方向,有认可的也有不认可的,认可的多在努力让自己的工作越来越轻松,自己的价值越来越能得到体现,不认可者多属于一天都很忙,而且认为运维就是帮开发人员打打杂,做大量重复

关于安全部和运维部门如何高效的协同工作,保障企业整体性安全。

目前安全热度已经上升国家安全的层次,伴随着各种有影响范围的安全事件频发,无论是来自国际的,还是国内的,使安全类工作逐渐在企业管理中成为了重要工作项之一.今天博主就和大家讨论一下如何使安全部和运维部门如何高效的协同工作.目前国内企业安全部和运维部在企业管理中所处的关系型如下几种: 1.死掐性 安全部站到安全视角发现识别安全风险,运维以运维带来成本砍掉安全需求.2.相安无事型 安全部和运维部在处理已识别的企业安全风险时,大家明面不发生冲突,但是暗地是太极推手,左右互博,尽显甩锅技能.3.协同性安全部

[运维] 第三篇:漫谈数据中心运维自动化

运维自动化是从2010年以后起来的一个运维需求,10年之前,运维项目主要集中在监控和ITIL流程上,当时也有BMC Control-M等产品在推,但是客户接受程度和影响力不如监控和流程.10年之后,运维自动化提上日程,建行开始招运维自动化的标,IBM.BMC.HP都纷纷参与,测了三轮,最后HP opsware中标,只能说一句厉害!工商银行也在自己组织服务商做自己特色的运维自动化平台,做了3.4年,基本成型,服务商也做出了自己的运维自动化产品,正式推向市场.当时运维自动化的主要功能是五项:自动化巡

单表60亿记录等大数据场景的MySQL优化和运维之道 | 高可用架构(转)

转自http://www.php1.cn/Content/DanBiao_60_YiJiLuDengDaShuJuChangJingDe_MySQL_YouHuaHeYunWeiZhiDao_%7C_GaoKeYongJiaGou.html, 更多详细资料请参看原文 此文是根据杨尚刚在[QCON高可用架构群]中,针对MySQL在单表海量记录等场景下,业界广泛关注的MySQL问题的经验分享整理而成,转发请注明出处. 杨尚刚,美图公司数据库高级DBA,负责美图后端数据存储平台建设和架构设计.前新浪高

实战:基于Python构建运维自动化平台

导语: 今天与大家一起探讨如何基于Python构建一个可扩展的运维自动化平台,也希望能与大家一起交流,共同成长. 此次分享将通过介绍OMServer.OManager具备的功能.架构设计.模块定制.安全审计.C/S结构的实现等几个方面的内容来展开. 为什么选择Python? 默认安装且跨平台 可读性好且开发效率高 丰富的第三方库(开发框架.各类API.科学计算.GUI等) 社区活跃&众多开发者. Python在腾讯的现状,根据去年内部提交组件语言统计,除去2.3.4前端技术,Python在高级编

如何基于Python构建一个可扩展的运维自动化平台

嘉宾简介 刘天斯 从事互联网运维工作已13年,目前就职于腾讯-互动娱乐部,负责游戏大数据的运营,曾就职于天涯社区,担任首席架构师/系统管理员. 热衷开源技术的研究,包括系统架构.运维开发.负载均衡.缓存技术.数据库.NOSQL.分布式存储.消息中间件.大数据及云计算.Mesos.Docker.DevOps等领域.擅长大规模集群的运维工作,尤其在自动化运维方面有着非常丰富的经验.同时热衷于互联网前沿技术的研究,活跃在国内社区.业界技术大会,充当一名开源技术的传播与分享者. 导言 受 Reboot

运维自动化平台思路

⑴客户端初始化: info collect  信息收集  CMDB 配置管理工具 ⑵服务端 ①资产管理simplecmdb ②配置管理(软件安装.配置同步) puppet.saltstack.ansible ③代码发布(自动化部署) jenkins.svn.python xml RPC ④监控报警  nagios(关乎状态) graphite(关乎性能和趋势) ⑤日志搜集  kibana logstash  elasticasearch 运维自动化平台思路

开源运维自动化

1. 开源运维自动化工具体系: 系统安装部署-Cobbler 配置管理部署--Saltstack 系统应用监控--zabbix 日志收集分析--fluentd or Elasticsearch 2. 集成开源自动化系统流程设计 裸机机房上架--->填写一些预配置信息(后期考虑直接实现"扫一扫")--->交给平台进行系统安装,进度控制等(cobbler的api实现)--->系统安装完成进行初始化和环境部署(saltstack的api完成)--->添加监控(zabb