在开发门户中通过 GitOps 实现自服务的基础设施即代码

在开发门户中通过 GitOps 实现自服务的基础设施即代码

翻译自 Self-Service Infrastructure as Code in a Dev Portal with GitOps 。

在幕后使用 Terraform 或其他 GitOps 启用黄金路径开发人员 IaC 操作的分步指南。

不久前，GitOps 风靡 DevOps，提供更流畅、更快速的软件交付体验。 GitOps 有很多优势，可以让开发人员、DevOps 和机器（工作流和管道）的生活变得更简单。

然而，这并非一帆风顺，因为 GitOps 要求开发人员熟悉许多 DevOps 实践和专业知识。例如，基础设施即代码。 IaC 是一个完整的专业领域。使用它需要遵守适用的 DevOps 团队标准和语法。

例如，假设开发人员需要为他们正在处理的微服务设置 MongoDB。独立创建 IaC 并向 GitOps 提交 pull request 来处理 Terraform 文件的应用程序可能会让一些开发人员望而生畏。它还需要相当程度的信任。然而，这很难大规模实施，因为并非所有开发人员都具备所需的 DevOps 专业知识。

让开发人员自由使用 IaC 会引发其他问题。编写 Terraform 代码需要了解安全最佳实践，缺乏经验的开发人员可能会在不知不觉中将安全漏洞引入基础架构。

这可能导致数据泄露、数据丢失或其他安全事件。此外，不一致的代码质量也可能是一个问题，因为开发人员可能有不同的编码风格和标准，这使得将来难以维护和更新基础设施。

所有这些都是开发人员体验问题，解决它的新方法是使用内部开发人员门户 (IDP)，这是平台工程中面向开发人员的核心工具。开发人员门户通过类似产品的用户界面提供预制的黄金路径，允许开发人员执行从供应测试环境到回滚部署的许多自助服务操作。

让我们探讨一下开发人员如何在 GitOps 的支持下执行基础设施即代码（IaC）的自助操作。在这种情况下，IaC 文件的创建由现有的 GitOps 工作流自动处理。

第 1 步：识别自助服务操作（通过 IaC 文件实现）

首先，确定您希望开发人员自助服务的操作。例子是：

• 创建 S3 存储桶/MongoDB
• 初始化开发人员环境
• 创建一个 AWS 账户

这是您可能已经拥有的示例 Terraform 文件，您希望通过内部开发人员门户将其作为自助服务操作提供。

第 2 步：为开发人员创建通过 UI 和 API 使用 IaC 的体验

现在我们要创建您希望开发人员在使用自助服务操作时使用的表单。表单（和向导）旨在减少认知负担并提供类似产品的体验。您还可以使用 API 使其更易于使用。无论哪种情况，这都定义了黄金路径，显​​示对开发人员重要的所有 IaC 元素，并将其余元素隐藏在幕后。这解决了开发人员访问 GitOps 时经常出现的分离问题，其中一些变量用于 DevOps，一些变量用于开发人员，从而为错误创造空间并减慢开发人员的速度。创建 UI 表单时，请考虑您希望为开发人员提供的最简单的体验。在需要的地方添加工具提示，这样就没有问题没有得到解答。

这是一个“添加 DocDB”的例子：

第 3 步：使用开发人员自助服务表单中的注入值自动生成 IaC

这是我们连接点的地方。

我们从自助服务表单中获取用户输入并将其转化为 IaC 参数。提交表单后，这将自动生成一个 IaC 文件。

第 4 步：提交并为生成的 IaC 文件的发起

为此，我们将为表单提交实现一个侦听器，该侦听器将创建对所选文件的拉取请求。在大多数情况下，DevOps 工程师将是批准该操作的人员。

这是 Pull Request 的一个例子。

第 5 步：更新内部开发人员门户的软件目录

内部开发人员门户还包含一个软件目录，它显示的不仅仅是微服务。它包含重要的内容：CI/CD 流、集群、开发环境、管道、部署和任何云。一旦发生自助服务操作，软件目录就会与触发的 GitOps 工作流（Azure Pipeline、Github Workflow 或任何其他处理 IaC apply 的实现）的过程保持同步。

在这里，您可以看到我如何使用 Port 的 GitHub 工作流提供程序来使 Port 的软件目录根据新请求的基础设施进行更新。

您可以从开发人员的角度和平台的角度在此处查看整个流程。

就是这样！您已经成功地实现了一个端到端的流程，让开发人员可以使用现有的 GitOps 实现，通过单击按钮体验将 IaC 添加到他们的应用程序中。

底层开发人员门户、IaC 和 GitOps 架构

让我们看一下架构以及开发人员门户如何与 GitOps 交互，然后更新软件目录。

1. 用户在开发人员门户中执行自助服务操作。
2. 然后将操作存储在 Kafka 的队列中。
3. 集中处理程序监听表单提交。在本例中，它是 Port 的 GitHub 应用程序，它既监听表单提交又处理 Terraform 文件生成。
4. 一旦 Terraform 文件准备就绪并包含相关参数，它将被提交并创建 pull request 。
5. 合并 PR 后，已经提前实现的 GitOps 工作流会触发处理 Terraform apply 的 Azure Pipeline（或任何其他 CI）。
6. 作为 Azure Pipeline 的一部分，软件目录数据与特定 IaC 操作的进度保持同步，并根据 Terraform 文件 apply/destroy 操作从目录中添加/修改/删除资源。

从开发人员的角度看 IaC 自助服务

让我们看看在内部开发人员门户中使用自助 IaC 操作时开发人员的体验。

这是开发者用户填写的表格：

由于 IaC 操作可能需要时间，因此最好向开发人员展示操作的进展情况，如本例所示：

操作完成后，开发人员将在内部开发人员门户中的软件目录中看到 IaC 操作的结果：

从平台角度看 IaC 自助服务

这是审计日志。在这里，您可以看到开发人员触发的不同自助服务操作的状态，包括它们的状态、调用它们的初始实体以及它们完成运行时的持续时间。

在这里，我们可以看到自助服务操作的特定调用的元数据。包括用户输入、操作的一般元数据和受影响的目录实体列表（作为操作的结果的新的、更新的或删除的）。

作为调用操作的元数据的一部分，还可以附加相关链接列表。在 IaC 用例中，一个很好的附加链接是指向 pull request 的链接，该 pull request 是使用新的 terraform 定义创建的自助操作及其对基础设施的预期影响。

接下来，您可能希望允许删除数据库或执行第 2 天操作，例如通过自助服务操作增加资源。当然，您可以允许开发人员执行许多其他操作，这完全取决于您。

结论

平台工程是关于创建可重用元素，而 IaC 操作应该是其中的一部分。为了避免认知负荷和入职开发人员使用 GitOps 的问题，内部开发人员门户为开发人员提供了广泛的自助服务功能，他们可以轻松地执行 IaC 操作并相应地更新软件目录。

当开发者门户与底层实现解耦时，开发者将获得一致的体验，而 DevOps 可以改变底层逻辑的实现方式。同时，将自助服务支柱的开发者门户与软件目录“本地化”，而不是将自助服务操作和软件目录作为两个独立的元素来管理，也是很重要的。