Automating Development Environments with Vagrant and Puppet | Hacker News Reader

Automating Development Environments with Vagrant and Puppet

blog.kloudless.com

109 pointsanalogAndroid34 comments

This is a very nice write up. If anyone is interested, I've put several screencasts together about Vagrant [1], creating a Vagrant box with Veewee [2], and Learning Puppet with Vagrant.

[1] http://sysadmincasts.com/episodes/4-vagrant

[2] http://sysadmincasts.com/episodes/5-create-a-vagrant-box-wit...

[3] http://sysadmincasts.com/episodes/8-learning-puppet-with-vag...

Thanks! I just got started with Vagrant and figured I should share my experience!

I think these tools are great and the more articles and how-to videos the better. It's nice to see the momentum building around IT automation.

Thanks analogAndroid - I'm just getting started with Puppet and Vagrant too. Great article, hoping to learn more from you!

You are welcome! Let me know if there are any things that you would be particularly interested in hearing about!

Isn't Veewee being somewhat superseeded by mitchellh's http://packer.io? Admittedly, packer.io has only recently been released.

This was my impression as well, There's a veewee-to-packer converter that I've had some success with:

https://github.com/mitchellh/veewee-to-packer

I have been using Vagrant for development on my Mac for over a year now and it has made having consistent dev, test and prod environments so much easier. I see others who dev on a Mac and deploy to Ubuntu running into a myriad of issues, ranging from libraries not compiling correctly to TCP sockets lingering on TIME_WAIT for different periods of time. It's nice to avoid that class of bugs.

The limitation with this type of approach is the assumption of a conventional (and, some would say, out of date) architecture, ie. single service on a single VM on a single cloud provider.

Topology specification, firewalling, resource constraints (bandwidth, IO speed/resilience... ie. RAID/backup persistence safety), service cohabitation or codependence, performance/capacity testing, cost, cloud provider abstraction, public DNS+SSL+sofware package distribution infrastructure dependencies, legal jurisdiction considerations, speed of instantiation, etc. are all realistic considerations (often requirements) for much modern infrastructure.

In short: this only gets you half-way, for relatively simple examples. But if your workload is within that space, by all means go for it.

(PS. Before anyone snaps 'you can manage multiple hosts with <tool>', sure. But the architecture of the tools begins to present issues.)

I'm not clear what your laundry list of things has to do with application development on a local developer's machine (the problem Vagrant is trying to solve). Is there some new way of development where developers never run on localhost and all those complex considerations are handled for them? It sounds like you're describing a full production or integration environment which is most definitely not the primary use case for Vagrant.

> ie. single service on a single VM on a single cloud provider.

Vagrant allows you to specify groups of VMs that spin up together.

Your general point that it doesn't simulate production perfectly is correct. But this is one case where the perfect is the enemy of the good.

Apparently to simulate production to the level OP requires, the only solution is to have the users test your product--the only way to perfectly simulate reality is reality.

If you're interested in getting up and running with a full development environment, I created a minimal LAMP stack utilizing the deliciousness of Vagrant and Chef. It's available on GitHub https://github.com/MiniCodeMonkey/Vagrant-LAMP-Stack

There has been a lot of discussions about which provisioner to use, but at the end of the day they all achieve the same goal. I would personally just use one that you feel comfortable with, in the sense of configuration system and structure.

How timely - I happen to be reading this while waiting for my environment to finish setting up :-)

Thank you for your work!

(Any chance it might work with Vagrant v2 soon?)

I myself am also a big fan of vagrant although it can be tough on your machine when working on multiple projects at the same time. Often times I find myself running out of memory and it can be quite tedious having to halt and bring back my vagrant boxes when I jump from project to project. Perhaps docker can address this issue someday?

use vagrant suspend to store the vm in the current state. resume is pretty much instant.

If you're just getting started with Vagrant and find yourself stuck, try a different provisioner. I had a lot of trouble wrapping my head around Puppet, but was up and running with Ansible very quickly. Puppet, Chef and Ansible can all be used to build out your Vagrant VM's environment.

Yeah, puppet isn't the easiest thing to get started with, but the primary thing I wanted to use puppet for was to make developing my puppet manifests faster/easier. It has helped a bunch, since before I had to deploy to a fresh EC2 instance every time I wanted to test out a fresh build.

I just read about Vagrant, and Ansible last week -- I would love to read the ansible playbooks of folks to see what they are doing with them, and to learn more about how its done.

Ideally, I'd love to find some vagrant scripts and ansible playbooks to bring Amazon ec2 instances up and down and configure them with a standard set of packages.

What I like about Vagrant is that while a provisioner can help, it's not mandatory. If you're stuck with a legacy "enterprise! It sings, it dances, it crashes if you look at it funny!" application with a lot of special requirements, you can get up and running pretty quickly with a little bash and perl. I whipped up a Vagrant script for our app which is capital-F Finicky.

If you're curious, here's the vagrantfile and bootstrap script:

https://github.com/opentusk/Opentusk/blob/master/Vagrantfile

https://github.com/opentusk/Opentusk/blob/master/install/vag...

Nice write up. I have been using Vagrant for a while now and it has made it really easy to move environments around to different machines. Mitchell Hashimoto is a brilliant guy.

I did a bit of extra work to make my puppet manifests work outside of vagrant too, so I can use a simple script to install to any Ubuntu base box (e.g. bare metal, EC2, docker, etc) - https://github.com/mozilla/socorro/blob/master/puppet/ubuntu...

This could have been 1/10th the content

https://puphpet.com/

Oh yeah, that is true, but the point is to learn how to do it by hand so you can do more than just bring up a php app (like develop django or rails or anything else).

Other languages are on my to-do list for PuPHPet!

I'm surprised they didn't call it VAMP

Its really important in the first instance to learn how to do things by hand and then use tools to speed up the process. Nice tool though, needs more DB options.

The author should really check out saltstack (with or without vagrant).

I have checked out saltstack (not in too much detail, since I have been busy with puppet). But I wasn't sure if there was an equivalent to exported resources in saltstack (I want to use them for automated monitoring and orchestrating of other services), since that is a pretty useful thing and I was somewhat skeptical about having everything defined in YAML, since there are somethings that I think one wouldn't be able to do... but I have been meaning to look into it!

why are people not using Docker as compared to Vagrant ? Doesnt it consume way less memory ?

The nice thing about Vagrant is that it is more platform independent, so even if you are doing your dev work on a mac you can still use the same dev-box as anyone else. Docker, on the other hand, is linux only (and requires a certain kernel version) to work well. Not to say you can't use Docker, and they seem to work well together, but they are kind of solving different problems.

How do you share files between the docker instance and the host? How do you run docker on your mac? Networking is very different for docker instances as well.

On a Mac you can use Vagrant to bring up a host that runs docker, but i'm not sure how you would be able to just run docker on your mac.

That being said docker looks pretty awesome for certain sets of problems.

can docker have different operating systems with different kernels (win, freebsd, debian lin, ubuntu) running on the same machine? or same o/s with different kernels? different modules?

the old vps vs. container discussion.

It is possible to run a VM inside Docker and still retain some advantages of containers, but not all of them since there is a "VM" in the sentence :)

Reply on news.ycombinator.com