Cloud Foundry 4：应用程序的生命周期

章节概述

在本节中，我们将带您了解 Cloud Foundry 中应用程序的生命周期管理。我们涵盖了平台的理想工作负载，以及故障排除的基础知识和有时出现的常见问题。

• 我们查看在 Cloud Foundry 中运行的容器化应用程序的剖析和配置输入。
• 我们查看应用程序在部署过程中经历的阶段。
• 我们着眼于在更新应用程序时可供开发人员使用的两种策略。
• 我们介绍了在 Cloud Foundry 上对应用程序进行故障排除的基础知识，包括开发人员在使用该平台时遇到的一些常见问题。
• 我们着眼于 Cloud Foundry 的理想工作负载，以及在设计和选择要在平台上运行的应用程序时的一般注意事项。

什么进入应用程序？

在我们进入推送和管理应用程序的不同方面之前，让我们回顾一下在 Cloud Foundry 中运行的应用程序的内容。

让我们讨论一下我们需要什么来运行您的应用程序并查看 Cloud Foundry 如何满足这些需求。记住 Cloud Foundry 在容器中运行应用程序实例。早在 Kubernetes 或 Docker 出现之前，它就已经这样做了。除了这些解决方案提供的功能之外，Cloud Foundry 还为您完成了创建容器映像和在适当的主机上调度容器的所有繁重工作。您只需提供您的应用程序代码和配置。

组件：

• App Code
  作为开发人员，您有责任向平台提供您的应用程序代码。您可以使用 cf push 命令执行此操作。
• Runtime Dependencies
  要运行您的应用程序代码，Cloud Foundry 需要运行时元素。这可能是 ruby​​ 应用程序的解释器，Java 应用程序的 JRE（或 JRE + Tomcat），或类似 NGINX 的东西来提供静态内容。运行时依赖项在暂存过程中由一个或多个构建包提供。droplet在暂存过程中，应用程序代码和运行时依赖项组合在一个称为“”的单元中。
• stack
  要运行您的应用程序实例，我们需要一个用于容器进程的文件系统。“堆栈”是用于构建容器映像的预构建文件系统。当应用程序实例启动时，通过将堆栈与液滴（应用程序 + 运行时依赖项）结合起来，“及时”创建一个容器。
• Application Configuration
  配置在您的应用程序之外。（十二因素应用程序原则指导我们通过环境注入此配置）。Cloud Foundry 允许您直接设置环境变量，也可以设置一些默认值。VCAP_APPLICATION 环境变量提供有关正在运行的应用程序实例的信息，包括路由和其他运行时配置。VCAP_SERVICES 环境变量用于注入服务实例凭据和配置。
• Deployment Configuration
  最后，部署配置用于指定 Cloud Foundry 的参数，包括要调度的应用程序实例（容器）的数量以及要为每个实例分配的内存和磁盘量。用于在 Cloud Foundry 中引用应用程序的应用程序名称是部署配置的一部分。应用程序路由（如果适用）也是部署配置的一部分。作为开发人员，您可以指定这些值。

总之，作为开发人员，您需要带上您的应用程序代码，告诉 Cloud Foundry 您要应用的部署配置，并可选择通过环境变量提供应用程序配置。Cloud Foundry 完成其余的工作。无需构建、审查和管理容器映像、文件系统、运行时等。

pushing

cf push 由三个阶段组成：upload, staging and starting.。 对于这些阶段中的每一个，cf push 都是发起者。

上传

1. 为应用程序创建了一条记录。
2. App metadata，包括名称、所需的实例数量、选定的buildpack，都存储在称为云控制器数据库 (CCDB) 的数据库中。
3. 源文件已上传。 任何已存在于资源缓存中的应用程序文件都将被忽略。
4. 上传的应用程序文件与资源缓存中的任何已有文件组合以创建应用程序包。
5. 应用程序包已存储。

Staging

此时，CLI 发出启动应用程序的请求，但在启动应用程序之前，它需要暂存。 暂存是为您的应用程序创建容器化映像的过程。

• 选择 buildpack 来暂存应用程序（如果未指定）。
• buildpack 创建并存储包含已编译和暂存应用程序的 droplet（tarball）。 Droplet是应用程序的容器映像减去根文件系统。
• buildpack 缓存已更新，以便下次登台应用程序时可以使用它。
• 分期阶段已完成。

Starting

• 容器化应用程序被安排为一个长时间运行的进程。
• 一旦通过健康检查，该应用程序就会启动并运行。

Restarting, Restaging, and Re-pushing

在某些情况下，您需要对正在运行的应用程序进行更改。 例如，您可能想要推出对应用程序代码的更新，或响应崩溃的应用程序。

在这种情况下，您通常会使用重新启动、重新暂存或 (re)-push 进行更改。

–strategy rolling

–strategy 标志是在 Cloud Foundry API v3 中引入的，以启用滚动（零停机时间）部署，它是目前唯一可用的策略，这意味着 --strategy 标志可以设置为滚动或 null。

在接下来的几节中，我们将讨论一下滚动部署的上下文，并将它们与早期的蓝绿部署机制进行比较。 目前，值得注意的是 --strategy 标志启用零停机时间应用程序更新，并且可以在重新启动、重新暂存或重新推送时使用。

Restarting

重新启动是三种操作中破坏性最小的。 重新启动应用程序时，Cloud Foundry 将销毁现有正在运行的容器实例并创建新的容器实例。 创建新实例时使用现有的 droplet 和配置。 当液滴内容未更改但您希望重新启动应用程序进程时，重新启动应用程序可能很有用。

如果您在没有 --strategy rolling的情况下运行 cf restart，您的应用程序将遇到停机时间。

重启单个实例

也可以重新启动应用程序的特定实例。如果您愿意，您可以一次手动重新启动一个应用程序实例以更新您的应用程序而无需停机（只要您有多个），但是 --strategy rolling 这样做更有效，您将在下一节中看到.

通过提供实例索引号来重新启动各个应用程序实例。这可以通过运行 cf app training-app 来检索，并且始终从 0 开始。

cf restart-app-instance training-app 0

实例重启的更好用例是在用户通过 ssh 访问它之后。让我们看看为什么。

cf ssh 将在故障排除部分更详细地介绍。这仅用于演示目的。

cf ssh training-app -i 0

然后，在容器会话中，运行：

rm -fr app
exit

rm -fr app 将递归删除应用目录。您通常不太可能这样做，但用户对应用实例所做的更改可能会对最终用户产生影响。如果您现在尝试在浏览器中打开培训应用程序，实例 0 提供的响应将失败。

如果您在通过 ssh 访问容器时无意中更改了某些内容，则可以使用 restart 来销毁您访问的容器实例并获取一个新的实例。

Restaging

当您重新暂存应用程序时，您是在要求 Cloud Foundry 创建一个新的 droplet（容器映像）。暂存过程会重用您上次推送中上传的应用程序代码。应用程序配置和部署配置不会因重新暂存而更改。

cf restage training-app

当运行时依赖项可能发生变化但您的应用程序代码未更改时，应重新暂存应用程序。例如，当您直接更改环境变量或通过绑定服务时。如果配置更改或绑定可能导致不同的运行时行为，则应重新暂存。

现实生活中的场景可能是将监控服务绑定到您的应用程序，该应用程序在运行时中包含代理（AppDynamics、NewRelic 等）。代理需要在暂存期间添加到液滴中，以便它与应用程序代码在同一容器进程中运行。在这种情况下，运行 cf restart 是不够的，因为 buildpack 不会添加必要的代理。

更改环境变量时，CLI 建议重新暂存，因为它不知道更改是否会影响 droplet。该建议基于环境变化将导致液滴变化的可能性。如果您确定对环境的更改仅由您的应用程序使用而不是暂存过程，则重新启动就足够了。

当 buildpack 发生变化时，需要重新编排。当操作员更新 buildpack 时会发生这种情况，从而有效地更新您的应用程序可以使用的运行时依赖项。这样，您的应用程序的运行时依赖项由平台管理。这与您负责修补容器映像的基于 Docker 的系统形成鲜明对比。

另一个常见的重新暂存场景是堆栈（根文件系统）发生更改时。很难确定更改的堆栈元素是否正在被运行时使用，因此在更改堆栈后重新暂存是一种常见做法。

您可以使用 cf stacks 查看 Cloud Foundry 上可用的堆栈。应用程序的堆栈在 cf app 的输出中可见。

Re-pushing

当您的应用程序代码更改时，需要Re-pushing。

当您将应用程序重新推送到 Cloud Foundry 时，您几乎会覆盖所有内容。 缓存的应用程序代码将替换为您的最新推送，并且此新应用程序代码通过暂存过程发送，从而导致创建新的 Droplet。 为确保更新所有正在运行的实例，每个现有容器（实例）都将被销毁并使用新的 droplet 替换。

重新推送时，部署配置可能会更改，具体取决于您是否更新它。 仅当提供新值时，才会覆盖现有值。 如果省略值，将使用现有的值。

接下来，我们将在更新策略部分重新推送应用程序。

更新应用程序：概述

当您添加新功能、修复错误并总体改进您的应用程序时，您将需要部署这些更改。 无论是否停机，Cloud Foundry 都可以轻松实现这一目标。 这是你的选择。

更新部署配置

重新推送时，您使用与首次部署应用程序时相同的推送命令。 您可以提供所有相同的部署配置（service bindings, environment variables, instance counts, etc等），也可以提供已更改的内容。 除了路径之外，您不覆盖的任何内容都将保持与以前相同。 您始终需要提供应用程序位的路径。

–strategy 标志

–strategy 标志在版本 7 中添加到 CLI。如果您在推送更新时省略 --strategy 标志，所有应用程序实例将立即更新。 虽然这是一种快速的部署方法，但它会导致停机，因为所有实例都将同时停止。

为防止停机，您可以在推送更新时指定 --strategy rolling。 使用滚动策略，应用程序实例一次更新一个。 首先，启动具有更新的新实例并将其映射到与旧应用程序相同的路由，然后删除旧实例。 重复此过程，直到所有实例都已更新。

请注意，其他命令也支持 --strategy 标志，包括 cf restart。 您可以通过查看 CLI 的帮助输出来获取更多信息。

滚动部署的含义

使用滚动部署时，请务必注意以下事项：

• 应用程序更改必须是附加的。 在部署期间，Cloud Foundry 会同时为您的应用程序的新旧版本提供服务。 如果您推送向后不兼容的 API 更改，这可能会暂时导致用户问题。
• 部署不处理数据库迁移。 当现有应用程序与迁移不兼容时迁移应用程序数据库可能会导致停机。

滚动部署仅通过前几页中描述的滚动更新序列运行 Web 进程。 更新所有 Web 进程后，这些命令会批量重启工作进程和其他非 Web 进程。

旧的部署方式

在先前版本的 Cloud Foundry 中，使用“蓝绿部署”方法实现了零停机更新。这将在本课程的下一部分中提到；应用程序的新版本使用不同的名称推送，并且路由（取消）映射用于切断来自实时应用程序部署的流量。虽然这种方法有效，但这种方法在 Cloud Foundry 眼中会产生一个“新”应用程序。将零停机更新作为 Cloud Foundry 的核心功能，简化了应用程序的全生命周期管理。

蓝绿部署很强大，但也有问题。因为新版本是使用新的应用程序名称（通常类似于 myapp-venerable）推送的，所以 Cloud Foundry 将其视为具有自己唯一 GUID 的不同应用程序。因此，用户必须在日志系统（和查询）、服务发现和查看事件时做出调整。旧版本的事件历史将独立于新版本，并在清理旧应用程序时丢失。此外，在某些服务发现系统中，拥有两个 GUID 需要变通方法。

滚动部署

包含一个名为updated-app 的简单静态文件应用程序以及一个清单。清单使用五个实例部署应用程序。

Deploy the app using the manifest:：

cf push

请注意分配给此应用程序的路线。与之前的一些练习一样，您会从应用程序清单中注意到随机路由字段设置为 true，因此将由 Cloud Foundry 随机分配。您可以随时使用 cf app updates-app 检索路线。

如果您在安装了 watch 实用程序的系统上，您可以查看正在运行的进程。 watch 将在给定的时间间隔内重新运行命令。如果您没有watch ，则需要手动重复运行以下命令以查看该过程的实际效果。如果您没有watch ，请不要担心 - 我们在本练习的视频中对此进行了演示。

使用watch ，在一个选项卡中开始：

watch -n 0.5 curl -L <ROUTE-TO-YOUR-APP>

验证您在输出中看到“BLUE”。这将每 0.5 秒卷曲一次应用程序，并允许您观察更新。

在另一个选项卡中，您可以启动不同的watch ：

watch -n 1 cf app updating-app

对应用程序进行更改。编辑位于更新应用程序目录中的 index.html 文件并将其更改为“绿色”，请务必保存它。更新正在运行的应用程序。在单独的选项卡中，使用滚动策略部署更新：

cf push --strategy rolling

在运行 watch 的选项卡中，您将观察到您被路由到 BLUE 和 GREEN。随着更多 GREEN 实例的启动，您将看到更多 GREEN 响应，直到所有实例都更新完毕。此时，您不再看到 BLUE。在 cf app watch 中，您还将看到 Cloud Foundry 删除和替换实例。

如果您有许多应用程序实例，您可能不想在 CLI 返回之前等待所有这些实例都更新完毕。在这些情况下，您可以在推送中使用 --no-wait 标志。使用时，CLI 将在第一个更新的实例变得健康后返回。

让应用程序和 watch 命令运行。在下一节中，我们将了解如何在您需要回滚的情况下取消活动部署。

Cancelling a Rolling Deployment

您可能会在滚动部署期间注意到问题并需要回滚。 您可以通过使用 cf cancel-deployment 取消部署来实现此目的。 取消部署时，应用程序将通过执行以下操作恢复到部署开始之前的状态：

• 扩大原始 Web 流程
• 删除任何部署工件
• 重置应用程序上的 current_droplet。

cancel-deployment 命令旨在尽快将应用程序恢复到其原始状态，并且不保证零停机时间。

注意：取消部署仅适用于正在进行的滚动部署。 我们将在另一部分讨论活动部署范围之外的回滚。

实例

让我们更改应用程序，重新部署并取消部署。

1. 将 index.html 更改为 RED 并保存。
2. 推送更改，这次还添加了 --no-wait 标志。 这样您就不需要第三个终端窗口。
3. 当 CLI 返回时，切换回窗口运行观察。
4. 当您开始看到 RED 时，使用 cf cancel-deployment updates-app 在另一个终端窗口中取消部署。

您应该会看到 RED 实例角色变回 GREEN。 如果您等待的时间过长，您将看到类似“未找到应用程序的活动部署”之类的消息。 你可以再试一次。

最后，清理：

1. 通过在这些终端窗口中按 CTRL-C 取消监视命令。
2. 使用 cf delete updates-app 删除应用程序。