Packer 'chroot' builder - faster, flexible multi-environment builds?

[Steven Schlansker]

Hello everyone,

I've toyed with Packer a bit for building images, and am fairly comfortable with the "grey-haired neck beard" traditional approach to building images (via e.g. debootstrap[1] and chroot) and would appreciate some input.

Packer's approach to building seems overly complicated to me.  It seems like I can start with a pre-existing image or a debootstrap environment, use a chroot to get inside of the image and run the Provisioners, and then take the result and 'specialize' it in post-processing -- e.g. install AWS tools and bundle as AMI, or install VirtualBox Guest Additions and package as a VDI.  The bulk of the provisioning work is shared and the post-processors can run in parallel at the end.  This ensures all of your built images are nearly identical, saves on resources, and removes a lot of the complexity of interacting with live VMs (be it AWS, VirtualBox, etc).

As an example of all the things that can be totally eliminated:
* AWS key / security group management
* Wait loops for VMs to come up
* Running things through SSH
* All interaction with e.g. VirtualBox

Has anyone considered adding such a builder to Packer?  Is there some reason this is not a good idea?  I wish Packer was written in something other than Go so I would feel confident to prototype it myself, but alas...

[1] http://diogogomes.com/2012/07/13/debootstrap-kvm-image/

[Alvaro Miranda Aguilera]

hello,

in the meantime, you can do the boot of the box with deboostrap/lxc/etc and use the null builder.. like a 2 step script

https://packer.io/docs/builders/null.html

then once the new environment is up, just use ssh to connect and benefit from the provisioners.

will this help somehow?

--
You received this message because you are subscribed to the Google Groups "Packer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to packer-tool...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Juanjo Presa]

Hi Steven.

I'm very agree with you about chroot image creation. I'm looking for something similar to your idea. Did you advanced in any direction about this?

[Juanjo Presa]

Yes, Im going with shell scripting and rules so much. Maybe dont scale well but i can live with it.

I'll keep some eyes un your code. Thanks a lot.

Wondering why hashicorp dont set this path. With rkt, lxc and systemd-nspawn hype is a very simple powerfull one.

Thanks for your time.

El 5 ago. 2016 7:39 p. m., "Steven Schlansker" <stevensc...@gmail.com> escribió:

Hi Juanjo,

I did end up prototyping out my approach.  I was very pleased with how well it worked,
we found that by doing the bulk of the work in a local chroot and not using network
assets our build times improved significantly (sometimes 2-3x faster) and were more
reliable.  It also made it easier for us to more directly control exactly
what went into our images, and guarantee that images built for different environments
are almost exactly the same.

The downside obviously is it is truly a "build your own" solution, cobbled together
with shell scripts and glue.  I placed the first piece of the puzzle out as open
source:

https://github.com/opentable/otpl-ami-ubuntu

but please understand that it is not a finished work, and while I am happy to
spend some time answering questions if you go down this path, you will have
to be willing to spend some time figuring out poorly documented APIs
(I'm looking at you, AWS) and difficult to diagnose issues when your
images don't boot for whatever reason.