packer - 总是在打包程序配置上 sleep ？

Question

在我对 Packer 的探索中，我想知道以下几点:

docs状态(作为向 AWS 预配 Ubuntu 镜像的入门步骤的一部分):

Note: The sleep 30 in the example above is very important. Because Packer is able to detect and SSH into the instance as soon as SSH is available, Ubuntu actually doesn't get proper amounts of time to initialize. The sleep makes sure that the OS properly initializes.

它显示了一个示例，其中 shell 配置器(内联)是第一个启动的配置器。

您是否总是需要 sleep 30在任何供应商开始之前，特别是:

当我使用文件配置器启动配置块时，它是否会自动等待操作系统正确初始化？

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

如果是这样，一般建议您始终将其放在配置块的顶部:

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

Answer 1

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

我在 apt 之前不使用 sleep 命令，但是我的软件包到处都是失败的。我正在使用 Packer AWS ebs 构建器。文档中有一个声明，它用一个非常相似的策略解决了我的问题——它轮询 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 上构建失败会浪费大量时间。