免费Python机器学习课程五

基于推送的GitOps部署

拉管道

社区认为对于GitOps，拉管道方法是一种更安全的做法。通过这种方法，引入了操作员。操作员是管道和业务流程工具之间的组件。它不断将环境存储库中的目标状态与已部署的基础架构中的实际状态进行比较。如果操作员检测到任何更改，便会更改基础结构以适合环境存储库。同样，可以监视映像注册表以识别要部署的映像的新版本。这就是GitOps如此特别的原因。
 

让我们分别看看它们。

基础架构即代码

IaC是作为声明文件(存储为代码)来配置和管理基础结构的一种做法。通过利用IaC和版本控制团队，可以优化所有操作程序。

GitOps围绕IaC的声明式模型。这就是为什么Kubernetes是实现的一个很好的例子。声明式意味着配置更多是对预期状态的声明，而不是一组命令。例如，在Kubernetes中，您可以在清单中定义服务所需的Pod数量。然后，系统将自行处理。无需工程师编写命令脚本即可获得所需的容器编号。

任何符合声明性模型的云原生软件都可以视为代码。我们使用AWS CloudFormation(一种声明性工具)编写AWS基础架构。这意味着我们可以将基础架构本身视为代码。将所需状态声明为代码。系统应用更改以自动实现该状态。

话虽如此，声明性模型并不是必须在GitOps中受益。您也可以在命令式定义的环境中执行操作。

拉取要求

GitOps概念背后的主要思想是版本控制系统是真实的唯一来源 。我们将Git用作应用程序代码的变更管理系统。我们也可以将其用于基础结构代码。因此，整个声明文件集都位于一个可以协作的地方。这使我们能够使用Git的关键概念-对操作更改的Pull 请求。

在应用开发工作流程中，我们使用一个主分支作为发布分支。开发人员从主分支创建功能分支。开发特定功能或故事，完成后创建Pull 请求以将其合并回主分支。相同的方法对于基础结构代码很方便。

创建拉取请求可使代码在集成到代码库的另一个分支之前，先经过代码审查过程。代码审查阻止不良代码进入测试或生产环境。这对于基础结构代码而言甚至更为重要。通过代码审查获得正式批准对审核和故障排除很有帮助。

Git组织

GitOps中的部署过程至少需要两个存储库：应用程序存储库和环境配置存储库。第一个包含应用程序的源代码及其部署清单。第二个包含使用每个环境的声明性规范描述的整个系统的期望状态。您可以在代码存储库中将环境描述为开发，测试，生产环境，其中包含可以在该环境的特定版本中运行的应用程序和基础结构服务。

对于基础设施，主分支可以代表一个环境。我们可以在功能分支中实现更改。然后创建一个拉取请求以合并主分支中的更改。这样一来，我们就可以实现协作，同时对谁进行了哪些更改保持透明。由于所有更改都是在Git中提交的，因此这对于从根本原因进行问题跟踪也很有用。

GitOps可与任何基于Git的系统一起使用，例如GitHub，BitBucket或GitLab。它不依赖于任何工具或技术。

CI/CD

要实现完整的GitOps实施，您需要一个CI/CD管道。借助自动交付管道，每次Git存储库中发生更改时，您都可以将基础结构更改交付到指定的环境。这里有管道将您的Git pull请求连接到业务流程系统。当您通过拉取请求触发管道时，业务流程系统将执行任务。

GitOps部署策略有两种可能性：推和拉管道。它们之间的区别在于您确保部署环境类似于所需基础结构的方式。

推管道

许多流行的CI/CD工具都在使用这种策略。我们将应用程序的源代码及其部署清单存储在一个存储库中。当应用程序代码中发生新更新时，构建管道将触发。管道构建容器映像并将更改推送到环境。该策略可支持任何类型的基础架构，因此带来了更大的灵活性。缺点是它使CI/CD工具可以写入您的环境。

（编辑：漯河站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!