Skip to content

Instantly share code, notes, and snippets.

@dotherightthing

dotherightthing/vagrant-and-puppet.md

Last active August 15, 2019 06:04
Show Gist options
  • Save dotherightthing/33aafa63a4f30be458cd to your computer and use it in GitHub Desktop.
Save dotherightthing/33aafa63a4f30be458cd to your computer and use it in GitHub Desktop.
Download ZIP
[Vagrant & Puppet] #virtualisation
Raw
vagrant-and-puppet.md

Vagrant & Puppet

https://docs.vagrantup.com/v2/

Introduction

My front end development environments are becoming very dependent on the software installed on my machine (Node/NPM, Grunt, Yeoman, Bower, Ruby Gems etc). When another developer picks up one of my projects they often have problems with software versions so that the build system cannot be run and they have to spend hours troubleshooting their system, often requiring me to hold their hand which kind of defeats the purpose of handing the work off to them in the first place.

Similarly our back end development environments are becoming increasingly complex, with software like Rails, Node/NPM, Composer, different versions of PHP, etc.

Vagrant & Puppet solve this problem by allowing developers to author configuration files in which they describe which software needs to be installed on which OS, in order to have a usable environment.

Getting started

Install Vagrant

  1. Download and Install Vagrant for your OS (~80mb)

Install Virtualisation Software

Vagrant requires a Virtual Machine to run boxes. By default Vagrant supports the VirtualBox virtualisation software, which is free and is what most of us use at work to test our websites on MS Windows (for different versions of MSIE).

  1. Download and Install Virtualbox for your OS (~110mb). The same Vagrant API also works with other providers including VMWare and AWS.

Download and install a Vagrant box

Vagrant needs a box to install software on.

Linux base boxes can be downloaded for free, but Apple forbids upload of OS X boxes. So we'd need to create our own OS X base box(es). See Boxes, below.

  1. Download and start the default Vagrant box (VM): vagrant up
  2. The will also download the default Linux box to /Users/USERNAME/.vagrant.d/boxes/BOXNAME. The .vmdk file for the hashicorp/precise32 box was 295.2mb
  3. VirtualBox will show that a new VM is running, but there is no UI

Manipulate the file system on the box

  1. Connect to the box via SSH: vagrant ssh
  2. Do some stuff
  3. Exit SSH: exit
  4. Destroy the box: vagrant destroy
  5. Windows users can also do vagrant rdp

Install a webserver on the box (Provisioning)

The Provisioning feature allows software to be automatically installed on vagrant up:

  1. Compose a shell script to install the software
  2. Save this to the host directory as eg bootstrap.sh
  3. Add this script to the Vagrantfile: config.vm.provision :shell, path: "bootstrap.sh" (Ruby)
  4. Reload an existing machine after updating provisioning: vagrant reload --provision
  5. Make simple modifications to the provisioning scripts on your machine and check for the desired results: vagrant provision, optionally with --provision-with x,y,z

Access the webserver on the guest (Port Forwarding)

This forwards network traffic from port 4567 on the host machine to port 80 (for use by Apache) on the guest. This allows a website to be edited on the host machine but viewed using the webserver / LAMP stack installed on the guest machine.

  1. Install Apache (https://docs.vagrantup.com/v2/getting-started/provisioning.html)
  2. Add this to the Vagrantfile: config.vm.network :forwarded_port, host: 4567, guest: 80 (Ruby)
  3. Reload an existing machine after updating port forwarding: vagrant reload
  4. You can now view files on the webserver @ http://127.0.0.1:4567
  5. The host directory is the one where you've run vagrant up, ie the one containing Vagrantfile (Vagrant automatically climbs up the directory tree looking for the first Vagrantfile it can find, starting first in the current directory)
  6. Files within the host directory can be edited on the host and will automatically sync to the guest

Share your host's Vagrant directory outside the network via HTTP

This allows you to eg share a local website with a user outside your network.

  1. Sign up for an Atlas account
  2. Check if you're already logged in: vagrant login --check
  3. vagrant login
  4. vagrant share
  5. In other use cases you can also vagrant share --ssh, vagrant connect --ssh and vagrant connect
  6. An obscure-url-NNNN.vagrantshare.com will be generated and output to the Terminal. The URL is accessible by anyone so be careful what you share.
  7. End the sharing session: Ctrl+C. The URL is no longer accessible.
  8. Logout: vagrant login --logout

Notes:

  • vagrant share ... will automatically share as many ports as possible for remote connections. If the Vagrant environment has a static IP or DNS address, then every port will be available. Otherwise, Vagrant will only expose forwarded ports on the machine.

  • Note the share name at the end of calling vagrant share, and give this to the person who wants to connect to your machine. They simply have to call vagrant connect NAME. This will give them a static IP they can use to access your Vagrant environment.

  • Share sessions expire after a short time (currently 1 hour)

  • Shared web applications must use relative paths for loading any local assets such as images, stylesheets, javascript.

  • HTTPS (SSL): vagrant share by default looks for any SSL traffic on port 443 in your development environment. If it can't find any, then SSL is disabled by default.

  • Sharing vs Security: https://docs.vagrantup.com/v2/share/security.html

Misc

Setup / Starting a VM

  1. vagrant up - set up / resume the guest VM. The optional --provider flag allows you to change from VirtualBox to eg VMWare or AWS
  2. vagrant reload - vagrant halt then vagrant up the guest VM
  3. vagrant reload --provision - vagrant halt then vagrant up the guest VM, forcing any provisioners to re-run
  4. vagrant resume - resumes a Vagrant managed machine that was previously suspended

Teardown / Stopping a VM

  1. vagrant suspend - saves the current running state of the VM
  2. vagrant halt - if possible, gracefully shut down the VM's OS, otherwise just power it off; preserve the contents of the VM's HDD
  3. vagrant destroy - removes all traces of the VM from the host machine

Get VM Status

  1. vagrant status

Help

  1. See all primary commands: vagrant
  2. See all commands: vagrant list-commands
  3. Get help on a particular command: vagrant COMMAND -h

Updating Vagrant

  1. vagrant version - checks site for latest version
  2. vagrant --version - just shows the locally installed version

Programmatic control of Vagrant

This is stil under development:

Plugins

Vagrant is architected with plugins.

  1. https://docs.vagrantup.com/v2/cli/plugin.html
  2. https://github.com/mitchellh/vagrant/wiki/Available-Vagrant-Plugins

Boxes

https://docs.vagrantup.com/v2/boxes/base.html

Download an existing box

Download an OS X box
  • There are 3 OS X boxes listed on Atlas, but all are self-hosted which means they cannot be installed by the public using vagrant up
  • Andrew Dryga has created a box (~10.8GB) which he can't upload to VagrantCloud as Apple forbid it.

Create a custom box

  • Base boxes are extremely useful for having a clean slate starting point from which to build future development environments.

  • Creating a base box can be a time consuming and tedious process, and is not recommended for new Vagrant users. If you're just getting started with Vagrant, we recommend trying to find existing base boxes to use first.

Create an OS X box
VirtualBox
VMware Fusion

We develop in OS X and VirtualBox support for OS X is only 'experimental'. From what I've read, VMWare Fusion appears to be a more robust option when it comes to emulating OS X. It still requires the host machine to be running Intel Mac hardware (as per Apple's system requirements) but as we're already running Macs that shouldn't be an issue.

Configuration Management tools

Puppet or Chef? Ansible or Salt?

Whereas Puppet and Chef will appeal to developers and development-oriented shops, Salt and Ansible are much more attuned to the needs of system administrators. Ansible's simple interface and usability fit right into the sys admin mindset, and in a shop with lots of Linux and Unix systems, Ansible is quick and easy to run right out of the gate.

Salt is the sleekest and most robust of the four, and like Ansible it will resonate with sys admins. Highly scalable and quite capable, Salt is hamstrung only by the Web UI.

Puppet is the most mature and probably the most approachable of the four from a usability standpoint, though a solid knowledge of Ruby is highly recommended. Puppet is not as streamlined as Ansible or Salt, and its configuration can get Byzantine at times. Puppet is the safest bet for heterogeneous environments, but you may find Ansible or Salt to be a better fit in a larger or more homogenous infrastructure.

Chef has a stable and well-designed layout, and while it's not quite up to the level of Puppet in terms of raw features, it's a very capable solution. Chef may pose the most difficult learning curve to administrators who lack significant programming experience, but it could be the most natural fit for development-minded admins and development shops.

Puppet

Online configurators

Books

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment