5

On my exploration of Packer I wonder the following:

The docs state (as part of the getting started steps where a Ubuntu image is provisioned to AWS):

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.

It shows an example where a shell provisioner (inline) is the first provisioner to kick in.

Do you always need to sleep 30 before any provisioner is to start, in particular:

  • When I start the provisioning block with a file provisioner, does it automatically wait until the OS properly initializes?
  • When I run a script/scripts shell provisioner instead of an inline block of commands, do I need to start the first script with sleep 30?

If so, would a general suggestion be that you always put this on top of your provisioning block:

"provisioners": [
{
    "type": "shell",
    "inline": [
        "sleep 30"
    ]
},
{...}]
mkd
  • 79
  • 1
  • 6

3 Answers3

10

You can run without the sleep, but particularly on AWS it's going to be a crapshoot whether it works or not. Packer builds can be long and complex, and some sleep here and there can greatly improve your success rate. You don't have to run a sleep before every provisioner though, just the first one. After that the OS is up and everything should be running along nicely.

I don't use the sleep command before apt, but my packages were failing all over the place. I'm using the Packer AWS ebs builder. There's a statement in the docs that solved my problems with a very similar strategy - it polls against cloud-init to see that it has finished; cloud-init being the aws init built into the Ubuntu ec2 images produced by canonical. 

{
"type": "shell",
  "inline": [
    "while [ ! -f /var/lib/cloud/instance/boot-finished ]; do echo 'Waiting for cloud-init...'; sleep 1; done"
  ]
}

So it's not strictly necessary, but you'll find that once you have a working build with Packer, you still will want to improve the reliability of your scripts and other provisioners with timing and retries. A failed build on Packer is a big time waster.

Ele Munjeli
  • 446
  • 1
  • 7
  • 15
  • In Google Compute Engine, instances run cloud-init on boot to setup GCE specific apt repositories. If you try to do apt operations in a shell provisioner they may fail because they run before cloud-init has finished. This as the first provisioner helps alleviate that scenario as well. – Andy Shinn Apr 08 '19 at 19:44
0

No, a sleep before every provisioner is not necessary - only the first one or after a provisioner restarts the box.

Once Packer has connected to the running instance successfully, further sleeps will just unnecessarily slow down your Packer runs.

Matthew Fellows
  • 3,669
  • 1
  • 15
  • 18
  • The thing is, Packer allows you to use whatever kind of provisioner you want in any order, and it processes in parallel where it can. With this as the model, you can easily have race conditions or locks. Packer isn't aware of the ramifications of every process you've declared. Handling races and locks is most practically handled (in my experience) by just reordering the automation of the provisioners; but in cases when you hit a race or lock and provisioners can't be reordered, sleep can help. It's generally not necessary to write orchestration or wait handles - the pack is pretty variable. – Ele Munjeli Jan 23 '17 at 20:25
0

Some images may do some jobs on its start, and you can find out your builds fail. You can use different checks to make sure the vm is ready to be provisioned like Ele Munjeli said. Also you can use sleep once as the first provisioner as you said.

Please note there is a better solution for sleep: you can use pause_before_connecting communicator option and set up required time. See the docs

Andrey
  • 41
  • 5