[UPHPU] Vagrant (up or down)

Tod Hansmann uphpu.org at todandlorna.com
Mon Aug 18 17:17:30 MDT 2014


I'm using the term "production" here loosely, because we don't use docker
containers in production at work, and I don't do anything myself that could
be considered production.  So with that caveat, let's discuss.

Docker process is very flexible to be whatever you need it to be, so I can
only say how I use it, and how I think I'd like to use it, and they're
close enough right now I'll just give you one run-down:

- Setup a docker file for the thing I wish to have encapsulated (usually a
single web service or database container)
- Create an image out of that docker file (for versioning later) so I will
never have to again (we share images from a single server in-house, so
every dev gets these revisions if the 'system' needs to change).
- Dev in our local repo, don't bother launching docker until you're ready
for testing against things
- Spin up a set of docker containers for any testing to run against for the
larger app (obviously you run your unit tests on their units somewhat
outside of these, but inside as well)
- Have jenkins or Travis do its own testing and packaging of docker images
- Deploy with a button!

That's the dream anyway.  I'm about half-way there with my own stuff, but
it's not very complex.  Some of the things we've worked on are more modular
and have a dozen repos pulled into a single web app, and supporting
databas(es) in a separate container.  You can separate things further and
have an nginx frontend divvy out things or what have you, and that can be
in its own container or just sitting there, and then you just spin up more
and more containers for scaling if needs be.  Need more database nodes in
your cluster?  Well, dockerize it and deploy it across a dozen environments
if you want, it doesn't matter, or you can just use Amazon instances, or
just hardware, or VPSes, etc.

The point of docker is less about workflow and more about isolating
environments, so again, my thing is going to be my thing, but it shouldn't
dictate yours.  The goal is that you will only have to figure out the
environment stuff once, and ship that as a whole.  This fits with the
virtualbox methods but is more flexible in how you isolate things and much
more flexible with deployment options in mind.

Your mileage may vary.  Void where prohibited.  Etc.


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
>
>
>
>


More information about the UPHPU mailing list