Devops理论与基础

目录

1、什么是DevOps

• DevOps是一种思维方式，同时也是一组工作实践。

• 成功的DevOps是将人、过程和工具相互融合。

• DevOps并不是简单的理解为自动化工具。

• DevOps 一词是由“开发”和“运营”这两个词组合而成的，是一种文化转变，在开发团队与运维团队架起了桥梁（一般开发团队与运维团队形成孤岛、隐形的墙）。

Devops基础

DevOps方法论是我们在进行DevOps实践时必须掌握的原则类知识。

2、什么是CI、CD？

1.一家软件公司

2.软件开发过程

3.传统应用发布模式

传统应用发布模式

目的： 找到传统发布存在的问题，如何改进。

一般一个开发团队中都会存在多个角色：开发、测试、运维。当时我们的应用发布模式可以能是这样的：

• 开发同学进行项目代码开发，本地运行测试成功后将代码上传到版本控制系统。
• 开发同学通知运维同学项目可以发布了，然后运维同学下载代码进行打包和构建，生成应用制品。
• 运维同学使用部署脚本将生成的制品部署到测试环境，并提示测试同学可以进行产品的测试。
• 测试同学开始进行手动、自动化测试，测试完成后提醒运维同学可以进行预生产环境部署。
• 运维同学开始进行预生产环境部署，然后测试同学进行测试，测试完成后，开始部署生产环境。

问题:

手动操作很多、出现的问题很多。上面看似很流畅的过程，其实每次构建或发布都可能会出现问题。未对每次提交验证、构建环境不一致：开发人员本地测试成功后提交代码，运维同学下载代码进行编译却出现了错误。

4.持续集成(CI)

• 开发人员频繁(—天内多次）合并和提交代码到分支。

• Cl是合并开发人员正在开发编写的所有代码的一种做法。

• 目标:在初始阶段检测到任何集成错误,以便可以迅速修复。

• 理想状态:每次提交代码会触发持续集成流程和反馈。

注意：以前有个争议？有必要每次提交代码都要触发持续集成流程和反馈吗？ -->推荐：一组代码提交！

5.持续部署(CD)

• 在CI的基础上自动化的将软件部署到各种环境中;

• 理想状态:每次变更自动部署到生产环境;(CI和CD是一条流水线)

6.CI/CD带来的好处

CI流程

• 更快的反馈有助于检查代码的质量问题;

• 尽快的发现问题,避免代码集成冲突;

CD流程

• 降低发布风险;
• 更加频繁的交付价值;
• 更快速的获得用户的反馈;

7.CI/CD管道的阶段

某条流水线并不是都适合每个公司团队的：
首先，要标准化他们的开发方式，开发模式。
然后，你再去设计这个流水线。

CI/CD常见的问题

CI遇到的问题比较多；
走出这个误区：有时候jenkins报错并不一定是jenkins本身有问题，有可能是研发的代码有问题。之前有个案例，研发本地代码编译没问题，但用jenkins打包出现了问题！最后排查后发现是研发本地有缓存，但生产环境里没缓存导致的！
CD遇到最多的一个问题就是环境不一致的问题：例如环境的配置不一致，最终导致我们的部署失败；

构建阶段：
maven、go 构建(单元测试) --》
jar包–>配置中心：nexus
docker镜像–>镜像仓库：harbor
仓库，配置中心：nexus 3制品库， （nacos，阿波罗， eurak）
制品库就是为了解决重复编译的问题。
制品类型： 制品（jar包 war包 二进制程序 ）

测试阶段：
手动测试
自动化测试：写测试用例，接口测试；
//其实这种单元测试写起来还是非常费时间的；单元测试的代码基本都是重复的，都是可以直接去用；性能测试；压力测试；
//压力测试：可能要熬夜哈哈。想用jenkins去解决这个问题，比如说定时，晚上自动去压。当时试了一下，还是可以的，但是还是有人要在限去值守的；
全链路测试；
基础测试:代码质量，你的项目能不能编译成功，单元测试用例能不能都跑过？
会扫描他们的代码：都是把这些工具集成到流水线里面。
有没有硬编码，有没有一些违规的东西；
harbor自己就有一个容器镜像扫描；

3、DevSecOps

• DevSecOps将安全工具和流程嵌入到DevOps工作流程中，并自动执行核心安全任务。

• 代码分析，识别安全漏洞;

• 变更分析，确定变更的影响;

• 合规性检查;

悬镜安全

4、ChatOps

ChatOps
	钉钉机器人
	飞书机器人
	企业微信
	TEAMS
	消息通知机器人/交互式机器人  需要自己去开发一个机器人！

• ChatOps是一种现代工作方式，它将人员，工具和聊天结合在一起，以提高生产力并帮助企业更快地发展。

• ChatOps奖励组织提高效率，自动化和创新的能力，更高的可靠性，更快的事件响应时间。

ChatOps-MasterMost/钉钉

5、GitOps

• 借助GitOps，团队可以自动化基础架构的配置过程。

• 使用声明文件将基础架构编写为代码 (laC) 。

• 存储在Git存储库中，就像存储应用程序开发代码一样。

• 编写Terraform配置文件创建VM/K8s集群;

• 编写Yaml配置文件部署K8s应用;

GitOps的火热程度基本上是要超过devops了；
GitOps更偏向于底层的基础架构。


1.vm
2.非vm：k8s环境
				1.k8s基础环境：tf写一个模板，我就可以调用云厂商的api，来创建一套k8s环境。--这个是收费的！
				2.k8s上层的应用：
						yaml文件也存到git上去，然后我们发布的时候在git里面修改yaml的配置就好。
						所以：git里面存了一个是基础架构的代码，一个是k8s环境里应用配置代码；

Gitops一种云原生的持续交付模型

• 提高生产力:采用集成了反馈控制循环的持续部署流水线可以大大提升新功能的发布速度。
• 提升开发者体验:开发者可以使用熟悉的工具Git去发布新功能,而无需了解复杂的部署交付流程。新入职的员工可以在几天内快速上手,从而提高工作效率。
• **行为可审计:**使用Git 工作流管理集群,天然能够获得所有变更的审计日志,满足合规性需求,提升系统的安全与稳定性。
• 更高的可靠性:借助Git的还原( revert)、分叉( fork )功能,可以实现稳定且可重现的回滚。由于整个系统的描述都存放在Git中,我们有了唯一的真实来源,这能大大缩短集群完全崩溃后的恢复时间。
• 一致性和标准化 :由于GitOps为基础设置、应用程序、Kubernetes 插件的部署变更提供了统一的模型,因此我们可以在整个组织中实现一致的端到端工作流。

6、实施DevOps应避免的问题

• 避免无序交付:手动确认仍然至关重要。避免将代码直接推送到生产中时用户可能会遇到的错误。

• 对DevOps误解:认为DevOps工程师的目标是解决与DevOps相关的所有问题。

• 速度胜于质量:急于在较短的时间内完成并完成尽可能多的DevOps项目，以保持其在竞争激烈的市场中的地位。

• 组建一支专门的DevOps团队:最好由QA,OPS和DEV的新团队成员和现有员工组成。

7、常见的Devops平台

企业，商业化的软件，例如云霄，蓝鲸。
大型公司：商业付费软件
小型公司：开源软件

8、DevOps工具选择

ci工具：

• jenkins：它有一个单独的系统 （优先学习这个）（jenkins使用shell和grooy来写，稍微有些难度）

• GitLabCI：它是GitALab里面的一个功能模块。（GitlabCI全部使用shell来写）

• tekton + argocd

⚠️ 问题：这些ci工具，如何才能无缝迁移？

我们可以写个python脚本去做发布流程，python–>jenkins(.sh),gitlab-ci(script) 你可以把jenkins、gitlab-ci等都可以当做成一个流程工具，具体的代码实现，你可以自己去写。

关于我

我的博客主旨：我希望每一个人拿着我的博客都可以做出实验现象，先把实验做出来，然后再结合理论知识更深层次去理解技术点，这样学习起来才有乐趣和动力。并且，我的博客内容步骤是很完整的，也分享源码和实验用到的软件，希望能和大家一起共同进步！

各位小伙伴在实际操作过程中如有什么疑问，可随时联系本人免费帮您解决问题：

1. 个人微信二维码：x2675263825 （舍得）， qq：2675263825。

   

2. 个人微信公众号：云原生架构师实战

   

3. 个人博客地址：www.onlyonexl.cn

   

4. 个人csdn

   https://blog.csdn.net/weixin_39246554?spm=1010.2135.3001.5421

   

5. 个人已开源干货

   名称	链接
   常见云笔记优缺点 & 定制宇宙中最美的typora皮肤 & 玩转vscode(已开源)	https://www.jianguoyun.com/p/DXS6qiIQvPWVCRiS0qoE

最后

好了，关于Devops理论与基础就到这里了，感谢大家阅读，最后贴上我女神的photo，祝大家生活快乐，每天都过的有意义哦，我们下期见！