自动化运维体系-DevOps理念

DevOps介绍

DevOps理念

开发 Development

运维 Operations

测试 test

DevOps能做什么

敏捷开发：一个敏捷开发小组里有各个职位的人，专门干一件事

快速发布，抢占先机

当下产品迭代（真实）

提高产品质量

1 自动化测试
2 持续集成/持续交付/持续部署
3 代码质量管理工具
4 程序员鼓励师

开发的痛

CI/CD介绍

产品的生命周期

• 立项

  • 产品原型图
  • 需求碰撞

• 市场调研

  • 市场需求
  • 竞争对手

• 开发（开发环境）

  • 功能拆分
  • 登录功能
  • 注册功能
  • 交易功能
  • 订单功能
  • 购物功能
  • 直播功能
  • 物流功能
  • 产品入库
  • 产品出库
  • ......等等
  • 项目排期
  • 项目开发
  • 传统开发（低端公司）
  • 敏捷开发（高端公司、scrum）
  • 项目完成
  • 代码集成（代码仓库：CI：Continunous Integration）
  • 代码质检（sonarqube）

• 测试（测试环境）

  • 测试用例
  • 性能测试
  • 功能测试（黑盒测试：在不知道什么功能的情况下进行测试）
  • 白盒测试（在知道功能的情况下进行测试）
  • 自动化测试

• 运维（预上线环境、生产环境）

  • 代码交付（CD：Continunous Delivery）
  • 代码部署（CD：Continunous Deployment）
  • 服务维护
  • 故障解决
  • 技术支持
  • 自动化运维

• 消亡（destroy）

CI：持续集成=>将代码提交到代码仓库
工具：gitlab\SVN 版本管理工具

CD：持续交付
CD：持续部署
工具：shell\Jenkins

环境

• 开发环境

• 测试环境

  • 性能测试环境
  • 功能测试环境

• 预上线环境\预生产环境\beta环境\staging环境\release环境 （内测）

• 生产环境

测试环境：部署代码

http://www.test.com

公司内部，搭建一个DNS服务器

• coreDNS（DNS会用到）
• Bind9
• DNSmsq（可以自己研究一下）

什么是代码部署？

简单的一句话：就是将开发写好的代码，通过一系列的手段，让它能够成功运行在我们的环境中。

其实我们很早就接触过。

比如：

• nginx

• 下载安装包（开发写好的代码）

• 构建代码

• 生成配置

• 编译安装

• 修改配置

• 启动程序

• MySQL

• wordpress

只不过不同的代码需要不同的环境。

或许有些人绕不过来，当你成为架构师之后，一切皆为中间件，所有的应用，只是为了给我的代码提供一个运行环境而已，那些所谓的应用，都只是我代码的一个小小的依赖而已，或许我需要有个地方存储我的数据，那么作为开发人员，我可以任意选择地方，比如：文件中，world，execl都可以，但是为了产品的性能，安全，使我不得不选择一个当下热门的数据库，再或许，我的代码需要一个web环境，那么我可以自己用前端写一个web环境，然后把我的页面放进去，但是当下也有了很热门web程序，我们为什么不使用呢？

代码发布方式

应用程序升级面临最大挑战是新旧业务切换，将软件从测试的最后阶段带到生产环境，同时要保证系统不间断提供服务。

长期以来，业务升级渐渐形成了几个发布策略：蓝绿发布、金丝雀发布和滚动发布，目的是尽可能避免因发布导致的流量丢失或服务不可用问题。

手动发布

手动发布很容易造成误操作

自动发布

应用程序升级米娜了最大挑战是新旧业务切换，将软件从测试的最后阶段带到生产环境，同时要保证系统不间断提供服务。

长期以来，业务升级渐渐形成了几个发布策略：蓝绿发布、金丝雀发布和滚动发布，目的是尽可能避免因发布导致流量丢失或服务不可用的问题。

蓝绿发布（AB发布）

项目逻辑上分为AB组，在项目系统是，首先把A组从负载均衡中摘除，进行新版本的部署，B组仍然继续提供服务。

当A组升级完毕，负载均衡重新接入A组，再把B组从负载列表中摘除，进行新版本的部署。A组重新提供服务。

最后，B组也升级完成，负载均衡重新接入B组，此时，AB组版本都已经升级完成，并且都对外提供服务。

特点：

如果出问题，影响范围较大；
发布策略简单；
用户无感知，平滑过渡；
升级/回滚速度快。

缺点：

需要准备正常业务使用资源的两倍以上服务器，防止升级期间单组无法承载业务突发；
短时间内浪费一定资源成本；
基础设施无改动，增大升级稳定性。

金丝雀发布（灰度发布）

灰度发布是指在黑与白之间，能够平滑过渡的一种发布方式。灰度发布是增量发布的一种类型，灰度发布是在原有版本可用的情况下，同时部署一个新版本应用作为“金丝雀”（金丝雀对瓦斯极敏感，矿井工人携带金丝雀，以便及时发发现危险），测试新版本的性能和表现，以保障整体系统稳定的情况下，尽早发现、调整问题。

从负载均衡列表中移除掉“金丝雀”服务器。
升级“金丝雀”应用（排掉原有流量并进行部署）。
对应用进行自动化测试。
将“金丝雀”服务器重新添加到负载均衡列表中（连通性和健康检查）。
如果“金丝雀”在线使用测试成功，升级剩余的其他服务器。（否则就回滚）

特点：

保证整体系统稳定性，在初始灰度的时候就可以发现、调整问题，影响范围可控；
新功能逐步评估性能，稳定性和健康状况，如果出问题影响范围很小，相对用户体验也少；
用户无感知，平滑过渡。

缺点：

自动化要求过高（流水线发布）

滚动发布

滚动发布是指每次只升级一个或多个服务，升级完成后加入生产环境，不断执行这个过程，直到集群中的全部旧版本升级新版本。

蓝色：旧版本
绿色：新版本

特点：

用户无感知，平滑过渡；
节约资源。

缺点：

部署时间慢，取决于每阶段更新时间；
发布策略较复杂；
无法确定OK的环境，不易回滚。