反模式:不使用源代码控制管理系统直接管理资源

您正在查看 Apigee X 文档。
查看 Apigee Edge 文档。

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

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

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

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

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

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

审核和历史记录

Apigee 提供了“审核”功能,其有助于问题排查场景。借助这些功能,您可以查看执行特定操作(创建、读取、更新、删除、部署、取消部署)的人员以及在 Apigee 资源上执行操作的时间等信息。但是,如果对任何 Apigee 资源执行任何更新或删除操作,则审核无法向您提供旧数据。

反模式

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

存在一个误解,即修改或删除后 Apigee 能够将资源恢复到之前的状态。但是,Apigee 不会将资源恢复到之前的状态。因此,用户有责任确保与 Apigee 资源相关的所有数据都通过源代码控制管理系统来管理,这样,即使意外删除或需要回滚任何更改,也能快速恢复旧数据。这对于运行时流量需要此类数据的生产环境来说尤其重要。

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

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

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

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

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

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

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

影响

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

最佳做法

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

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

更多详情