[UPHPU] Vagrant (up or down)

Matt Gauthier mr.mattyg at gmail.com
Fri Aug 15 13:11:51 MDT 2014


Once you go Vagrant, you never go back....


On Fri, Aug 15, 2014 at 11:16 AM, James Guymon <jguymon at progrexion.com>
wrote:

> Another up-vote from a vagrant user here.
>
> -----Original Message-----
> From: uphpu-bounces at uphpu.org [mailto:uphpu-bounces at uphpu.org] 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 <timcharper at gmail.com> 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 <thinbegin at gmail.com> 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 <
> > david.skinner.83 at gmail.com>
> > > 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
> > > UPHPU at uphpu.org
> > > http://uphpu.org/mailman/listinfo/uphpu
> > > IRC: #uphpu on irc.freenode.net
> >
> >
> > _______________________________________________
> >
> > UPHPU mailing list
> > UPHPU at uphpu.org
> > http://uphpu.org/mailman/listinfo/uphpu
> > IRC: #uphpu on irc.freenode.net
> >
>
> _______________________________________________
>
> UPHPU mailing list
> UPHPU at uphpu.org
> http://uphpu.org/mailman/listinfo/uphpu
> IRC: #uphpu on irc.freenode.net
>
> _______________________________________________
>
> UPHPU mailing list
> UPHPU at uphpu.org
> http://uphpu.org/mailman/listinfo/uphpu
> IRC: #uphpu on irc.freenode.net
>


More information about the UPHPU mailing list