Once you go Vagrant, you never go back....
On Fri, Aug 15, 2014 at 11:16 AM, James Guymon <[email protected]> wrote: > Another up-vote from a vagrant user here. > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Sean Thayne > Sent: Friday, August 15, 2014 11:05 AM > To: Tim Harper > Cc: uphpu > Subject: Re: [UPHPU] Vagrant (up or down) > > Yo Jim! > > Vagrant is amazing. For a quick test drive, you should check out > www.puphpet.com for a quick setup. It's really easy to customize after > the fact as well. So with Playground's stuff, we have it so you can just > run `vagrant up` and it does everything, configures apache, creates local > db, propagates it, etc. It's really slick. We store the vagrant files in > the git repo with the source code, so it's just a git clone and vagrant up, > and your ready to code. > > Also a side note, it uses shared folders, so you can use whatever mac > editor or pc editor you want, and code edits are fast. It also allows your > editor to be able to index all your code fast, because it's all still local. > > Best setup I've ever used > > -Sean Thayne > > > On Fri, Aug 15, 2014 at 10:55 AM, Tim Harper <[email protected]> wrote: > > > 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 > > > > _______________________________________________ > > 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 > _______________________________________________ UPHPU mailing list [email protected] http://uphpu.org/mailman/listinfo/uphpu IRC: #uphpu on irc.freenode.net
