总是睡在打包机配置上?

mkd*_*mkd 4 packer

在我对Packer的探索中,我想知道以下内容:

所述文档的状态(如,其中一个Ubuntu的图像被提供到AWS使用入门步骤的一部分):

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

它显示了一个示例,其中shell配置程序(内联)是第一个启动的配置程序.

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

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

如果是这样,那么一般建议您始终将其置于您的配置块之上:

"provisioners": [
{
    "type": "shell",
    "inline": [
        "sleep 30"
    ]
},
{...}]
Run Code Online (Sandbox Code Playgroud)

Ele*_*eli 8

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

我之前没有使用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"
  ]
}
Run Code Online (Sandbox Code Playgroud)

所以它并不是绝对必要的,但是你会发现,一旦你有了Packer的工作版本,你仍然希望通过计时和重试来提高脚本和其他配置程序的可靠性.Packer失败的构建是一个很大的浪费时间.