4

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

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

注意：上例中的 sleep 30 非常重要。因为 Packer 能够在 SSH 可用时立即检测并通过 SSH 进入实例，所以 Ubuntu 实际上没有足够的时间来初始化。睡眠确保操作系统正确初始化。

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

sleep 30在启动任何配置程序之前，您是否总是需要这样做，特别是：

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

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

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

3 回答 3

9

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

我在 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 上构建失败会浪费大量时间。

于 2016-04-25T05:02:25.447 回答
0

不，不需要在每个provisioner之前休眠- 只有第一个provisioner 或provisioner 重新启动box 之后。

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

于 2016-04-27T11:26:03.957 回答
0

一些图像可能在开始时就完成了一些工作，你会发现你的构建失败了。您可以使用不同的检查来确保虚拟机已准备好进行配置，就像 Ele Munjeli 所说的那样。你也可以使用sleep一次作为你所说的第一个供应商。

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

于 2021-11-12T12:10:28.043 回答