使用 API 部署 API 代理

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

每个组织都有唯一的软件开发生命周期 (SDLC)。通常有必要将 API 代理部署与后端服务所用的流程同步并保持一致。

本主题演示的 Edge API 方法可用于将 API 代理管理集成到组织的 SDLC 中。此 API 的常见用法是编写用于部署 API 代理的脚本或代码,或者将 API 代理从一个环境迁移到另一个环境,作为一个更大的自动化流程的一部分,该流程也会部署或迁移其他应用。

Edge API 不会对您的 SDLC(或其他任何人)做出任何假设。 相反,它公开可以由开发团队协调的原子函数,以自动执行和优化 API 开发生命周期。

如需了解完整信息,请参阅 Edge API

如需使用 Edge API,您必须在调用中验证自己的身份。您可以使用以下方法之一执行此操作:

本主题重点介绍用于管理 API 代理的一组 API。

视频:观看此简短视频,了解如何部署 API。

与 API 交互

以下步骤将引导您完成与这些 API 的简单交互。

列出组织中的 API

您可以首先列出组织中的所有 API 代理。(请务必将 EMAIL:PASSWORDORG_NAME 替换为相应条目。如需了解相关说明,请参阅使用 Edge API

curl -u EMAIL:PASSWORD \
  https://api.enterprise.apigee.com/v1/o/ORG_NAME/apis

示例响应:

[ "weatherapi" ]

获取 API

您可以在组织中的任何 API 代理上调用 GET 方法。此调用会返回 API 代理的所有可用修订版本的列表。

curl -u EMAIL:PASSWORD -H "Accept: application/json" \
  https://api.enterprise.apigee.com/v1/o/ORG_NAME/apis/weatherapi

示例响应:

{
  "name" : "weatherapi",
  "revision" : [ "1" ]
}

此方法返回的唯一详细信息是 API 代理的名称以及具有关联编号的关联修订版本。API 代理由一组配置文件组成。修订版本提供了一种轻量级机制,用于在迭代时管理配置更新。修订版本会按顺序进行编号,使您能够通过部署 API 代理的先前修订版本来还原更改。此外,您还可以将 API 代理的修订版本部署到生产环境中,同时继续在测试环境中创建该 API 代理的新修订版本。准备就绪后,您可以在测试环境中将 API 代理的更高修订版本升级,以高于生产环境中 API 代理的先前修订版本。

在此示例中,由于刚刚创建了 API 代理,因此只有一个修订版本。在 API 代理经历迭代配置和部署的生命周期时,修订版本号将以整数递增。使用直接 API 调用进行部署,您可以选择递增 API 代理的修订版本号。有时,当您进行细微更改时,您可能不想递增修订版本。

获取 API 修订版本

API 版本(例如 api.company.com/v1)的更改频率非常低。如果您递增 API 版本,则表示 API 公开的外部接口的签名已发生重大变化。

API 代理修订版本是与 API 代理配置关联的递增编号。API 服务会维护配置的修订版本,以便您在出现问题时还原配置。默认情况下,每次使用导入 API 代理 API 导入 API 代理时,API 代理的修订版本都会自动递增。如果您不想递增 API 代理的修订版本,请使用更新 API 代理修订版本 API。如果您使用 Maven 进行部署,请使用 cleanupdate 选项,如 Maven 插件自述文件中所述。

例如,您可以在 API 代理修订版 1 上调用 GET 方法以获取详细视图。

curl -u EMAIL:PASSWORD -H "Accept:application/json" \
  https://api.enterprise.apigee.com/v1/o/ORG_NAME/apis/weatherapi/revisions/1

示例响应

{
  "configurationVersion" : {
    "majorVersion" : 4,
    "minorVersion" : 0
  },
  "contextInfo" : "Revision 1 of application weatherapi, in organization {org_name}",
  "createdAt" : 1343178905169,
  "createdBy" : "andrew@apigee.com",
  "lastModifiedAt" : 1343178905169,
  "lastModifiedBy" : "andrew@apigee.com",
  "name" : "weatherapi",
  "policies" : [ ],
  "proxyEndpoints" : [ ],
  "resources" : [ ],
  "revision" : "1",
  "targetEndpoints" : [ ],
  "targetServers" : [ ],
  "type" : "Application"
}

API 代理配置参考中详细介绍了这些 API 代理配置元素。

将 API 部署到环境

将 API 代理配置为正确接收和转发请求后,您可以将其部署到一个或多个环境。通常情况下,您需要对 test 中的 API 代理进行迭代,然后在准备就绪后将 API 代理修订版本提升到 prod通常,您会发现测试环境中的 API 代理的修订版本较多,主要原因是生产环境环境中的迭代次数会大大减少。

在将 API 代理部署到环境中之前,无法调用该代理。将 API 代理修订版本部署到生产环境后,您可以将 prod 网址发布给外部开发者。

如何列出环境

Apigee Edge 中的每个组织至少有两个环境:testprod。这种区别是任意的。在向外部开发者开放 API 代理之前,我们的目标是为您提供一个区域,供您验证 API 代理是否正常工作。

每个环境实际上只是一个网络地址,让您能够隔离您正在使用的 API 代理和应用在运行时访问的 API 代理之间的流量。

环境还可隔离数据和资源。例如,您可以在测试和生产环境中设置不同的缓存,这些缓存只能由在该环境中执行的 API 代理访问。

查看组织中的环境

curl -u EMAIL:PASSWORD \
  https://api.enterprise.apigee.com/v1/o/ORG_NAME/environments

示例响应

[ "test", "prod" ]

探索部署情况

部署是环境中部署的 API 代理的修订版本。您可以通过网络访问处于已部署状态的 API 代理,访问该环境的 <VirtualHost> 元素中定义的地址。

部署 API 代理

API 代理在部署之前无法调用。API 服务公开提供控制部署过程的 RESTful API。

在给定的时间,只能部署一个 API 代理的一个修订版本。因此,需要取消部署已部署的修订版本。您可以控制是否将新软件包部署为新修订版本,或者是否覆盖现有修订版本。

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

首先取消部署现有修订版本。指定要取消部署的 API 代理的环境名称和修订版本号:

curl -X DELETE \
  https://api.enterprise.apigee.com/v1/o/ORG_NAME/environments/ENV_NAME/apis/API_NAME/revisions/REVISION_NUMBER/deployments \
  -u EMAIL:PASSWORD

然后部署新的修订版本。API 代理的新修订版本必须已存在:

curl -X POST -H "Content-type:application/x-www-form-urlencoded" \
  https://api.enterprise.apigee.com/v1/o/ORG_NAME/environments/ENV_NAME/apis/API_NAME/revisions/REVISION_NUMBER/deployments \
  -u EMAIL:PASSWORD

无缝部署(零停机时间)

为了最大限度地降低部署期间停机的可能性,请在部署方法中使用 override 参数,并将其设置为 true

您不能在 API 代理的一个修订版本上部署另一个修订版本。必须始终取消部署第一个集群。将 override 设置为 true,即表示您指示应在当前部署的修订版本上部署 API 代理的一个修订版本。结果是部署顺序相反,即部署新的修订版本,并且部署完成后,已部署的修订版本将被取消部署。

以下示例通过将 override 值作为表单参数传递来设置该值:

curl -X POST -H "Content-type:application/x-www-form-urlencoded" \
  https://api.enterprise.apigee.com/v1/o/ORG_NAME/e/ENV_NAME/apis/API_NAME/revisions/REVISION_NUMBER/deployments" \
  -d "override=true" \
  -u EMAIL:PASSWORD

您可以通过设置 delay 参数进一步优化部署。delay 参数指定应取消部署上一个修订版本的时间间隔(以秒为单位)。结果是,正在进行的事务有一个时间间隔,在取消部署处理其事务的 API 代理之前完成该时间间隔。以下是使用 override=truedelay 参数集会发生的情况:

  • 修订版 1 正在处理请求。
  • 正在并行部署修订版本 2。
  • 修订版 2 完全部署后,新流量将发送到修订版 2。没有新流量发送到修订版 1。
  • 但是,修订版 1 可能仍在处理现有事务。通过设置 delay 参数(例如 15 秒),您可以为 Revision 1 留出 15 秒的时间来完成现有事务的处理。
  • 在延迟间隔过后,修订版本 1 将被取消部署。
curl -X POST -H "Content-type:application/x-www-form-urlencoded" \
  https://api.enterprise.apigee.com/v1/o/ORG_NAME/e/ENV_NAME/apis/API_NAME/revisions/REVISION_NUMBER/deployments?delay=15" \
  -d "override=true" \
  -u EMAIL:PASSWORD
查询参数 说明
override

默认值为 false(正常部署行为:取消部署现有修订版本,然后部署新修订版本)。

设置为 true 可替换正常部署行为并提供无缝部署。在部署新修订版本的同时,现有修订版本将保持已部署状态。部署新修订版本时,旧修订版本将被取消部署。与 delay 参数结合使用可控制取消部署的时间。

delay

如需在取消部署现有修订版本之前在现有修订版本上完成事务处理并消除 502 Bad Gateway504 Gateway Timeout errors 的可能性,请将此参数设置为您希望取消部署延迟的秒数。您可以设置的秒数没有限制,设置大量的秒数不会对性能产生任何影响。在延迟期间,新流量不会发送到旧修订版本。

默认值为 0(零)秒。如果将 override 设置为 true 且 delay 为 0,则在部署新修订版本后,系统会立即取消部署现有修订版本。负值将被视为 0(零)秒。

如果将 override=truedelay 结合使用,则可以消除部署期间的 HTTP 5XX 响应。这是因为这两个 API 代理修订版本将同时部署,而较旧的修订版本将在延迟后取消部署。

查看 API 修订版本的所有部署

有时,需要提取 API 代理当前部署的所有修订版本的列表。

curl https://api.enterprise.apigee.com/v1/o/ORG_NAME/apis/weatherapi/revisions/1/deployments \
  -u EMAIL:PASSWORD
{
  "aPIProxy" : "weatherapi",
  "environment" : [ {
    "configuration" : {
      "basePath" : "",
      "steps" : [ ]
    },
    "name" : "test",
    "server" : [ {
      "status" : "deployed",
      "type" : [ "message-processor" ],
      "uUID" : "90096dd1-1019-406b-9f42-fbb80cd01200"
    }, {
      "status" : "deployed",
      "type" : [ "message-processor" ],
      "uUID" : "7d6e2eb1-581a-4db0-8045-20d9c3306549"
    }, {
      "status" : "deployed",
      "type" : [ "router" ],
      "uUID" : "1619e2d7-c822-45e0-9f97-63882fb6a805"
    }, {
      "status" : "deployed",
      "type" : [ "router" ],
      "uUID" : "8a5f3d5f-46f8-4e99-b4cc-955875c8a8c8"
    } ],
    "state" : "deployed"
  } ],
  "name" : "1",
  "organization" : "org_name"
}

上述响应包含 Apigee Edge 内部基础架构所特有的许多属性。除非您在本地使用 Apigee Edge,否则无法更改这些设置。

响应中包含的重要属性包括 organizationenvironmentaPIProxynamestate。通过查看这些属性值,您可以确认是否已在环境中部署 API 代理的特定修订版本。

查看测试环境中的所有部署

您还可以使用以下调用检索特定环境的部署状态(包括当前部署的 API 代理的修订版本号):

curl -u EMAIL:PASSWORD
  https://api.enterprise.apigee.com/v1/o/ORG_NAME/environments/test/deployments

这样会针对测试环境中部署的每个 API 返回与上述相同的结果

查看贵组织中的所有部署

如需提取所有环境中所有 API 代理当前部署的所有修订版本的列表,请使用以下 API 方法:

curl https://api.enterprise.apigee.com/v1/o/ORG_NAME/deployments \
  -u EMAIL:PASSWORD

对于所有环境中部署的所有 API 代理,返回的结果与上述结果相同。

由于 API 是 RESTful,因此您只需对同一资源使用 POST 方法以及 JSON 或 XML 载荷即可创建 API 代理。

系统会为您的 API 代理生成配置文件。API 代理的默认表示法采用 JavaScript 对象表示法 (JSON)。以下是对上述 POST 请求的默认 JSON 响应,该请求创建了一个名为 weatherapi 的 API 代理。配置文件中每个元素的说明如下:

{
  "configurationVersion" : {
    "majorVersion" : 4,
    "minorVersion" : 0
  },
  "contextInfo" : "Revision 1 of application weatherapi, in organization {org_name}",
  "createdAt" : 1357172145444,
  "createdBy" : "you@yourcompany.com",
  "displayName" : "weatherapi",
  "lastModifiedAt" : 1357172145444,
  "lastModifiedBy" : "you@yourcompany.com",
  "name" : "weatherapi",
  "policies" : [ ],
  "proxyEndpoints" : [ ],
  "resources" : [ ],
  "revision" : "1",
  "targetEndpoints" : [ ],
  "targetServers" : [ ],
  "type" : "Application"
}

生成的 API 代理配置文件演示了 API 代理的完整结构:

  • APIProxy revision:API 代理配置的按顺序编号的迭代,由 API 服务维护
  • APIProxy name:API 代理的唯一名称
  • ConfigurationVersion:API 代理配置遵循的 API 服务版本
  • CreatedAt:生成 API 代理的时间(采用 UNIX 时间格式)
  • CreatedBy:创建 API 代理的 Apigee Edge 用户的电子邮件地址
  • DisplayName:API 代理的简单易记的名称
  • LastModifiedAt:生成 API 代理的时间,采用 UNIX 时间格式
  • LastModifiedBy:创建 API 代理的 Apigee Edge 用户的电子邮件地址
  • Policies:已添加到此 API 代理的政策列表
  • ProxyEndpoints:已命名的 ProxyEndpoint 的列表
  • Resources:可在此 API 代理中执行的资源(JavaScript、Python、Java、XSLT)列表
  • TargetServers:已命名的 TargetServer 列表(可以使用 Management API 创建),用于高级配置以实现负载均衡
  • TargetEndpoints:已命名的 TargetEndpoint 列表

请注意,在上述使用简单的 POST 方法创建的 API 代理配置的许多元素都是空的。在以下主题中,您将了解如何添加和配置 API 代理的关键组件。

您还可以在 API 代理配置参考中了解这些配置元素。

针对 API 编写脚本

GitHub 上的使用示例 API 代理部分提供了封装 Apigee 部署工具的 Shell 脚本。如果由于某种原因您无法使用 Python 部署工具,则可以直接调用 API。下面的示例脚本中演示了这两种方法。

封装部署工具

首先,确保您的本地环境中提供了 Python 部署工具

然后创建一个文件来保存您的凭据。您编写的部署脚本将导入这些设置,从而帮助您集中管理帐号的凭据。在 API 平台示例中,此文件名为 setenv.sh

#!/bin/bash

org="Your ORG on enterprise.apigee.com"
username="Your USERNAME on enterprise.apigee.com"

# While testing, it's not necessary to change the setting below
env="test"
# Change the value below only if you have an on-premise deployment
url="https://api.enterprise.apigee.com"
# Change the value below only if you have a custom domain
api_domain="apigee.net"

export org=$org
export username=$username
export env=$env
export url=$url
export api_domain=$api_domain

上面的文件使所有设置都可用于封装部署工具的 Shell 脚本。

现在创建一个 shell 脚本来导入这些设置并使用这些设置来调用部署工具。(如需查看示例,请参阅 Apigee API 平台示例。)

#!/bin/bash

source path/to/setenv.sh

echo "Enter your password for the Apigee Enterprise organization $org, followed by [ENTER]:"

read -s password

echo Deploying $proxy to $env on $url using $username and $org

path/to/deploy.py -n {api_name} -u $username:$password -o $org -h $url -e $env -p / -d path/to/apiproxy

为了切实简化工作,还需要创建一个脚本来调用和测试该 API,如下所示:

#!/bin/bash

echo Using org and environment configured in /setup/setenv.sh

source /path/to/setenv.sh

set -x

curl "http://$org-$env.apigee.net/{api_basepath}"

直接调用 API

编写简单的 Shell 脚本会很有用,这些脚本可以自动执行上传和部署 API 代理的过程。

以下脚本会直接调用 Management API。它会取消部署您要更新的 API 代理的现有修订版本,从包含代理配置文件的 /apiproxy 目录中创建 ZIP 文件,然后上传、导入和部署配置。

#!/bin/bash

#This sets the name of the API proxy and the basepath where the API will be available
api=api

source /path/to/setenv.sh

echo Delete the DS_store file on OSX

echo find . -name .DS_Store -print0 | xargs -0 rm -rf
find . -name .DS_Store -print0 | xargs -0 rm -rf

echo "Enter your password for the Apigee Enterprise organization $org, followed by [ENTER]:"

read -s password

echo Undeploy and delete the previous revision

# Note that you need to explicitly update the revision to be undeployed.
# One benefit of the Python deploy tool is that it manages this for you.

curl -k -u $username:$password "$url/v1/o/$org/e/$env/apis/$api/revisions/1/deployments" -X DELETE

curl -k -u $username:$password -X DELETE "$url/v1/o/$org/apis/$api/revisions/1"

rm -rf $api.zip

echo Create the API proxy bundle and deploy

zip -r $api.zip apiproxy

echo Import the new revision to $env environment 

curl -k -v -u $username:$password "$url/v1/o/$org/apis?action=import&name=$api" -T $api.zip -H "Content-Type: application/octet-stream" -X POST

echo Deploy the new revision to $env environment 

curl -k -u $username:$password "$url/v1/o/$org/e/$env/apis/$api/revisions/1/deployments" -X POST