I want to stress that this is the _first public release_. There is a lot of work to be done and a lot of improvements to be made. It may not be "production ready" but it is definitely "experimentation ready." Although I know many companies already starting to use this in production.
I also want to note that although I made Vagrant as well, Packer is not tied to Vagrant in ANY WAY. Packer stands on its own as an extremely useful tool. However, Packer can be used to make Vagrant boxes, as well.
ENJOY!
The docs look good, but it's hard to see which steps to follow in what order for someone who hasn't tried to automate this kind of thing before.
For the dev/prod parity use case, where do you usually draw the line between Packer and Vagrant? I'm currently building boxes with Veewee with all dependencies pre-installed and distributing this to the team. Vagrant could easily deal with this, installing dependencies when the VM is launched using provisioners.
Does anyone have any preferences/reasons to go one way or another?
How does something like Packer/Vagrant help me? From what I understand, all they do is create a VM, which just takes two seconds in VirtualBox anyway. There must be a benefit, since everyone is using them, but I'm missing it. Can anyone please explain?
Totally depends on what you need doing. Might want to check out use cases in the packer documentation.
There is some overlap in all these tools. ThAnsible/Salt/Chef/Puppet tend to used to manage "live" OS's/systems, keeping them updated, deploying new builds to them. Although some like Ansible are more generic.
Vagrant and Packer(I know little) manage images. Starting, stoping, provisioning (and often running one of the above Configuration Managments to finish customizing. Although some believe in running from pure AMI, updating them instead of the live systems).
They get more power when there are many devs, lots of images. I.E. when you have enough complexity you need help managing it.
If your small or simple (no negative connotation implied) they probably aren't worth it. I'm one man shop and use Ansible cause it's the right fit for that (although it's expanding fast).
Maybe it's just that I don't have a big enough need for it, but I did see people using it for single VMs/servers, so I was wondering.
Thanks for the explanation! Also, have you seen ansible's pull mode? I just saw it the other day and I am itching to try it, it looks phenomenal.
1. Single command setup across virtualization platforms
2. Tight integration with provisioning tools (ships local config to VM and runs)
3. Network configuration*
4. Automated shared folders (includes NFS since VBox has really bad shared folders)
5. Generally homogeneous config across host and virtualization platforms
6. Safe cleanup on command cancellation (ie, very safe/sane command line behavior)
There's much more to add but this is nice short list. [UPDATE] Generally speaking it takes the idea of using VMs locally to guarantee a development environment/state and streamlines the process enormously.
* Most people underestimate the number of ways that you can screw up network config on local VMs.
No more going trough a list of VMs and asking yourself if you left any work on that or if you can scrap it. Just `vagrant destroy` and `vagrant up` when you need it again. Plus the provisioning bits gets tested a lot more.
Anyway, thanks for that article, very informative.
Edit: Just Checked GitHub, it is Written in Go, Interesting..... Another sign of Ruby being painfully slow.
Distributing programs in written in Go is _much_ easier that distributing them in Ruby, i.e. cross compile and ship the binary, but distribution of Ruby programs is hard.
Too much time is wasted on 'omnibus' projects to distribute Ruby programs, just look at Chef or Sensu or Mitchell's own Vagrant installers project:
https://github.com/mitchellh/vagrant-installers
(I don't mean to say those projects were a waste of time, but that it seems like this should be a 'solved' problem).
I wonder if there is anything developers can do as a community to help solve the problems these distributors feel they have?
There are other reasons but this was a _big_ one.
There are two ways to make AMIs: EBS-backed or instance-store. For instance-store, you basically need to debootstrap a chroot or something like that. You can do this offline, technically. EBS-backed you just launch a source AMI, build on that, then re-snapshot it.
For the purposes of a 0.1, Packer currently only supports the EBS-backed approach. This is not a technical limitation, however, and in a future version I do want to add the ability to make instance store.
* Packer abstracts creation of images.
* Vagrant abstracts running images, via a VM, and applying changes to images (via chef/puppet, although that seems to overlap with Packer as well).
* Docker seems to abstract both creation of images (via docker build) and running of images (albeit only on top of LXC).
To complicate things further, it seems like Vagrant has some initial support for running (Linux) images on top of LXC (via Fabio Rehm's plugin) and possibly on top of Docker (although the state of the plugin for this is vague).
All this stuff seems very powerful, but the overlap is confusing. My head hurts...
Seems as though there's some overlap between how I provision environments and where this tool fits in. What would be the advantages moving this away from my provisioning tool and towards Packer?
