GitOps

我会将 GitOps 方法与我正在从事的项目中当前使用的 CI/CD 设置进行比较。我还将重点比较我项目中当前设置的 CI/CD 具有以下工具和技术:

• Jenkins:用于编排

• AWS:云提供商

• Terraform:用于 IAC

• Kubernetes:用于托管微服务

• Helm:用于 Kubernetes 部署

如果您是第一次听说 GitOps,可以在此处查看我的博文。

在部署到任何环境时,我们需要选择以下参数:

• 环境

• 构建工件

由于 GitOps 主要针对部署,我们将其与当前的 CD 作业配置进行比较。 CD作业有以下阶段和相应的时间消耗:

• 授权用户(1分钟)

• 验证分支(1 分钟)

• Artefact Pull(3分钟)

• 生成配置(10 分钟)

• 部署(15–30 分钟)

• 测试(10 分钟)

• 标记人工制品(3 分钟)

平均而言,部署大约需要 30 到 45 分钟,并且必须手动触发部署(在较低的环境中)。

当我们实施 GitOps 时,让我们根据 OpenGitOps 原则分解将受到影响的事物:

1. **声明式

**所有系统状态都应以声明方式存储。

我们需要存储所有以声明方式动态生成的配置。

2. **版本化和不可变

**所需状态是存储以强制不变性、版本控制和保留完整版本历史的方式。

我们使用 Bitbucket 作为带有 Git 存储库的版本控制系统,所以看起来它已经被处理了。

3. **自动拉取

**软件代理会自动从源中提取所需的状态声明。

我们还没有设置,但是如果我们实现一个软件代理来提取所需的状态声明,那么与现有的相比,创建和触发部署所花费的总时间应该非常低。

我确实希望部署时间(在环境中推出应用程序版本所需的时间)本身不会改变。

4. **不断和解

**软件代理持续观察观察实际系统状态,并且尝试应用所需状态。

在这里,由于有持续的协调,如果我必须在环境中部署新版本,我需要做的就是将 PR 提升并合并到由软件代理监控的目标分支。它将接受更改并将其应用于必要的环境。

考虑到所有这些原则的成功实施,让我们看看切换到 GitOps 后对整体部署时间的影响。

• Authorize User(1分钟)——重用现有的SCM工具授权

• Validate Branch(1 分钟)——重用现有的 SCM 工具分支权限

• Artefact Pull(3 分钟)——GitOps 代理拉取所需的配置

• 生成配置(10 分钟)- 声明式方法因此无需生成配置

• 部署(15-30 分钟)— 大约在同一时间

• 测试(10 分钟)— 大约相同的时间

• 标记人工制品(3 分钟)——不需要,因为 SCM 保持所需状态

因此,每次部署可节省大约 20 分钟的总时间。这似乎更低,但是当您将它与每天可能数千次部署相乘时,它就有多大价值,并提高了开发人员的生产力。

展望未来,采用 GitOps 似乎是组织适应的下一个合乎逻辑的步骤。

请随时与我联系:https://www.linkedin.com/in/nishadmehendale/