Introducing Vagrant

Now there are two Boxes installed:


>vagrant box list
lucid32
rhel5.7

It is important to note that you can reuse these base images. A Box can be the base for multiple projects without contamination. Changes in any one project will not change the other projects that share a Box. As you'll see, changes in the base can be shared to projects easily. One of the powerful concepts about using Vagrant is that the development environment is now totally disposable. You persist your critical work on the Host, while the Guest can be reloaded quickly and provisioned from scratch.

Starting Vagrant

Create a directory on the Host as your starting point. This directory is your working directory. Vagrant will share this directory between the Guest and the Host automatically. Developers can edit files from their preferred Editors or IDEs without updating the Guest. Changes made in the Host or Guest are immediately visible to the user from either perspective:


> mkdir ProjectX
> cd ProjectX

To get started, you need a Vagrantfile. The Vagrantfile is to similar to a Makefile, a set of instructions that tells Vagrant how to build the Guest. Vagrant uses Ruby syntax for configuration. The simplest possible Vagrantfile would be something like this:


Vagrant::Config.run do |config|
  config.vm.box = "lucid32"
end

This configuration tells Vagrant to use all the defaults and the Box called lucid32. There actually are four Vagrantfiles that are read: the local version in the current directory, a user version in ~/.vagrant.d/, a Box version in the Box file and an initial config installed with the Gem. Vagrant reads these files starting with the Gem version and finishing with the current directory. In the case of conflicts, the most recent version wins, so the current directory overrides the ~/.vagrant.d, which overrides the Box version and so on. Users can create a new Vagrantfile simply by running:


> vagrant init 

This creates a Vagrantfile in the current directory. The generated Vagrantfile has many of the common configuration parameters with comments on their use. The file tries to be self-documenting, but additional information is available from the Vagrant Web site. To run most Vagrant commands, you need to be in the same directory as the Vagrantfile.

Let's give it a try:


$ vagrant up
[default] Importing base box 'lucid32'...
[default] The guest additions on this VM do not match the install 
version of VirtualBox! This may cause things such as forwarded 
ports, shared folders, and more to not work properly. If any of 
those things fail on this machine, please update the guest 
additions and repackage the box.

Guest Additions Version: 4.1.0
VirtualBox Version: 4.1.8
[default] Matching MAC address for NAT networking...
[default] Clearing any previously set forwarded ports...
[default] Forwarding ports...
[default] -- 22 => 2222 (adapter 1)
[default] Creating shared folders metadata...
[default] Clearing any previously set network interfaces...
[default] Booting VM...
[default] Waiting for VM to boot. This can take a few minutes.
[default] VM booted and ready for use!
[default] Mounting shared folders...
[default] -- v-root: /vagrant

Let's break this down. I'm running with VirtualBox 4.1.8 and a Guest at 4.1.0. In this case it works smoothly, but the warning is there to help troubleshoot issues should they appear. Next, it sets up the networking for the Guest:


[default] Matching MAC address for NAT networking...
[default] Clearing any previously set forwarded ports...
[default] Forwarding ports...
[default] -- 22 => 2222 (adapter 1)

I used the default network setting of Network Address Translation with Port Forwarding. I am forwarding port 2222 on the Host to port 22 on the Guest. Vagrant starts the Guest in headless mode, meaning there is no GUI interface that pops up. For users who want to use the GUI version of the Guest, the option is available in the Vagrantfile to run within a window. Once the network is set up, Vagrant boots the virtual machine:


[default] VM booted and ready for use!
[default] Mounting shared folders...
[default] -- v-root: /vagrant

After the Guest has started, Vagrant will add the shared folder. Vagrant uses the VirtualBox extensions to mount the current folder (ProjectX in this case) as /vagrant. Users can copy and manipulate files from the Host OS in the ProjectX directory, and all the files and changes will be visible in the Guest. If the shared folder isn't performing well because you have a large number of files, Vagrant does support using NFS. However, it does require that NFS is supported by both the Guest and Host systems. At this time, NFS is not supported on Windows Hosts.

______________________

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