代码视角深入浅出理解 DevOps | 原力计划

国内新闻 阅读(791)

Author | Yitian Coder

Editor | Tang

Headline | Download from Oriental IC

Production | CSDN博客

关于DevOps的理解各不相同,甚至维基百科也没有给出统一的定义。一般的解释是字面上的,即集成开发和运营,以加速和自动化从启动到在线的过程。这是对德文的广义解释,大多数人都同意。然而,这种解释过于宽泛,几乎包含了信息技术的所有内容,因此毫无意义。DevOps是近几年才出现的(2014年开始流行),是对某个项目模式的描述,有其特定的内涵。任何项目都可以分为两个部分:开发、运营和维护。开发的整个过程和工具早在开发之前就已经存在,并且没有改变。“DevOps”真正改变的是运营。因此,只有从运行维护的角度来理解DevOps,才能把握其本质。通过发展,你可以把它理解为“作为发展的行动”,这是狭义的发展。开发的方式是编写代码,换句话说,DevOps就是为操作和维护编写代码。

操作和维护中一个非常流行的概念叫做“IAC(基础设施)”基础设施,即代码,它以代码的形式描述运行环境的创建,并通过运行代码来创建环境。这是操作和维护领域的一场革命,创造了现代操作和维护技术,也是DevOps的基石。然而,基础设施的创建只是运营和维护的一部分。如果我们继续将这场革命扩展到操作和维护的所有领域,并让代码覆盖整个操作和维护,那么代码就是作为代码的操作,这就是DevOps的本质。

那么从应用项目的角度来看,什么是DevOps呢?它是把应用程序代码和操作维护代码放入一个源程序库中,并对其进行版本管理,这样你就有了关于项目的所有信息,你可以随时部署程序(包括程序本身和它的运行环境),并且你可以保证每次创建的程序的运行结果是相同的(因为它的运行环境是相同的)。

作为代码的操作)

让我们一个接一个地拆分操作,看看它们是如何用代码实现的。

运行和维护工作通常包括以下几个方面:

基础设施:即程序运行环境的创建和维护。

连续部署:部署应用程序并自动化整个过程。

service的健壮性:是指当服务的运行环境出现问题时,如网络故障、服务过载或某些微服务停机,程序仍能提供部分或大部分服务。

操作监控:它包括对程序和操作环境的监控。

基础设施即代码)

让我们以一个Go(其他语言相同)微服务程序为例,展示如何使用代码创建基础设施。程序本身的功能非常简单,只需使用SQL语句来访问数据库中的数据并将其写入日志。您可以简单地将其分为两层,后端数据访问层和数据库层。程序的部署环境是基于k8s的容器环境。在k8s中,它分为两种服务。一个是后端程序服务,另一个是数据库(MySQL)服务。后端程序调用数据库服务,然后将一些数据写入日志。

在这种新模式下,运行环境的代码和应用程序的代码存在于一个源代码库中,所以当你下载源代码库时,你不仅拥有程序的所有源代码,还拥有运行环境的源代码。这样,当要创建一个新的运行环境时,一套完整的运行环境只能通过运行一次代码来创建,并且每次创建的环境都是一致的。

以上是这个围棋程序的目录结构。其中有一个目录“脚本”,用于存储与运行环境相关的文件。其中的“kuburnetes”子目录是整个运行环境的代码。除了“脚本”之外的其他目录包含应用程序代码。这样,与该应用程序相关的信息以代码的形式存储在源代码库中。有了它,您可以在任何时候部署相同的程序操作环境,并且它保证是相同的。

在“kubernetes”目录下有两个子目录“后端”和“数据库”,分别存储后端程序和数据库的配置文件。它们的内部结构相似。它们都有三个“yaml”文件:

back-deployment . YAML:deployment profile

back-service . YAML:service profile

back-volume . YAML:persistent volume profile

and other。sh "文件是其运行命令。当您运行这个外壳文件时,它调用上面的三个k8s配置文件来创建运行环境。

kubernetes目录的最外层有两个“yaml”文件“k8sdemo-config.yaml”和“k8sdemo-secret.yaml”,它们用于创建k8s运行时环境参数,因为它们由不同的服务共享,因此位于最外层。另一个“k8sdemo.sh”文件是k8s命令文件,用于创建k8s对象。

这种源程序结构的好处之一是可以更好地集成应用程序及其运行环境。例如,当您想要修改服务的端口时,您习惯于在操作环境和源代码中分别修改它,但是它是由开发和操作分别完成的,这很容易导致修改不同步。当您将它们放在同一个源代码库中时,您只需要修改一个地方,从而确保应用程序和运行环境的一致性。

以下是后端服务的k8s配置代码:

API Version : V1

Kind 3360 ServiCe

Metadata :

NAME : K8SDEMO-BACKED-ServiCe

LABELS :

APP : K8SDEMO-BA ckend

spec :

type : NodePort

selector :

APP : K8SDEMO-BA ckend

Ports :

-协议3:如有兴趣,请参阅如何将应用程序迁移到k8s[1]。

基础结构可以分为两个级别,一个是上面提到的k8s级别,即容器级别,它与应用程序密切相关。另一层是容器下的支持层,即虚拟机层。当然,它还包括网络、负载平衡和其他设备或软件。在阿里云或华为云上创建k8之前,您需要构建它们。它也可以在代码中部署。Terraform是一个非常流行的创建虚拟机的工具。它是由思想工程公司推荐的(见思想工程技术雷达第20卷[2号])。它支持用代码创建虚拟机。

代码如下:

resource ' ' AWS _ instance ' ' ' example ' ' {

count=10

AMI=' ' AMI-v1 ' '

instance _ type=' T2 . micro ' '

部署应用程序是操作和维护中的一项重要工作。随着商业竞争的加剧,需要更快的程序更新,从几周一次到一天十几次甚至几十次。这样,手动部署完全不能满足需求,所以整个过程必须自动化,这就是连续部署。

但在此级别,基础结构的工作与应用程序的关系不是很密切,因此这部分代码没有放在应用程序中。您可以单独创建基础结构的源代码项目来存储这部分代码。

Continuous Deployment)

部署应用程序是操作和维护中的一项重要工作。随着商业竞争的加剧,需要更快的程序更新,从几周一次到一天十几次甚至几十次。这样,手动部署完全不能满足需求,所以整个过程必须自动化,这就是连续部署。

管道是一个非常重要的概念,用于描述连续部署的整个步骤和过程。Jenkins是一个非常流行的持续集成和部署工具,它提出了“管道即代码”(参见管道[3)。它将持续部署的管道作为程序源代码的一部分,并与应用程序一起管理它,以便它具有与应用程序相同的版本和审查过程。

让我们举一个具体的例子来说明他是如何做到的。此示例使用与上面相同的过程。让我们先看看程序的目录结构。

与持续部署相关的文件都在“脚本”目录中。他分为两个部分,一个是“cd”子目录,存储詹金斯的管道,另一个是“Kubernetes”下的“jenkins”子目录,存储Jenkinsde k8s配置文件。如果你仔细看,你会发现其中的文件与前面提到的后端程序和数据库的k8s配置文件非常相似。有了它,你可以在k8s中创建詹金斯的运行环境。

这里我把Jenkins的k8s配置文件放在应用程序中,但实际上它应该在前面提到的基础设施项目的源代码中。因为詹金斯是由应用程序共享的,而不是单独的应用程序。这里,为了便于解释,把它放在一起。当它真正被使用时,它应该被提取。

这是管道的代码:

def POD _ LABEL='' k8 sdemopod-$ { uuid . random uuid . tostring } ' '

POD template(LABEL : POD _ LABEL,cloud:' kubernetes ',container :[

ContainerTemplate(name : ' modified-Jenkins ',image : ' jfeng 45/modified-Jenkins :1.0 ',ttyEnabled: true,command:BUILD _ NUMBER }“

def DockerDirectory=“$ { KubBackEnddirectory }/Docker/Dockerfile-k8sdemo-后端' '

container(' modified-Jenkins '){

withCredentials([[$ class : ' UserNamePasswordMubBinding ',

credentialsId: ' dockerhub ',

UserNameVariable: ' Docker _ HUB _ USER ',

PasswordVariable: ' DOCKER _ HUB _ PASSO ']){

sh

docker push $ { ImageName }

' ' ' '

该部分的功能包括以下几个部分:

该部分的功能包括以下几个部分:

该部分的功能包括以下几个部分:

stage(' Deploy '){

container(' modified-Jenkins '){

sh ' ' ku pectl apply-f $ { WORKSWAGE } $ { KubBackEnddirectory }/Back end-Deployment。YAML ' '

docker push $ { ImageName }

该部分的功能包括以下几个部分:

该部分的功能包括以下几个部分:

该部分的功能包括以下几个部分:

由于空间限制,这将不再详细解释。如果您感兴趣并想知道如何运行Jenkins来完成连续部署,请参考在容器上构建连续部署和最佳实践初步探索[4]。

我在这里使用了詹金斯软件,它还有一个子项目叫詹金斯-x,是专门为k8s环境设计的。它的主要功能是帮助您自动生成管道代码(您需要回答他的一些问题)。如果你不想写自己的代码,你可以试试。详情请见詹金斯-X[5]。

服务弹性代码)

也称为服务弹性。这部分不像前两部分那样有公认的名称。英语被称为“服务弹性”,它可以通过多种方式翻译成中文。我认为称之为服务弹性更合适。

“服务弹性”是指当服务的操作环境出现问题时,如网络故障或服务过载或一些微服务停机,程序仍能提供部分或大部分服务。现在,我们说这项服务非常有弹性。这是衡量服务质量的一个重要指标。

该部分的功能包括以下几个部分:

该部分的功能包括以下几个部分:

该部分的功能包括以下几个部分:

服务速率限制)

docker push $ { ImageName }

故障注入)

隔板)

该部分的功能包括以下几个部分:

该部分的功能包括以下几个部分:

该部分的功能包括以下几个部分:

该部分的功能包括以下几个部分:

请注意,这里的服务弹性功能完全是从业务逻辑中提取的,没有任何对业务逻辑的入侵。它在一个单独的中间件中实现。这是一个装饰图案。有关计划实施的详细信息,请参阅运行微服务容错和弹性[6]。

我上面说的是用程序来实现这些功能,但本质上,这些功能不应该属于应用程序,而应该由基础设施来完成。现在人们普遍认为服务网格是实现这些功能的最佳解决方案。使用服务网格的方式类似于k8s,它创建一个配置文件,然后通过运行配置文件为服务网格创建一个操作环境。我们用Istio作为例子来说明Istio是一个非常流行的服务网格软件。

上面的图片是下载的Istio软件的目录。“bookinfo”是一个示例程序。在这个例子中,它展示了许多使用Istio的方法,包括如何实现服务韧性。详情请见[研究所。

监视或可观察性)

监视是操作和维护的重要组成部分,通常包括以下几个方面:

logging):记录程序运行过程中的信息;

tracing):记录与请求相关的信息,尤其是与时间相关的请求信息。

metrics):不同于上面的离散信息。这里记录了可累积的信息,通常是根据时间轴累积的。

我们经常称之为可观察性的三大支柱。有一篇很好的文章解释了它们之间的关系。有关详细信息,请参见“度量、跟踪和日志记录之间的关系”。

这部分的内容可能有争议。因为前几个部分都是明确的操作和维护工作。即使服务是灵活的,尽管它以前是一项开发工作,但它一直被认为是一项操作和维护工作,并且它们的代码可以被干净地获取。然而,操作监控是不同的。虽然主要的工作还是由操作和维护来完成,但是它的代码与业务逻辑代码混合在一起,很难挑选清楚。

Log:

这部分代码在应用程序中,但是日志的收集、汇总、分析和显示是通过操作和维护来完成的。它的代表是着名的ELK系列。在DevOps被采用后,这里几乎没有什么变化。最多,收集代理与服务网格或k8s更好地集成,使它更容易。

分布式跟踪:

这部分有点像服务韧性。一开始,它是由程序完成的。慢慢地,它变成了一个独立的部分,从应用程序中分离出来。最后,大部分工作由服务网格完成。但这与服务韧性不同。服务弹性可以在应用程序中做出非常清晰的划分,而分布式跟踪取决于跟踪的粒度。如果它只是在服务之间进行跟踪,那么根本就没有问题,它可以完全由服务网格来完成。然而,如果它在服务中跟踪,服务网格什么也做不了,它应该像日志一样通过程序代码来完成。然而,我认为服务之间的跟踪具有最高的投入产出比。在大多数情况下,这就足够了,不需要对服务进行内部跟踪。

详情请参阅运行微服务全链接跟踪详情[9]。

Metrics:

观察的这一部分是积累的信息。在大多数情况下,只要安装了工具,就可以收集数据进行分析。最流行的工具是普罗米修斯。您不需要编写代码来获取数据,但是如果您想快速找到所需的信息,k8s配置仍然需要与Prometheus设置相匹配,所以您需要做一些详细的设计。详情请参考普罗米修斯和库本内特斯:监控您的应用[10]。

当然普罗米修斯不能直接满足你对更详细监控的需求。此时,您需要在应用程序中插入一些普罗米修斯监控代码来满足您的需求。

其他工作

还有其他操作和维护工作吗?

Continuous Integration)

许多人认为持续集成是DevOps的一个重要组成部分,因为他使用了一个宽泛的定义。从狭义上讲,DevOps只包括操作和维护的内容。持续集成和持续部署明显不同。持续集成是开发工作,而持续部署是操作和维护工作。下图显示了它们的差异。

Source:

如图所示,整个过程如下:

程序员从源代码管理下载源代码,编写程序,完成后将代码提交给源代码管理,连续集成工具从源代码管理下载源代码,编译源代码,然后提交给运行时。然后,连续交付工具从运行时下载代码,生成发布版本,并将其发布到不同的运行环境(如开发、质量保证、UAT、生产)。

在图中,左边部分是持续集成,主要与开发和程序员有关。正确的部分是持续部署,主要是测试和操作维护。连续交付也称为连续部署。如果它们被细分,仍然有一点区别。然而,我们在这里没有把它们分割得如此之细。它们统称为连续部署。

我没有把持续集成放入到DevOps中,因为本文使用了一个狭义的解释,也就是说,只包括操作和维护部分。

Conclusion

这篇文章从代码的角度解释了对DevOps的理解。DevOps的本质是为操作和维护编写代码。同时也给出了各部分操作和维护的具体例子,希望对想采用DevOps的朋友有所帮助。DevOps在开发和运营方面,尤其是在运营方面,已经发生了巨大的变化。

在不久的将来,将不会有开发、操作和维护。只有一项工作,那就是写代码。当然,它可以细分为开发代码农民和操作和维护代码农民。操作和维护工作通过编写代码来完成。应用程序不仅包括业务逻辑代码,还包括操作和维护代码,这些代码将同时存储在源代码库中。

完整源代码的GitHub链接:

K8SDemO:

grp service:

原始地址:

CSDN经作者授权发布。

索引:

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

?雷军谈小米10价格:不贵,交朋友;百度开源的第一个面具人脸检测模型;18.04.4 LTS发布|极客头条?沙迦美国大学科学研究副总裁赵薇:过去的生活| CPS传记记录揭示工业4.0的核心技术?蚂蚁金服AAAI发表的论文已经曝光。动态网络剪枝方法和无需预先训练的网络剪枝技术取得了重大突破。2.7亿学生在家上课,父母对…

?我是如何在6个月内从零编程经验变成数据科学家的?

?孟雁:疫情带来的暂停将为区块链和数字经济带来一个更基于大反弹的视频开放课程