devops

自动化运维体系CICD

dev：开发		开发 development
ops：运维  	运维 operations

devops的介绍

image-20240724140343237

# 开发
根据需求 写代码
开发：创新 有变化 bug
为了优化 不断的改进
开发改完10次 上线10次
# 运维
将开发写好的代码 部署到环境
维护 7x24
追求服务稳定 用户能够正常访问 没有问题出现

devops的理念

image-20240724140500391

devops主要是为了做CICD
cicd 开发开始写好了代码 流水线的工作 自动上线
# CICD的作用
持续集成 开发写代码的时候
持续交付 写完代码交付给测试，测试完了没问题交给运维
持续部署 将测试号的代码放到生产环境
开发把代码放入gitlab里 代码仓库
开发在提交代码的那一刻 代码就会自动的从仓库部署到环境中区
代码质检 质检完毕部署到生产环境
jenkins拉取仓库中的代码，将代码部署到生产环境
shell脚本
CICD 减轻开发的压力 测试的压力 运维压力

image-20240724140536756

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

image-20240724140738953

什么是环境？

开发环境
测试环境
	功能测试环境
	性能测试环境
预生产环境（beta）
生产环境
数据是否要保持一致？

什么是代码部署？

简单的一句话：就是将开发写好的代码，通过一系列的手段，让它能够成功运行在我们的环境中。
其实我们很早就接触过。
比如：
- nginx
- 下载安装包（开发写好的代码）
- 构建代码
- 生成配置
- 编译安装
- 修改配置
- 启动程序
- MySQL
- wordpress
只不过不同的代码需要不同的环境。
那么在企业中也是一样的，比如开发写好的代码，需要用到nginx，那就要安装nginx，此时的nginx对
于代码来说就是一个为了能够成功运行代码的中间件，需要MySQL，那么也是一样。
就好比，安装nginx，要先安装很多依赖， openssl-devel 、 zlib-devel 、 pcre-devel
曾老湿精髓名言：或许有些人绕不过来，当你成为架构师之后，一切皆为中间件，所有的应用，只是为
了给我的代码提供一个运行环境而已，那些所谓的应用，都只是我代码的一个小小的依赖而已，或许我
需要有个地方存储我的数据，那么作为开发人员，我可以任意选择地方，比如：文件中，world，execl
都可以，但是为了产品的性能，安全，使我不得不选择一个当下热门的数据库，再或许，我的代码需要
一个web环境，那么我可以自己用前端写一个web环境，然后把我的页面放进去，但是当下也有了很热
门web程序，我们为什么不使用呢？

代码的发布方式

手动发布
	手动发布，我就不过多说了，咱们以前用的， 全都是手动（手动操作很容易误操作）
自动发布
	应用程序升级面临最大挑战是新旧业务切换，将软件从测试的最后阶段带到生产环境，同时要保证系统不间断提供服务。长期以来，业务升级渐渐形成了几个发布策略：蓝绿发布、金丝雀发布和滚动发布，目的是尽可能避免因发布导致的流量丢失或服务不可用问题。
蓝绿发布
金丝雀发布（灰度发布）
滚动发布
在互联网中，这类的专业名词太多了，还有红黑部署、AB测试等...感兴趣的自行百度
蓝绿发布
项目逻辑上分为AB组，在项目系统时，首先把A组从负载均衡中摘除，进行新版本的部署。B组仍然继续提供服务。
当A组升级完毕，负载均衡重新接入A组，再把B组从负载列表中摘除，进行新版本的部署。A组重新提供服务。
最后，B组也升级完成，负载均衡重新接入B组，此时，AB组版本都已经升级完成，并且都对外提供服务。
# 特点：发布策略简单；用户无感知，平滑过渡；升级/回滚速度快。
# 缺点：需要准备正常业务使用资源的两倍以上服务器，防止升级期间单组无法承载业务突发；短时间内浪费一定资源成本；基础设施无改动，增大升级稳定性

image-20240724141144059

image-20240724141207753

image-20240724141222480

灰度发布（金丝雀发布）
灰度发布只升级部分服务，即让一部分用户继续用老版本，一部分用户开始用新版本，如果用户对新版本没什么意见，那么逐步扩大范围，把所有用户都迁移到新版本上面来。
特点
保证整体系统稳定性，在初始灰度的时候就可以发现、调整问题，影响范围可控；
新功能逐步评估性能，稳定性和健康状况，如果出问题影响范围很小，相对用户体验也少；
用户无感知，平滑过渡。

缺点
自动化要求高

image-20240724141459250

滚动发布
滚动发布是指每次只升级一个或多个服务，升级完成后加入生产环境，不断执行这个过程，直到集群中的全部旧版本升级新版本。 
特点
用户无感知，平滑过渡；
节约资源。

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

image-20240724141602537

发布方式总结
综上所述，三种方式均可以做到平滑式升级，在升级过程中服务仍然保持服务的连续性，升级对外界是无感知的。那生产上选择哪种部署方法最合适呢？这取决于哪种方法最适合你的业务和技术需求。如果你们运维自动化能力储备不够，肯定是越简单越好，建议蓝绿发布，如果业务对用户依赖很强，建议灰度发布。如果是K8S平台，滚动更新是现成的方案，建议先直接使用。

蓝绿发布：两套环境交替升级，旧版本保留一定时间便于回滚。

灰度发布：根据比例将老版本升级，例如80%用户访问是老版本，20%用户访问是新版本。

滚动发布：按批次停止老版本实例，启动新版本实例。