构建您自己的 AWS Service Broker 服务

AWS Service Broker 徽标。 AWS Service Broker 开源项目在 re:Invent 2017 大会上推出，方便开发人员使用 Pivotal Cloud Foundry 等平台在应用程序平台接口内部预置和暴露原生的 AWS 服务。

虽然 Service Broker 支持的服务不断增长，但客户希望能通过一种简单的方式来扩展 AWS Service Broker 的服务本身。在本博文中，我们将探索 AWS Service Broker 背后的工作原理，以及开发、运营和安全团队如何根据自己的业务需求自定义解决方案。

从 Service Broker 首次面世以来，创建自定义服务的流程已经改变，使其成为一个更加简单、更加愉悦的过程。我们将略微深入介绍此方面，首先是 Broker 如何使用 AWS CloudFormation 以及可以如何自定义 CloudFormation 模板。然后，我们将介绍 CloudFormation 与 Broker 的参数映射的简化情况，以及如何使用自定义的模板目录来存储自定义设置。

Service Broker 与 AWS CloudFormation

AWS Service Broker 使用 AWS CloudFormation 基础设施即代码模板来预置将在应用程序平台中使用的资源。对于 Service Broker 中可用的每个资源，都有一个规定的模板。AWS Service Broker 模板已经开源化，因此您可以根据自己的需求对它们进行修改和扩展。

在 Service Broker 的首次发行版中，您必须为您希望使用的服务创建一个 CloudFormation 模板。通过在预置时为 CloudFormation 模板中需要的一些输入使用默认值，我们简化了用户体验。（虽然这些默认参数值适合大多数常见的使用案例，但它们可以根据需要进行修改。）

然后，Service Broker 需要通过某种方式来了解应该在应用程序平台 UI　中呈现哪些 CloudFormation 模板参数，哪些参数是可选的，哪些参数是必选的，等等。在最初版本的 Broker 中，这需要创建一个 YAML 文件来记录 CloudFormation 模板和 Broker 中参数的映射关系。现在，您可以将自己的模板存储在自定义目录中，并使用自动生成的 Service Broker 元数据，无需手动参数映射。

将您自己的模板存储在自定义目录中

现在，Service Broker 本身允许您将模板存储在一个自定义目录中 — 您可以完全自定义您将用于 Broker 的模板。有一些使用案例需要这种功能。

一些客户在 Broker 中使用自己现有的 CloudFormation 模板；这些模板往往已经在他们现有的基础设施即代码管理中使用，满足他们的要求，并且通过了安全评估。对于这些客户，在 Broker 中使用这些现有的模板是非常合理的。

一些客户（尤其是希望执行严格安全性评估流程的客户）希望使用复杂的模板集合（例如 VPC、数据库层，然后使用通过网状模板堆栈来管理的前端），并将这些模板作为可重复使用的自助式构建块，供开发团队使用。开发安全运营团队可以评估现有的模板，根据自己的业务需求进行修改，然后在自己的目录中存储通过安全审批的白名单版本。这将需要用一个 S3 存储桶来存储模板，并且 Broker 的 YAML 配置文件也将需要更新以列出存储桶的位置。此外，这还需要客户将 AWS Service Broker 与 AWS GovCloud 结合使用，因为在 GovCloud 中运行的系统要求将其资源存储在 GovCloud 区域运行的 Amazon S3 中，不能使用来自公有 S3 目录的现有 Service Broker 模板。

有关设置目录的更多详细信息，请参阅 AWS Service Broker 文档。甚至还有一个 CloudFormation 前提模板，您可以使用此模板来构建 S3 存储桶和需要的权限，启动堆栈，以及将输出中的信息添加到 Broker 配置中。

OpenShift 配置示例

（请注意 S3 存储桶和区域配置。）

TARGETACCOUNTID=
TARGETROLENAME=
VPCID=
REGION=us-east-1
IMAGE=awsservicebroker/aws-servicebroker:beta
IMAGEPULLPOLICY=Always
S3BUCKET=<YOUR S3 BUCKET IN GOVCLOUD>
S3KEY=templates/latest
S3REGION=us-gov-west-1
TABLENAME=awssb
VERBOSITY=10
BROKERID=awsservicebroker
PRESCRIBE_OVERRIDES=true

Cloud Foundry 配置示例

从手动参数映射转向元数据

我们进行的第二项更改是降低参数映射过程的难度。Broker 更新后，不再需要单独的 YAML 文件来记录映射，而是在 CloudFormation 模板中利用元数据生成此映射。

...
Metadata:
  AWS::ServiceBroker::Specification:
    Version: 1.0
    Tags:
    - AWS
    - Lex
    - Bot
    - NLU
    - chatbot
    Name: lex
    DisplayName: Amazon Lex
    LongDescription: Amazon Lex is a service for building conversational interfaces
      into any application using voice and text.Amazon Lex provides the advanced
      deep learning functionalities of automatic speech recognition (ASR) for converting
      speech to text, and natural language understanding (NLU) to recognize the intent
      of the text, to enable you to build applications with highly engaging user experiences
      and lifelike conversational interactions.
    ImageUrl: https://s3.amazonaws.com/awsservicebroker/icons/AmazonLex_LARGE.png
    DocumentationUrl: https://thinkwithwp.com/documentation/lex/
    ProviderDisplayName: Amazon Web Services
    ServicePlans:
      default:
        DisplayName: Standard
        Description: Amazon Lex
        LongDescription: Creates an Amazon Lex bot
        Cost: https://thinkwithwp.com/lex/pricing/
        ParameterValues: {}
...

您可以看出，Broker 的规范定义了一个描述、服务计划、必选或可选参数以及默认值。此规范可以如此处的示例一样非常简单，也可以更为复杂，例如对于 Amazon Relational Database Service (Amazon RDS)，开发环境和生产环境需要不同的计划，同时参数和选项也相当不同。

将映射信息变为 CloudFormation 模板中的元数据部分，有利于确保单个真相来源，更加方便客户进行自定义。但元数据的创建也仍然是一个负担。

根据一位客户工程师的反馈，元数据的创建十分痛苦，容易产生错误，处理多个计划是更需要特别小心。根据 CloudFormation 模板中参数选项的复杂度不同，人们会很容易丢失、忘记甚至忽略某个东西。该工程师反映最多的一个意见是，手动构建元数据需要的时间和精力导致他无力构建新的乐高登月模块!

自动生成 Service Broker 元数据

简单的脚本搞定一切！现在，我们提供了一个元数据生成器来帮助构建自定义。这让您可以构建或自定义 CloudFormation 模板，并运行将会根据模板中的参数构建元数据的元数据生成器。然后，来自元数据生成器的输出将放入 CloudFormation 模板，并将新模板添加到您的自定义目录 S3 存储桶中。

元数据生成器输出示例

...
==================================YAML========================================

AWS::ServiceBroker::Specification:
  Version: 1
  Tags:
  - ''
  - ''
  Name: ''
  DisplayName: ''
  LongDescription: ''
  ImageUrl: ''
  DocumentationUrl: ''
  ProviderDisplayName:  Amazon Web Services
  ServicePlans:
    production:
      DisplayName: Production
      Description: Configuration designed for production deployments
      LongDescription: ''
      Cost: ''
      ParameterValues: &o0
        AccessCidr:
        AllocatedStorageAndIops: 100GB 1000IOPS
        AllowMajorVersionUpgrade: false
        AutoMinorVersionUpgrade: true
        AvailabilityZones: Auto
        BackupRetentionPeriod: 35
        CidrBlocks: Auto
 ...

根据使用 Service Broker 的应用程序平台不同，您可能需要为 Broker 执行一项操作才能看到新模板。Red Hat OpenShift 等应用程序平台将会在一定时间后轮询更改和更新。 Pivotal Cloud Foundry 仅会加载安装时存在的模板列表，如果您使用 Pivotal Cloud Foundry，您将需要执行 Broker 部署。这将不会影响 Broker 预置的任何现有服务，因为此信息存储在 DynamoDB 稳定会话状态中。

如要进行迭代，您需要：

创建一个 S3 存储桶以存储自定义模板或新的服务模板。
更新 Service Broker 配置以使用目录存储桶（请参阅上文有关 OpenShift 和 Cloud Foundry 的配置示例）。
创建或自定义 CloudFormation 模板，并确保您已经拥有启动和使用业务所需服务需要的所有参数和输出。
使用元数据生成器来生成 Service Broker 规范。
复制生成器的输出并将它复制到 CloudFormation 模板中。
将模板及其元数据规范上传到用于测试的目录 S3 存储桶中。
根据您使用的应用程序平台创建新服务，例如：cf create-service <newcustomservice> default <blognewcustomservice>。

此流程是否绝对有必要？不是，许多客户都在使用现有规定的Service Broker 服务。AWS GovCloud 区域的客户已经在使用自定义目录，但大多数客户使用现有规定的模板，下载这些模板，然后将它们上传到自己的自定义目录中。需要自行构建自定义模板或聚合 Service Broker 所提供解决方案的客户将发现此过程更为简单。

后续步骤

自己试试吧！
AWS Service Broker 是一个开源项目 — 请大胆为 AWS Service Broker、服务模板的扩展做贡献，也可随时在 Service Broker 项目下提出问题。

更多详细信息请参阅 AWS Service Broker。

亚马逊AWS官方博客