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

AWS OpsWorks 堆栈故障排除

本节包含一些常见的 AWS OpsWorks Stacks 问题及其解决方案。

无法管理实例

问题：您无法继续管理过去可管理的实例。在某些情况下，日志可能会显示与以下内容相似的错误。

Aws::CharlieInstanceService::Errors::UnrecognizedClientException - The security token included in the request is invalid.

原因：如果编辑或删除实例所依赖的 AWS OpsWorks 以外的资源，则会发生此错误。下面是一些关于可中断与实例的通信的资源变更的示例。

解决方案：不要删除您的实例所依赖的 IAM 用户或角色。如果可以，仅当从属实例运行时编辑卷或存储配置。 AWS OpsWorks 用于管理实例的负载均衡器或 EIP 成员资格。 AWS OpsWorks 当您注册实例时，为了防止出现意外删除用户后无法管理注册的实例的情况，可将 --use-instance-profile 参数添加到您的 register 命令，以使用实例的内置实例配置文件。

Chef 运行后，实例不启动

问题：在 Chef 11.10 或配置为使用自定义说明书的较早版本的堆栈上，当 Chef 运行 (使用社区说明书) 后，实例不启动。日志消息可表明配方无法编译 (“配方编译错误”)，或无法负载，因为它们找不到依赖项。

原因：最可能的原因是自定义或社区说明书不支持您的堆栈使用的 Chef 版本。一些常见的社区说明书 (如 apt 和 build-essential) 与 Chef 11.10 之间存在已知的兼容性问题。

解决方案：在开启了 “使用自定义 Chef 食谱” 设置的 Stacks AWS OpsWorks 堆栈上，自定义或社区食谱必须始终支持堆栈使用的 Chef 版本。将社区说明书固定到一个与在您的堆栈设置中配置的 Chef 版本兼容的版本 (即，将说明书版本号设置为特定版本)。要查找受支持的社区说明书版本，请查看无法编译的说明书的变更日志，并仅使用您的堆栈将支持的说明书的最新版本。要固定说明书版本，请在您的自定义说明书存储库的 Berksfile 中指定精确的版本号。例如，cookbook 'build-essential', '= 3.2.0'。

层的所有实例都没有通过 Elastic Load Balancing 状态检查

问题：您将 Elastic Load Balancing 负载均衡器连接到某个应用程序服务器层，但所有实例都没有通过状态检查。

原因：当您创建 Elastic Load Balancing 负载均衡器时，您必须指定负载均衡器调用的 ping 路径，以确定实例的状态是否良好。请确保指定适用于您的应用程序的 ping 路径，默认值是 /index.html。如果您的应用程序不包括 index.html，您必须指定适当的路径，否则将无法通过状态检查。例如，Chef 11 Linux 堆栈入门 中使用的 SimplePHPApp 应用程序不使用 index.html；这些服务器的适当的 ping 路径是 /。

解决方案：编辑负载均衡器的 ping 路径。有关更多信息，请参阅 Elastic Load Balancing

无法与 Elastic Load Balancing 负载均衡器通信

问题：您创建一个 Elastic Load Balancing 负载均衡器并将它连接到一个应用程序服务器层，但当您单击负载均衡器的 DNS 名称或 IP 地址以运行该应用程序时，您得到以下错误：“The remote server is not responding (远程服务器未响应)”。

原因：如果您的堆栈正在默认 VPC 中运行，则当您在区域中创建 Elastic Load Balancing 负载均衡器时，您必须指定安全组。该安全组必须拥有入口规则，这些规则允许来自您的 IP 地址的入站流量。如果您指定 default VPC security group，则默认入口规则不接受任何入站流量。

解决方案：编辑安全组入口规则，以接受来自适当 IP 地址的入站流量。

导入的本地实例重启后无法完成卷设置

问题：您重新启动已导入到 AWS OpsWorks 堆栈中的 EC2 实例， AWS OpsWorks Stacks 控制台将实例状态显示为失败。Chef 11 或 Chef 12 实例上都会发生此问题。

原因：AWS OpsWorks Stacks 在设置过程中可能无法将卷连接到您的实例。一种可能的原因是：当您运行 setup 命令时， AWS OpsWorks Stacks 覆盖了您的实例上的卷配置。

解决方案：打开实例的 Details 页面，检查 Volumes 区域中的卷配置。请注意，您只有在实例处于 stopped 状态时才能更改您的卷配置。请确保每个卷都拥有指定的挂载点和名称。在重启实例之前，请确认您在 AWS OpsWorks Stacks 的配置中提供了正确的挂载点。

重启后 EBS 卷不重新连接

问题：您使用 Amazon EC2 控制台将 Amazon EBS 卷连接到实例，但是当您重启实例时，卷无法连接。

原因： AWS OpsWorks 堆栈只能重新连接它知道的 Amazon EBS 卷，这些卷仅限于以下内容：

解决方案：只能使用 AWS OpsWorks 堆栈控制台、API 或 CLI 来管理您的 Amazon EBS 卷。如果您想对一个堆栈使用您账户的 Amazon EBS 卷之一，请使用该堆栈的 资源 页面注册该卷并将其附加到实例。有关更多信息，请参阅 资源管理。

无法删除 AWS OpsWorks Stacks 安全组

问题：删除堆栈后，仍有许多 AWS OpsWorks 堆栈安全组无法删除。

原因：必须按照特定的顺序删除安全组。

解决方案：首先，确保任何实例都未使用安全组。然后，按照下面的顺序删除以下任何安全组 (如果存在)。

意外删除了 AWS OpsWorks Stacks 安全组

问题：您删除了其中一个 AWS OpsWorks Stacks 安全组，需要重新创建它。

原因：这些安全组通常是无意中被删除的。

解决方案：重新创建的组必须与原始组完全相同，包括组名称的大写字母也要相同。首选的方法不是手动重新创建组，而是让 AWS OpsWorks Stacks 为您执行此任务。只需在同一 AWS 区域和 VPC（如果有）中创建一个新堆栈， AWS OpsWorks Stacks 就会自动重新创建所有内置安全组，包括您删除的安全组。如果您不再需要该堆栈，则随后您可以删除它；安全组将保留。

Chef 日志突然终止

问题：Chef 日志突然终止；日志结尾未指示运行成功，也未显示异常情况和堆栈跟踪。

原因：此行为通常是由于内存不足造成的。

解决方案：创建一个较大的实例，然后使用代理 CLI run_command 命令再次运行配方。有关更多信息，请参阅 执行配方。

说明书未更新

问题：您更新了说明书，但是堆栈的实例仍然运行旧的配方。

原因： AWS OpsWorks Stacks 在每个实例上缓存食谱，并从缓存而不是存储库中运行食谱。当您启动新实例时， AWS OpsWorks Stacks 会将您的食谱从存储库下载到实例的缓存中。但是，如果您随后修改您的自定义说明书，则 AWS OpsWorks Stacks 不会自动更新联机实例的缓存。

解决方案：运行 U pdate Cookbooks 堆栈命令，明确指示 AWS OpsWorks Stacks 更新在线实例的食谱缓存。

实例停滞在启动状态

问题：当您重启实例或自动修复自动重启实例时，启动操作停滞在 booting 状态。

原因：引发此问题的一种可能原因是 VPC 配置，包括默认 VPC。实例必须始终能够与 AWS OpsWorks Stacks 服务、Amazon S3 以及软件包、食谱和应用程序存储库进行通信。例如，如果您从默认 VPC 中移除默认网关，则这些实例将失去与 AWS OpsWorks Stacks 服务的连接。由于 AWS OpsWorks Stacks 无法再与实例代理通信，因此它会将实例视为失败并且 auto 对其进行修复。但是，如果没有连接， AWS OpsWorks Stacks 就无法在治疗过的实例上安装实例代理。如果没有代理， AWS OpsWorks Stacks 就无法在实例上运行安装配方，因此启动操作无法超出 “启动” 状态。

解决方案：修改您的 VPC 配置，以便实例拥有所需的连接。

实例意外重启

问题：已经停止的实例意外重启。

原因 1：如果您为实例启用了自动修复功能，则 AWS OpsWorks Stacks 会定期对关联的 Amazon EC2 实例执行状态检查，并重启状态不佳的实例。如果您使用 Amazon EC2 控制台、API 或 CLI 停止或终止 AWS OpsWorks 堆栈管理的实例，则不会通知 AWS OpsWorks 堆栈。它会认为已停止的实例状态不佳，并自动重启该实例。

解决方案：仅使用 AWS OpsWorks Stacks 控制台、API 或 CLI 管理您的实例。如果您使用 AWS OpsWorks Stacks 停止或删除实例，则该实例不会重启。有关更多信息，请参阅 手动启动、停止和重启全天候实例 和 删除 AWS OpsWorks 堆栈实例。

原因 2：实例可能会因为各种原因而失败。如果您启用了自动修复， AWS OpsWorks Stacks 会自动重启失败的实例。

解决方案：这是正常操作；除非您不希望 AWS OpsWorks Stacks 重启失败的实例，否则无需执行任何操作。在这种情况下，您应当禁用自动修复功能。

正在对实例运行 opsworks-agent 进程

问题：正在对您的实例运行多个 opsworks-agent 进程。例如：

aws 24543 0.0 1.3 172360 53332 ? S Feb24 0:29 opsworks-agent: master 24543
aws 24545 0.1 2.0 208932 79224 ? S Feb24 22:02 opsworks-agent: keep_alive of master 24543
aws 24557 0.0 2.0 209012 79412 ? S Feb24 8:04 opsworks-agent: statistics of master 24543
aws 24559 0.0 2.2 216604 86992 ? S Feb24 4:14 opsworks-agent: process_command of master 24

原因：这些是执行代理的常规操作所需的合法进程。它们执行诸如处理部署以及将保持活动状态的消息发送回服务等任务。

解决方案：这是常规行为。不要停止这些进程；这样会影响代理的操作。

意外的 execute_recipes 命令

问题：实例的详细信息页面上的 Logs 部分包含意外的 execute_recipes 命令。意外的 execute_recipes 命令还可能显示在 Stack 和 Deployments 页面上。

原因：此问题通常是由权限变更导致的。当您更改用户或组的 SSH 或 sudo 权限时， AWS OpsWorks Stacks 会运行execute_recipes以更新堆栈的实例，还会触发配置事件。出现 execute_recipes 命令的另一个原因是 AWS OpsWorks Stacks 更新了实例代理。

解决方案：这是常规操作；无需执行其任何他操作。

要了解 execute_recipes 命令执行了哪些操作，请转到 Deployments 页面并单击该命令的时间戳。这会打开该命令的详细信息页面，上面列出了已经运行的关键配方。例如，以下详细信息页面对应的是运行了 ssh_users 以更新 SSH 权限的 execute_recipes 命令。

要查看所有详细信息，单击该命令的 Log 列中的 show 以显示关联的 Chef 日志。在日志中搜索Run List。 AWS OpsWorks 堆栈维护配方将出炉。OpsWorks Custom Run List例如，下面是上文中的屏幕截图中显示的 execute_recipes 命令的运行列表，其中显示了与该命令相关联的每个配方。

[2014-02-21T17:16:30+00:00] INFO: OpsWorks Custom Run List: ["opsworks_stack_state_sync",
  "ssh_users", "test_suite", "opsworks_cleanup"]