This depends on your environment. You may be able to find a pre-built image with your stack all ready to go, and that'd be the simplest.
The more custom your setup, the more complex it gets. Vagrant allows you to create a provisioning script to further configure the instance after spinning it up. It also has tools integration with tools like Puppet or SaltStack, which are great if you want to keep dev environment in sync with test / production environments. On Aug 15, 2014, at 10:30, thin <[email protected]> wrote: > Vagrant seems like a universal thumbs up then. Cool. Can any of you speak > to what the ramp up / setup effort might be? > > > > > On Fri, Aug 15, 2014 at 10:06 AM, David Skinner <[email protected]> > wrote: > >> We also use Vagrant everyday here where I work. For the same reasons >> Richard Miller gave. We do have a different configuration though. Our >> project has many domains pointed to our code base. Our provisioning sets up >> each project with a specific private IP address. 10.0.0.2. We then use >> dnsmasq and configure a custom TLD to point to the vagrant machine. The >> dnsmasq config uses a wildcard to route all traffic on our local machine >> using the custom TLD to the IP address of our vagrant machine. Our TLD is >> ".sc". So I can simply type something like clientdomain.com.sc in my >> browser and dnsmasq will route it to my vagrant box, loading the clients >> version of our site. This helps us as we bring on new clients all the time >> using their own domain. We have a table in the database that stores the >> clients info along with their domain name. We then refer to that table with >> a provisioning script to dynamically generate the Apache configs for the >> vagrant environment, automatically appending the .sc TLD. >> >> Before we use Vagrant, it could take a person 1 - 3 days to get their >> environment set up correctly. Now with Vagrant, we can have someone up and >> running in about an hour. You can also use Vagrant to provision EC2 >> instances on Amazon if that's something that would be helpful. >> >> Another use case where Vagrant came in super helpful was a PHP version >> upgrade. We simply cloned a new copy of our project. Made an upgrade >> branch. Changed the provision scripts to install a newer version of PHP. >> Pushed the branch up to origin. Then each developer could clone the >> project, switch to that branch, then run vagrant up to provision that >> environment with the new version of PHP. Then we all worked together to >> make the code compatible with the newer version of PHP. Since we had this >> second clone of the codebase, we could easily turn of the newer machine and >> turn on the old one to perform any emergency bug fixes that were needed on >> the Production servers. >> >> We use Debian 7 as a base. >> We use a collection of shell scripts to provision the environment. Though >> when time permits we'd like to move to something better like Puppet. >> >> dnsmasq: http://www.thekelleys.org.uk/dnsmasq/doc.html >> AWS EC2 integration: https://github.com/mitchellh/vagrant-aws >> > > _______________________________________________ > > UPHPU mailing list > [email protected] > http://uphpu.org/mailman/listinfo/uphpu > IRC: #uphpu on irc.freenode.net _______________________________________________ UPHPU mailing list [email protected] http://uphpu.org/mailman/listinfo/uphpu IRC: #uphpu on irc.freenode.net
