Are you tired of putting the same sane configuration options to every Vagrantfile? Here is how to make the life with Vagrant a little easier.
Vagranfile holds the project configuration, but did you know that there are more Vagrantfiles involved in every
vagrant up? Vagrant will first apply a Vagrantfile that comes with you .box (if present), then apply your Vagrantfile from your home directory and then finally update the configuration from the Vagrantfile of your project.
So the first option would be to repackage your .box (it’s just tar!), edit the Vagrantfile and upload it to Vagrant again. This might be handy if you and your mates need to work on more projects together and so you would like to distribute some sane defaults together with the box file. Chances are that this is overkill for you.
And that’s where the user’s Vagrantfile comes into play. Just create a regular Vagrantfile at
~/.vagrant.d/Vagrantfile and it will be automatically applied before your project’s configuration. I personally like to enable KVM’s nested virtualization since I am also testing Vagrant packages by running Vagrant in domains created by Vagrant (how cool is that?:)) and set up vagrant-registration plugin that will automatically register mine RHEL boxes.
Here is how that looks like:
$ cat ~/.vagrant.d/Vagrantfile
Vagrant.configure(2) do |config| config.vm.provider :libvirt do |libvirt| # Enable KVM nested virtualization libvirt.nested = true end if Vagrant.has_plugin?('vagrant-registration') config.registration.username = ENV['SUB_USERNAME'] config.registration.password = ENV['SUB_PASSWORD'] end end
← BUY THE PRE-RELEASE
I am writing a complete guide on web application deployment. Ruby with Puma, Python with Gunicorn, NGINX, PostgreSQL, Redis, networking, processes, systemd, backups, and all your usual suspects. 23 chapters and 3 scripted demonstrations already available.