[UPHPU] Vagrant (up or down)

Sean Thayne sean at skyseek.com
Mon Aug 18 15:43:29 MDT 2014


That's a good question. Could you store the Docker setup in a git repo like
you can with the lightweight Vagrant scripts?

-Sean Thayne


On Mon, Aug 18, 2014 at 3:39 PM, Richard K Miller <richardkmiller at gmail.com>
wrote:

> Tod, are you using Docker in developer or production or both? I'm curious
> because I've mostly seen people speaking to Docker's virtues -- and it is
> very cool technology -- but I haven't seen a lot of people actually using
> it.
>
> (For those not familiar with Docker, it's a lightweight form of
> virtualization (kind of). It uses Linux LXC, which is similar to FreeBSD
> Jails, to keep applications and file systems separate from each other.
> Imagine having the MySQL binary and configuration running in their own
> layer. The root layer can see mysqld running. However, the MySQL layer can
> only see its own filesystem and processes. It's like having a server
> appliance inside a layer. Great encapsulation for convenience, security,
> etc.)
>
> Tod, I'm specifically curious how you do provisioning since neither
> Vagrant nor Docker do their own provisioning.
>
> Vagrant process:
> 1. Start with a base box, e.g. Ubuntu 14.04.
> 2. Write Puppet code to install MySQL
> 3. Distribute Vagrantfile to other developers
> 4. When other developers type "vagrant up", it downloads the base box,
> then Puppet installs MySQL
> 5. (Optional) If you decide that you  always want MySQL on your VM, you
> can use a tool called Packer to create a new base box that includes MySQL.
> Then you don't need Puppet to install it each time. However, then you've
> frozen that MySQL binary and configuration into the box. If a MySQL upgrade
> comes along, you have to recreate the base box. At our company we do not do
> this step.
>
> Docker process:
> 1. Create a new Docker container
> 2. Install and configure MySQL manually (or maybe with Puppet?)
> 3. Save and distribute the Docker container to your developers, using it
> in both development and in production
> 4. If you need to make a change to MySQL, e.g. upgrade it, change
> configuration, etc. start back at step #1
>
> Docker seems to be lighter for execution, but heavier for distribution
> since you're passing around containerized binaries.
>
> It seems perfect for letting someone try an open source project, e.g.
> "Click here to download the Postgresql/Redis/Riak Docker container and try
> it for yourself". Could also be an interesting way to distribute a
> proprietary server "appliance".
>
> FWIW, Vagrant now offers Docker support. It's considered a provisioner
> like Puppet or Chef. If you use run Vagrant+Docker on a Mac, it will
> transparently run a Linux VM since Mac doesn't support LXC natively.
> However, that still leaves me with the question, who/what does the manual
> work of installing and configuring MySQL? For us, the downsides of freezing
> the MySQL binary and configuration in a Docker container haven't been worth
> the Docker benefits. And for developers on Macs, it's one more layer they
> don't necessarily need.
>
> I'm really curious how you or anyone else is using it.
>
> Richard
> >
> > Alright, I'll be the unpopular one.
> >
> > I prefer docker for technical superiority (unless you're doing OS-level
> > dev, but this is UPHPU).  I say this knowing it's linux-only.  If that's
> a
> > problem, you're not imaginative enough for this conversation to be very
> > useful, since you can spinup a docker container and develop inside that
> > from any machine anywhere if you want to glue it together.  If you're
> > programming in PHP, you're deploying to linux anyway.
> >
> > That's where docker gets really awesome.  Not only is it WAY faster than
> > vagrant (by virtue of not having to provision an entire vm and
> environment)
> > it's also a deployable item.  You can literally hand the app in a docker
> > container to IT or whatever and it will perform exactly as you expect it
> > to, because it's in the exact environment you meant it to be in, no
> > dependency or OS differences matter.
> >
> > It used to be a beta tool, but has recently been production ready and
> > useful.  Vagrant is just a wrapper to virtualbox, and while I used it, it
> > seems like it was an inbetween help from the old ways of spinning up a vm
> > manually and the current joy of docker.
> >
> > Just do yourself a favor and learn the better tool.  If you're on windows
> > or mac doing the development, well, figure out how to mount a linux
> > filesystem locally and just use a server for your docker provisioning or
> > something.  Whatever works for you, I guess.  Just don't limit yourself
> to
> > virtualbox for web dev.  It's just going to continue to be a subpar
> method
> > of managing what is basically just in your way in the first place.
> >
> > So basically, go docker unless you need a windows/bsd/osx environment
> > (why?) for your site.
> >
> >
> > On Fri, Aug 15, 2014 at 1:11 PM, Matt Gauthier <mr.mattyg at gmail.com>
> wrote:
> >
> >> 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
> >>>
> >>
> >> _______________________________________________
> >>
> >> 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