【】如今,许多团队都在各种项目中争相使用着诸如:版本控制、代码审查、以及CI/CD管道等,与DevOps有关的优秀实践。不过,您是否注意到,这些方法主要针对的是软件开发生命周期中的自动化。而在涉及到基础架构的设置和部署时,项目团队仍然主要依赖的是手动的过程。
站在用户的角度思考问题,与客户深入沟通,找到那曲网站设计与那曲网站推广的解决方案,凭借多年的经验,让设计与互联网技术结合,创造个性化、用户体验好的作品,建站类型包括:网站制作、成都网站制作、企业官网、英文网站、手机端网站、网站推广、域名申请、虚拟空间、企业邮箱。业务覆盖那曲地区。
[[355786]]
对此,GitOps提供了一套管理基础架构的自动化方法。项目团队可以借助GitOps,并通过使用各种声明文件,将基础架构编写为代码(infrastructure as code,IaC),进而自动化配置的过程。也就是说,我们可以像存储应用程序的开发代码那样,将基础架构存储放在Git存储库中,以提高整体的交付能力和产品质量。
GitOps的工作原理
GitOps的概念最初是由Kubernetes管理公司--Weaveworks(请参见https://www.weave.works/)提出的。众所周知,基于容器的应用往往比较复杂,而且难以进行配置和管理。因此,GitOps主要针对的是:在Kubernetes背景下,如何将编排平台转换到运行在容器中的微服务上,并采用DevOps领域的成熟技术,来协助简化该过程。下面我们将深入讨论GitOps的各个主要组成部分:
基础架构即代码(IaC)
如前所述,IaC可以通过将各种声明性文件存储为代码,进而实现基础架构的配置和管理。据此,通过利用IaC和版本控制,项目团队可以优化当前的各项操作进程。此处提到的声明式(Declarative),意味着您的配置将不再是一组命令,而是对某种预期状态的声明。例如,在Kubernetes中,您可以在清单文件(manifest)中定义服务所需的Pod数量。系统将通过自行处理,获取所需的容器编号,而无需工程师额外编写命令脚本。
在此,任何符合声明性模型的云原生软件,都可以被视为代码。通常,我们会将各种所需的状态声明为代码,并通过系统应用的更改,以自动化的方式实现目标状态。例如:我们可以使用诸如AWS CloudFormation之类的声明性工具,来编写AWS的基础架构。
拉取请求(Pull Requests)
GitOps概念背后的主要思想是:版本控制系统是唯一的来源。我们既可以将Git用作应用代码的变更管理系统,通过拉取请求来实现各项操作性的变更,又可以将其用于基础架构的代码上,以便将整个声明文件集中于一处。
在应用开发的工作流中,我们需要将某个主分支作为发布分支。在此基础上,开发人员会从主分支处创建各个功能性分支,以便开发出特定的功能或故事线。而在功能性分支上,一旦完成了更改,他们会通过创建拉取请求的方式,重新合并回主分支。这样一来,我们就可以在方便实现协作的同时,透明地获悉到谁在何处进行何种更改。而且,由于所有更改都是在Git处被提交的,因此这对于开发团队从根本原因处进行问题的跟踪,也是非常实用的。
可见,创建拉取请求的好处在于,我们可以让代码在被集成到代码库的另一个分支之前,事先经历代码的审查过程。而代码审查恰好能够阻止各种不良的代码,进入测试或生产环境。显然,这对于故障的消除,以及基础架构代码而言,都是非常重要的。
Git的组成
GitOps并不依赖于任何工具或技术。它可以与诸如:GitHub、BitBucket或GitLab等,任何基于Git的系统协同使用。
而在部署过程中,GitOps至少需要两个存储库,即:包含了应用源代码、及其部署清单的应用程序存储库;和使用着每个环境的声明性规范描述的,包含了整个系统目标状态的环境配置存储库。您可以在代码存储库中将目标环境定义并描述为开发环境、测试环境、生产环境、或是包含了运行着特定版本的应用和基础架构服务的环境。
CI/CD
要实现完整的GitOps,您势必需要一个CI/CD管道,以实现Git存储库在每次发生更改时,开发团队都能将对应的基础架构变更交付到指定的环境中。该自动交付管道能够将Git的拉取请求连接到编排系统中,以便通过请求来触发管道,并让编排系统执行指定的任务。
一般而言,GitOps有两种可能的部署策略:推送管道和拉取管道。您可以根据当前架构需要部署的实际环境,在两者间做出选择。下面我们来具体看看两种策略的各种特点:
推送管道(Push Pipelines)
目前,许多流行的CI/CD工具都在使用这种策略。开发人员通常将应用程序的源代码、及其部署清单存储在一个存储库中。当应用代码发生变更时,管道将触发容器映像的构建,并将变更推送到相应的环境中。由于该策略支持任何类型的基础架构,因此它具有较大的灵活性。不过,其缺点是:它会赋予CI/CD工具对于目标环境的写入权限。
基于推送的DevOps部署
拉取管道(Pull Pipelines)
在开发者社区中,人们普遍认为:对于GitOps的拉取管道方法是一种更安全的策略。这种方法引入了操作符(operator)的概念。它是管道和业务流程工具之间的组件。操作符能够不断将环境存储库中的目标状态,与已部署的基础架构的实际状态,进行比较。如果操作符检测到任何修改,那么它就会更改基础架构,以适应环境存储库。同样地,它也可以监视镜像注册表,以识别出需要部署的镜像新版本。
基于拉取的DevOps部署
可见,在GitOps中,只有在环境存储库中出现修改时,对应的环境才会更新。相反,如果已实施的基础架构在环境存储库中并未定义任何方式的修改,那么系统将会自动还原。
在实际项目中,大多数应用程序都会同时涉及到多个环境。对此,GitOps允许您创建多个管道,以同时更改多个环境存储库。当然,您也可以在环境存储库中使用单独的分支,来管理多个环境。我们既可以通过将操作符部署到生产环境中,来对单个分支的修改及时做出反应,又可以通过部署到测试环境中,来响应另一个分支。
GitOps的优势
由于GitOps专注于Git工作流、IaC、CI/CD管道,不可变服务器(immutable servers)、跟踪、以及可观测性等优秀实践模型,因此它代表了对于Kubernetes云原生应用管理的高级状态。据此,开发团队可以从如下方面受益:
简化持续部署
顾名思义,持续部署(https://microtica.com/cracking-the-continuous-deployment-code/)意味着更快、更频繁的部署。通过GitOps,部署操作符提供了必要的结构和自动化,而且这一切都在版本控制系统中发生,因此我们无需各种工具,便可管理系统的状态、停机时间、上游/下游依赖关系、以及其他与组织相关的流程。
此外,GitOps不但提高了项目团队的生产率,而且加快了他们的平均部署时间(Mean-time-to-deployment,MTTD)。有证据表明,自动化持续部署能够确保团队每天触发30到100次以上的变更,并将生产环境的性能平均提高2到3倍。
缩短平均修复时间(Mean-time-to-repair,MTTR)
MTTR是衡量DevOps团队绩效的一项关键指标(https://microtica.com/13-devops-metrics-for-increased-productivity/https://microtica.com/13-devops-metrics-for-increased-productivity/)。由于GitOps保留了版本控制系统中的所有修改,并且能够实现自动化的管理,因此,开发团队能够全面了解目标环境中的变化,轻松发现和修复错误,从而显著降低MTTR。
简化Kubernetes管理
在无需透彻了解Kubernetes的情况下,开发人员可以使用Git等较为熟悉的工具,更加轻松地管理Kubernetes的升级和各项功能。据此,新加入的成员也能够在几天时间快速上手Kubernetes。
全面掌握并标准化工作流
由于GitOps提供了一站式的应用程序、软件、以及针对Kubernetes修改的框架,因此开发团队可以清晰地洞悉整个项目的端到端工作流,并能通过Git来完全复现日常的业务运营活动。
GitOps的实现
小结
作为一种非常好的工作流模式,GitOps不但可以帮助我们有效地处理云基础架构,还能够为工程团队提供:更好的协调性、透明度、稳定性、以及系统耐用性等方面的诸多好处。
原文标题:GitOps – DevOps for Infrastructure Automation,作者:Sara Miteva
【译稿,合作站点转载请注明原文译者和出处为.com】
网站栏目:你了解DevOps的自动化架构GitOps吗?
文章路径:http://www.shufengxianlan.com/qtweb/news31/41581.html
网站建设、网络推广公司-创新互联,是专注品牌与效果的网站制作,网络营销seo公司;服务项目有等
声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联