总是使用 Packer provisioning 进行休眠吗？

Question

在我探索Packer时，我想知道以下内容： 文档中提到（作为入门步骤的一部分，其中Ubuntu镜像被提供给AWS）：

注意：上面示例中的sleep 30非常重要。因为当SSH可用时，Packer能够检测并SSH到实例，Ubuntu实际上没有足够的时间来初始化。sleep确保操作系统正确初始化。

它展示了一个示例，其中一个shell provisioner（inline）是第一个启动的provisioner。

您是否总是需要在任何provisioner开始之前都sleep 30，特别是：

当我使用文件provisioner启动provisioning block时，它是否会自动等待操作系统正确初始化？

当我运行脚本/脚本shell provisioner而不是一块内联命令时，我是否需要使用sleep 30来启动第一个脚本？

如果是这样，那么一个普遍的建议是始终将其放在provisioning block的顶部：

"provisioners": [
{
    "type": "shell",
    "inline": [
        "sleep 30"
    ]
},
{...}]

- mkd

Answer 1

你可以不使用sleep命令运行，但特别是在AWS上，它是否有效将是一个未知数。Packer构建可能会很长且复杂，这时偶尔加入一些sleep可以极大地提高成功率。你不必在每个provisioner之前都运行sleep，只需要在第一个provisioner之前运行即可。之后操作系统应该已经启动并且一切都应该正常运行。

我在apt之前没有使用sleep命令，但我的软件包到处都失败了。我正在使用Packer AWS ebs builder。文档中有一条语句解决了我的问题，采用了非常类似的策略-它针对cloud-init进行轮询以确保其已完成；cloud-init是内置于由canonical生产的Ubuntu ec2映像中的aws init。

{
"type": "shell",
  "inline": [
    "while [ ! -f /var/lib/cloud/instance/boot-finished ]; do echo 'Waiting for cloud-init...'; sleep 1; done"
  ]
}

所以这不是绝对必要的，但是你会发现一旦你用Packer构建成功后，你仍然希望通过时间和重试来提高脚本和其他配置文件的可靠性。在Packer上构建失败是一个巨大的时间浪费。

- Ele Munjeli

---

在Google Compute Engine中，实例在启动时运行cloud-init来设置GCE特定的apt存储库。如果您尝试在shell提供程序中执行apt操作，则可能会失败，因为它们在cloud-init完成之前运行。作为第一个提供程序，这有助于缓解这种情况。 - Andy Shinn

Answer 2

不需要在每个供应程序之前都进行休眠 - 只需要在第一个供应程序或供应程序重新启动盒子后进行休眠。

一旦Packer成功连接到运行的实例，进一步的休眠只会不必要地减慢您的Packer运行速度。

- Matthew Fellows

---

问题是，Packer允许您以任何顺序使用任何类型的配置程序，并在可能的情况下并行处理。基于这个模型，您很容易遇到竞争条件或锁定。Packer不知道您声明的每个进程的影响。在我的经验中，处理竞争和锁最实用的方法是重新排序配置程序的自动化；但在某些情况下，当您遇到竞争或锁定且无法重新排序配置程序时，可以使用sleep来帮助解决问题。通常不需要编写编排或等待句柄 - pack相当灵活。 - Ele Munjeli

Answer 3

有些图像在启动时可能会执行某些任务，这可能导致构建失败。您可以使用不同的检查方法来确保虚拟机已准备好被设置，就像Ele Munjeli所说的那样。 另外，您可以像您所说的那样在第一个配置程序中使用sleep。

请注意，sleep有更好的解决方案：您可以使用pause_before_connecting通信器选项并设置所需的时间。请参见文档

- Andrey