您正在查看 Apigee Edge 文档。
前往 Apigee X 文档。信息
每个组织都有唯一的软件开发生命周期 (SDLC)。使 API 代理部署与您目前开发、测试和部署其他应用的相同流程保持同步和一致通常是很有必要的。
API 服务提供了各种工具和 RESTful API,让您能够将 API 代理部署和管理集成到组织的 SDLC 中。RESTful API 的一个常见用途是编写脚本或代码,以编程方式部署 API 代理或将 API 代理从一个环境迁移到另一个环境,这也是大型自动化流程的一部分,该流程还部署或迁移其他应用。API 服务对您的 SDLC(或者其他任何人的 SDLC)不做任何假设。相反,它公开了可由开发团队协调的原子函数,以自动化和优化 API 开发生命周期。
API 参考文档中介绍了 API 服务 API。请参阅 API 参考文档使用入门。
观看此视频,简要了解 API 环境和 API 开发生命周期。
环境
Apigee Edge 上的每个组织至少有两个可用于 API 代理的部署环境:“test”和“prod”。这两个环境的区别是任意的,每个环境只是由不同的网络地址(网址)识别。这样做的目的是提供一个网域,您可以在其中构建和验证 API 代理,然后再向外部开发者公开 API。
您可以利用这些环境将 API 代理开发流程与您的 SDLC 同步。每个环境都由一个网络地址定义,因此您可以在正在构建的 API 代理与在运行时被应用访问的 API 代理之间分离流量。每个环境可用的网络地址由该环境中可用的 VirtualHost 定义。
系统会自动为每个环境启用入站服务器 TLS/SSL。两个环境中都有两个预定义的 VirtualHost:default
和 secure
。default 定义 HTTP 地址,而 secure 使用预配置的服务器端 TLS/SSL 定义 HTTP/S 地址。在 API 代理配置中,您需要指定 ProxyEndpoint 应侦听的 VirtualHost。提升到生产环境时,通常通过从 API 代理配置中移除 default
VirtualHost 来停用 HTTP。
例如,以下 ProxyEndpoint 侦听 HTTP 和 HTTPS。
<HTTPProxyConnection> <BasePath>/v0/weather</BasePath> <Properties/> <VirtualHost>default</VirtualHost> <VirtualHost>secure</VirtualHost> </HTTPProxyConnection>
通过从 ProxyEndpoint 配置中删除 default
VirtualHost,您将创建一个只侦听 HTTPS 而不侦听 HTTP 的 API 代理。
<HTTPProxyConnection> <BasePath>/v0/weather</BasePath> <Properties/> <VirtualHost>secure</VirtualHost> </HTTPProxyConnection>
您可以通过在管理界面的主菜单中选择环境来查看环境中可用的 VirtualHost。
环境还可隔离数据和资源。例如,您可以在测试和生产环境中设置不同的缓存,此类缓存只能由在该环境中运行的 API 代理访问。此外,在测试环境中颁发的 API 密钥在生产环境中无效,反之亦然。
将 API 代理部署到环境
创建 API 代理时,您需要确定在哪个环境中工作。您可以选择在生产环境中创建新的 API 代理,但我们不建议这样做,因为您有可能会在 API 准备就绪之前就将其公开给开发者。通常,首先在 test
中创建 API 代理,然后在测试后提升到 prod
。
如需了解详情,请参阅了解部署。
测试中的迭代开发
在您构建 API 代理时,API 服务会将您的配置迭代保存为修订版本。部署 API 代理时,您需要选择一个特定修订版本进行部署。通常是部署最新的修订版本,如有必要,可以还原到之前的修订版本号。您可以选择部署这些修订版本的位置。例如,您可以将修订版本提升到生产环境,以允许开发者开始使用您的 API。同时,您可能在测试环境中迭代多个修订版本,向其添加功能或微调政策。准备就绪后,您可以将新修订版本部署到生产环境,覆盖该环境中的现有修订版本。使用此方法,您可以在进行开发的同时始终为开发者提供一个 API 的现行修订版本。
提升到生产环境
完全实现并测试某个 API 代理后,您就可以将其提升到生产环境。测试环境中的 API 代理的修订版本将用于覆盖部署在生产环境中的 API 代理的修订版本。
API 服务提供的功能可确保 API 代理的无缝部署,从而在部署过程中最大限度地减少对应用和最终用户的影响。
编写部署脚本
借助 Apigee Edge 管理界面,您可以直接从 API 代理构建器将 API 代理部署到生产环境。然而,在许多情况下,安全性、可靠性和一致性的要求会要求开发团队编写部署过程的脚本。为此,您可以编写代码和脚本来调用由 API 服务公开的 RESTful API。
环境资源
为了在提升期间更好地进行控制,建议您只对测试环境中的 API 代理进行迭代,并对生产环境中部署的 API 代理进行尽量少的更改。
为此,您需要确保将与每个环境关联的某些资源配置为在 API 代理配置中保持静态。
- 目标网址:API 代理在测试和生产期间调用不同的后端网址很常见。您可以使用 TargetServer 配置来创建独立于环境的 TargetEndpoint 配置。请参阅跨后端服务器的负载均衡。
- 缓存和键值对映射:这两种持久资源都按环境划分。您应确保采用命名惯例,让 API 代理在升级期间无需更改配置即可存储数据。请参阅创建和修改环境缓存。
- ServiceCallout 目标:service callout 可能会根据环境使用不同的目标,例如,测试环境中的 ServiceCallout 使用演示服务。 请参阅服务标注政策。
如需使 API 代理配置独立于环境,您还可以使用条件语句。使用 environment.name
变量构建的条件语句可用于在强制执行政策或路由到后端网址之前评估当前环境。
如需了解详情,请参阅了解部署。