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.
Related
There used to be a gui where you could configure PuPHPet settings for vagrant.
It would allow you to set, shared folders, users, Apache, Mysql, etc.
I can't seem to find this site anymore. Is it gone?
Is there an alternative way to configure a vagrant for Magento?
PuPHPet is abadoned according to it's creator: https://twitter.com/juantreminio/status/1199022035588075520
However, the whole project was open source and you can find the repositories here:
https://github.com/puphpet
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.
I'm new to Vagrant and I'm trying out PuPHPet in order to get things up and running. I can get a debian box up and running and ssh into it. It's more the workflow I'm unclear on.
At the moment I'm downloading the PuPHPet config into a folder called vagrant which I can cd/ into and run vagrant up then vagrant ssh. What I'm confused about is am I doing it wrong in terms of where I've placed the files.
Do you download the set up files on a per project basis, directly into the project directory? Or do I download this into a directory, for instance C:/sites/vagrant and then this directory runs my environments and the config files point towards the project folders such as C:/sites/project_one.
In my mind the PuPHPeT setup it what then gets used for all projects if I want it on debian as per what I chose via the GUI. But I'm really confused!
Short Answer
I recommend that you keep your PuPHPet files, the resulting Vagrantfile and its environment in a directory separate from your site (source) files directory because this seems more organized and secure to me. It is perfectly fine to set up a new virtual machine for each project, but I prefer to set up one single Vagrant box and have it service all of my projects at once so I'm not constantly putting boxes up-and-down as I switch between projects.
Explanation
To do this, configure your "Shared Folder Pairs" on PuPHPet.com to map your Folder Source (the /source/code/path/name where your source files are on your main computer) to the Folder Target (the /destination/path/name on the Vagrant-generated virtual machine where your Vagrant-generated web server can find them) for each of your projects (screenshot). Configure the web server (using PuPHPet's Web Servers configuration page) to reference such /destination/path/name directories, which maps those working files to a usable server name, server alias and document root.
As a warning, do NOT use the /var/www folder directly as a Folder Target. In some configurations, this will cause Apache to fail installation when provisioning with Vagrant.
In the config.yaml file created by PuPHPet, you'll see entries like this:
synced_folder:
vflsf_12randomlettersandnumbers:
source: /Users/unrivaled/www-development-source-files
target: /var/www/dev
On PuPHPet.com, where you would configure your environment, there is a section where you configure your "Shared Folder Pairs." This is where you tell Vagrant where your files are now (on your main computer) and where you want them to appear in your Vagrant-generated virtualized environment.
An important concept to grasp here is my use of the words "are" and "appear."
Your files "are" on your computer - the one you are presumably using to edit and debug your projects, and from which you want to run PuPHPet to host a Vagrant-generated web server. This is your "host" operating system, and your development files (source code) will always simply reside here. You will never need to copy them back-and-forth between your main computer and the Vagrant-generated web server.
By contrast, your files "appear" on the Vagrant-generated web server created when you run vagrant up, which generates a "guest" operating system in a Vagrant-generated virtualized environment where the web server, database engines and so forth run. Note that you are not copying files there (onto the "guest" operating system). Instead, Vagrant will cause them to appear there for you, per your use of the "Shared Folder Pairs" mentioned earlier:
Folder Source represents the location on your main computer (the "host" operating system), where your source files reside.
Folder Target represents the location on your virtual computer (the "guest" operating system), where you want Vagrant to make them visible in the guest OS.
In this way, you simply edit your files in your development environment, wherever they happen to be now; and Vagrant will make sure your Vagrant-generated web server sees those files instantly, live, in real time. Even if you vagrant destroy this generated web server environment, your source files will be completely untouched. Simply recreate a new environment (vagrant up), and bam! There you go. Back in business.
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.
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.