Vagrant itself has a highly extensible architecture that can be utilized to provide additional functionality. Vagrant extensions are written using Vagrant's plugin framework. Vagrant plugins are typically written to extend Vagrant by:
Creating new providers that can execute commands and configure resources within the guest operating systems
Adding or modifying resources on guest operating systems
Adding or modifying resources on the host operating system
Plugins can also create new commands that can be executed within the Vagrant executable.
Vagrant plugins are written in the language of Vagrant itself: the Ruby programming language. Writing Vagrant plugins utilizes a framework to get started, but will be rather difficult unless you have a basic grasp of the Ruby programming language. This appendix will create and explain a simple example of a custom provider, one that allows us to add a new provisioner block to say hello to the provisioner. In the end, this block of code can be added to our Vagrantfile:
config.vm.provision :hello do |hello|
hello.inline = 'Chad!'
endThis will produce the output on provisioning:
==> default: Running provisioner: hello... [stdout] Hello Chad!!
Extending Vagrant in this way can be useful to publish extensions to Vagrant itself. Users might want to take care in creating new plugins rather than using existing provisioners for a few reasons:
Provisioning operations are typically best done using existing provisioners. Ruby code written to support provisioning operations will not be typically portable in the way that provisioning code written using portable provisioning tools, such as Chef, Puppet, shell scripts, and so on.
Vagrant plugins require additional complexity for end users to manage. A written Vagrantfile that requires a plugin also requires users to install plugins before the Vagrantfile itself is usable.
When using Vagrant plugins, one must also take care to use Ruby features that are available in the Ruby runtime provided in Vagrant packages. There are ways of specifying these versions and failing the plugin, but care in compatibility is something that must be kept in mind. Developers should also note that the current versions of Vagrant are no longer distributed as RubyGems, so dependencies between Vagrant and Vagrant plugins (which are distributed as RubyGems) are implicit rather than explicitly defined in Gemfiles.