Question

在我对Packer的探索中，我想知道以下内容：

docs状态（作为将Ubuntu映像配置到AWS的入门步骤的一部分）：

注意：上例中的睡眠30非常重要。因为一旦SSH出现，Packer就能够检测并SSH到实例中可用，Ubuntu实际上没有得到适当的时间初始化。睡眠可确保操作系统正确初始化。

它显示了一个示例，其中shell配置程序（内联）是第一个启动的配置程序。

在开始配置任务之前，您是否始终需要sleep 30，特别是：

当我使用文件配置程序启动配置块时，是否会自动等待操作系统正确初始化？
当我运行脚本/脚本shell配置程序而不是内联命令块时，是否需要使用sleep 30启动第一个脚本？

如果是这样，一般建议您始终将其放在配置块之上：

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

Answer 1

你可以在没有睡眠的情况下运行，但特别是在AWS上，无论它是否有效，它都将成为一个废话。 Packer构建可能是漫长而复杂的，有些人在这里睡觉，可以大大提高你的成功率。您不必在每个供应商之前运行睡眠，只需要在第一个供应商之前运行。之后操作系统启动，一切都应该很好地运行。

我没有在apt之前使用sleep命令，但是我的软件包在整个地方都失败了。我正在使用Packer AWS ebs构建器。在文档中有一个声明用一个非常类似的策略解决了我的问题 - 它对cloud-init进行了调查，看它已经完成了; cloud-init是由规范生成的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失败的构建是一个很大的浪费时间。

Answer 2

不，在每个配置器之前休眠是不必要的 - 只有第一个或在配置器重启盒子之后。

一旦Packer成功连接到正在运行的实例，进一步的睡眠将不必要地减慢您的Packer运行速度。

总是睡在打包机配置上？

2 个答案: