150 lines
5.0 KiB
Markdown
150 lines
5.0 KiB
Markdown
---
|
|
page_title: "Basic Usage - Provisioning"
|
|
sidebar_current: "provisioning-basic"
|
|
---
|
|
|
|
# Basic Usage of Provisioners
|
|
|
|
While Vagrant offers multiple options for how you are able to provision
|
|
your machine, there is a standard usage pattern as well as some important
|
|
points common to all provisioners that are important to know.
|
|
|
|
## Configuration
|
|
|
|
First, every provisioner is configured within your [Vagrantfile](/v2/vagrantfile/index.html)
|
|
using the `config.vm.provision` method call. For example, the Vagrantfile
|
|
below enables shell provisioning:
|
|
|
|
```ruby
|
|
Vagrant.configure("2") do |config|
|
|
# ... other configuration
|
|
|
|
config.vm.provision "shell", inline: "echo hello"
|
|
end
|
|
```
|
|
|
|
Every provisioner has a type, such as `"shell"`, used as the first
|
|
parameter to the provisioning configuration. Following that is basic key/value
|
|
for configuring that specific provisioner. Instead of basic key/value, you
|
|
can also use a Ruby block for a syntax that is more like variable assignment.
|
|
The following is effectively the same as the prior example:
|
|
|
|
```ruby
|
|
Vagrant.configure("2") do |config|
|
|
# ... other configuration
|
|
|
|
config.vm.provision "shell" do |s|
|
|
s.inline = "echo hello"
|
|
end
|
|
end
|
|
```
|
|
|
|
The benefit of the block-based syntax is that with more than a couple options
|
|
it can greatly improve readability. Additionally, some provisioners, like
|
|
the Chef provisioner, have special methods that can be called within that
|
|
block to ease configuration that can't be done with the key/value approach.
|
|
|
|
## Running Provisioners
|
|
|
|
Provisioners are run in three cases: the initial `vagrant up`, `vagrant
|
|
provision`, and `vagrant reload --provision`.
|
|
|
|
A `--no-provision` flag can be passed to `up` and `reload` if you don't
|
|
want to run provisioners. Likewise, you can pass `--provision` to force
|
|
provisioning.
|
|
|
|
The `--provision-with` flag can be used if you only want to run a
|
|
specific provisioner if you have multiple provisioners specified. For
|
|
example, if you have a shell and Puppet provisioner and only want to
|
|
run the shell one, you can do `vagrant provision --provision-with shell`.
|
|
|
|
## Multiple Provisioners
|
|
|
|
Multiple `config.vm.provision` methods can be used to define multiple
|
|
provisioners. These provisioners will be run in the order they're defined.
|
|
This is useful for a variety of reasons, but most commonly it is used so
|
|
that a shell script can bootstrap some of the system so that another provisioner
|
|
can take over later.
|
|
|
|
If you define provisioners at multiple "scope" levels (such as globally
|
|
in the configuration block, then in a
|
|
[multi-machine](/v2/multi-machine/index.html) definition, then maybe
|
|
in a [provider-specific override](/v2/providers/configuration.html)),
|
|
then the outer scopes will always run _before_ any inner scopes. For
|
|
example, in the Vagrantfile below:
|
|
|
|
```ruby
|
|
Vagrant.configure("2") do |config|
|
|
config.vm.provision "shell", inline: "echo foo"
|
|
|
|
config.vm.define "web" do |web|
|
|
web.vm.provision "shell", inline: "echo bar"
|
|
end
|
|
|
|
config.vm.provision "shell", inline: "echo baz"
|
|
end
|
|
```
|
|
|
|
The ordering of the provisioners will be to echo "foo", "baz", then
|
|
"bar" (note the second one might not be what you expect!). Remember:
|
|
ordering is _outside in_.
|
|
|
|
## Overriding Provisioner Settings
|
|
|
|
<div class="alert alert-block alert-warn">
|
|
<p>
|
|
<strong>Warning: Advanced Topic!</strong> Provisioner overriding is
|
|
an advanced topic that really only becomes useful if you're already
|
|
using multi-machine and/or provider overrides. If you're just getting
|
|
started with Vagrant, you can safely skip this.
|
|
</p>
|
|
</div>
|
|
|
|
When using features such as [multi-machine](/v2/multi-machine/index.html)
|
|
or [provider-specific overrides](/v2/providers/configuration.html),
|
|
you may want to define common provisioners in the global configuration
|
|
scope of a Vagrantfile, but override certain aspects of them internally.
|
|
Vagrant allows you to do this, but has some details to consider.
|
|
|
|
To override settings, you must assign an ID to your provisioner. Then
|
|
it is only a matter of specifying the same ID to override:
|
|
|
|
```ruby
|
|
Vagrant.configure("2") do |config|
|
|
config.vm.provision "shell",
|
|
inline: "echo foo", id: "foo"
|
|
|
|
config.vm.define "web" do |web|
|
|
web.vm.provision "shell",
|
|
inline: "echo bar", id: "foo"
|
|
end
|
|
end
|
|
```
|
|
|
|
In the above, only "bar" will be echoed, because the inline setting
|
|
overloaded the outer provisioner. This overload is only effective
|
|
within that scope: the "web" VM. If there were another VM defined,
|
|
it would still echo "foo" unless it itself also overloaded the
|
|
provisioner.
|
|
|
|
**Be careful with ordering.** When overriding a provisioner in
|
|
a sub-scope, the provisioner will run at _that point_. In the example
|
|
below, the output would be "foo" then "bar":
|
|
|
|
```ruby
|
|
Vagrant.configure("2") do |config|
|
|
config.vm.provision "shell",
|
|
inline: "echo ORIGINAL!", id: "foo"
|
|
|
|
config.vm.define "web" do |web|
|
|
web.vm.provision "shell",
|
|
inline: "echo foo"
|
|
web.vm.provision "shell",
|
|
inline: "echo bar", id: "foo"
|
|
end
|
|
end
|
|
```
|
|
|
|
If you want to preserve the original ordering, you can specify
|
|
the `preserve_order: true` flag.
|