使用 AWS CloudFormation 创建资源 - Amazon GameLift
AWS 文档中描述的 AWS 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅中国的 AWS 服务入门

本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。

使用 AWS CloudFormation 创建资源

您可以使用 AWS CloudFormation 管理您的 GameLift 资源。在创建和更新单独的资源时,GameLift 控制台和 CLI 命令是非常有用的工具。但是,使用 AWS CloudFormation,您可以管理全套的资源以支持游戏托管。在 AWS CloudFormation 中,您可以创建对每个资源构建模型的模板,然后使用该模板创建资源。要更新资源,您可以对模板进行更改,然后使用 AWS CloudFormation 实施更新。您可以将资源按照称为堆栈和堆栈集的逻辑组排列。

使用 AWS CloudFormation 维护您的 GameLift 托管资源提供了一种更有效的方式来管理 AWS 资源集。您可以使用版本控制来跟踪模板随时间推移的更改,并协调由多个团队成员进行的更新。您还可以重复使用模板。例如,在跨区域部署游戏时,您可以在各个区域中使用相同的模板创建相同的资源。您还可以使用这些模板在另一个分区中部署相同的资源集。

有关 AWS CloudFormation 的更多信息,请参阅 AWS CloudFormation 用户指南。要查看 GameLift 资源的模板信息,请参阅 Amazon GameLift 资源类型参考

以下主题介绍了将 AWS CloudFormation 与 GameLift 结合使用的最佳实践,并提供了构建模板结构的一些建议。

最佳实践

有关使用 AWS CloudFormation 的详细指南,请参阅 AWS CloudFormation 用户指南 中的 AWS CloudFormation 最佳实践。此外,这些最佳实践与 GameLift 有特殊关联。

  • 仅通过 AWS CloudFormation 一致地管理您的资源。 这是一种核心 AWS CloudFormation 最佳实践,但仍应反复提醒。如果您在 AWS CloudFormation 外部更改资源,例如使用 GameLift 控制台、GameLift API 调用或 CLI 命令,则资源将与模板失去同步。这可能会导致在您下次使用 AWS CloudFormation 模板更新资源时出现意外后果。

  • 使用 AWS CloudFormation 堆栈和堆栈集高效管理多个资源。

    • 使用堆栈管理一组连接的资源。AWS CloudFormation 可根据资源属性是否可变,智能更新堆栈中彼此引用的资源。例如,假设您有一个堆栈,其中包含一个生成包、一个引用该生成包的队组和一个引用该队组的别名。在 GameLift 中,生成包和队组之间的关系不可变。如果您更新模板以替换生成包,AWS CloudFormation 还会替换连接到所替换生成包的队组。然后,AWS CloudFormation 更新现有别名以指向新队组。有关更多信息,请参阅 AWS CloudFormation 用户指南 中的使用堆栈

    • 如果您要跨多个区域或 AWS 账户部署相同的堆栈,请使用 AWS CloudFormation 堆栈集。有关更多信息,请参阅 AWS CloudFormation 用户指南 中的使用堆栈集

  • 如果您使用 Spot 实例,请包括按需队组作为备份。 我们建议您在每个区域使用两个队组来设置模板,一个队组采用 Spot 实例,一个队组采用按需实例。GameLift 的 FleetIQ 功能确保游戏会话始终首先放在可用的 Spot 实例中。按需队组在 Spot 队组不可用时充当备份。

  • 当您在多个区域中管理资源时,将您的区域特定资源和全局资源分组到单独的堆栈中。 部分资源(例如 GameLift 队组)只能引用同一区域中的其他资源。其他资源(例如 GameLift 队组)可以引用其他区域中的资源。将它们放置在单独的堆栈中可让您在放置全局资源时具备更好的灵活性。

  • 将您的全局资源置于使用它的服务附近。 在您放置全局资源时,请注意这些资源的访问方式。队列和对战配置等资源往往会接收来自特定源(如后端服务)的大量请求。通过将资源放在靠近这些请求源的位置,您可以最大限度地减少请求行程时间并提高整体性能。

  • 将您的对战配置放在与使用它的游戏会话队列相同的区域中。 对战配置将对新游戏会话的请求发送到队列,因此将这些资源放在一起也有助于优化系统性能。

  • 为堆栈中的每个队组创建一个单独的别名。 使用别名,在替换游戏生成包和队组时,可以更容易地传输玩家流量。

使用 AWS CloudFormation 堆栈

以下是在为 GameLift 相关的资源设置 AWS CloudFormation 堆栈时建议使用的结构。您的最佳堆栈结构根据您在一个区域中部署游戏还是跨多个区域部署游戏而异。

适用于单个区域的堆栈

要管理单个区域中的 GameLift 资源,我们建议使用双堆栈结构:

  • 支持堆栈 – 此堆栈包含您的 GameLift 资源所依赖的资源。此堆栈至少应包括您存储自定义游戏服务器或 Realtime 脚本文件的 S3 存储桶。堆栈还应包含 IAM 角色,在创建 GameLift 生成包或脚本资源时,该角色向 GameLift 授予从 S3 存储桶检索文件的权限。此堆栈还可能包含用于您游戏的其他 AWS 资源,例如 DynamoDB 表、Amazon Redshift 集群和 Lambda 函数。

  • GameLift 堆栈 – 此堆栈包含您的所有 GameLift 资源,包括生成包或脚本、队组集合、别名和游戏会话队列。AWS CloudFormation 使用存储在 S3 存储桶位置中的文件创建生成包或脚本资源,并将生成包或脚本部署到一个或多个队组资源。每个队组都应该具有一个对应的别名。游戏会话队列引用部分或全部队组别名。如果您使用 FlexMatch 进行对战,则此堆栈还包含对战配置和规则集。

下图说明了用于在单个 AWS 区域中部署资源的双堆栈结构。


                该图显示了两个 AWS CloudFormation 堆栈。一个堆栈包含 GameLift 资源,另一个则包含支持 GameLift 的资源。后一个堆栈包括用于存储生成包文件或脚本文件的 S3 存储桶,以及允许 GameLift 从 S3 存储桶检索文件的 IAM 角色。

适用于多个区域的堆栈

在多个区域中部署游戏时,请注意资源如何跨区域进行交互。部分资源(例如 GameLift 队组)只能引用同一区域中的其他资源。其他资源(例如 GameLift 队列)与区域无关。要管理多个区域中的 GameLift 资源,我们建议使用以下结构。

  • 区域支持堆栈 – 这些堆栈包含您的 GameLift 资源所依赖的资源。此堆栈必须包括您存储自定义游戏服务器或 Realtime 脚本文件的 S3 存储桶。它还可包含您游戏的其他 AWS 资源,例如 DynamoDB 表、Amazon Redshift 集群和 Lambda 函数。其中许多资源特定于区域,因此您必须在各个区域中创建它们。GameLift 还需要允许访问这些支持资源的 IAM 角色。由于 IAM 角色与区域无关,因此您只需要一个角色资源,放置在任意区域中,并在所有其他支持堆栈中引用。

  • 区域 GameLift 堆栈 – 此堆栈包含部署游戏的各个区域中必须存在的 GameLift 资源,包括生成包或脚本、队组集合和别名。AWS CloudFormation 使用 S3 存储桶位置中的文件创建生成包或脚本,并将生成包或脚本部署到一个或多个队组资源。每个队组都应该具有一个对应的别名。游戏会话队列引用部分或全部队组别名。您可以维护一个模板,用于描述这种类型的堆栈并将其用于在每个区域中创建相同的资源集。

  • 全局 GameLift 堆栈 – 此堆栈包含您的游戏会话队列和堆栈资源。这些资源可以位于任意区域中,通常放置在相同区域。队列可以引用位于任意区域中的队组或别名。要在不同的区域中放置其他队列,请创建另外的全局堆栈。

下图说明了在多个 AWS 区域中部署资源的多堆栈结构。第一张图显示了单个游戏会话队列的结构。第二张图显示了多个队列的结构。


                    此图显示了三个区域的多个 AWS CloudFormation 堆栈。每个区域中的支持堆栈包含支持资源,例如 S3 存储桶。其中一个堆栈还包含 IAM 角色,该角色可由 GameLift 用于访问任何支持资源,而不受区域的限制。区域 GameLift 堆栈包含 GameLift 生成包或脚本、队组和别名。全局 GameLift 堆栈包含对战资源和队列,它们可以引用多个区域中的队组或别名。

                        此图显示了三个区域的多个 AWS CloudFormation 堆栈,包括在两个区域中具有游戏会话队列的 GameLift 全局堆栈。每个队列引用来自 GameLift 区域堆栈的别名。

更新生成包

GameLift 生成包是不可变的,就像生成包与队列之间的关系。因此,当您更新托管资源以使用一组新的游戏生成包文件时,必须执行以下操作:

  • 使用一组新文件创建新生成包(替换)。

  • 创建一个新的队组集合以部署新游戏生成包(替换)。

  • 重定向别名以指向新队组(无中断更新)。

有关更多信息,请参阅 AWS CloudFormation 用户指南 中的 堆栈资源的更新行为

自动部署生成包更新

更新包含相关生成包、队组和别名资源的堆栈时,默认 AWS CloudFormation 行为是自动执行序列中的这些步骤。通过先将新生成包文件上传到新的 S3 位置即可触发此更新。然后,您修改 AWS CloudFormation 生成包模板以指向新 S3 位置。使用新 S3 位置更新堆栈时,这将触发以下 AWS CloudFormation 序列:

  1. 从 S3 检索新文件、验证文件并创建新 GameLift 生成包。

  2. 在队列模板中更新生成包引用,该引用将触发新队组创建。

  3. 新队组处于活动状态之后,更新别名中的队组引用,这将触发将别名更新以指向新队组。

  4. 删除旧队组。

  5. 删除旧生成包。

如果您的游戏会话队列使用队组别名,则玩家流量会在更新别名之后自动切换到新队组。在游戏会话结束时,旧队组中的玩家逐渐全部退出。在玩家流量波动时,Auto-scaling 处理在每个队组集合中添加和删除实例的任务。或者,您可以指定所需的初始实例计数,以便快速增加切换并在稍后启用 Auto-scaling。

您还可以让 AWS CloudFormation 保留资源而不是删除资源。有关更多信息,请参阅 AWS CloudFormation API Reference 中的 RetainResources

手动部署生成包更新

在希望更好地控制什么时候为玩家上线新队组时,您可以利用一些选项。您可以选择使用 GameLift 控制台或 CLI 来手动管理别名。或者,您无需更新生成包模板以替换生成包和队组,而是可以向模板添加第二个生成包和队组定义集合。当您更新模板时,AWS CloudFormation 创建第二个生成包资源和相应的队组。由于未替换现有资源,因此这些资源不会被删除,别名仍然指向原始队组。

这种方法的主要优点在于向您提供了灵活性。您可以为生成包的新版本创建单独的资源,测试新资源,并控制何时为玩家上线新队组。这种方法的一个潜在缺点是,在很短的一段时间内,它在各个区域中需要两倍的资源。

下图阐明了此过程。


                    图中显示了三个区域的多个 AWS CloudFormation 堆栈,包括在两个区域中具有游戏会话队列的 GameLift 全局堆栈。每个队列引用来自 GameLift 区域堆栈的别名。

回滚的工作原理

执行资源更新时,如果任何步骤未成功完成,AWS CloudFormation 将自动启动回滚。此过程反向执行序列中的各个步骤,删除新创建的资源。

如果您需要手动触发回滚,请将构建模板的 S3 位置键更改回原始位置并更新堆栈。此时创建新 GameLift 生成包和队组,在该队组处于活动状态之后,别名切换回新队组。如果您要单独管理别名,则需要将其切换为指向新队组。

有关如何处理失败或卡住的回滚的更多信息,请参阅 AWS CloudFormation 用户指南 中的 继续回滚更新