Vagrant Workflow - vagrant ssh, vagrant destroy, vagrant up commands

Question

I am having some trouble understanding the vagrant workflow from their website.

I had previously been working on a project and had gone through the whole process of changing directory and setting up the vagrant box, etc. I had even run bundle install that installed all of the gems of the forked project I am working on. I configured the web server to work and was even able to go to see the project on my browser through the web server connection.

Later on I had to go get dinner so I did

vagrant destroy

When I returned, in the same directory I ran

vagrant up

Then I did

vagrant ssh

followed by

cd /vagrant

when I get here I run

rails s

and I get the following error:

The program 'rails' is currently not installed.  You can install it by typing:
sudo apt-get install rails

Shouldn't running vagrant up remember all of the work I had previously done? Or do I have to restart from scratch and rebuild all of my gems every time? Am I missing something?

Answer 1

vagrant destroy does literally what the command says - destroys started up VM, completely with disc images. Every change (i.e. installation of software, results of running bundle install, etc) is lost, beyond the changes that happened in /vagrant directory.

If you want to just stop the VM without destroying disc images - you should use vagrant halt instead (or just power off VM as you would do with a real server - i.e. by issuing poweroff).

The general workflow for deploying a vagrant-powered VM outlined in documentation is that you distribute Vagrantfile along with your sources that includes provisioning section (config.vm.provision) which does the stuff you've described - installation of additional software not bundled in a box image (i.e. Rails, gems), setting up the databases, etc. It can be implemented in several ways, starting from just running a simple shell script (with sequential commands to execute), up to using high-profile configuration management systems like Chef, Puppet, CFEngine, Ansible, etc.

Temporary break (like going for dinner) generally does not require even halting a VM, less destroying it. Even a full-fledged VM running under VirtualBox / VMware / KVM with a single-user Rails application hardly consumes lots of resources to worry about.