Slides split up into multiple sections.

Slides both vertical and horizontal.

About Presenter

• Director of Development
  @ Deseret Digital Media
• President of Utah PHP Usergroup
• 8+ years of professional web development
• Goofy dad

About This Presentation

• Slides & code examples will be posted online
• If something isn't clear, ask in chat and Eli will let me know
• We'll have time for questions at the end
• Feel free to contact me
  afterward the presentation

Our Goal

• Introduction to Vagrant
• When To Use It
• Live Demo On How to Use Vagrant
• Get you excited to try it on your own!

Lets Start

With a Story

You're a Happy Developer

You're Part of a
Small Team of Devs

You find an impressive new hire

Lets call him Bob

Bob show ups on his first day

Ready to do amazing stuff!

HOLD ON!

Bob needs to get his

Dev Environment Setup

Bob will take days to get setup

Example

Problem #1:

Manual Development Environments

Typical New Hire Scenario:

First Week

• Gets work laptop
• Clones / Checkouts code repos
• Installs PHP, Apache, etc
• Configures Apache to point to source directory
• Mashes buttons until it hello worlds

Typical New Hire Scenario:

First Month

• Discovers things that won't work on his machine
• Hacks & Mashes until he fixes it hopefully
• Discovers things don't work in production
• Tears hair out while combing through logs
  trying to see why it doesn't work in production

Bob's Has An HDD Failure

Bob starts to re-setup his

Dev Environment Setup... Again

Problem #2:

Increasingly Complex Environments

Web Dev isn't

simple LAMP anymore

One of my Current Projects:

Nginx - Apache - PHP-FPM - PHP 5.4 (new sites)

PHP 5.3 (legacy tools) - MySQL - MongoDB - Redis

Beanstalkd - Memcached

We Need a Better Solution

Goals For Our Solution

• Automated As Much As Possible
• Quickly On-Board New Team Members
• Reasonably Simulate Production
• Share Across Your Team
• Share Env Updates with Team
• Use Source Control to Track Changes

Introducing:

What is Vagrant?

A CLI tool to create & configure

lightweight, reproducible, and portable

development environments

How it Works

• Vagrant with spin up a local virtual machine using something like VirtualBox
• It will mount shared folders automatically
• Vagrant will then use a provisioner (i.e. pupptet) to configure the machine as needed

All 100% Automated

Personal Success Story with Vagrant

• Local Team in Utah all on 64 bit Macs or Linux Machines
• New Remote team in the Ukraine all on 32-bit Windows machines
• Only have 1 overlapping hour in our work days.

Using Vagrant, they were able to setup our complex environment on their own in an hour while the other half of our team were sleeping on the other side of the world.

Install Vagrant

Prerequisites

• VirtualBox (or another provider)
• SSH client (i.e. Putty for windows)

Install VirtualBox

• Download VirtualBox for your given environment
• Run the VirtualBox Installer & Follow Instructions

Install Vagrant

• Download the Vagrant Installer for your platform.
• Run the Vagrant Installer & Follow Instructions

"Hello World" of Vagrant

Open up your terminal and run the following:

$ mkdir vagrant_test
$ cd vagrant_test
$ vagrant init precise32 http://files.vagrantup.com/precise32.box
$ vagrant up
                        

Vagrant Overview

What happens when you type: vagrant up

Step #1:

Vagrant locates & reads Vagrantfile

The Vagrantfile contains configurations in ruby for:

• Which BaseBox to use for VM(s)
• Network Configuration for VMs
• Which "provisioner" (i.e. puppet, chef) to use
• Shared / Synced Folders
• Port Forwarding

Step #2:

Vagrant instructs provider (i.e. VirtualBox) to create & setup VM(s)

The Provider will:

• Import Base Box
• Set VM Networking Config (per Vangrantfile)
• Setup Shared / Synced Folders
• Setup Port Forwarding

Step #3:

Vagrant runs the Provisioner

The Provisioner (i.e. Puppet, Chef, Salt, Ansible, etc) will:

• Read Provisioner Config Files to Determine Desired State
• Determine Current State of VM
• Apply changes to VM (i.e. installing packages, starting services,
  updating files) to match the desired state

Live Demo Time

In our Demo we'll use:

• Vagrant 1.2.2
• Provider: VirtualBox 4.2
• Provisioner: Puppet
• Base Box: Precise64 (Ubuntu 12.04 LTS 64-Bit)

Demo

Getting The Most Out of Vagrant

Which Provisioner Should You Use?

Available Provisioners: Puppet, Chef, Salt, Ansible, Shell

• Using one already in production? Use that one!
• Have a preference for one? Use that one!
• Personally, I think Puppet is the easiest to pick up.
• Stand-Alone versions are easier than a server based one.
• Try to avoid using the Bash Provider

Put Heavy Lifting into your Provisioner

• You want the only set to setup your
  Environment to be to execute a "vagrant up"
• Rolling your own pre-configured Base Box
  can be complex, difficult to update
• Great way to test: "vagrant destroy && vagrant up"

User Configuration

Sometimes you want to allow your team to configure parts of your vagrant project.

Things to configure:

• User Credentials for Services
• Paths for Files
• Domain Names to Use

Configuration Example

config/prefs.rb

#!/usr/bin/env ruby
$config_source_dir = "/Users/jcarmony/git/demo"
$config_base_box = "precise64"
                        

Vagrantfile

# -*- mode: ruby -*-
# vi: set ft=ruby :

load "config/prefs.rb"
                        

Useful Vagrant Plugins

• vagrant-vbguest - will auto-update base box guest additions if out-of-date
• vagrant-aws - provider for AWS
• vagrant-rackspace - provider for rackspace cloud
• vagrant-salt - SaltStack provisioner
• Many, many, many other plugins

Base Boxes

Vagrant has the website http://www.vagrantbox.es/

• Try to find the closes distro to your production environment
• Boxes are provider specific, so if you want the option to use either VirtualBox or VMWare, you'll want a generic distro and use a provisioner to customize

Source Control

A couple of things to keep in mind:

• Ignore the .vagrant directory
• You can include the Vagrant project in the same repo
• Or you can split it out into it's own repository (My preference)

Port Forwarding vs Accessing Via IP

• I almost always prefer to access via the VM's IP.
• When running multiple vagrants, I commonly get port forwarding conflicts
• Can edit your local hosts file to use a domain (i.e. dev.example.com) to access vagrant machine

Multiple VMs

• Multiple VMs are totally possible, but they do take up more resources
• It's a judgment call on replicating production env vs resources.
• Personally I keep functionally on same machine unless there is a commonly broken technology issue.
• Example: Running php 5.4 and php 5.3 on different servers.

Okay, so...

Now What?

Pick a Project,

Make a Vagrant Project For It

Basic Steps

• Decide which distro & basebox
• Configure which local directories to sync
• Decide on which provisioner to use (when in doubt, puppet)
• Get very familiar with that provisioner, since most of the work will be in your manifest files.

Questions?

<shameless_plug>

BTW, We're Hiring a DevOps position at
Deseret Digital Media, so email me if interested.

</shameless_plug>

Thank You

• Slides: http://www.justincarmony.com/slides/vagrant-intro/
• Example Code: https://github.com/JustinCarmony/vagrant-lamp-demo
• Email: justin [AT] justincarmony [DOT] com
• Twitter: @JustinCarmony
• IRC: irc.freenode.net #uphpu