Vagrant Provision

Provisions

"The vagrant provision runs any configured provisioners against the running Vagrant managed machine. This command is a great way to quickly test any provisioners, and is especially useful for incremental development of shell scripts, Chef cookbooks, or Puppet modules. We can just make simple modifications to the provisioning scripts on our machine, run a vagrant provision, and check for the desired results.

-Chef Solo

-Chef Server

-Puppet Standalone

-Puppet Server

-Shell

Chef Solo

The Vagrant Chef Solo provisioner allows you to provision the guest using Chef, specifically with Chef Solo.

chef-solo is an open source version of the chef-client that allows using cookbooks with nodes without requiring access to a Chef server. chef-solo runs locally and requires that a cookbook (and any of its dependencies) be on the same physical disk as the node.

chef-solo is a limited-functionality version of the chef-client and does not support the following:

-Node data storage

-Search indexes

-Centralized distribution of cookbooks

-A centralized API that interacts with and integrates infrastructure components

-Authentication or authorization

-Persistent attributes

list the complete set of available options for the Chef Solo provisioner.

cookbook_path(string or array) - A list of paths to where cookbooks are stored. By default this is "cookbooks", expecting a cookbooks folder relative to the Vagrantfile location.

data_bags_path(string or array) - A path where data bags are stored. By default, no data bag path is set. Chef 12 or higher is required to use the array option. Chef 11 and lower only accept a string value

environments_path (string) - A path where environment definitions are located. By default, no environments folder is set.

nodes_path(string or array) - A list of paths where node objects (in JSON format) are stored. By default, no nodes path is set.

recipe_url(string) - URL to an archive of cookbooks that Chef will download and use.

environment(string) - The environment you want the Chef run to be a part of. This requires Chef 11.6.0 or later, and thatenvironments_path is set.

roles_path(string or array) - A list of paths where roles are defined. By default this is empty. Multiple role directories are only supported by Chef 11.8.0 and later.

synced_folder_type (string) - The type of synced folders to use when sharing the data required for the provisioner to work properly. By default this will use the default synced folder type. For example, you can set this to "nfs" to use NFS synced folders.

Chef Server

Chef Server allows you to provision your virtual machine without having to keep the cookbooks within the repository itself. There are various benefits to this approach, such as being able to use your production cookbooks from chef server to provision your development environment.

The Chef Server URL

-First step to provisioning with chef server is to tell Vagrant where the chef server is located.

Vagrant::Config.run do |config|
  config.vm.provision :chef_client do |chef|
    chef.chef_server_url = "http://mychefserver.com:4000"
  end
end

Validation Key Path

Chef server uses key pairs in order to verify and register nodes to the chef server (similar to SSH key-based authentication).

The validation key is used by an unregistered client to verify itself and register with the chef server.

Vagrant needs to know the path to this validation key in order to configure the client for chef server.

Vagrant::Config.run do |config|

config.vm.provision :chef_client do |chef|

chef.validation_key_path = "validation.pem"

end

end

The path given as the value to the configuration is expanded relative to the project directory if it’s a relative path. If it’s an absolute path, then it is taken as is.

Specifying the Run List

The run list is the list of things to run on the node, which are recipes and/or roles. Usually the run list is managed by the chef server. In this case, you don’t have to do anything, since by default Vagrant will pull the run list from the chef server.

Vagrant::Config.run do |config|
  config.vm.provision :chef_client do |chef|
    # Provision with the apache2 recipe
    chef.add_recipe("apache2")

    # Provision with the database role
    chef.add_role("database")
  end
end

If you need to access the run list directly, you can also use the run_list accessor: 

Vagrant::Config.run do |config|
  config.vm.provision :chef_client do |chef|
    # Modifying the run list directly
    chef.run_list = ["recipe[foo]", "role[bar]"]
  end
end

Specifying the Environment

Chef 0.10 or later, you have access to environments. If you’d like to configure the environment you’re node is part of, simply use the environment configuration option:

Vagrant::Config.run do |config|
  config.vm.provision :chef_client do |chef|
    # Set the environment for the chef server
    chef.environment = "development"
  end
end

Configuration Options

There are other configuration options as well, but these can normally be left as their default. But if your chef server requires these to be customized, they are available to you. This documentation won’t go into detail of their function since if you’re looking for these you probably already know what they are for:

Vagrant::Config.run do |config|
  config.vm.provision :chef_client do |chef|
    chef.validation_client_name = "chef-validator"
    chef.client_key_path = "/etc/chef/client.pem"
  end
end

Cleanup

When you provision your Vagrant virtual machine with Chef server, it creates a new Chef Node entry and Chef Client entry on the Chef server, using the hostname of the machine. After you tear down your virtual machine, you must explicitly delete these entries from the Chef server before you provision a new one with Chef server.

For example, using knife:

$ knife node delete vagrant-ubuntu-oneiric

$ knife client delete vagrant-ubuntu-oneiric

If you fail to do so, you will get the following error when trying to provision a new virtual machine with the same hostname:

HTTP Request Returned 409 Conflict: Client already exists.

Puppet Standalone

Puppet in the client-server mode to configure your production environment then you might want to be able to copy & paste from the prod configuration into the Vagrant’s standalone puppet‘s configuration to test stuff. One of the key features necessary for that is enabling file serving via “source => ‘puppet:///path/to/file'”.

Enabling Puppet Standalone in Vagrant to Resolve puppet:///…

-Make the directory with the files to be served available to the Vagrant VM

-Create fileserver.conf to inform Puppet about the directory

-Tell puppet about the fileserver.conf

-Use it

Make the directory with the files to be served available to the Vagrant VM

Puppet Server

Use a Puppet server, then Vagrant can register itself as a node on the server and use the configuration that server has to configure your virtual machine. If you’re just getting started with Puppet, you should instead be using the standalone Puppet provisioner.

Setting the Puppet Server

Vagrant needs to know the name of your Puppet server. By default, Vagrant will look for a server called puppet. You can override this in your Vagrantfile using the puppet_server option.

Vagrant::Config.run do |config|

config.vm.provision :puppet_server do |puppet|

puppet.puppet_server = "puppet.example.com"

end

end

Here we’ve specified the Puppet Server as puppet.example.com.

Configuring the node name

We can also control the name of the node which is passed to the Puppet Server. Remember this is important because Puppet uses this node name to identify both the configuration to be applied and to generate an SSL certificate to authenticate the node to the Puppet Server.

The node name defaults to the name of the box being provisioned.

Vagrant::Config.run do |config|
  config.vm.provision :puppet_server do |puppet|
    puppet.puppet_server = "puppet.example.com"
    puppet.puppet_node = "vm.example.com"
  end
end

Setting options

Specify additional options to be passed to the Puppet Server using the options variable.

Vagrant::Config.run do |config|
  config.vm.provision :puppet_server do |puppet|
    puppet.options = ["--user","puppet"]
  end
end

You can also pass options as strings:

 config.vm.provision :puppet_server, :options = "--verbose --debug"

 Shell

The Vagrant Shell provisioner allows you to upload and execute a script within the guest machine.Shell provisioning is ideal for users new to Vagrant who want to get up and running quickly and provides a strong alternative for users who are not comfortable with a full configuration management system such as Chef or Puppet.

The shell provisioner takes various options. One of inline or path is required:

inline (string) - Specifies a shell command inline to execute on the remote machine. See the inline scripts section below for more information.

path (string) - Path to a shell script to upload and execute. It can be a script relative to the project Vagrantfile or a remote script (like agist).

The remainder of the available options are optional:

args(string or array) - Arguments to pass to the shell script when executing it as a single string. These arguments must be written as if they were typed directly on the command line, so be sure to escape characters, quote, etc.

env(hash) - List of key-value pairs to pass in as environment variables to the script. Vagrant will handle quoting for environment variable values, but the keys remain untouched.

binary(boolean) - Vagrant automatically replaces Windows line endings with Unix line endings. If this is false, then Vagrant will not do this. By default this is "false".

privileged(boolean) - Specifies whether to execute the shell script as a privileged user or not (sudo). By default this is "true". Windows guests use a scheduled task to run as a true administrator without the WinRM limitations.

upload_path(string) - Is the remote path where the shell script will be uploaded to. The script is uploaded as the SSH user over SCP, so this location must be writable to that user.

keep_color(boolean) - Vagrant automatically colors output in green and red depending on whether the output is from stdout or stderr.

name(string) - This value will be displayed in the output so that identification by the user is easier when many shell provisioners are present.

powershell_args(string) - Extra arguments to pass to PowerShell if you are provisioning with PowerShell on Windows.

powershell_elevated_interactive(boolean) - Run an elevated script in interactive mode on Windows. By default this is "false". Must also be privileged.