I cloned a repo that included a Vagrantfile, a requirements file, and a few other things. I like the VM enough to want to re-use it for various projects, all of which would have their own repos. Rather than configuring each new repo's origin and removing extraneous files after cloning anew, I thought instead I could just make a copy of the VM and re-use it. So my basic workflow that I've pieced together would be this:
$ git clone https://github.com/.../x.git Template
$ cd Template
$ vagrant up
$ VBoxManage list vms
$ vagrant package --base Template_default_1394051969748_83660 --output ./template.box
$ vagrant box add template template.box virtualbox
Now I could just make a new directory for a project, run vagrant init, and then edit the Vagrantfile to use the template box.
My question is simply whether those who are more experienced in Vagrant think that I'm perhaps making this too hard or somehow missing the point of Vagrant.
The answer depends on the modifications you have made to the base box, the time it takes to provision those modifications, the complexity of making the modifications, and the time the users of your modified boxes can afford to wait for provisioning on each "vagrant up --provision" request.
If your modifications are trivial and completed within seconds (e.g. your recipe run list is limited to the installation of a few, small public apps) then there is no need to create a new modified base box. If your changes are complex, time consuming, and perhaps require authentication credentials then perhaps you do provide value by pre-provisioning a modified base box.
The choice you make will likely vary from Vagrantfile to Vagrantfile.
To strive to honor the principle, you can declare the configuration of your modified, derivative base box with a packer specification. Ideally, you do not leave your users with a virtual machine that cannot be recreated if they lose access to your personal knowledge. Tailor your base box image with packer, create that modified box, and commit both the packer specification, the Vagrantfile, and the chef (or similar) provisioning scripts to change management.
Related
I have a new developer coming to work with me soon, and I'd like to make it as simple as possible for them to get a development environment set up.
I'm currently using a Vagrant (Laravel Homestead) box with about 15 domains set up, each with different configurations (different PHP versions etc), and I'd like to just share the existing box with them if possible.
Is it as simple setting up a repository with the VagrantFile, getting them to clone it and provision the box, or are there more steps involved?
Also, I've had to edit the MySQL configuration on the box, is there any way I can include these updates in what I share with them, or will they just need to reconfigure their own version manually?
Any advice appreciated.
Thanks
The easiest way to share the Homestead environment is to use the after.sh file to to perform any customization you may need beyond what Homestead gives you.
You can also copy your Homestead.yaml file to Homestead.yaml.example for the new coworker to easily copy and paste the sites & any other configuration changes.
When you download a vagrant box. The first time it has to download from a server. Then it caches that box for future use.
Is there a way to do this for files within a chef script. For example we use wget to pull down a zip file for some software. These usually take 40 minutes. I would like to have this only download one time (for each unique version) and cache the file somewhere for global usage later. So that if I create another vagrant machine that references the same zip file, it will use the cached file instead of downloading again. Is this possible?
Especially if you use remote_file resource, you can use the vagrant-cachier plugin to cache the downloaded files to a synced folder from the host. Even with direct wget calls you could specify a generic bucket and download files there.
Another approach is to use a caching web proxy in your local network, on your host, or even on another VM (see polipo-box for an example), and use the vagrant-proxyconf plugin to automate the configuration of the Vagrant VMs.
Are there any tools that I can use to automatically build vagrant base boxes on a remote linux server. It'll be better if it is extendable and version control friendly.
Thanks. First question on SO.
Packer can create Vagrant boxes. It's from the same company that have created and maintain Vagrant.
http://www.packer.io/docs/post-processors/vagrant.html
Another valid option is Veewee, as pointed out in a previous answer.
Try out veewee: https://github.com/jedi4ever/veewee
I'm not sure by "extendable" what you mean. veewee should do the job. it supports debian preseed file and other configurations that can be checked into version control.
We have multiple projects that each are going to use Vagrant for managing their development environments. We're happily using Chef for provisioning and all that's working fine. But, we're finding that our Vagrantfiles have a lot of cut'n'paste between them. We'd like to consolidate our Vagrantfile definitions so that they can share from a common Vagrantfile-library (either locally or installed from some remote location). Is this a thing?
One good way could be to include the common directives of your Vagrantfile in a custom box.
A box is just a .tar or tar.gz file containing all the stuff needed by the provider for running the Vagrant instances. As far as I know, all provider-specific formats allow adding a Vagrantfile with common settings to the box.
I'm trying to create a custom vagrant box for my team to use. The box is based off the base CentOS-x64-6.4-virtualbox-guest-additions-and-chef box. I vagrant up the VM and installed a bunch of software on it. With the software in place, I created a custom Vagrantfile and then packaged the box with vagrant package --output "my-custom-centos.box" --vagrantfile Vagrantfile and made it available.
Unfortunately, it turns out that when you pull down the shared box, the default shared directory that maps /vagrant on the box to the current working directory doesn't work (folder is empty). Furthermore, adding additional custom working directories also has no effect. I can't seem to find any good resources for how best to package custom vagrant boxes and haven't seen anything like shared directories not working. Any help would be greatly appreciated.
When you add --vagrantfile Vagrantfile to your package command, it embeds the Vagrantfile that the box was using into the package. I think the outermost Vagrantfile is supposed to take precedence over the others. The default shared folder is always where you set up your box (where your Vagrantfile and .vagrant folder are) and will change each time you start a box from a new place. When I make custom boxes, I leave the Vagrantfile out of the package and have not run into any problems with shared files. Hopefully some of that helps.
I tried to package a box once and ran into all sorts of issues... its a little hard to speculate on the exact issue you are having but in my experience Vagrant can be a little picky.
I found it better to just use a working base box and make sure to include everything that needs to be installed within a provisioning script.
The easiest way to get started is probably just to use the shell provisioner where you can literally just get it to run all of the same commands you are already running. But if you want to do things in a more robust way you should check out Chef since the base box you using already includes it.
Using Chef you will be able to get everything installed that you need on your box in a repeatable and extendable way... it's really quite powerful once you get your head around it.