对 AWS OpsWorks Stacks 进行故障排除

重要

AWS OpsWorks Stacks 不再接受新客户。在 2024 年 5 月 26 日之前，现有客户将能够照常使用 OpsWorks 控制台、API、CLI 和 CloudFormation 资源，届时这些工具或资源将停用。为准备此过渡，我们建议您尽快将堆栈过渡到AWS Systems Manager。有关更多信息，请参阅 AWS OpsWorks Stacks 生命周期终止常见问题解答 和 将 AWS OpsWorks Stacks 应用程序迁移到 AWS Systems Manager Application Manager：

这部分包含一些常见的 AWS OpsWorks Stacks 问题和它们的解决方案。

无法管理实例

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

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

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

• 在 AWS OpsWorks Stacks 之外意外删除了与实例关联的 IAM 用户或角色。这导致实例上安装的 AWS OpsWorks 代理与 AWS OpsWorks Stacks 服务之间的通信失败。在实例的整个生命周期中，都需要与实例关联的 用户。

• 在实例处于离线状态时编辑卷或存储配置可能会导致实例不可管理。

• 向 ELB 手动添加 EC2 实例。每当实例进入或退出在线状态时，AWS OpsWorks 都会重新配置分配的 Elastic Load Balancing 负载均衡器。 仅将它知道的实例视为有效成员；添加到 AWS OpsWorks 以外的实例或通过某些其他过程添加的实例都将被删除。其他所有实例都将被删除。

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

Chef 运行后，实例不启动

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

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

解决方案：在已打开 AWS OpsWorksUse custom Chef cookbooks 设置的 Stacks 堆栈上，自定义或社区说明书必须始终支持您的堆栈使用的 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 地址的入站流量。

1. 在 Amazon EC2 控制台的导航窗格中，单击 Security Groups。

2. 选择负载均衡器的安全组。

3. 单击 Inbound 选项卡上的 Edit。

4. 添加入口规则，并将 Source 设置为适当的 CIDR。

   例如，指定 Anywhere 会将 CIDR 设置为 0.0.0.0/0，这会指示负载均衡器接受来自任何 IP 地址的传入流量。

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

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

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

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

重启后 EBS 卷不重新连接

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

原因： AWS OpsWorks Stacks 只能重新连接以下已知 Amazon EBS 卷：

• 由 AWS OpsWorks Stacks 创建的卷。

• 您账户中的卷，您已明确使用 Resources 页面向堆栈注册这些卷。

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

无法删除 AWS OpsWorks Stacks 安全组

问题：删除堆栈后，会遗留许多 AWS OpsWorks Stacks 安全组，无法删除。

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

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

1. AWS-OpsWorks-Blank-Server

2. AWS-OpsWorks-Monitoring-Master-Server

3. AWS-OpsWorks-DB-Master-Server

4. AWS-OpsWorks-Memcached-Server

5. AWS-OpsWorks-Custom-Server

6. AWS-OpsWorks-nodejs-App-Server

7. AWS-OpsWorks-PHP-App-Server

8. AWS-OpsWorks-Rails-App-Server

9. AWS-OpsWorks-Web-Server

10. AWS-OpsWorks-Default-Server

11. AWS-OpsWorks-LB-Server

意外删除了 AWS OpsWorks Stacks 安全组

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

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

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

Chef 日志突然终止

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

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

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

说明书未更新

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

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

解决方案：运行 Update Cookbooks 堆栈命令，以明确指示 AWS OpsWorks Stacks 更新您的联机实例的说明书缓存。

实例停滞在启动状态

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

原因：引发此问题的一种可能原因是 VPC 配置，包括默认 VPC。实例必须始终能够与 AWS OpsWorks Stacks 服务、Amazon S3、程序包、说明书和应用程序存储库通信。例如，如果您删除默认 VPC 的默认网关，则实例会失去与 AWS OpsWorks Stacks 服务的连接。因为 AWS OpsWorks Stacks 无法再与实例代理通信，它会将实例视为失败并自动修复它。但是，在没有连接的情况下，AWS OpsWorks Stacks 无法在修复的实例上安装实例代理。如果没有代理，AWS OpsWorks Stacks 就无法运行实例上的 Setup 配方，因此启动操作就无法跳过“启动”状态。

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

实例意外重启

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

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

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

原因 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 以更新堆栈的实例，同时触发 Configure 事件。出现 execute_recipes 命令的另一个原因是 AWS OpsWorks Stacks 更新了实例代理。

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

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

要查看所有详细信息，单击该命令的 Log 列中的 show 以显示关联的 Chef 日志。搜索该日志以查找 Run List。AWS OpsWorksStacks 维护配方将位于 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"]