平常运维工做是比较繁琐的,研发同窗会常常须要到服务器上查日志,重启应用,或者是说今天上线某个产品,须要部署下环境。这些杂事是传统运维的大部分工做php
在部署某应用后,应用不能访问,就会听到开发人员说,在个人环境运行很好的,怎么部署到测试环境后,就不能用了,由于各种环境的类库不统一
还有一种极端状况,运维人员习惯不一样,可能凭本身的习惯来安装部署软件,每种服务器上运行软件的目录不统一html
想一想运维人员须要登录到服务器上执行命令,部署程序,不只效率很低,而且很是容易出现人为的错误,一旦手工出错,追溯问题将会很是不容易python
常常会收到不少报警信息,多数是无用的报警信息,形成运维人员常常屏蔽报警信
另外若是应用的访问速度出了问题,老是须要从系统、网络、应用、数据库等一步步的查找缘由mysql
资产管理,服务管理常常记录在excel、文本文件或者wiki中,不便于管理,老员工由于比较熟,不注重这些文档的维护,只有靠每次有新员工入职时,资产才可以更正一次linux
运维自动化最重要的就是标准化一切
- OS的选择统一化,同一个项目使用一样的OS系统部署其所须要的各种软件
- 软件安装标准化,例如JAVA虚拟机,php,nginx,mysql等各种应用须要的软件版本,安装目录,数据存放目录,日志存放目录等
- 应用包目录统一标准化,及应用命名标准化
- 启动脚本统一目录和名字,须要变化的部分经过参数传递
- 配置文件标准化,须要变化的部分经过参数传递
- 日志输出,日志目录,日志名字标准化
- 应用生成的数据要实现统一的目录存放
- 主机/虚拟机命名标准化,虚拟机管理使用标准化模板
- 使用docker比较容易实现软件运行环境的标准化
CMDB是全部运维工具的数据基础
- 用户管理,记录测试,开发,运维人员的用户表
- 业务线管理,须要记录业务的详情
- 项目管理,指定此项目用属于哪条业务线,以及项目详情
- 应用管理,指定此应用的开发人员,属于哪一个项目,和代码地址,部署目录,部署集群,依赖的应用,软件等信息
- 主机管理,包括云主机,物理机,主机属于哪一个集群,运行着哪些软件,主机管理员,链接哪些网络设备,云主机的资源池,存储等相关信息
- 主机变动管理,主机的一些信息变动,例如管理员,所属集群等信息更改,链接的网络变动等
- 网络设备管理,主要记录网络设备的详细信息,及网络设备链接的上级设备
- IP管理,IP属于哪一个主机,哪一个网段, 是否被占用等
关键点:
1. 到linux服务器上, 执行linux的命令, 最终获取服务器的信息
2. 用Python的方式执行linux命令, 而后将执行的结果返回分析并最终入库nginx
Agent方式,能够将服务器上面的Agent程序做定时任务,定时将资产信息提交到指定API录入数据库web
import subprocess res= subprocess.getoutput('ipconfig') print(res)其本质上就是在各个服务器上执行
subprocess.getoutput()
命令,而后将每台机器上执行的结果,返回给主机API,而后主机API收到这些数据以后,放入到数据库中,最终经过web界面展示给用户面试
优势:速度快
缺点:须要为每台服务器部署一个Agent程序sql
中控机经过Paramiko(py模块)登陆到各个服务器上,而后执行命令的方式去获取各个服务器上的信息docker
优势:无Agent 缺点:速度慢
若是在服务器较少的状况下,可应用此方法
import paramiko # 建立SSH对象 ssh = paramiko.SSHClient() # 容许链接不在know_hosts文件中的主机 ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy()) # 链接服务器 ssh.connect(hostname='127.0.0.1', port=22, username='root', password='123') # 执行命令 stdin, stdout, stderr = ssh.exec_command('df') # 获取命令结果 result = stdout.read() # 关闭链接 ssh.close()
此方案本质上和第二种方案大体是差很少的流程,中控机发送命令给服务器执行。服务器将结果放入另外一个队列中,中控机获取将服务信息发送到API进而录入数据库。
优势:快,开发成本低 缺点:依赖于第三方工具
一、安装与配置
master端: """ 1. 安装salt-master yum install salt-master yum install -y epel-release salt-master salt-minion 2. 修改配置文件:
vim /etc/salt/master # 第15行左右 打开注释并修改
interface: Master的IP地址 # 表示Master的IP 3. 启动 service salt-master start """
slave端: """ 1. 安装salt-minion yum install salt-minion 2. 修改配置文件
vim /etc/salt/minion
# 第15行左右 打开注释并修改
master: Master的IP地址 # master的地址
3. 启动 service salt-minion start
"""二、受权
""" salt-key -L # 查看已受权和未受权的slave
salt-ket -A # 接受全部 salt-key -a salve_id # 接受指定id的salve salt-key -r salve_id # 拒绝指定id的salve salt-key -d salve_id # 删除指定id的salve """三、执行命令:在master服务器上对salve进行远程操做
salt '*' cmd.run 'ifconfig'
基于API设计
# python2 import salt.client local = salt.client.LocalClient() result = local.cmd('c2.salt.com', 'cmd.run', ['ifconfig']) # python3 import subprocess cmd_info = "salt '%s' cmd.run '%s'" % (self.hostname, cmd) result = subprocess.getoutput(cmd_info)
参考安装:
http://www.cnblogs.com/tim1blog/p/9987313.html
https://www.jianshu.com/p/84de3e012753
1. 本来公司使用的是EXCE表格用来,管理起来比较麻烦
2. 部门推行本身的自动化运维,CMDB是基石
能够将服务器上面的Agent程序做定时任务,定时将资产信息提交到指定API录入数据库
其本质上就是在各个服务器上执行
subprocess.getoutput()
命令,而后将每台机器上执行的结果,返回给主机API,而后主机API收到这些数据以后,放入到数据库中,最终经过web界面展示给用户
中控机经过Paramiko(py模块)登陆到各个服务器上,而后执行命令的方式去获取各个服务器上的信息
中控机发送命令给服务器执行。服务器将结果放入另外一个队列中,中控机获取将服务信息发送到API进而录入数据库。
根据公司的业务需求决定
负责采集数据这一方面:
- 高级配置文件 参考django的配置文件(用户自定义的用用户本身的,没有自定义的用系统默认的配置)
- 高内聚低耦合思想
- 可插拔式的插件采集资产信息 参考的django的中间件
一、不知道需求 --- 沟通问题
二、Linux不熟悉 --- 百度,问老运维
三、惟一标识问题
# 经过选取hostname做为每台服务器的惟一表示,可是每台机器的主机名可能会被开发更改,形成查询资产时候丢失,所以提早分配好 , 而且每台服务器的主机名是惟一的,再分配给开发以前,咱们须要跑一遍client代码, 此时采集到的信息是最干净的, hostname也是最原始分配的hostname能够把这个最原始的hostname记录到一个文件中,每次查询时候,就按照最原始的记录的数据进行查询,这样就能避免由于开发者更改主机名而形成查询的遗漏