运维自动化之---ansilbe运维自动化和ansible架构介绍(1)
运维自动化的发展历程1、自动化运维应用场景1、1云计算运维工程师核心职能运维相关的工具Podman是用来替代docker的工具1.2 运维职业的发展路线目标::一切皆自动化1.3 企业实际应用场景分析开发工程师—测试工程师----运维工程师白核测试工程师::心功能实现不,还要关心其他黑核测试工程师::不关心其他,仅仅关心功能实现不1.3.1 Dev开发环境使用者:程序员功能:程序员个人的办公电脑或
运维自动化的发展历程
1、自动化运维应用场景
1、1云计算运维工程师核心职能
运维相关的工具
Podman是用来替代docker的工具
1.2 运维职业的发展路线
目标::一切皆自动化
1.3 企业实际应用场景分析
开发工程师—测试工程师----运维工程师
白核测试工程师::心功能实现不,还要关心其他
黑核测试工程师::不关心其他,仅仅关心功能实现不
1.3.1 Dev开发环境
使用者:程序员
功能:程序员个人的办公电脑或项目的开发测试环境,部署开发软件,测试个人或项目整体的BUG的环境
管理者:程序员
1.3.2 测试环境
使用者:QA测试工程师
功能:测试经过Dev环境测试通过的软件的功能和性能,判断是否达到项目的预期目标,生成测试报告
管理者:运维
说明:测试环境往往有多套,测试环境满足测试功能即可,不宜过多
1、测试人员希望测试环境有多套,公司产品多产品线并发,即多个版本,意味着多个版本同步测试。
2、通过测试环境有多少套和产品线数量保持一致
1.3.3 预发布环境
使用者:运维
功能:使用和生成环境一样的数据库,缓存服务等配置,测试是否正常
1.3.4 发布环境
包括代码发布机,有些公司为堡垒机(安全屏障)
使用者:运维
功能:发布代码至生产环境
管理者:运维(有经验者)
发布机:往往需要两台(主备)
1.3.5 生成环境
使用者:运维,少数情况开发权限给核心开发人员,极少数公司将权限完全开放给开发人员并其维护
功能:多用户提供公司产品的服务
管理者:只能是运维
生产环境服务器数量:一般比较多,且应用非常重要,往往需要自动工具协助部署配置应用
1.3.6 灰度环境(金丝雀发布)
属于生产环境的一部分
使用者:运维
功能:在全量发布代码前将代码的功能面向少量精准用户发布的环境,可基于主机或用户执行灰度发布
案例:共100台生产服务器,先发布其中的10台服务器,这10台服务器就是灰度发布服务器
管理者:运维
灰度环境:往往该版本功能变更比较大,为了保险起见特意先让一部分用户优先体验改功能,待这部分用户使用没有重大问题的时候,在全量发布至所有服务器
1.4 程序发布
程序发布需求:
不能导致系统故障或造成系统完全不可用
不能影响用户体验
预发布验证:
新版本的代码先发布至服务器(跟线上环境配置完全相同,只是为接入到调度器)
灰度发布:
基于主机,用户,业务
发布路径:
/webapp/tuangou ----- 软链接
/webapp/tuangou-1.1 ----老版本
/webapp/tuangou-1.2 ----新版本
发布过程
1、在调度器上下线一批主机(标记为maintenance状态)
2、关闭服务
3、部署新版本的应用程序
4、启动服务
5、在调度器上启动这一批服务器
自动化灰度发布
- 脚本
- 发布平台
1.5 自动化运维应用环境
- 文件传输
- 应用部署
- 配置管理
- 任务流编排
1.6 常用自动化运维工具
- Ansible : python,Agentless,中小型应用环境
- Saltstack:python,一般需部署agent,执行效率更高
- Puppet:ruby,功能强大,配置复杂,重型,适合大型环境
- Fabric:python,agentless
- Chef:ruby,国内应用少
- Cfengine
- func
同类自动化工具GitHub关注程度(2016-7-10)
2、Ansible 介绍和架构
公司计划在年底做一次大型市场促销活动,全面冲刺下交易额,为明年的上市做准备。公司要求各业务组,对年底大促做准备,运维部要求所有业务容量进行三倍扩容,并搭建出多套环境可以供开发和测试人员做测试,运维老大为了年底所有表现,要求运维部门同学尽快实现,当你接到这个任务时,有没有更快的解决方案。
2.1 Ansible 发展史
2.2 Ansible 特性
- 模块化:调用特定的模块,完成特定任务
- Paramiko (python对ssh的实现),PyYAML,Jinja2(模板语言)三个关键模块
- 支持自定义模块,可使用任何编程语言写模块
- 基于Python语言实现
- 部署简单,基于python和SSH(默认已安装),agentless,无需代理不依赖PKI(无需ssl)
- 安全,基于OpenSSH
- 幂等性:一个任务执行1遍和执行n遍效果一样,不因重复执行带来意外情况
- 支持playbook编排任务,YAML格式,编排任务,支持丰富的数据结构
- 较强大的多层解决方案role
2.3 Ansible架构
2.3.1 Ansible 组成
组合INVENTOPY,API,MODULES、PLUGINS的绿框,可以理解为是ansible命令工具,其为核心执行工具
- INVENTOPY:Ansible管理主机的清单/etc/ansible/hosts
- MODULES:ansible执行命令的功能模块,多数为内置核心模块,也可以自定义
- PLUGINS:模块功能的补充,如连接类型插件,循环插件,变量插件,过滤插件等,该功能不常用
- API:供第三方程序调用的应用程序编程接口
2.3.2 Ansible 命令执行来源
- USER 普通用户,即SYSTEM ADMINISTRATOR
- PLAYBOOKS:任务剧本(任务集),编排定义Ansible任务集的配置文件,由Ansible顺序依次执行,通常是JSON格式的YML文件
- CMDB (配置管理数据库) API 调用
- PUBLIC/PRIVATE CLOUD API调用
- USER-> Ansible Playbook ->Ansible
2.3.3 注意事项
- 执行ansible主机一般为主控端,中控,master或堡垒机
- 主控端Python版本需要2.6或以上
- 被控端Python版本小于2.4需要安装libselinux-python
- Windows不能做为主控端
更多推荐
所有评论(0)