Tracking Vagrant and Puppet files in your web application’s code repository lets you go back and build and run any version of the software.
That’s a benefit that might be obvious to Puppet people. It’s one that I came to realise through the path of trying Vagrant, and then testing the waters of Puppet. As a web developer (in Limerick, Ireland) with a focus on PHP, it’s helped me a lot.
Let’s say you have a PHP web application with server-side dependencies. You’re tracking that application’s code in a version control repository.
PHP’s Composer lets you define component dependencies for the application. But you might also have an external service as a dependency, like elasticsearch. Your code’s dependency on elasticsearch’s version will change over time. If you want to check out a commit from 6 months ago, you might have the problem of having the wrong version of elasticsearch installed on your web development machine, or a standard once-off virtual machine.
Your base dependencies might also have change, like you’re running a newer version of PHP that no longer allows calls to a function the code calls in that older commit.
The same dependencies problem will happen with different builds of the same system. A release build may be a version of software behind the development version.
In this case, you’d be better off with Vagrant handling your virtual machine, and Puppet handling your service dependencies. Puppet will let you define the version of software you want, like a specific version of elasticsearch and PHP.
If it happens that you need to check out an earlier build, you’d check out that version of your code. Then you would start the Vagrant virtual machine (probably first “destroying” your current machine). With Puppet tracking dependencies, the new virtual machine will build for you, using the older dependencies.
One catch to this that I can think of is that a Vagrant machine will define which base machine it wants to use. The default way to specify your base machine is giving it the URL of an external base machine. That URL may indeed go out of service in the future, meaning it’s not available when you’re trying to build from it.
On the subject of builds, I’m finding it easiest to have multiple copies of the project checked out. In each copy, I’ll check out the specific build I want. That means I can run that Vagrant virtual machine separately to my standard development build. A complexity to this is each build may be configured with the same local static IP address. A work-around may indeed be issuing a new IP address to each release (although unique available address could then run out, in which case you might just start again with the first IP address again for the next release).
If you want to build a Vagrant machine with Puppet, and don’t know where to start, I recommend PuPHPet. It’s a web application that will generate Puppet scripts based on your options. Thanks to @jamiebarry for this tip.