Skip to content

Latest commit

 

History

History
113 lines (78 loc) · 3.88 KB

README.md

File metadata and controls

113 lines (78 loc) · 3.88 KB
Raw

Vagabond

At Balanced, we use Vagrant for all our developer work. These are common settings, helpers, and utilities for facilitating Vagrantfile management as well as other virtualization environments.

Getting Started

Installing default vagrantbox

vagrant box add ubuntu/precise64 https://vagrantcloud.com/ubuntu/boxes/precise64/versions/1/providers/virtualbox.box

Modifying Vagrantfile

Given that Vagrant's Vagrantfile is just plain ruby code, it is possible to extend it in many different ways.

However, it is preferable that we try to enforce uniformity across the Vagrantfile, so custom ruby code for modifications is discouraged. If there's an addition that is welcome to the project, please open up a github issue.

That being said, the current way to utilize Vagabond is to use it as submodule in a parent project.

Vagabond as a submodule in a parent project

The current way on how to use Vagabond is to include it as a git submodule. Then run:

ln -s vagabond/Vagrantfile

Customizations

Most developers will have custom settings, i.e. locations on where code will be stored, and they they will also need to customize the machine for their own machines or maybe even using remote clouds.

Projects like the below can help produce this effect:

Nugrant

Vagabond currently is using Nugrant to control customizations to a Vagrantfile. It works by allowing a developer to place a .vagrantfile, that's not checked into VCS, with personalizations. The .vagrantuser file should be in the $YOUR_PROJECT_PATH folder. Here's an example tree:

$YOUR_PROJECT_PATH
$YOUR_PROJECT_PATH/vagabond   # submodule / cloned
$YOUR_PROJECT_PATH/Vagrantfile -> vagabond/Vagrantfile
$YOUR_PROJECT_PATH/.vagrantuser    # <-- your personalizations **NOT IN VCS (i.e. Git, etc)**

Example .vagrantuser file:

# -*- mode: yaml -*-
---
providers: {
  virtualbox: {
    memory: 4096,
    cpus: 2
  },
  aws: {
    region: us-west-1,
    availability_zone: us-west-1a,
    ssh_key: ~/.ssh/id_rsa.pub,
    flavor_id: m3.2xlarge,
    iam_profile_name: some-profile,
  }
}

synced_folders:
  - folder_1
  - folder_2

exec:
  - "ENV['USER']"

Updating Vagabond's submodule

This trick is really cool to update git submodules and serves as a really neat way to manage and update git submodules.

First, run this:

git config --global alias.up-sub '!f() { cd $1 && git checkout master && git pull && git submodule update --init --recursive; }; f'

Then, when you can easily update to the latest Vagabond by running:

git up-sub vagabond

Why is this its own repo?

Borrowing from this StackOverflow Question and this Vagrant mailing-list question, it seems that this is a common concern.

Balanced has previously used one Vagrantfile per project and that didnt' scale as many Vagrantfiles were divergent and required constant updating.

From this other stackoverflow question about git repo in a subdirectory, we can also see this is the general direction to take.

Hacking on Vagabond

git clone git@github.com:balanced-cookbooks/vagabond.git

Why the name Vagabond?

It was either that or hobo :-D