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" <[email protected]> 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. > > > On Aug 4, 2016, at 11:53 PM, Juanjo Presa <[email protected]> wrote: > > > > 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? > > > > El martes, 6 de enero de 2015, 20:16:30 (UTC+1), Steven Schlansker > escribió: > > 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/ > > > > -- This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list. GitHub Issues: https://github.com/mitchellh/packer/issues IRC: #packer-tool on Freenode --- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/packer-tool/CAJnHUTCB6sRRDwtG%3Dbc6_OzBFXCX-YwG7YCV3b_wxcW8rb2FcA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
