云原生应用程序以其改进的性能和高效率在市场上占主导地位。尽管有更多资源来支持做为微服务运行的云原生应用程序,可是管理复杂的云架构仍然是一个挑战。您运行的微服务越多,您必须处理的任务越多,以保持云环境的健康和平稳运行。html
自动化成为解决该问题的明显方法。特别是Kubernetes如今受到新方法的支持,例如基础架构即代码和大量自动化工具。尽管如此,当今的CI / CD周期仍须要更强大且敏捷的体系结构。这是GitOps为Kubernetes就派上用场了。git
GitOps是一种持续部署的新方法,它利用Git做为声明性基础结构和应用程序的单一事实来源,同时提供修订和变动控制。使用GitOps,经过提交拉取请求(和后续合并)来运行系统,以实现Git存储库中表示的系统的所需状态。github
带有Kubernetes的GitOps经过声明性的持续交付系统提供了代码级基础架构和不变的基础架构。声明式配置和主动对账模型的样式扩展了该平台在Kubernetes应用程序的部署,监视和生命周期管理方面的核心优点。数组
该框架旨在与任何CI / CD管道很好地集成,即便您使用第三方工具来本机管理管道也是如此。安全
实际上,GitOps比实际工具更多的是工做流程或方法。这种方法能够帮助您优化CI / CD周期,而无需更改将微服务开发和部署到云的方式。服务器
因为GitOps是做为持续交付云原生应用程序的框架而开发的,所以您能够依靠该框架来简化管道中的某些流程。它无缝集成了咱们已经熟悉的Git工具和CD工具。架构
本质上,GitOps将传统的CI / CD管道与Git工做流结合在一块儿,从而能够更好地进行Kubernetes的端到端管理和应用程序开发。二者被视为统一的过程,而不是分开的过程。框架
GitOps的特色是:运维
经过定义,很容易看出GitOps如何从改进的开发人员体验开始为表带来不少好处。开发人员再也不须要担忧将代码打包在容器中以及使用Kubernetes集群的问题。相反,他们能够专一于本身的代码,依靠熟悉的工具(如Git)来处理其余全部内容。微服务
这是对开发人员体验的绝对改善。即便在DevOps专家的协助下,在许多状况下,应用程序部署仍然是瓶颈,这仅仅是由于须要易于打包的包装良好的代码和微服务。GitOps以其很是规的方法解决了这一瓶颈。
实施该方法后,还能够指望应用程序具备更好的稳定性。Git具备详细的日志记录系统,可轻松进行审核和跟踪,当您使用GitOps做为方法时,您将从同一日志记录工具中受益。对Kubernetes集群的更改被记录在日志中,从而使云审计变得更加容易管理。
甚至错误和崩溃之类的细节也是能够追溯的。诸如谁提交更改以及这些更改的结果之类的详细信息会记录在每一步中。不管您是尝试遵循安全性最佳实践仍是追求SOC 2合规性,Git日志的使用无疑会使维护稳定的系统变得更加容易。
大多数组织必须对其流程和系统进行大量投资才能合规和可审核。使用GitOps和Kubernetes,能够以最小的努力知足大多数合规性和可审核性要求。在此处阅读有关与咱们达成SOC 2合规性的更多信息。
还有一个事实,GitOps帮助开发团队提升了生产率。DevOps运动中出现的最突出的范例之一是声明性系统和配置的模型。简而言之,使用声明性模型描述了要实现的目标,而不是如何实现目标。
消除与基础架构相关的任务也是巨大的帮助。尽管使用传统的DevOps方法,但许多开发人员对将其云基础架构做为代码进行管理并不彻底满意。该过程仍然涉及必定程度的复杂性。
传统上,基础架构维护每每成为瓶颈,而不是支持功能。许多开发团队最终将管理基础架构的任务与主要的CI / CD管道分开,从而致使流程效率进一步下降。GitOps彻底消除了瓶颈,而无需更改管道。
GitOps还有助于改善云环境的安全性和标准化。将代码更改推送到Git,而后再进行进一步处理。能够采起其余安全措施,例如根据安全标准进行代码检查。将登台服务器集成到流程中也是一种惯例。
在这种状况下,事实的惟一来源是Git接管的角色。每当安全问题影响系统时,您始终能够经过查看Git存储库找到根本缘由。只要直接对Kubernetes集群进行更改,警报和日志就会自动发送到Git,这为该方法增长了一层安全性。
另外,GitOps经过将其对环境的声明性规范存储在源代码控制中做为事实来源来帮助恢复基础结构环境。经过对环境应该是什么的完整定义(惟一的事实来源),它有助于在发生灾难时从新建立环境。
最后,事实是GitOps使整个系统更加可靠。您能够经过控制Git存储库来分叉和还原更改。您用于管理代码和分支的相同Git命令可用于管理整个云环境。当出现问题时,回滚到某个快照很容易。
GitOps还增长了复杂的自动化功能。您能够在Git中自动化的全部事情均可以在GitOps中实现。同时,该方法自己能够经过简单的命令自动管理Kubernetes集群。这是一种真正知足现代云原生应用程序需求的方法。
在介绍如何实现GitOps做为一种方法以前,还须要仔细研究这种方法的基本原理。
1.有关基础架构的全部内容均以声明方式描述。全部服务器配置都定义为事实,并已彻底合并到Git存储库中,以实现最大的可靠性。声明式还意味着对应用程序声明进行完全的版本控制。
2.系统状态在Git中进行版本控制。这是从GitOps的错误中恢复很是容易的主要缘由之一。您能够以一致的方式回滚到某个版本。无需花费数小时进行灾难恢复,您只需花费几分钟。
3.须要批准更改,可是能够在系统中实施批准的更改。在实施以前,不须要单独的部署工做流或新代码的预打包。一切都会自动发生。
4.正确性和安全性是流程的一部分。无需将单独的安全性和完整性工做流程并入CI / CD管道。基础架构即代码已提高到一个全新的水平。
GitOps在处理更改方面很是简单。该过程从将新代码推送到Git进行进一步审查开始。一旦清除并批准了新代码,它们就会合并到Git中。这是触发部署新代码的动做的地方。
Git将与您喜欢的CD流水线工具一块儿触发建立新映像。该过程是彻底自动化的,所以您只须要定义一次参数。与AWS CodePipeline和AWS CodeCommit之类的工具结合使用,可能性是无限的。不是AWS用户?整合谷歌云乙ü ILD的连续部署詹金斯的持续集成工具。或者,Cloud Build的CI也能够连接到Google的Spinnaker CD工具。
经常使用的工具是Flux。Flux与Amazon EKS无缝协做 ,可提供真正可扩展的云环境。CodeBuild可用于将新代码推送到ECR,而后Flux将自动对EKS集群进行必要的更改。
Flux自动将容器部署到Kubernetes。它填补了构建和监视之间存在的自动化空白。
Flux的主要功能是版本控制存储库和集群之间的自动同步。若是您对存储库进行任何更改,则这些更改将自动部署到集群中。
另外一个功能是容器的部署自动化。它将持续监视一系列的容器注册表,并在适用时部署新版本。
这对于使存储库以及群集保持最新状态很是有用。因为Flux可以查看新映像并相应地更新集群,所以它还容许独立的团队拥有本身的部署管道。可是也能够禁用此功能,而且能够将图像锁定到特定版本。
为了跨环境和群集自定义配置,Flux内置了对Kustomize和Helm的支持。
助焊剂工做流程
Flux将监视您指定的全部容器映像存储库。它能够检测新映像,触发部署并自动更新Kubernetes集群的所需运行配置,而且能够在可配置部署策略的范围内进行。
若是您已经在使用Kubernetes和Helm,请按照Flux的深刻教程进行操做。该教程是最新的Flux版本1.18.0。
如您所见,设置Flux,部署应用,授予Flux访问权限以及完成修改所涉及的实际步骤很是简单。
许多开发人员已经在利用GitOps并实现收益。这种方法将进一步加强Kubernetes做为云平台的能力。指望未来会在更多开发项目中实施GitOps。
更多文章请搜索“运维派”,有惊喜。