反模式:在不使用源代码控制管理的情况下管理 Edge 资源

您正在查看的是 Apigee Edge 文档。
转到 Apigee X 文档
信息

Apigee Edge 提供许多不同类型的资源,每种资源的用途不同。某些资源只能通过 Edge 界面、管理 API 或使用管理 API 的工具进行配置(即创建、更新和/或删除),并且只能由拥有必要角色和权限的用户配置。例如,只有属于特定组织的组织管理员才能配置这些资源。这意味着,最终用户无法通过开发者门户配置这些资源,也无法通过任何其他方式配置这些资源。这些资源包括:

  • API 代理
  • 共享流
  • API 产品
  • 缓存
  • KVM
  • 密钥库和信任库
  • 虚拟主机
  • 目标服务器
  • 资源文件

虽然这些资源确实具有受限访问权限,但即使由授权用户对其进行任何修改,历史数据也不会被新数据覆盖。这是因为这些资源仅根据当前状态存储在 Apigee Edge 中。此规则的主要例外是 API 代理和共享流。

进行修订版本控制的 API 代理和共享流

API 代理和共享流可通过修订版本进行管理,即创建、更新和部署。修订版本按顺序编号,这样您就可以添加新更改并将其保存为新修订版本,或者通过部署 API 代理/共享流的先前修订版本来还原更改。在任何时候,环境中都只能部署 API 代理/共享流的一个修订版本,除非修订版本具有不同的基本路径。

虽然 API 代理和共享流可通过修订版本进行管理,但如果对现有修订版本进行任何修改,则无法回滚,因为会覆盖旧更改。

审核和历史记录

Apigee Edge 提供审核以及 API、产品和组织历史记录功能,在排查问题时非常有用。借助这些功能,您可以查看谁执行了特定操作(创建、读取、更新、删除、部署和取消部署)以及对 Edge 资源执行操作的时间等信息。但是,如果对任何 Edge 资源执行了更新或删除操作,审核将无法为您提供旧数据。

反模式

直接通过 Edge 界面或管理 API 管理 Edge 资源(如上所列),无需使用源代码控制系统

人们有一个误解,他们认为 Apigee Edge 可以在修改或删除后将资源恢复到之前的状态。但是,Edge Cloud 不会将资源恢复到之前的状态。因此,用户应负责确保与 Edge 资源相关的所有数据都通过源代码控制管理机制进行管理,以便在意外删除或需要回滚任何更改的情况下快速恢复旧数据。这对于运行时流量需要此类数据的生产环境来说尤其重要。

我们通过几个示例来解释这一点,以及在未通过源代码控制系统管理数据并蓄意或无意修改了/删除了数据时可能导致的影响类型:

示例 1:删除或修改 API 代理

删除 API 代理或在现有修订版本上部署更改时,以前的代码将不可恢复。如果 API 代理包含的 Java、JavaScript、Node.js 或 Python 代码未在 Apigee 外部的源代码控制管理 (SCM) 系统中进行管理,则大量开发工作和工作量可能会丢失。

示例 2:使用特定虚拟主机确定 API 代理

虚拟主机上的证书即将过期,且该虚拟主机需要更新。如果有许多 API 代理,确定哪个 API 代理使用该虚拟主机进行测试可能很困难。如果 API 代理在 Apigee 外部的 SCM 系统中管理,则可以轻松搜索代码库。

示例 3:删除密钥库/信任库

如果虚拟主机或目标服务器配置使用的密钥库/信任库已被删除,则除非将密钥库/信任库(包括证书和/或私钥)的配置详细信息存储在源代码控制系统中,否则无法恢复密钥库/信任库。

影响

  • 如果有任何 Edge 资源被删除,则无法从 Apigee Edge 中恢复该资源及其内容。
  • 在将资源恢复到之前的状态之前,API 请求可能会失败,并出现导致中断的意外错误。
  • 在 Apigee Edge 中,很难搜索 API 代理与其他资源之间的相互依赖性。

最佳做法

  • 搭配使用任何标准 SCM 以及持续集成和持续部署 (CICD) 流水线来管理 API 代理和共享流。
  • 使用任何标准 SCM 管理其他 Edge 资源,包括 API 产品、缓存、KVM、目标服务器、虚拟主机和密钥库。
    • 如果有任何现有的 Edge 资源,请使用管理 API 以 JSON/XML 载荷的形式获取这些资源的配置详细信息,并将其存储在源代码控制管理机制中。
    • 在源代码控制管理系统中管理对这些资源的任何新更新。
    • 如果需要创建新的 Edge 资源或更新现有 Edge 资源,请使用存储在源代码控制管理中的适当 JSON/XML 载荷,并使用管理 API 更新 Edge 中的配置。

* 不能在 API 中以纯文本形式导出加密 KVM。用户有责任记录保存在加密 KVM 中的值。

更多详情