Introducing Vagrant

To access the Guest, Vagrant Boxes have a default user with username:vagrant, password:vagrant and a default shared insecure ssh-key. Vagrant users usually have sudo rights if they need to make changes to the Guest OS. You can ssh to the Guest by using ssh vagrant@localhost 2222 on the Host or use the vagrant shortcut:


>vagrant ssh

Although you can automatically reach your Guest using vagrant ssh, sometimes it is useful to use scp or git, which refers to your SSH setup. To make life easier, you can update the entry in your ~/.ssh/config with information specific to the Guest (Windows users can achieve similar results by making similar updates to their PuTTY configuration):


>vagrant ssh-config 
Host default
  HostName 127.0.0.1
  User vagrant
  Port 2222
  UserKnownHostsFile /dev/null
  StrictHostKeyChecking no
  PasswordAuthentication no
  IdentityFile /Users/jay/.vagrant.d/insecure_private_key
  IdentitiesOnly yes

By plugging this information in to ~/.ssh/config, you can access your Guest with scp to move a file my_file from /vagrant to the Host desktop:


> scp default:/vagrant/my_file.txt ~/Desktop/my_file.txt

What if you want to run a Web server on your Guest that's accessible by the Host? Let's add one. Edit your Vagrant file, adding the following line:


config.vm.forward_port 80, 8080

The forward_port parameter allows the Host to forward ports from the Host to the Guest. In this case, you're forwarding port 8080 on the Host to 80 on the Guest. By default, Vagrant uses Network Address Translation networking, meaning the Guest can access the network through the Host. Machines on the Host network cannot reach the Guest directly unless the ports are forwarded. Vagrant also provides Host-only networking, where a Guest can access only the host or other Guests on the Host, and bridge networking where the Guest will be on the same network as the Host. Once you update the Vagrantfile, restart the system:


>vagrant reload

Make sure that when you open port forwarding in Vagrant you also are opening the appropriate firewall permissions on the Guest! If you try to make a connection to a Guest via port forwarding with a firewall turned on, the initial handshake will work with the host port (8080 in the example here) but fail if port 80 is blocked by the Guest firewall.

Finishing Vagrant

Once you're done with your work, you have a few choices. If you're just done for the day, or trying to get a few resources back for the Host, you can simply suspend Vagrant:


>vagrant suspend

and resume:


>vagrant resume 

when you want to restart. All state is maintained, and nothing is lost. Once an environment is completely finished, or if you want to start over from a clean slate, you can run vagrant destroy. This will remove the Guest and any changes to content outside of the shared folders (/vagrant). Shared folders reside on the Host and will survive the destruction of the Guest.

Provisioning a Guest

Creating and maintaining virtual images can be a delicate balance in terms of configuration. Over-configure the image, and it gets stale faster as applications are replaced with patches. Under-configure the image with a simple base, and each time a new instance is created, the user must spend the time configuring the Box to the exacting specifications of the project. With Vagrant, there is a good middle ground. A base image can be created and minimally updated to manage OS-level patches and libraries, while applications can be provisioned using tools like Chef, Puppet or shell scripts.

Many systems administrators are already familiar with Chef and Puppet, two configuration management tools that allow for consistent creation and maintenance of a system. By plugging Chef and Puppet into Vagrant, users can take immediate advantage of the scripts that already have been created by system administrators to create up-to-date images for development.

Chef and Puppet are both supported to work in solo/standalone mode and server mode. In Chef Solo or Puppet standalone, the configuration for the images are all self-contained. In server mode, Chef or Puppet Server users can leverage the existing Chef or Puppet infrastructure already established in their companies.

This article doesn't go into great detail about Chef, but let's look at a simple example of how using Chef can be helpful. Vagrant can run without additional servers in Chef-solo mode. To set up Chef, you first need a Cookbook. Cookbooks are a collection of Recipes. A Recipe is a description of how you would like the system configured. Recipes also are written in Ruby. For this example, I've downloaded Cookbooks available from the Opscode community site.

In this example, let's install Apache2 and MySQL on our Guest. Here's the setup. Create a directory called "cookbooks" under the ProjectX directory. Download the Cookbooks for Apache2 and MySQL from http://community.opscode.com (see Resources). In addition, you'll need two dependencies: the apt recipe to get the latest updates and openssl, which is required for the MySQL recipe.

Extract these files and save them to the cookbooks directory:


> ls -l cookbooks/
total 0
drwxr-xr-x@ 10 jay  staff  340 Feb 16 18:49 apache2
drwxr-xr-x@  9 jay  staff  306 Feb 14 12:00 apt
drwxr-xr-x@  9 jay  staff  306 Feb 16 18:23 mysql
drwxr-xr-x@  7 jay  staff  238 Jun  3  2011 openssl

In my Vagrantfile, I have added the following lines:


config.vm.provision :chef_solo do |chef|
  chef.cookbooks_path = "cookbooks"
   chef.add_recipe("apt")
   chef.add_recipe("openssl")
   chef.add_recipe("mysql::server")
   chef.add_recipe("apache2")
  # You may also specify custom JSON attributes:
    chef.json = {
             :mysql => {
                   :server_root_password => "MYSQL PASSWORD"
                  }
              }
  
end

When Vagrant runs the provisioning step (included in vagrant up but also available on a running Guest by using vagrant provision), it will install apt, openssl, mysql and apache2. Recipes can take arguments as well. In this example, I've included a parameter for the mysql recipe that sets the server root password. The parameters available for a given recipe are included in the documentation. The parameters are passed as JSON attributes to Vagrant, which will pass them along to Chef.

Managing this with Vagrant allows you to enforce change controls around your environments. Vagrantfiles and Cookbooks can be checked into source control and managed just like code resources. Branching and tagging environment configurations can be used to track changes as projects develop or requirements and packages are updated.

Creating a New Image

The traditional method is to use VirtualBox to create a new virtual machine image using the standard operating system installer. Because operating system steps vary, I'm not going to go into the details here, but here are some key steps:

  • When choosing the Virtual Disk storage details, choose "Dynamically Allocated"—you want your disk to start small but be able to increase as needed.

  • If you want to use Chef or Puppet with your application, you'll need to install the Chef or Puppet applications when creating the base image.

  • Install the VirtualBox Guest Additions. This is necessary to support shared folders!

Let's set up the vagrant user. Create a user with the user name vagrant. Add this user to an admin group. Update the sudoers file to make sure that users in the admin group do not need a password to access sudo. For a group called "admin", it should look like this:


%admin ALL=NOPASSWD:ALL

Also make sure that the Defaults requiretty is commented out. You also want to make sure you can ssh into the Vagrant account. By default, Vagrant will try to use the insecure SSH key with vagrant ssh. To add the key to your Vagrant account, do the following as the vagrant user:


> mkdir .ssh
> chmod 755 .ssh
> curl -L http://github.com/mitchellh/vagrant/raw/master/
↪keys/vagrant.pub
> > .ssh/authorized_keys
> chmod 644 .ssh/authorized_keys

Once the image is complete, you'll need to package the image into a Box. To create a set of default configurations for the Box, you can create a new Vagrantfile. Use vagrant package, which takes two arguments --base (the name of the image in VirtualBox that you created) and --include (which takes the files you wish to include in your Box):


> vagrant package --base RHEL-5.7-64 --include Vagrantfile 

In this example, you created a package with the base image called RHEL-5.7-64 and included your custom Vagrantfile.

Summary

Vagrant is a powerful tool for creating and managing flexible development environments. In this article, I covered the basic use and creation of Vagrant images.

Resources

Vagrant's Home on the Web: http://vagrantup.com

VirtualBox: https://www.virtualbox.org/wiki/Downloads

Ruby: http://www.ruby-lang.org/en/downloads

RubyInstaller (for Windows): http://rubyinstaller.org

Opscode Community Site: http://community.opscode.com

Chef Cookbooks:

Vagrantbox.es (a Web Site That Lists Boxes): http://vagrantbox.es

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

China may still be a

Anonymous's picture

China may still be a developing country, but the Chinese people have kept up with the fashion and culture of the modern world. While you may still find people in China who regularly wear Mao jackets, tunics and loose traditional-style trousers, the vast majority of people in China dress similarly to people in Western countries in jeans, t-shirts and business suits. Qipao (Mandarin) or cheongsam (Cantonese), the ancient style of long women's formal gowns, are still worn but only during formal occasions or by hostesses in upscale restaurants and hotels. Chinese Dress

Buggy so far...

Lucas Pottersky's picture

My experience with Vagrant has been pretty awkward, to say the least.

At first it was working great, but then after a few days using I started to get timeouts and was unable to do the provision without timing out.

Ruby's not a scripting

Anonymous's picture

Ruby's not a scripting language, it's a dynamic language.

RE

Johanna's picture

I hate it when multiple persons work on the same piece of code, it always takes a lot of guesswork to see who made which error and when...
------
Zorgverzekeringvergelijkenstudenten.nl

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix