一、自动化运维发展历程及技术应用
- 打个比喻：
二、自动化运维应用场景
- 文件传输
- 命令执行
应用部署
配置管理
任务流编排
三、企业实际应用场景分析
3.1 企业应用场景
-
1 Dev开发环境
使用者：程序员
功能：程序员开发软件，测试BUG的环境
管理者：程序员 -
2 测试环境
使用者：QA测试工程师
功能：测试经过Dev环境测试通过的软件的功能
管理者：运维
说明：测试环境往往有多套,测试环境满足测试功能即可，不宜过多
（1）测试人员希望测试环境有多套,公司的产品多产品线并发，即多个版本，意味着多个版本同步测试
（2）通常测试环境有多少套和产品线数量保持一样 -
3 发布环境：代码发布机，有些公司为堡垒机（安全屏障）
使用者：运维
功能：发布代码至生产环境
管理者：运维（有经验）
发布机：往往需要有2台（主备） -
4 生产环境
使用者：运维，少数情况开放权限给核心开发人员，极少数公司将权限完全开放给开发人员并其维护
功能：对用户提供公司产品的服务
管理者：只能是运维
生产环境服务器数量：一般比较多，且应用非常重要。往往需要自动工具协助部署配置应用。 -
5 灰度环境（生产环境的一部分）
使用者：运维
功能：在全量发布代码前将代码的功能面向少量精准用户发布的环境,可基于主机或用户执行灰度发布
案例：共100台生产服务器，先发布其中的10台服务器，这10台服务器就是灰度服务器
管理者：运维
灰度环境：往往该版本功能变更较大，为保险起见特意先让一部分用户优化体验该功能，待这部分用户使用没有重大问题的时候，再全量发布至所有服务器
3.2程序发布
- 预发布验证：
- 新版本的代码先发布到服务器（跟线上环境配置完全相同，只是未接入到调度器）
- 程序发布：
不能导致系统故障或造成系统完全不可用
不能影响用户体验 - 灰度发布：
- 发布路径：
/webapp/tuangou-1.1
/webapp/tuangou
/webapp/tuangou-1.2 - 发布过程：在调度器上下线一批主机(标记为maintanance状态) --> 关闭服务 --> 部署新版本的应用程序 --> 启动服务 --> 在调度器上启用这一批服务器
- 自动化灰度发布：脚本、发布平台
四、常用自动化运维工具
Ansible:python,Agentless,中小型应用环境
Saltstack:python，一般需部署agent，执行效率更高
Puppet:ruby, 功能强大,配置复杂，重型,适合大型环境
Fabric：python，agentless
Chef: ruby,国内应用少
Cfengine
func