跳到主要内容

DevOps理论与基础

DevOps理论与基础​

image-20230319085806123

目录​

[toc]

1、什么是DevOps​

image-20240519053555526

image-20240519053641506

1.Dev和Ops之间的孤岛​

image-20230318164112934

为什么会存在孤岛？ 我来给大家简单的描述一下。这个这种情况可能出现的也比较多。如图所示左边是开发团队， 右边是我们的运维团队。

举个例子： 现在我们有一套应用的生产环境（PROD 生产环境），以开发同学的角度来说“提交代码想要快速更新的生产环境” 而以运维同学的角度来说“不希望频繁的更新，更希望环境的稳定”。这时候就会产生沟通和协作类的问题。

形成了中间的一堵墙，怎么来打破这个墙？ 通过DevOps解决Dev开发团队与Ops运维团队之间的沟通和协作问题。

2.DevOps指的是什么​

DevOps最重要的一点就是要提高研发效能！

image-20230318165258464

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

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

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

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

image-20230318165506111

  • DevOps提倡的是：文化+工具相互结合；
  • DevOps = 软件开发人员（Dev）和 IT运维人员（Ops）的组合词；
  • DevOps是促进软件开发人员与IT运维人员之间的沟通和协作；

DevOps不仅仅是工具，也不仅仅是自动化而是文化与工具的相互结合。 （如果想了解更多DevOps文化相关的知识可以网上找下或者买本书**==《DevOps实践指南》 《持续交付》==**）

在企业中去实施DevOps， 工具是底层的技术，更多的是先了解软件开发团队之间的一些协作的过程，找出协作相关的问题进行实施改进。自动化流程改进涉及到很多工具链的集成技术。

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

image-20230318165358624

3.传统的应用发布模式​

我们开发过程中一般经常会遇到以下环境：

简单的来说就是：

pro环境：生产环境，面向外部用户的环境，连接上互联网即可访问的正式环境。

uat环境：验收测试环境，主要面向要交付的人员进行验证测试。

pre环境：灰度环境，外部用户可以访问，但是服务器配置相对低，其它和生产一样。

test环境：测试环境，外部用户无法访问，专门给测试人员使用的，版本相对稳定。

dev环境：开发环境，外部用户无法访问，开发人员使用，版本变动很大

img

image-20230318173614018

然后我们来了解一下， 传统的这个应用发布模式。 更有助于理解DevOps解决的核心问题。

  1. DEV编写代码，本地测试后提交到版本控制系统；
  2. 开发同学通知运维同学应用发布；
  3. OPS下载代码，编译生成可部署的制品并部署测试环境；
  4. TEST开始功能等测试，发现问题提交给DEV, 无问题继续部署；
  5. OPS部署预发布环境、生产环境；

GitLab作为我们的版本控制系统，存储相关的项目开发代码。 开发人员写完代码会Push到版本控制系统并通知运维同学进行部署。

运维同学会Pull下载代码并通过一些构建工具进行Build阶段生成Artifact制品。如果Artifact制品生成失败，定位错误原因如果是代码问题需要开发同学Review和Check。 Artifact制品打包成功后通过scp等工具发布到应用环境服务器，然后通过脚本启动运行服务。

最后交给测试同学进行测试验证（发现功能性问题提Bug给开发，环境不稳定问题提Bug给运维同学）。

问题:

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

4.存在的已知问题​

image-20230318174039446

传统的发布模式存在的一些问题： 这都是人工手动操作的。 手动进行一些这个更新和发布的一些操作，极容易出现一些错误。流程太依赖于手动操作了。

DevOps第一件事情就是将人工手动重复操作的事情都进行自动化实现。将Build、Deploy、Test阶段进行结合，对流程可视化有助于发现问题。

5.Devops误区​

6.DevOps职责​

7.传统DevOps vs 云原生DevOps​

8.一个完整的Devops体系​

  • 基础架构自动化

现在的coreOS被redhat收购了。

  • 应用生命周期管理

CI工具：(gitlabCI,github-action) Prow是kubernetes官方使用的工具！ Kaniko在云原生平台做镜像打包的工具；

  • 监控体系-四个黄金指标

  • 服务可观测性

  • 告警

  • 4个关键指标

2、持续集成与持续部署​

image-20230318175403117

上一章节我们说了是“DevOps核心=CI/CD自动化”。 主要是因为这些传统的发布模式所带来的一些问题，导致我们不得不做一些自动化。

代码是写死的，失败就是失败，成功就是成功。排查失败原因并不断的优化最后形成稳定的工作流程。人工手动操作可能会出现随着时间的增长，某些集群未同步导致应用启动等问题发生。

只有掌握了DevOps的一些方法论的相关知识，你才能够通过这些技术工具等一些手段来实现它的效能的提升。

核心还是价值流和效能提升。

  • 一家软件公司

image-20230318180737933

  • 软件开发过程

image-20230318180814788

1.持续集成（CI）​

image-20230318175429658

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

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

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

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

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

持续集成主要指的是开发人员的一些操作， 为什么会出现持续集成？ 有些开发人员并不会将每次开发完成的特性代码提交到版本控制系统， 发布时才会对代码进行集成导致出现代码冲突和编译等相关的问题。

持续集成提倡的是开发同学以小的特性为单位，每完成相关特性就更新同步到版本控制系统。 并进行一些测试和验证（例如：此时配置一套提交构建流水线，对提交的代码进行编译构建和代码扫描，发现问题邮件通知提交人）

持续集成的目标不是每次提交就进行构建，按照实际项目的情况选择定时构建或者自动触发。例如开发人员提交代码后晚上11点进行定时构建，第二天上班可以及时看到项目的集成测试情况。

2.持续部署（CD）​

image-20230318175919360

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

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

持续集成的流程完成后会有一个构建阶段，此阶段会输出一个包，即我们的应用程序。接下来开始去部署。

回顾传统的发布模式，运维同学通过scp手动的将包发布到服务器上面， 而如果要做自动化就要通过脚本或者自动化部署工具完成。

持续部署在持续集成阶段后面， 主要是通过自动化的方式将应用部署到各个环境中。 此时注意一个“无序交付”的问题。不应该变更后直接自动部署到生产环境，这样会造成错误的代码发布的生产环境造成风险。而是增加一个审批限制（卡点），通过审批后再进行生产环境的发布。

3.CI/CD的好处​

image-20230318180114546

CI流程

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

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

CD流程

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

做了CI/CD之后有哪些好处呢

CI体现的就是更快的反馈， 有些问题的时候可以快速的反馈给开发人员。谁提的代码然后构建出问题了给他发个邮件、钉钉、企业微信通知。快速的反馈、尽快的发现问题，避免代码集成的冲突。 这是CI流程解决的一个问题

CD可以降低发布风险，自动化工具要比人工发布更可靠一些，出错的情况更少一些。 持续部署可以更快的获得用户的反馈。

4.CI/CD阶段组成​

image-20230318180247327

提交阶段主要是对开发人员提交的代码进行检查，代码扫描；

构建阶段是通过构建工具进行打包生成制品的过程；

测试阶段主要对已发布到环境的应用进行自动化的测试；

生产发布是最后一个阶段，当测试没问题后进行生产版本的发布。

3、DevOps的演进​

==AiOps,NoOps==

1.DevSecOps​

image-20230318200937433

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

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

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

  • 合规性检查;

Sec指的是安全实践，每个公司里面都是有安全团队的。 我们之前做的一些实践，就比如说我们上面做的这个CI/CD管道。可以在管道中添加一些安全工具和流程。（安全是个单独的领域，如果感兴趣也可以进行学习和实践）

  • 悬镜安全

image-20230318201112816

image-20230318201126757

image-20230318201138589

2.GitOps​

image-20230318201700576

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

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

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

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

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

GitOps，Git与代码有关，即将基础设施以代码的方式声明并存储到Git版本控制系统中。GitOps强调的是基础设施即代码。

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

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

Pipeline as Code指的是以代码的方式描述Jenkins Pipeline。 而基础设施即代码指的是以代码的方式描述所使用的基础设施资源， 例如服务器，负载均衡器等等。

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

image-20230318203528907

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

3.ChatOps​

image-20230318201417817

image-20230318201454320

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

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

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

ChatOps， 大家应该都用过钉钉机器人来消息通知和协作。 以聊天的方式发送指令由机器人自动化处理。

  • ChatOps-MatterMost/钉钉

image-20230318201606927

image-20220411145305253

4、企业中实施DevOps​

1.企业中实施DevOps​

image-20230318205724067

那在企业里面怎么推起来，其实在企业里面去实施DevOps，除了技术上的一些问题，还有很多因素去决定的。

  1. 技术方面准备： 提供稳定的工具链
  2. 实施方面准备： 收集项目开发信息，制定统一的规范。
  3. 培训推广DevOps

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

2.DevOps项目信息收集​

  1. 版本管理（代码库管理规范、分支开发模式、配置文件管理）
  2. 构建管理（构建工具脚本、构建节点管理、构建方式自动|定时）
  3. 质量管理（单元测试、接口测试、UI测试、代码质量规则与规范） （系统负载测试(压测)-并发量）（自动化测试）
  4. 制品管理（制品存储、镜像源、版本号定义、制品复用）
  5. 发布管理（自动化发布、发布策略、发布环境一致性）

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

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

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

代码库管理规范：

2种方式：

  1. 一个服务，一个代码库（代码库的管理方式上肯定是有一些区别的：要维护很多个代码库；流水线这一块儿也挺复杂的，要去下载多个库；）
  2. 多个服务放一个代码库。 （冲突问题；多人开发问题；）

分支开发模式：

主、干分支 特性分支

3.DevOps工具链​

  1. 需求管理 Jira （禅道）
  2. 代码管理 GitLab-CE
  3. 持续集成 Jenkins、GitLabCI/CD 、Maven、Gradle
  4. 制品管理 Nexus3、Harbor （Kaniko：在云原生平台做镜像打包的工具；）
  5. 环境管理 Terraform
  6. 持续部署 Ansible、Helm、ArgoCD

jacoco是什么？

Tekton是什么？

gitlab：一体化的平台

学习devops最好的方式，看devops的厂商，例如云原生监控，制品库厂商。

企业里用的最多的还是Jenkins，Gitlab-ci做ci还是可以的，做CD还是有一点点不方便的； 大型公司用的也是Jenkins；

Devops平台化（基于工具链开发一个UI） 学一些开发技巧对这个Devops平台进行扩展；

ci工具：

  • jenkins：它有一个单独的系统（jenkins使用shell和grooy来写，稍微有些难度）
  • GitLabCI：它是GitALab里面的一个功能模块。（GitlabCI全部使用shell来写）

需求管理 Jira

image-20230312164833100

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

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

4.实施DevOps应避免的问题​

image-20230319082511032

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

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

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

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

5.常见的Devops平台​

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

6.企业实践​

Pipeline + Groovy YYDS!​

Jenkins2.0核心特性：Pipeline As Code，以代码的方式描述流水线作业。特别适合大规模下的流水线复用，即多条流水线使用相同一套流水线模板。

训练营中最重要的一部分就是Jenkins PIpeline As Code，是最核心的内容。 Pipeline + Groovy YYDS!

Groovy这门语言其实与Python编程语言语法上很类似。

最基本的一个流水线​

围绕着Gitlab做持续集成流水线，用Jenkins来集成Gitlab来实现提交流水线。--这个也是最基本的一个流水线。

问题：流水线触发一般是如何来触发？​

image-20230312160207480

回答：

其实这2种方式，都是我们经常用到的2种方式。

  1. 配置成提交即构建方式；

  2. 手动触发，例如发布到生产环境，中间需要有个审批（卡点）流程；

范例：跨国之间devops​

环境：

日本：跑灰度的

台湾：生产环境

日本跑完灰度，没问题后，想直接用这个镜像来发布到台湾的生产环境中去；

之前是2个job；

用ansible来发布的；

harbor镜像仓库；

image-20230319094300767

回答：

1.把yaml模板通过版本管理起来； Jenkins调api从git上去拿；

image-20230319094523521

2.或者镜像单独存git里，生成一个文件，总之要有一个状态 Jenkins调api从git上去拿；

延迟很大 2套jenkins库。

Harbor搭个主从，让异地自己去同步。（harbor是有这种策略的）

生产环境的灰度。

网关才是最可怕的。

如果两边合成一个集群的话，一定要考虑etcd一致性问题，时延一旦大，etcd必定出问题，集群必崩。

用istio的东西流量去做灰度，这个会更方便一点。

FAQ​

devops图片​

image-20230614222144712

image-20230627170240865

gitops架构​

  • 例子

  • 2023年12月2日

ci-cd流程图

  • 2023年8月2日

image-20230802093920670

  • 例子

62459c22c9d36e360a319de626e8f96

  • 例子：一个完整的Devops体系

关于我​

我的博客主旨：

  • 排版美观，语言精炼；
  • 文档即手册，步骤明细，拒绝埋坑，提供源码；
  • 本人实战文档都是亲测成功的，各位小伙伴在实际操作过程中如有什么疑问，可随时联系本人帮您解决问题，让我们一起进步！

🍀 微信二维码 x2675263825 （舍得）， qq：2675263825。

image-20230107215114763

🍀 微信公众号 《云原生架构师实战》

image-20230107215126971

🍀 语雀

https://www.yuque.com/xyy-onlyone

image-20230306221144511

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

image-20230107215149885

🍀 知乎 https://www.zhihu.com/people/foryouone

image-20230107215203185

最后​

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

image-20220415235843683

0%