Varying Vagrant Vagrants is an evolving Vagrant configuration with a goal of providing a system to pass development projects between team members for easy ramp up on projects.
Vagrant is a "tool for building and distributing development environments". It works with virtualization software such as VirtualBox to provide a virtual machine that is sandboxed away from your local environment.
vagrantwill now be available as a command in the terminal
git clone git://github.com/10up/varying-vagrant-vagrants.git vagrant-local
vagrant up- omg magic happens
192.168.50.4 local.wordpress.dev local.wordpress-trunk.dev
http://local.wordpress.dev/in your browser for WordPress 3.5.1 or
http://local.wordpress-trunk.devfor WordPress trunk.
The first time you run
vagrant up, a pre-packaged virtual machine box is downloaded to your local machine and cached for future use. The file used by Varying Vagrant Vagrants is about 280MB.
After this box is download, it begins to boot as a sandboxed VirtualBox virtual machine. When ready, it runs the provisioning script also provided with this repository. This initiates the download and installation of around 80MB of packages to be installed on the new virtual machine.
The time for all of this to happen depends a lot on the speed of your Internet connection. If you are on a fast cable connection, it will more than likely only take a few minutes.
On future runs of
vagrant up, the pre-packaged box will already be cached on your machine and Vagrant will only need to deal with provisioning. If the machine has been destroyed with
vagrant destroy, it will need to download the full 80MB of packages to install. If the vagrant has been powered off with
vagrant halt, the provisioning script will run but will not need to download anything.
Now that you're up and running with a default configuration, start poking around and modifying things.
vagrant sshfrom your
vagrant-localdirectory. You can do pretty much anything you would do with a standard Ubuntu installation on a full server.
vagrant upcommand will initiate the complete provisioning process again.
vagrant haltor suspend it with
vagrant suspend. If you suspend it, you can bring it back quickly with
vagrant resume, if you halt it, you can bring it back with
Vagrantfileand it will be used on the next
database/init-custom.sqland edit it to add whichever
GRANT ALL PRIVILEGESstatements you want to run on startup to prepare mysql for SQL imports (see next bullet).
database/backups/directory and named as
import-sql.shscript will run automatically when the VM is built and import these databases into the new mysql install as long as the proper databases have already been created via the previous step's SQL.
config/nginx-config/sitesand create any other site specific configs you think should be available on server start. The web directory is
/srv/www/and default configs are provided for basic WordPress 3.5.1 and trunk setups.
vagrant up, it will persist on the local machine a mapped mysql data directory.
A bunch of stuff!
Startup times for this Vagrant setup can vary widely, especially when booting from scratch, due to the downloads required to install all packages the first time. Here are some real world scenarios.
vagrant destroy(or from scratch) with only the initial ~280M box cached took about 3 minutes
vagrant provisionon running box took about 30 seconds
vagrant upon powered off box (
vagrant halt) took about 30 seconds
vagrant upafter a
vagrant destroy(or from scratch) with only the initial ~280M box cached took about 15 minutes
vagrant upafter a
vagrant halttook about 1 minute.
vagrant resumeafter a
vagrant suspendtook about 12 seconds
Let us have it! If you have tips that we need to know, open a new issue, send them our way at @jeremyfelt, or find us in other ways. Some blog posts have been written documenting the process that may provide insight....