01·自动化运维体系-DevOps理念

DevOps介绍

file

开发 development
运维 operations

DevOps能做什么?

file

快速发布,抢占先机
当下产品迭代(真实)

file

提高产品质量

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

开发的痛

file

CI/CD介绍

软件的生命周期

  • 立项
    • 产品原型图
    • 需求碰撞
  • 市场调研
    • 市场需求
    • 竞争对手
  • 开发（开发环境）
    • 功能拆分
    • 登录功能
    • 注册功能
    • 交易功能
    • 订单功能
    • 购物功能
    • 直播功能
    • 物流功能
    • 产品入库
    • 产品出库
    • .......等等
    • 项目排期
    • 项目开发
    • 传统开发（低端公司）
    • 敏捷开发（高端公司、scrum）
    • 项目完成
    • 代码集成（代码仓库：CI：Continunous Integration）
    • 代码质检（sonarqube）
  • 测试（测试环境）
    • 测试用例
    • 性能测试
    • 功能测试（黑盒测试）
    • 白盒测试
    • 自动化测试
  • 运维（预上线环境、生产环境）
    • 代码交付（CD：Continunous Delivery）
    • 代码部署（CD：Continunous Deployment）
    • 服务维护
    • 故障解决
    • 技术支持
    • 自动化运维
  • 消亡（destroy）

file

file

什么是环境

  • 开发环境
  • 测试环境
    • 功能测试环境
    • 性能测试环境
  • 预生产环境(beta)
  • 生产环境

数据是否要保持一致?

什么是代码部署

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

其实我们很早就接触过。

比如：

  • nginx
  • 下载安装包（开发写好的代码）
  • 构建代码
  • 生成配置
  • 编译安装
  • 修改配置
  • 启动程序
  • MySQL
  • wordpress

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

那么在企业中也是一样的，比如开发写好的代码，需要用到nginx，那就要安装nginx，此时的nginx对于代码来说就是一个为了能够成功运行代码的中间件，需要MySQL，那么也是一样。

就好比，安装nginx，要先安装很多依赖，openssl-devel、zlib-devel、pcre-devel

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

代码的发布方式

手动发布

手动发布，我就不过多说了，咱们以前用的，全都是手动(手动操作很容易误操作)

自动发布

应用程序升级面临最大挑战是新旧业务切换，将软件从测试的最后阶段带到生产环境，同时要保证系统不间断提供服务。
长期以来，业务升级渐渐形成了几个发布策略：蓝绿发布、金丝雀发布和滚动发布，目的是尽可能避免因发布导致的流量丢失或服务不可用问题。

1.蓝绿发布
2.金丝雀发布(灰度发布)
3.滚动发布

在互联网中,这类的专业名词太多了,还有红黑部署、AB测试等..感兴趣的自行百度

蓝绿发布

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

file

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

file

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

特点：

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

缺点：

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

蓝绿发布在早期物理服务器时代，还是比较昂贵的，由于云计算普及，成本也大大降低。

金丝雀发布(灰度发布)

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

file

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

特点：

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

缺点：

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

滚动发布

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

file

红色：正在更新的实例 蓝色：更新完成并加入集群的实例 绿色：正在运行的实例

特点：

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

缺点：

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

山林不向四季起誓 荣枯随缘