1、概述

1.1、运维自动化发展历程及技术应用

image.png

1.2、企业实际应用场景分析

  1. Dev开发环境
  2. 使用者:程序员
  3. 功能:程序员开发软件,测试BUG的环境
  4. 管理者:程序员
  5. 测试环境
  6. 使用者:QA测试工程师
  7. 功能:测试经过Dev环境测试通过的软件的功能
  8. 管理者:运维
  9. 说明:测试环境往往有多套,测试环境满足测试功能即可,不宜过多
  10. 1、测试人员希望测试环境有多套,公司的产品多产品线并发,即多个版本,意味着多个版本同步测试
  11. 2、通常测试环境有多少套和产品线数量保持一样
  12. 发布环境:代码发布机,有些公司为堡垒机(安全屏障)
  13. 使用者:运维
  14. 功能:发布代码至生产环境
  15. 管理者:运维(有经验)
  16. 发布机:往往需要有2台(主备)
  17. 生产环境
  18. 使用者:运维,少数情况开放权限给核心开发人员,极少数公司将权限完全
  19. 开放给开发人员并其维护
  20. 功能:对用户提供公司产品的服务
  21. 管理者:只能是运维
  22. 生产环境服务器数量:一般比较多,且应用非常重要。往往需要自动工具协助部署配置应用
  23. 灰度环境(生产环境的一部分)
  24. 使用者:运维
  25. 功能:在全量发布代码前将代码的功能面向少量精准用户发布的环境,可基
  26. 于主机或用户执行灰度发布
  27. 案例:共100台生产服务器,先发布其中的10台服务器,这10台服务器就是灰度服务器
  28. 管理者:运维
  29. 灰度环境:往往该版本功能变更较大,为保险起见特意先让一部分用户优化体验该功能,
  30. 待这部分用户使用没有重大问题的时候,再全量发布至所有服务器

1.3、程序发布

  1. 程序发布要求:
  2. 不能导致系统故障或造成系统完全不可用
  3. 不能影响用户体验
  4. 预发布验证:
  5. 新版本的代码先发布到服务器(跟线上环境配置完全相同,只是未接入到调度器)
  6. 灰度发布:
  7. 基于主机,用户,业务
  8. 发布路径:
  9. /webapp/tuangou
  10. /webapp/tuangou-1.1
  11. /webapp/tuangou-1.2
  12. 发布过程:在调度器上下线一批主机(标记为maintanance状态) --> 关闭服务 -->
  13. 部署新版本的应用程序 --> 启动服务 --> 在调度器上启用这一批服务器
  14. 自动化灰度发布:脚本、发布平台

1.4、运维自动化发展历程及技术应用

image.png

1.5、自动化运维应用场景

  1. 文件传输
  2. 应用部署
  3. 配置管理
  4. 任务流编排

1.6、常用自动化运维工具

  1. Ansible:python,Agentless,中小型应用环境
  2. Saltstack:python,一般需部署agent,执行效率更高
  3. Puppet:ruby, 功能强大,配置复杂,重型,适合大型环境
  4. Fabric:python,agentless
  5. Chef:ruby,国内应用少
  6. Cfengine
  7. func

1.7、企业级自动化运维工具应用实战ansible

  1. 公司计划在年底做一次大型市场促销活动,全面冲刺下交易额,为明年的上市做准备。
  2. 公司要求各业务组对年底大促做准备,运维部要求所有业务容量进行三倍的扩容,
  3. 并搭建出多套环境可以共开发和测试人员做测试,运维老大为了在年底有所表现,
  4. 要求运维部门同学尽快实现,当你接到这个任务时,有没有更快的解决方案?

2、ansbile介绍

2.1、Ansible发展史

  1. Ansible
  2. Michael DeHaan( Cobbler 与 Func 作者)
  3. 名称来自《安德的游戏》中跨越时空的即时通信工具
  4. 2012-03-09,发布0.0.1版,2015-10-17,Red Hat宣布收购
  5. 官网:https://www.ansible.com/
  6. 官方文档:https://docs.ansible.com/
  7. 同类自动化工具GitHub关注程度(2016-07-10)

image.png

2.2、特性

  1. 1> 模块化:调用特定的模块,完成特定任务
  2. 2> Paramiko(python对ssh的实现),PyYAML,Jinja2(模板语言)三个关键模块
  3. 3> 支持自定义模块
  4. 4> 基于Python语言实现
  5. 5> 部署简单,基于python和SSH(默认已安装),agentless
  6. 6> 安全,基于OpenSSH
  7. 7> 支持playbook编排任务
  8. 8> 幂等性:一个任务执行1遍和执行n遍效果一样,不因重复执行带来意外情况
  9. 9> 无需代理不依赖PKI(无需ssl)
  10. 10> 可使用任何编程语言写模块
  11. 11> YAML格式,编排任务,支持丰富的数据结构
  12. 12> 较强大的多层解决方案

2.3、Ansible架构

image.png

  1. ansible的作用以及工作结构
  2. 1、ansible简介:
  3. ansible是新出现的自动化运维工具,基于Python开发,
  4. 集合了众多运维工具(puppet、cfengine、chef、func、fabric)的优点,
  5. 实现了批量系统配置、批量程序部署、批量运行命令等功能。
  6. ansible是基于模块工作的,本身没有批量部署的能力。
  7. 真正具有批量部署的是ansible所运行的模块,ansible只是提供一种框架。
  8. 主要包括:
  9. (1)、连接插件connection plugins:负责和被监控端实现通信;
  10. (2)、host inventory:指定操作的主机,是一个配置文件里面定义监控的主机;
  11. (3)、各种模块核心模块、command模块、自定义模块;
  12. (4)、借助于插件完成记录日志邮件等功能;
  13. (5)、playbook:剧本执行多个任务时,非必需可以让节点一次性运行多个任务。
  14. 2、ansible的架构:连接其他主机默认使用ssh协议

2.4、Ansible工作原理

image.png

2.5、Ansible主要组成部分

  1. ANSIBLE PLAYBOOKS:任务剧本(任务集),编排定义Ansible任务集的配置文件,
  2. 由Ansible顺序依次执行,通常是JSON格式的YML文件
  3. INVENTORY:Ansible管理主机的清单 /etc/anaible/hosts
  4. MODULES: Ansible执行命令的功能模块,多数为内置核心模块,也可自定义
  5. PLUGINS: 模块功能的补充,如连接类型插件、循环插件、变量插件、过滤插件等,该功能不常用
  6. API: 供第三方程序调用的应用程序编程接口
  7. ANSIBLE: 组合INVENTORY、API、MODULES、PLUGINS的绿框,可以理解为是ansible命令工具,其为核心执行工具
  1. Ansible命令执行来源:
  2. 1> USER,普通用户,即SYSTEM ADMINISTRATOR
  3. 2> CMDB(配置管理数据库) API 调用
  4. 3> PUBLIC/PRIVATE CLOUD API调用 (公有私有云的API接口调用)
  5. 4> USER-> Ansible Playbook -> Ansibile
  6. 利用ansible实现管理的方式:
  7. 1> Ad-Hoc 即ansible单条命令,主要用于临时命令使用场景
  8. 2> Ansible-playbook 主要用于长期规划好的,大型项目的场景,需要有前期的规划过程
  1. Ansible-playbook(剧本)执行过程
  2. 将已有编排好的任务集写入Ansible-Playbook
  3. 通过ansible-playbook命令分拆任务集至逐条ansible命令,按预定规则逐条执行
  4. Ansible主要操作对象
  5. HOSTS主机
  6. NETWORKING网络设备
  7. 注意事项:
  8. 执行ansible的主机一般称为主控端,中控,master或堡垒机
  9. 主控端Python版本需要2.6或以上
  10. 被控端Python版本小于2.4需要安装python-simplejson
  11. 被控端如开启SELinux需要安装libselinux-python
  12. windows不能做为主控端
  13. ansible不是服务,不会一直启动,只是需要的时候启动