总是睡在打包机配置上？

Posted 2023-02-19

【中文标题】总是睡在打包机配置上？

【英文标题】：Always sleep on packer provisioning?

【发布时间】：2015-06-07 12:58:38

【问题描述】：

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

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

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

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

在启动任何配置程序之前，您是否总是需要sleep 30，尤其是：

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

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

"provisioners": [

    "type": "shell",
    "inline": [
        "sleep 30"
    ]
,
...]

【参考方案1】：

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

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

【讨论】：

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

【参考方案2】：

不，没有必要在每个配置器之前休眠 - 只有第一个或在配置器重新启动机器之后。

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

【讨论】：

问题是，Packer 允许您以任何顺序使用您想要的任何类型的配置器，并且它可以并行处理。以此为模型，您可以轻松地拥有竞争条件或锁定。 Packer 不知道您声明的每个过程的后果。处理竞争和锁（根据我的经验）是通过重新排序供应商的自动化来最实际地处理的；但是如果您遇到比赛或锁定并且无法重新排序供应商，睡眠可以提供帮助。通常不需要编写编排或等待句柄 - 包是非常可变的。

【参考方案3】：

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

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