Using Vagrant for Development
Vagrant is a tool for managing virtual machines in the terminal.
After running through the setup instructions here, you should be ready to use Vagrant for the first time.
First, we'll run vagrant up to download, unpack and start our virtual machine.
Go ahead and run the following terminal commands:
cd ~/code/mks
vagrant up
The first time you run this, it will take a few minutes to download the Vagrant box, unpack it locally and boot the vagrant machine. After the box has been setup the first time you run it, vagrant up will still be the command used to boot your vagrant machine. You can check the status of your vagrant machine at any time by using the command vagrant status to see what state the machine is in now: turned off or running.
Once you've set up your vagrant machine or started it using the vagrant up command, we need to actually connect to our Vagrant box via the terminal, the command we use to do this is vagrant ssh, we'll still need to run this from the same directory as our Vagrantfile, ~/code/mks:
vagrant ssh
You should notice the terminal change its appearance. This means you are now connected to the Vagrant box running on your virtual machine (you'll also notice it says its using Ubuntu 12.04 instead of whatever OS you are normally using). You can check that everything worked correctly by running ruby -v and rails -v which should return 2.1.0 and 4.0.2 respectively.
A key feature of Vagrant is that your local copy of ~/code/mks is also available on your Vagrant box at /vagrant. If you create a new folder or file on your local machine in ~/code/mks or its subdirectories, they will instantly be available in your vagrant machine under /vagrant.
So, for example, if I create a new Rails application on my local machine at ~/code/mks/backend/new_rails_app, I can then find the same folder in my Vagrant machine at /vagrant/backend/new_rails_app.
Our local machine's shared folder (~/code/mks):
Our vagrant machine's shared folder (/vagrant):
Because we have a shared folder it is easy to edit files locally and share the contents with your Vagrant box where you will actually be running your applications.
Your vagrant machine is tied to the ip address 10.10.10.10. What this means is that, if you are to start a server in your vagrant machine that you would normally access using localhost, you'll instead access it with 10.10.10.10. For example, if we were running a Rails server:
$ rails s
=> Booting WEBrick
=> Rails 4.0.2 application starting in development on http://0.0.0.0:3000
=> Run `rails server -h` for more startup options
=> Ctrl-C to shutdown server
[2014-02-05 17:40:17] INFO WEBrick 1.3.1
[2014-02-05 17:40:17] INFO ruby 2.1.0 (2013-12-25) [i686-linux]
[2014-02-05 17:40:17] INFO WEBrick::HTTPServer#start: pid=3095 port=3000
Normally, we'd then go to our browser and navigate to http://localhost:3000 to access our server. Since we're using a browser on our local machine but running our server in our vagrant machine, we need to instead navigate to http://10.10.10.10:3000 to access our app, since our vagrant machine has the address 10.10.10.10. If you were running a Sinatra app instead, and would normally use http://localhost:4567 to access it, you'd instead use http://10.10.10.10:4567 and so on. Basically, just replace localhost with 10.10.10.10 but keep your port (the number after the :) the same.
When you're done with your virtual machine (perhaps when you're going home for the day), you can utilize the vagrant halt command on your local machine to power down the virtual machine. If we run vagrant status after this command, it should tell us our box is "turned off" now. Whenever we want to start the vagrant box again, we can run vagrant up to do so.
In the context of development, we use virtual machines to generate and run emulated computer systems within our operating system. For an example, we can use an application like VirtualBox to create virtual systems running the operating system of our choosing within our normal local operating systems (like OSX if you're using a Mac).
Virtual machines makes setting up your development environment much less painful. Because virtual machines are fully contained in a disk image, you don't have to worry about messing up your local operating system by deleting or moving things around by accident (especially helpful for those inexperienced in the terminal). On top of that, instead of having to jump through all the hoops of setting up development environments and configuration files from scratch, we can instead distribute virtual machine images that have all the software required for MakerSquare contained pre-installed and ready to go, so students can get to work faster on day 1.
Vagrant can be used to download, setup and manage virtual machines for the purpose of development. Instead of installing tools like Ruby, Node.js, etc., on your local machine, making changes that could potentially be hard to undo and hard to switch, we can instead create what Vagrant calls boxes. These boxes contain a disk image (in our case, an Ubuntu Linux system) that can come pre-installed with all the tools you'll need for day-to-day development. When you want to edit your files, you can (and should) still do this locally using tools like Sublime Text and Git. However, when you want to do things like run rake tasks, start rails server, or use something like pry for experimentation, you'll run these after first connecting to your Vagrant machine in the terminal.
When we're using Vagrant, it is important to note that we are emulating connecting to a remote server. Typically when developers work on a physically remote server, they use the ssh command to connect their terminal program to that server, and are able to execute commands as if they were using it locally.
With Vagrant, what we are doing is similar. Instead of connecting to a physically remote server, we're connecting to a remote machine that just happens to live on our own hard drive. In fact, if you open the VirtualBox application, and monitor what happens as you run commands like vagrant up and vagrant down, you'll notice that the virtual machine is shown actually powering up and powering off. You can also see the "hardware" that it has available, like memory, hard drives, dvd drives, etc.
click here to learn more about ssh