构建可扩缩的弹性应用

构建可扩缩的弹性 Web 应用对于任何应用架构都是不可或缺的。一个精心设计的应用应随着需求的增加和减少而无缝扩缩,并且应具有足够的弹性以承受一个或多个计算资源的丢失。

本文档适用于熟悉 Compute Engine 的系统运营专业人员。在本文档中,您将学习如何使用 Google Cloud Platform (GCP),通过广泛适用于任何应用的模式及做法来构建可扩缩的弹性应用架构。此外,您将通过热门开源项目管理工具 Redmine(一款基于 Ruby on Rails 的应用)的部署示例,了解这些原则如何应用于真实场景。稍后,在部署示例解决方案部分,您将有机会亲自部署应用和下载所有源以供参考。

利用 GCP,您可以构建和运行可扩缩的弹性 Web 应用。您可以使用 Compute Engine 和自动扩缩程序等服务,根据需要调整应用的资源。根据 Compute Engine 的价格模式,您可以按秒付费,并且无需任何复杂的容量或预订计划即可自动获得具有持续使用折扣的最优惠价格。

如需大致了解 GCP 上的网站托管选项,请参阅提供网站服务

定义可扩缩性和弹性

在说明示例应用架构之前,不妨先定义可扩缩性和弹性这两个术语。

可扩缩性:调整容量以满足需求

可扩缩的应用面对 1 个用户或 1 百万个用户都能应付自如,并且可以从容地自动处理流量高峰和流量缩减。可扩缩应用仅在需要时添加和移除虚拟机,因此仅消耗满足需求所需的资源。

下图展示了可扩缩应用如何响应需求的增加和减少。

展示资源如何扩缩以满足需求的图表。

请注意,容量会动态调整以应对需求变化。此配置(有时在设计中称为弹性)有助于确保您仅为您的应用在某一特定时间所需的计算资源付费。

弹性:旨在应对意外情况

尽管系统中的组件出现预期或意外故障,高可用性或弹性应用仍能继续正常运行。如果单个实例发生故障或整个地区遇到问题,弹性应用仍具有容错能力,即继续正常运行并在必要时自动修复。由于有状态信息不存储在任何单个实例上,因此实例(甚至整个地区)的丢失应该不会影响应用的性能。

真正弹性佳的应用需要从软件开发级别和应用架构级别进行规划。本文档主要关注应用架构级别。

为弹性应用设计应用架构通常涉及:

  • 负载平衡器,用于监控服务器并将流量分配给能够以最佳效果处理请求的服务器
  • 在多个区域托管虚拟机
  • 配置强大的存储解决方案

GCP:弹性且经济高效

支持可扩缩性和弹性的传统架构通常需要对资源进行大量投资。如果使用本地解决方案,则可扩缩性通常意味着在以下两个方面之间做出取舍:要么超支投入服务器容量以处理峰值使用量,要么仅根据平均需求进行购买,但在流量高峰期具有应用性能变差或用户体验不佳的风险。弹性不仅仅是指服务器容量,此外,位置也非常重要。为了减轻严重风暴或地震等物理事件的影响,您必须考虑在不同物理位置运行服务器,而这需要很高的费用。

GCP 提供了一种替代方案:让您可以灵活地向架构添加可扩缩性和弹性的一组云服务。此外,GCP 通过使用您可以控制的价格结构来提供这些服务。

使用 GCP 构建可扩缩的弹性架构

下表展示了不同 GCP 服务与实现应用的可扩缩性和弹性所需的关键要求的对应关系。

架构要求 GCP 服务
负载平衡 HTTP 负载平衡
服务器托管 Compute Engine区域和地区
服务器管理 实例模板托管实例组自动扩缩程序
数据存储 Cloud SQLCloud Storage

下图展示了这些 GCP 组件如何协同工作以构建可扩缩的弹性应用。每个组件所起的作用将在下一部分详细介绍。

展示可扩缩弹性应用的图表。

组件概览

示例应用架构中的每个组件都在确保应用可扩缩且弹性佳方面发挥着作用。本部分简要介绍这些服务。后面部分将介绍这些服务如何协同工作。

HTTP 负载平衡器

HTTP 负载平衡器公开了客户用于访问应用的单个公共 IP 地址。该 IP 地址可以与 DNS A 记录(例如 example.com)或 CNAME(例如 www.example.com)相关联。传入请求会根据每个组的容量分配到每个地区的实例组中。在地区中,请求均匀分布到组内的实例上。虽然 HTTP 负载平衡器可以平衡多个区域的流量,但本示例解决方案将其用于具有多个地区的单个区域中。

地区

地区是一个区域内的独立位置。同一区域中的地区之间有着高带宽、低延迟网络连接。Google 建议在一个区域内的多个地区部署应用。

实例

实例是 Google 基础架构上托管的虚拟机。您可以像安装和配置物理服务器一样安装和配置这些实例。在示例部署中,您将使用启动脚本和 Chef 为实例配置应用的应用服务器和代码。

实例模板

实例模板定义机器类型、映像、地区、标签和其他实例属性。您可以使用实例模板来创建托管实例组

托管实例组

托管实例组是一组基于实例模板的同构实例。HTTP 负载平衡器可以将托管实例组作为目标,将工作分散到组内的多个实例。托管实例组具有相应的实例组管理器资源,该资源负责在组中添加和移除实例。

自动扩缩程序

Compute Engine 自动扩缩程序通过连接托管实例组的管理器,在该组中添加或移除 Compute Engine 实例以响应流量、CPU 利用率或其他信号。在示例解决方案中,自动扩缩程序响应 HTTP 负载平衡器的每秒请求数 (RPS) 指标。您希望自动扩缩的每个托管实例组都需要自动扩缩程序。

Cloud SQL

Cloud SQL 是一项完全托管式数据库服务,支持 MySQL 和 PostgreSQL。复制、加密、补丁和备份均由 Google 管理。Cloud SQL 实例部署到单个地区,数据自动复制到其他地区。本示例中使用的 Redmine 应用与 MySQL 兼容,可与 Cloud SQL 无缝协作。

Cloud Storage

Cloud Storage 允许使用简单且可扩缩的界面来存储和检索对象(通常是文件)。在此解决方案中,Cloud Storage 存储分区用于将私有 SSL 密钥分发到可扩缩的 Compute Engine 实例,还用于存储上传到 Redmine 应用的所有文件,这意味着任何实例的磁盘上都未存储有状态信息。

弹性

为了使此示例架构具有良好的弹性,它需要自动替换已失败或已变得不可用的实例。当新实例联机时,它应该:

  • 了解它在系统中的作用。
  • 自动配置自身。
  • 发现它的任何依赖项。
  • 自动开始处理请求。

为了自动替换失败的实例,您可以同时使用多个 Compute Engine 组件:

启动脚本会在实例启动或重启时运行。您可以使用这些脚本安装软件和更新,以确保服务在虚拟机中运行,甚至可以安装配置管理工具,例如 Chef、Puppet、Ansible 或 Salt。

此场景使用启动脚本安装 Chef Solo,而这反过来又会进一步配置实例以使用该应用。如需了解如何使用启动脚本和 Chef Solo 自动配置实例,请参阅本主题结尾的附录:添加新实例

除了启动脚本之外,您还需要在启动 Compute Engine 实例之前定义更多项。例如,您需要指定其机器类型、需要使用的操作系统映像以及要附加的任何磁盘。可以使用实例模板定义这些选项。

实例模板和启动脚本一起定义如何启动 Compute Engine 实例以及如何在该实例上配置软件以在应用架构中实现特定作用。

展示启动脚本、实例模板和实例如何协同工作的图表。

当然,实例模板只是一个模板而已。若要使用此模板,您需要知道如何在新的 Compute Engine 实例联机时向其应用该模板。为此,您需要创建一个托管实例组。由您决定要在任何给定时间运行的实例数,以及要应用于这些实例的实例模板。然后,实例组管理器会负责根据需要启动和配置这些实例。

下图展示了这些组件协同工作的方式:

  • 启动脚本
  • 实例模板
  • 单个实例组管理器
  • 托管实例组
展示启动脚本、实例模板、实例组管理器和托管实例组如何协同工作的图表

托管实例组及其对应的实例组管理器可以是特定于地区的资源或者区域资源。实例模板是一种项目级层资源,可以在任何区域的任何地区中的多个托管实例组中重复使用;但是,您可以在实例模板中指定一些地区资源,这样就可以将该模板的使用范围限制为这些地区资源所在的地区。

具备启动脚本、实例模板和托管实例组后,您现在拥有一个可将运行状况不佳的实例替换为新实例的系统。下一部分将介绍如何定义运行状况不佳的实例以及如何检测该实例。

运行状况检查

此时,示例应用具备了获得良好弹性所需的几乎所有工具。但还缺少一点,即它需要一种方法来标识运行状况不佳的实例,从而知道它应该替换这些实例。

该应用旨在让用户使用 HTTP 负载平衡器连接到运行状况良好的适当实例。通过该架构,您可以使用两种服务标识能够处理请求的实例:

  • 运行状况检查。HTTP 运行状况检查指定在每个实例上执行运行状况检查的端口和路径。运行状况检查应该会从运行状况良好的实例收到 200 OK 响应。
  • 后端服务。后端服务可定义会从负载平衡器接收流量的一个或多个实例组。后端服务指定实例公开的端口和协议(例如 HTTP 端口 80),以及要针对实例组中的实例进行的 HTTP 运行状况检查。

下图展示了应用架构,以及后端服务和 HTTP 运行状况检查与负载平衡器和实例组的关系。

展示运行状况检查和后端服务的图表。

使用 Cloud SQL 实现数据弹性

任何应用架构的三个主要方面都是网络、计算和存储。本文所述的应用架构介绍了网络组件和计算组件,但为了完整,它还必须介绍存储组件。

此示例解决方案使用 Cloud SQL 第一代实例提供完全托管式 MySQL 数据库。借助 Cloud SQL,Google 可自动管理复制、加密、补丁和备份。

Cloud SQL 数据库是在区域范围内,这意味着数据可在一个区域内的多个地区复制。这等效于在数据发生任何更新时备份更新。如果某一地区出现完全故障(这种情况一般不可能发生),数据仍将被保留。

Cloud SQL 可让您在以下两种复制类型之间进行选择:

  • 同步复制。使用同步复制,在返回到客户端之前,更新会被复制到多个地区。如果发生重大事件,这非常有利于可靠性和可用性,但会减慢写入速度。
  • 异步复制。异步复制在写入数据在本地缓存后,但在复制到其他位置之前确认写入数据,以此方式增加写入吞吐量。异步复制可以更快地向数据库写入数据,因为不必等待复制完成。但如果数据中心系统在更新数据库的几秒钟内发生故障(这种情况一般不可能发生),则您可能会丢失最新的更新。

此解决方案中使用的 Redmine 应用使用同步复制,因为工作负载的写入不是非常密集。您可以根据应用的写入性能和数据耐用性要求在同步复制和异步复制之间进行选择。

可扩缩性

前面部分已经展示了示例应用如何使用 GCP 来创建弹性应用。但弹性还不够 - 可扩缩性也非常重要。该应用面对 1 个用户或 1 百万个用户应该都能应付自如,并且其资源应随这些用户增加或减少以具备成本效益。

应用资源可以增减的想法要求它具有:

  • 一种可用于在服务中添加或移除实例的方法。此外,您还需要一种方法来决定何时需要添加实例,以及何时应移除实例。GCP 的自动扩缩程序可解决此问题。
  • 一种用于存储有状态数据的方法。由于实例会不断增减,因此不建议在这些实例上存储有状态数据。应用架构通过将关系型数据存储在单独的 Cloud SQL 实例中来解决此类数据的这种问题,但它还需要考虑用户上传的文件。Cloud Storage 满足此要求。

以下各部分介绍如何使用自动扩缩程序来扩缩运行 Redmine 应用的基础架构,以及如何针对已上传文件利用 Cloud Storage。

使用自动扩缩程序进行扩缩

随着应用使用量的波动,应用需要动态调整所需资源。您可以使用 Compute Engine 自动扩缩程序解决这一难题。

当流量或负载增加时,自动扩缩程序会添加资源以处理额外的活动,并且会在流量或负载减少时移除资源以帮助降低费用。自动扩缩程序会根据您定义的扩缩规则自动执行这些操作,而无需您进行后续干预。

自动扩缩程序具有双重影响:

  1. 您的用户在使用应用时获得良好的体验,因为始终有足够的资源来满足需求。
  2. 您可以更好地控制费用,因为当需求低于指定阈值时,自动扩缩程序会移除实例。

自动扩缩程序可以根据 CPU 利用率、服务容量或 Stackdriver Monitoring 指标扩缩虚拟机数。此解决方案根据实例从负载平衡器接收的每秒请求数 (RPS) 使用服务容量指标添加或移除 Compute Engine 实例。请参阅使用 Compute Engine 自动扩缩程序进行批处理了解详情。

每秒请求数 (RPS)

前面部分描述了单个后端服务,该服务标识从负载平衡器接收流量的实例组。对于与后端服务关联的每个实例组,此示例解决方案还设置了 balancingMode=RATE。此属性指示负载平衡器根据 maxRatePerInstance 属性中定义的 RPS(在此示例中设置为 100)进行平衡。此配置意味着负载平衡器会尝试将每个实例保持在 100 RPS 或 100 RPS 以下。如需详细了解后端服务的配置属性,
请参阅后端服务的文档

如需根据 RPS 进行扩缩,您需要为希望自动扩缩的每个实例组创建一个自动扩缩程序。在此示例中,实例组是地区级资源,因此您需要在每个地区中创建一个自动扩缩程序。

展示自动扩缩程序如何适应应用架构的图表。

每个自动扩缩程序都包含一个 utilizationTarget 属性,该属性定义了自动扩缩程序应维护的负载平衡器最大服务容量的比例。此示例将每个自动扩缩程序的 utilizationTarget 设置为每个实例的后端服务的最大比率 (100 RPS) 的 80%。这意味着,当 RPS 超过每个实例的最大比率的 80%(即 80 RPS)时,自动扩缩程序将进行扩展。当 RPS 降至该阈值以下时,自动扩缩程序将进行缩减。

展示自动扩缩程序如何确定应添加还是移除实例的流程图。

每个自动扩缩程序还定义了自动扩缩程序不会超出的最小和最大实例数。

请注意,只有托管实例组才提供自动扩缩功能。如需了解详情,请参阅实例组自动扩缩实例组

处理文件上传

Redmine 应用的部分功能包括允许用户在登录时上传和保存文件。Redmine 和许多其他类似应用的默认行为是将这些文件直接存储在本地磁盘上。如果您只有一个具有明确定义的备份机制的服务器,则此方法很不错。但是,如果在负载平衡器后面具有多个自动扩缩的 Compute Engine 实例,则此方法不是最佳选择。如果用户上传文件,则无法保证下一个请求将到达存储该文件的机器。此外,还无法保证自动扩缩程序不会终止包含文件但暂时不需要的实例。

更好的解决方案是使用 Cloud Storage,它提供了一个集中的位置,非常适合存储和访问来自自动扩缩的一系列网络服务器的文件上传。Cloud Storage 还公开了一个可与 Amazon S3 客户端互操作的 API,使其与 Amazon S3 的现有应用插件(包括 Redmine S3 插件)兼容,而无需任何修改。许多第三方和开源应用都具有支持 Cloud Storage 等对象存储的插件。如果您正在构建自己的应用,则可以直接使用 Cloud Storage API 支持存储文件。

下图显示了使用 Redmine 和 Cloud Storage 上传(蓝色箭头)和检索(绿色箭头)文件的流程:

展示通过 Redmine 应用的请求流的图表。

图中显示的过程如下:

  1. 用户从网络浏览器发布文件。
  2. 负载平衡器选择一个实例来处理请求。
  3. 实例将文件存储在 Cloud Storage 中。
  4. 实例将文件元数据(例如名称、所有者及其在 Cloud Storage 中的位置)存储在 Cloud SQL 数据库中。
  5. 当用户请求某一文件时,该文件会从 Cloud Storage 流式传输到实例。
  6. 实例通过负载平衡器发送流。
  7. 文件被发送给用户。

存储空间容量

除了从 Compute Engine 实例中移除有状态文件上传以及允许它们动态扩缩之外,Cloud Storage 还为几乎无限量的文件上传提供了冗余、持久的存储空间。此存储空间解决方案弹性佳、可扩缩且经济高效 - 您只需为所使用的存储空间付费而无需担心容量规划,并且数据会自动跨多个地区进行冗余存储。

费用

到目前为止,本文档中描述的应用架构展示了如何使用 GCP 构建弹性佳且可扩缩的应用。但是,能够构建应用是不够的,您还需要能够以尽可能经济高效的方式来构建应用。

本部分演示如何使本文档中描述的应用架构不仅弹性佳且可扩缩,而且还经济高效。首先,对应用的使用程度和频率进行一些一般性假设,然后将这些假设转换为基本费用估算。请记住,这些假设仅仅只是假设。您可以根据需要随意调整这些数字,以创建更符合您应用的预期使用情况的费用估算。

计算

任何应用架构的主要关注点都是保持服务器运行的费用是多少。此费用分析使用以下假设:

指标
每月平均网页浏览量 2000 万
每月平均 HTTP 请求数 1.2 亿
使用高峰时段(90% 或更高) 周一至周五上午 7:00 至下午 6:00
每次网页浏览的数据传输 100 KB
每月高峰小时数 220
高峰时段的请求率 127 个请求/秒 (RPS)
非高峰时段的请求率 6 个请求/秒 (RPS)

根据这些假设,您可以计算出应用在每月周一至周五上午 7:00 至下午 6:00 的高峰时段接收的网页浏览量:

2000 万(浏览量/月)* 6(请求数/浏览)* 90%(发生于高峰时段)= 1.08 亿

平均每个月有 22 个工作日。如果每个工作日有 11 个高峰小时数,您需要提供足够的计算资源才能处理每月 242 个高峰小时数。

接下来,您需要确定哪种类型的 Compute Engine 实例可以处理此类流量。此应用架构已使用 gatling.io 进行基本负载测试。这些测试结果确定 4 个 n1-standard-1 类型的 Compute Engine 实例已足够。

对于非高峰时段,此解决方案至少运行两个 n1-standard-1 实例。

如需了解运行这些实例所需的费用,请在 GCP 价格计算器上查看最新价格估算值。进行此操作时,请注意,在这两种情况下,这些实例都自动符合持续使用折扣的条件。

负载平衡和数据传输

此应用为负载平衡器配置了单个转发规则,该规则是用户连接到的公共 IP 地址。该转发规则按小时结算。

对于数据传输估算,首先考虑最糟糕的情况。负载平衡器会对其处理的入站数据收费,并且负载平衡器的出站流量按标准出站费率收费。假设 1.2 亿个 HTTP 请求中有 99.5% 是用户加载 Redmine 项目页面。加载一个页面会计入 1 个 HTTP GET 请求,然后会导致另外 5 个 HTTP GET 请求加载其他资源(CSS、映像和 jQuery)。加载整个页面涉及 6 个 HTTP 请求。这将导致:

  • 每月大约 2000 万个完整网页加载
  • 每页处理大约 10 KB 的入站数据并产生 450 KB 的数据传输
  • 负载平衡器每月处理的数据总量约为 214 GB,出站流量为 9091 GB

2000 万个 HTTP 请求中的另外 0.5% 是 HTTP POST 请求,用于上传平均大小(大约 0.5 MB)的文件,每月额外处理 500 GB 数据。

此 GCP 价格计算器估算值显示了负载平衡器处理 714 GB 数据传输量的预期费用,而在这种情况下出站流量会超过 9091 GB。

该数据传输估算是按可能的最大用量,因为它从 Compute Engine 实例和负载平衡器为每个请求提供所有内容(包括静态资源),没有考虑缓存或内容分发网络 (CDN) 的益处。在每个网页加载的大约 450 KB 的载荷中(回想一下,此解决方案基于每月超过 2000 万的网页加载),加载 jQuery 需要 333 KB。只需更新应用的一行以从 Google 托管的库加载 jQuery,即可将数据传输费用减少 73%。

此更新的价格估算值显示通过切换到 Google 托管的库实现的数据传输节省费用。

存储

此解决方案将 Cloud Storage 用于通过 Redmine 应用上传的所有文件。如前面部分所述,大约 0.5% 的使用是上传文件,每个文件的平均大小约为 0.5 MB。这意味着,您每月应该会看到 100 万个新文件上传,每月产生 500 GB 的新存储。该解决方案还假设每月进行 100 万次 HTTP PUT 操作以存储新文件,这些操作作为 A 类操作收费。

GCP 价格计算器提供的此价格估算值显示了使用 Cloud Storage 的预期费用。

此架构使用 Cloud SQL 存储应用的所有关系型数据。根据前面描述的示例指标,具有 1024 MB RAM 的 D2 数据库类型应为应用工作负载提供足够的容量,并且将每周运行 7 天,每天运行 24 小时。因为此数据库可能会出现高使用率,所以请在计算器中为 I/O 操作选择 Heavy 选项。通过插入 10 万个文档来测试此示例架构,结果确定了 50 GB 的磁盘将支持超过 1 亿个文档,从而允许数据库按所述比率使用 8 年以上。

以下是 GCP 价格计算器提供的估算值,该估算值显示了此部分架构费用的预期费用。

部署示例解决方案

如需部署此解决方案中描述的示例应用,请访问 GitHub 代码库 GCP 上的可扩缩弹性应用

附录:添加新实例

作为创建弹性佳且可扩缩的应用架构的一部分,您需要确定如何添加新实例。具体而言,您需要确定在新实例联机时如何自动配置它们。

在本部分中,您将看到一些可用选项。

引导软件安装

为了处理用户的 Web 请求,每个实例都需要在基本操作系统上安装一些其他软件和配置数据。配置数据包括数据库连接信息以及将在其中存储文件的 Cloud Storage 存储分区的名称。如果将这些组件想象为层,则可以直观呈现在每个实例上运行的整个堆栈:

展示软件如何在实例上堆叠的图表。

此解决方案使用实例模板,该模板指定实例在启动时使用的 Compute Engine 映像。具体来说,此解决方案使用 Canonical 开发和支持的 Ubuntu 14.10 映像。由于这是基本操作系统映像,因此它不包含应用所需的任何软件或配置。

为了在新实例启动时自动安装堆栈的其余部分,您可以在启动时结合使用 Compute Engine 启动脚本Chef Solo 进行引导。您可以通过将 startup-script 元数据特性项添加到实例模板来指定启动脚本。启动脚本在实例启动时运行。

此启动脚本:

  1. 安装 Chef 客户端。
  2. 下载名为 node.json 的特殊 Chef 文件。此文件告知 Chef 要针对此实例运行的配置。
  3. 运行 Chef 并让其处理详细配置。

下面是完整的启动脚本:

#! /bin/bash

# Install Chef
curl -L https://www.opscode.com/chef/install.sh | bash

# Download node.json (runlist)
curl -L https://github.com/googlecloudplatform/... > /tmp/node.json

# Run Chef
chef-solo -j /tmp/node.json -r https://github.com/googlecloudplatform/...

提供应用配置

在新实例使用启动脚本和 Chef 启动并自我配置后,该实例需要知道一些信息然后才能开始处理请求。在此示例中,每个实例都需要知道数据库连接信息(例如主机名、用户名和密码),以及要使用的 Cloud Storage 存储分区的名称和要用于连接的凭据。

每个 Compute Engine 实例都具有与之关联的元数据特性,您可以定义这些特性。之前,您了解了添加特殊 startup-script 元数据特性,但您还可以添加任意键值对。您可以在此处指定实例模板中的特性,以包括实例连接到数据库和 Cloud Storage 存储分区所需的配置数据。

下面是 GCP Console 中实例模板的元数据的外观:

Google Cloud Platform Console 的屏幕截图,显示实例模板的自定义元数据信息。

Chef 使用名为 Ohai 的工具从实例的元数据中解析这些配置信息,并填充模板以创建应用所需的配置文件。下面是创建 database.yaml 文件的模板,其中包含数据库连接信息,可自动访问相应元数据项:

production:
    adapter: mysql2
    database: <%= node['gce']['instance']['attributes']['dbname'] %>
    host:     <%= node['gce']['instance']['attributes']['dbhost'] %>
    username: <%= node['gce']['instance']['attributes']['dbuser'] %>
    password: <%= node['gce']['instance']['attributes']['dbpassword'] %>

您还可以使用本地元数据服务从实例中手动访问元数据值。这时,您可以使用 curl 检索数据库密码:

curl "http:/metadata.google.internal/computeMetadata/v1/instance/attributes/dbpassword" -H "Metadata-Flavor: Google"

性能和依赖项注意事项

此解决方案中采用的引导方法包括从默认操作系统映像开始进行操作、在启动时使用 Chef 安装所有软件,以及使用实例元数据提供应用配置数据。

展示软件如何在实例上堆叠的图表。此堆栈展示了某些软件与映像捆绑在一起、某些软件在启动时安装,以及某些软件在启动后提供的情形。

此方法的一个优点是系统的配置在 Chef 实战宝典中指定。该实战宝典可进行版本控制和共享,并且用于在本地预配虚拟机以进行测试、使用 Vagrant 或 Docker,或者用于配置位于数据中心或具有不同云提供商的服务器。此外,映像管理也得到了简化:在此示例应用中,您只需跟踪应用使用的一个基本操作系统映像。

需要考虑的一些缺点包括启动时间可能较慢,因为要下载和安装所有软件,在某些情况下需要编译。此外,考虑此方法引入的依赖项也很重要:在此示例中,Chef 安装了 apt、Rubygems 和 GitHub 中的许多软件包。如果这些代码库中的任何一个代码库在新实例启动时不可用,其配置都将失败。

自定义图像和引导

因为您可以使用 Compute Engine 创建自己的自定义映像,因此在启动时安装所有内容并不是进行引导的唯一方法。例如,您可以:

  1. 启动基础 Ubuntu 14.10 映像。
  2. 安装除 Redmine 应用(Ruby、nginx 等)之外的所有内容
  3. 从结果中创建映像。
  4. 在实例模板中使用该映像。

现在,当新实例启动时,它只需安装 Redmine。启动时间加快,并且外部软件包依赖项的数量也减少了。

展示映像上安装了除 Redmine 之外的所有内容的实例堆栈的图表。

您甚至可以进一步采用自定义映像方法,并将所有内容(包括所有依赖项、应用来源和配置)完全合并到映像中。这样做的优点是启动时间最短以及无外部依赖项,但现在如果应用中的任何内容发生变化,则必须创建新映像并更新实例模板。

展示所有软件都与映像捆绑在一起的实例堆栈的图表。

请考虑将实例作为连续体引导的方法。启动时需要更多配置意味着启动时间更慢但要管理的映像更少。将更多配置合并到自定义映像中意味着启动时间更快、依赖项更少,但可能需要管理更多映像。对于大多数客户而言,正确的方法是采用一种折中的办法。请选择一种适合您和您的应用的方法。

展示用于在实例上安装软件的一系列方式的图表。范围从启动后安装所有内容到将所有内容与映像捆绑在一起。

后续步骤

  • 如需大致了解 GCP 上的网站托管选项,请参阅提供网站服务
  • 试用其他 Google Cloud Platform 功能。查阅我们的教程
此页内容是否有用?请给出您的反馈和评价:

发送以下问题的反馈:

此网页
解决方案