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.
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.
Problem: on Windows 7, due to the fact that we can't use nfs (naturally, without hacks), the performance of the couple Vagrant/Magento are really poor.
After so much research, i found that the best way (maybe the only) to solve the problem is to use rsync. Ok, i succeed to use it and the performancies now are really good!
I found a problem: it seems to be that rsync is mono-directional. What i mean? Suppose I do install magento succesfully and then i call "vagrant rsync" command. It will perform a new sync of the folders and, cause it sync the guest file structure with the host file structure, it will "delete" the etc/app/local.xml file that Magento has built for me after the installation, just beacause it doesn't exist in the host file structure.
Now, i read some solution like exclude folders or file from sync, but i think it's really not a great way to solve the problem.
Someone has a better solution? There is a way to sync bidirectionally the two file structures?
UPDATE
I tried to find a solution.
1) I tried to use unison, but i found some kind of error i can't understand.
2) I tried to use the vagrant plugin rsync-back, but it seems it can't find the right folders to sync
3) I finally choose to execute the rsync within the virtual machine. Access through vagrant ssh, execute the command "rsync -av /var/www/ /vagrant.
It seems to work.
So, for the moment, the solution to improve the performance of Vagrant and Magento is to activate the rsync system. To solve the uni-directional sync problem, I need to execute the rsync command from the VM if i need to sync from guest to host (viceversa, it's enough to use vagrant rsync).
If you have a better way, please, give it to me!
Best option i know is unison (realtime bidirectional folder sync)
vagrant-unison plugin from https://github.com/mrdavidlaing/vagrant-unison is outdated and not functioning.
Get updated version of vagrant-unison plugin here https://github.com/dmatora/vagrant-unison
This is indeed the case right now; Vagrant's rsync support is not bidirectional—it only syncs from your host machine to the VM, and not back. There is an open issue to add two-way sync (rsync-push and rsync-pull), but I'm not sure when this issue will see the light of day.
Some other options, in the meanwhile:
vagrant rsync-back plugin - currently allows for only manual one-time rsync pulls, no support for rsync-auto
vagrant unison plugin - uses Unison to synchronize only one folder at a time
The main reason I like rsync is because it's one of the simplest/most robust file sync tools available for Mac/Windows/Linux, and since it's already installed on 2/3 of those platforms, only the Windows devs need to do any extra work to get it going. Most other options (NFS, Unison, etc.) require extra software for everyone, and don't offer much in the way of a performance gain over rsynced files.
The problem I had using rsync was it was a mono directional so if my app creates a file on the remote server, it will be deleted when rsynced next time.
I've tried the above suggestions but I've ended up with using ftp.
I'm using phpstorm and use the automatic deployment. So that if I change anything in the file or create a new one then it will automatically upload your files to the remote server (VM).
It's still one way but it works for me.
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.
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.
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.