SitePoint Sponsor

User Tag List

Results 1 to 8 of 8
  1. #1
    Hosting Team Leader silver trophybronze trophy
    cpradio's Avatar
    Join Date
    Jun 2002
    Location
    Ohio
    Posts
    5,220
    Mentioned
    153 Post(s)
    Tagged
    0 Thread(s)

    Vagrant, what are your best tips/pieces of advice?

    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?

  2. #2
    #titanic {float:none} silver trophy
    molona's Avatar
    Join Date
    Feb 2005
    Location
    from Madrid to Heaven
    Posts
    8,259
    Mentioned
    245 Post(s)
    Tagged
    1 Thread(s)
    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

  3. #3
    SitePoint Author silver trophybronze trophy
    wwb_99's Avatar
    Join Date
    May 2003
    Location
    Washington, DC
    Posts
    10,649
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    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.

  4. #4
    Hosting Team Leader silver trophybronze trophy
    cpradio's Avatar
    Join Date
    Jun 2002
    Location
    Ohio
    Posts
    5,220
    Mentioned
    153 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by wwb_99 View Post
    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.
    I'm in the "easy start" phrase making my way into "horrible complex issues"

    Quote Originally Posted by wwb_99 View Post
    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.
    That makes sense.

    Quote Originally Posted by wwb_99 View Post
    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.
    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).

  5. #5
    SitePoint Author silver trophybronze trophy
    wwb_99's Avatar
    Join Date
    May 2003
    Location
    Washington, DC
    Posts
    10,649
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    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.

  6. #6
    Hosting Team Leader silver trophybronze trophy
    cpradio's Avatar
    Join Date
    Jun 2002
    Location
    Ohio
    Posts
    5,220
    Mentioned
    153 Post(s)
    Tagged
    0 Thread(s)
    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).

  7. #7
    SitePoint Author silver trophybronze trophy
    wwb_99's Avatar
    Join Date
    May 2003
    Location
    Washington, DC
    Posts
    10,649
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    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.

  8. #8
    Hosting Team Leader silver trophybronze trophy
    cpradio's Avatar
    Join Date
    Jun 2002
    Location
    Ohio
    Posts
    5,220
    Mentioned
    153 Post(s)
    Tagged
    0 Thread(s)
    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).


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •