cpradio — 2014-05-29T20:42:35-04:00 — #1
Okay, so I finally found time to jump into vagrant and I must admit, I like what I see, but I can see things getting awfully messy from an organization standpoint, so what are your best tips for utilizing vagrant to its fullest?
Right now, I've created my initial vagrant vm using puphpet, and although it simplified everything for me, it makes me wonder what I may have missed. It seems, I can have it spin up a machine that installs just about anything and everything, so by putting munin in the installed packages, I can have that installed and setup for me.
What interests me most is two fold.
1) does anyone else typically like to run separate DB and Application servers? And if you do, do you setup your vagrant files to work that way (so you have to spin up two of them)?
2) All of my projects are now in git, so how do you typically share those projects with your vagrant instances? Do you just setup apache with your git repo, do you have vagrant execute a script to clone your git repo, what do you do?
And of course, what advice would you give someone new to vagrant that you wish someone told you when you first started to use it?
molona — 2014-06-02T04:02:46-04:00 — #2
What? That's something new to me... Never heard of Vagrant and I'm not sure if I should ask you about it since you're trying it yourself... but maybe when you have your questions answered you can do a proper evaluation and tell me if it is worth it
wwb_99 — 2014-06-02T10:13:37-04:00 — #3
Vagrant is awesome when you have cross platform stuff going on. I've spent a lot of time building our whole workflow around it. The project was generally well worth it though there are still a number of warts. The warts are more with the VM provisioning process and/or finnicky hypervisors and/or weird filesystem stuff than vagrant itself. Fair warning -- it is one of those "easy start -> horrible complex issues -> omg this is awesome" sort of experiences.
For #1 -- we typically run the apps on the same VM, most of our vagrant based stuff is running drupal or wordpress apps so they are pretty agnostic as long as you tell them the right db server. We always have separate configs for dev / qa / production so that is easy to navigate. The reason for one machine is fundamentally resources on the client -- VMs add up real fast in RAM and disk space.
For #2 -- we store the vagrant script in the repo, our projects typically have 2 folders above the web root. The approach usually is to mount a container folder on the vagrant VM and then use a shell script or provisioner to symbolicly link configuration and kickstart apache. The provisioner also handles the setup of said apache and other dependencies. There is a lot to this but I'm running off to a meeting so if you have more specific questions I can elaborate later.
cpradio — 2014-06-02T10:28:09-04:00 — #4
I'm in the "easy start" phrase making my way into "horrible complex issues"
That makes sense.
So from my initial start, since I'm using puphpet with Vagrant, I'd have to put the puphpet directory and the vagrant file in the git repo. I'd need to alter the configuration so it mounts the appropriate directory for apache to utilize, but other than that, it likely would then be self encompassing (which would be nice).
wwb_99 — 2014-06-02T11:28:38-04:00 — #5
It is puppet not pupphet Think manipulating servers.
We use chef (though I'd look hard at docker or perhaps ansible now) and that is exactly what we do. We use hg subrepositories [git has a similar feature] to handle alot of that as this code is typically shared across projects. The loopier thing we do is transport a lot of the site content in it's own subrepo so it really is self contained -- anybody, including the designers, can go vagrant up a project and get a fully funcitoning version of the site.
cpradio — 2014-06-02T14:03:12-04:00 — #6
Ah, sorry for the confusion, I simply referred to puphpet, because I used https://puphpet.com/ to build my initial vagrant configuration. I'm starting to get used to chef (as I see another project utilizing it, so I may ultimately reduce things down to that, as I don't think I need anything massive and puphpet seems to add a lot on top of the vagrant file (not sure if that is good or bad at this moment).
wwb_99 — 2014-06-03T15:57:26-04:00 — #7
Ah, I wasn't familiar with that site so that makes sense
Our vagrantfile is 86 lines long. I don't have a handy total on the custom chef stuff but it isn't huge. There is a boatload of chef dependencies that we carry though. If I was doing it again I would probably use berkshelf to handle alot of that though on the other hand I really like all my dependencies in the source not hanging off of a 3rd party repo for various reasons.
cpradio — 2014-06-03T17:30:34-04:00 — #8
Yeah, puphpet is nice in that it guides you through everything, so it was great for getting my initial configuration and then allowing me to see what it generated. I've got a lot to figure out, but at least I think I could primarily get away very few vagrant files at this moment. I don't do a lot of different configurations when it comes to setting up/deploying servers, so almost all of them are the same, but I'm definitely enjoying not having to run apache/mysql locally and just throwing up a vm with it instead. It really makes building my system less complicated and forces me to write better processes for spinning up projects (which I've been lazy about).