DevOps理论与基础

最新推荐文章于 2024-11-02 08:45:09 发布

一念一生～one

最新推荐文章于 2024-11-02 08:45:09 发布

阅读量312

点赞数

文章标签： devops 运维数据库

本文链接：https://blog.csdn.net/weixin_39246554/article/details/129646662

版权

DevOps理论与基础

1、什么是DevOps

1.Dev和Ops之间的孤岛

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

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

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

2.DevOps指的是什么

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

DevOps是一种思维方式，同时也是一组工作实践。
成功的DevOps是将人、过程和工具相互融合。
DevOps并不是简单的理解为自动化工具。
DevOps 一词是由“开发”和“运营”这两个词组合而成的，是一种文化转变，在开发团队与运维团队架起了桥梁（一般开发团队与运维团队形成孤岛、隐形的墙）。

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

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

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

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

3.传统的应用发布模式

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

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

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

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

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

问题:

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

4.存在的已知问题

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

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、持续集成与持续部署

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

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

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

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

一家软件公司

软件开发过程

1.持续集成（CI）

开发人员频繁(—天内多次）合并和提交代码到分支。
Cl是合并开发人员正在开发编写的所有代码的一种做法。
目标:在初始阶段检测到任何集成错误,以便可以迅速修复。
理想状态:每次提交代码会触发持续集成流程和反馈。

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

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

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

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

2.持续部署（CD）

在CI的基础上自动化的将软件部署到各种环境中;
理想状态:每次变更自动部署到生产环境;(CI和CD是一条流水线)

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

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

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

3.CI/CD的好处

CI流程

更快的反馈有助于检查代码的质量问题;
尽快的发现问题,避免代码集成冲突;

CD流程

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

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

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

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

4.CI/CD阶段组成

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

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

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

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

3、DevOps的演进

1.DevSecOps

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

代码分析，识别安全漏洞;
变更分析，确定变更的影响;
合规性检查;

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

悬镜安全

2.ChatOps

ChatOps是一种现代工作方式，它将人员，工具和聊天结合在一起，以提高生产力并帮助企业更快地发展。
ChatOps奖励组织提高效率，自动化和创新的能力，更高的可靠性，更快的事件响应时间。

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

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

ChatOps-MatterMost/钉钉

3.GitOps

借助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一种云原生的持续交付模型

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

例子：

62459c22c9d36e360a319de626e8f96

例子：一个完整的Devops体系

4、企业中实施DevOps

1.企业中实施DevOps

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

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

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

2.DevOps项目信息收集

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

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

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

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

代码库管理规范：

2种方式：