自动化运维

自动化运维的概念:

IT运维,指的是对已经搭建好的网络,软件,硬件进行维护。运维领域也是细分的,有硬件运维和软件运维
分类:
    硬件运维:IDC运维,硬件运维主要包括对基础设施的运维,好比机房的设备,主机的硬盘,内存这些物理设备的维护
  软件运维:主要包括系统运维和应用运维,系统运维主要包括对OS,数据库,中间件的监控和维护,这些系统介于设备和应用之间,应用运维主要是对线上业务系统的运维。好比说对mysql进行备份管理,对nginx,apache软件的管理以及配置
  shell 脚本(基本语言)
  
传统运维的特色:平常工做繁琐,应用运行环境单一,运维及部署效率低下,无用报警信息过多,资产管理及应用管理混乱

自动化运维平台的特性

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

CMDB

是自动化运维的一个基石
全称:配置管理数据库
做用:收集服务器的各类信息 (包括收集服务器的内存,硬盘,CPU,IP, 主机名等信息)

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

1.Agent实现方式:
Agent方式,能够将服务器上面的Agent程序做定时任务,定时将资产信息提交到指定API录入数据库php

本质上就是在各个服务器上执行subprocess.getoutput()命令,而后将每台机器上执行的结果,返回给主机API,而后主机API收到这些数据以后,放入到数据库中,最终经过web界面展示给用户python

优势:速度快
缺点:部署比较麻烦, 每次新增一台服务器,都须要部署相应的脚本
使用场景:服务器多(500台以上)的场景mysql

如何使用python执行linux命令---subprocess
如何将拿到的结果返回给api---启动一个django服务,链接请求requests库传输数据
“header:Content-Type:application/json----只能从request.body中获取数据
header:application/x-www-form-urlencoded----会将request.body中的值赋值给request.POST”linux

2.ssh实现方式(基于Paramiko模块)运维里面是ansiblenginx

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

优势:无Agent,相比于第一套方案来讲, 不须要额外的部署代码

缺点:相比于第一套方案来讲, 速度比较慢, 由于它须要进行ssh的链接sql

若是在服务器较少的状况下,可应用此方法
************************************
import paramikodocker

建立SSH对象

ssh = paramiko.SSHClient()shell

容许链接不在know_hosts文件中的主机

ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy())数据库

链接服务器

ssh.connect(hostname='c1.salt.com', port=22, username='root', password='123')

执行命令

stdin, stdout, stderr = ssh.exec_command('df')

获取命令结果

result = stdout.read()

关闭链接

ssh.close()
************************************

3.saltstack方式
此方案本质上和第二种方案大体是差很少的流程,中控机发送命令给服务器执行。服务器将结果放入另外一个队列中,中控机获取将服务信息发送到API进而录入数据库。
安装和配置
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端:
    """
  4. 安装salt-minion
    yum install salt-minion
  5. 修改配置文件 /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
  6. 启动
    service salt-minion start
    """

底层原理是zeromq队列

优势:快,开发成本低

缺点:依赖于第三方工具,依赖saltstack软件


"""
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
"""
在master服务器上对salve进行远程操做
salt 'c2.salt.com' cmd.run 'ifconfig'
基于API的方式
import salt.client
local = salt.client.LocalClient()
result = local.cmd('c2.salt.com', 'cmd.run', ['ifconfig'])

4.puppet方案(没人用 ruby on rails)

第一种:

第二种

第三种

相关文章
相关标签/搜索