自动化运维

原来给公司里开发的运维系统遇到了瓶颈，抽时间反思和网上收集了不少想关信息，准备按照ITIL的理念，开发第二代自动化运维系统。 =========记录一下从ITIL学到的理念======== IT是一种服务和工具，而不是单纯的技术体现，运维以服务为中心 一切皆配置（CI），CI灵活准确，系统才可信、可扩展 CMDB是真实IT基础架构的虚拟映射 服务台是唯一对外窗口，能快速对接第三方系统，同时提供第三方各种CI及其关联信息 事故的解决强调速度第一，问题来自大量同类型事故的抽象，其解决是对架构发起变更 CI的变更需要流程，历史需记录 核心数据层是当前最新CI结构，外围是CI变更日志，再外围是与第三方APP交互日志 来源： oschina 链接： https://my.oschina.net/u/922576/blog/182121

运维与自动化运维发展概括 https://www.cnblogs.com/guigujun/p/6574731.html 1、运维自动化发展 运维学习和发展的一个线路： 1.搭建服务（部署并运行起来） 2.用好服务（监控、管理、优化） 3.自动化（服务直接的关联和协同工作） 4.产品设计（如何设计一个运维系统） -----当下云计算的核心竞争力是运维！ 系统架构师（偏管理）：网络 系统 数据库 开发 云计算 自动化 运维管理 服务管理 项目管理 测试 业务 -----专注于某一领域 2、运维自动化发展 运维工作内容分类： 监控运维（7x24运维值班、故障处理） 应用运维（业务熟悉、服务部署、业务部署、版本管理、灰度发布、应用监控） 安全运维（整体的安全方案、规范、漏洞检测、安全防护等） 系统运维（架构层面的分布式缓存、分布式文件系统、日志收集、环境规划（测试、开发、生产）、架构设计、性能优化） 基础服务运维（包含运维开发）（内部dns、负载均衡、系统监控、资产管理、运维平台） 基础设施运维（系统初始化、网络维护、负责设备上下架、巡检、报修、硬件监控） 3、运维自动化发展 标准化： 物理设备层面： 1.服务器标签化、设备负责人、设备采购详情、设备摆放标准 2.网络划分、远程控制卡、网卡端口 3.服务器机型、硬盘、内存统一。根基业务分类 4.资产命名规范、编号规范、类型规范 5

DevOps（Development和Operations的组合词）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。从定义来看，其实devops就是为了让开发、运维和QA可以高效协作的流程 来源： https://www.cnblogs.com/levin180425/p/11722329.html

SaltStack；以及与AnsibleWorks,Chef-solo,puppet等等等的比较！ ... 　　　　　　 http://www.vpsee.com/2013/08/a-system-configuration-management-and-orchestration-tool-saltstack/ 系统自动化配置和管理工具 SaltStack 2013年08月22日 | 标签: devops , puppet , salt , saltstack | 作者： vpsee 我们的服务器 由 Puppet 配置管理工具来管理 ，服务器上线后由 puppet 完成初始化和配置等一系列工作（比如，静态 IP 配置，DNS 设置，NFS/SAN 挂载，LDAP/Kerberos 登录，安全加固配置，内核参数优化，防火墙规则配置等等），等初始化完成后开始运行，运行一段时间后有一些需要自动和手动操作的任务（比如升级、重启、备份等），这时候我们 使用 Fabric 来批量执行 这些临时任务。 所以从这里可以看到 Puppet 和 Fabric 其实是两个不同性质的工具，看下面的归类可能会更清楚一些。Puppet 和 Fabric 两个的工作其实可以由一个工具 SaltStack（或 AnsibleWorks）完成，减少一个工具的使用会减轻一点负担（学习工具的人力成本

考虑的因素： 源代码 下载编译后 打包为镜像 发布到镜像库 利用K8S发布到物理机器运行，以服务的形式对外提供服务 目前的做法 0、建立一个执行远程命令的框架 1、每个应用建立一个部署文件脚本 A、指定元代码地址 B、下载源代码到本地 C、同步源代码到目标主机 D、接受脚本参数： appname= $ 1---应用名称或者说是服务名称 vername= $ 2----版本号，镜像tag fromPort= $ 3----宿主端口 toPort= $ 4----容器端口 gitaddress= $ 5---git地址 cname= $ 6-----容器名称 cnum= $ 7-------容器的个数 E、到远程机器上执行构建镜像的命令 1、部署的物理机器，IP 2、原代码位置 来源： https://www.cnblogs.com/justart/p/11686291.html

中小型企业通用自动化运维架构 学习 教程 python发送邮件 sendmail.py #!/usr/bin/python # -*- coding: UTF-8 -*- import smtplib import email.MIMEMultipart import email.MIMEText import email.MIMEBase import sys #from email.mime.application import MIMEApplication #import os.path def sendmail(f_from, f_to, f_cclist, alert_info, f_subject): From = f_from To = f_to #file_name = f_file_name server = smtplib.SMTP("smtp.xxxx.com.cn") server.login("xxxx","xxxx") #构造MIMEMultipart对象做为根容器 main_msg = email.MIMEMultipart.MIMEMultipart() text_msg = email.MIMEText.MIMEText("您好。<br><br><br><br>" + alert_info.title() + "<br>任凤军 <br>"

ansible自动化运维常用模块 　　常用模块实现的功能：安装软件包；修改配置文件；创建程序用户组；创建目录，并修改所属和权限；挂载；启动服务；测试。 　　　　command模块： 　　　　shell模块： 注意：command和shell模块功能类似，区别：command只能使用一条指令，shell可以使用管道！ 　　　　 　　　　例子：　　　　　 　　　　　　[root@host1 ~]# ansible test1 -m shell -a "df -h|grep /$" 　　　　　　192.168.132.163 | CHANGED | rc=0 >> 　　　　　　/dev/mapper/centos-root 17G 4.5G 13G 26% / 　　　　　　192.168.132.162 | CHANGED | rc=0 >> 　　　　　　/dev/mapper/centos-root 17G 4.4G 13G 26% / 　　　　yum模块： 　　　　copy模块： 　　　　service模块： 来源： https://www.cnblogs.com/renyongbin/p/11646726.html

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

目录 自动化运维工具-Ansible基础 自动化运维的含义 Ansible 基础及安装 Ansible的架构 Ansible的执行流程 ansible配置文件 ansible Inventory（主机清单文件） Ansible ad-hoc ansible常用模块 实战 自动化运维工具-Ansible基础 自动化运维的含义 1.手动运维时代 2.自动化运维时代 3.自动化运维工具给运维带来的好处 Ansible 基础及安装 1.什么是Ansible Ansible是一个自动化 统一配置管理工具 2.同类型软件对比 1.puppet 学习难，安装ruby环境难，没有远程执行功能 2.ansible 轻量级，大规模环境下只通过ssh会很慢，串行的 3.saltstack 一般选择salt会使用 C/S 结构的模式， salt-master 和 salt-minion ，并行的，大规模批量操作的情况下，会比Ansible速度快一些，底层使用的是 zero-MQ 消协队列 Ansible使用的是python2 saltstack即有python2也有python3 Ansible的功能及优点 1.远程执行 批量执行远程命令，可以对多台主机进行远程操作 2.配置管理 批量配置软件服务，可以进行自动化方式配置，服务的统一配置管理，和启停 3.事件驱动 通过Ansible的模块

第一部分 puppet基础 一、puppet概述 1.1 puppet功能简介 1.2 puppet项目说明 二、puppet基础原理 2.1 puppet基础概念 2.1.1 资源 2.1.2 资源清单 2.1.3 类 2.1.4 模块 2.1.5 catalog 2.2 puppet的三层模型 2.2.1 资源抽象层 2.2.2 事务层 2.2.3 配置语言 2.3 puppet工作模型 2.3.1 单机模型 2.3.2 master/agent模型 2.4 puppet工作流程 2.4.1 单机模型工作流程 2.4.2 master/agent模型工作流程 三、puppet安装配置 本部分揉碎至后续各部分中讲解。 第二部分 puppet概念详解以及在单机模型中使用puppet 四、puppet资源 4.1 资源申报 4.1.1 常见的资源类型 4.1.2 资源类型相关帮助信息的获取及查看 4.1.3 申报资源 4.1.3.1 user和group资源 4.1.3.2 file资源 4.1.3.3 notify资源 4.1.3.4 service资源 4.1.3.5 exec资源 4.1.3.5 service资源 4.2 资源依赖：顺序和通知 4.2.1 资源依赖关系概述 4.2.2 资源应用顺序 4.2.2.1 before属性 4.2.2.2 require属性 4.2