Linux----------自动化运维

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

  • 打个比喻:

二、自动化运维应用场景

  • 文件传输
  • 命令执行
    应用部署
    配置管理
    任务流编排

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

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

原文地址:https://www.cnblogs.com/wangchengshi/p/10917019.html