【Vagrantドキュメント意訳】09.プロビジョニング


# はじめに

本文章は、Vagrant公式サイト内のドキュメント内の[PROVISIONING](https://www.vagrantup.com/docs/provisioning/)に記載されている内容を意訳に近い形で日本語化したものである。
誤訳が含まれている可能性が十分にあることを踏まえて、参考いただきたい。

# プロビジョニング

Vagrantにおけるプロビジョナは、自動的にソフトウェアをインストールしたり、設定を変更したり、そのほかいろいろなことを`vagrant up`プロセスの一部としてできるようにする。

[Box](https://www.vagrantup.com/docs/boxes.html)は通常、用途に対して完璧に構築されていないので、これは非常に有用なものである。もちろん、ただ単に`vagrant ssh`を使い、手動でソフトウェアをインストールを行っても、十分動いてくれるだろう。しかし、Vagrantに組み込まれたプロビジョニング・システムを使用すれば、繰り返し使える処理として自動化できる。最も重要なことは、人間とのやりとりが不要で、`vagrant destroy`と`vagrant up`のコマンドによって、完全に準備が完了した環境を手に入れられることである。

Vagrantはマシンのプロビジョニングの方法として、単純なシェル・スクリプトから、より複雑な業界標準の構成管理システムまで複数の選択肢がある。

過去に構成管理システムを使ったことがないなら、プロビジョニング用に基本的な[シェル・スクリプト](https://www.vagrantup.com/docs/provisioning/shell.html)から使い始めることを推奨する。

左側のナビゲーションエリアから、組み込みプロビジョナの一覧と、これらプロビジョナの使い方を見られる。

## プロビジョニングの発生

プロビジョニングは、Vagrant環境の稼働時間の中のある特定の場合に発生する。

* 第一の場合は、環境を生成するために`vagrant up`したときにプロビジョニングが発生する。もし、環境がすでに生成されており、単なるレジュームからの復帰やブートであった場合は、次に`--provision`フラグが明示的に与えられるまではプロビジョニングは発生しない。
* `vagrant provision`が環境の起動時に使用された場合。
* `vagrant reload --provision`が呼ばれた場合。`--provison`フラグは強制プロビジョニングを示す。

`--no-provision`を指定することで明確にプロビジョナを実行せずに、環境を起動することもできる。

# プロビジョナの基本的な使い方

どのようにマシンをプロビジョニングすることができるかに対して、Vagrantは複数の選択肢を提案をしており、すべてのプロビジョナに共通で知っておくべき重要な点があるのと同様に、標準的な使用方法がある。

## 設定

はじめに、すべてのプロビジョナは[Vagrantfile](https://www.vagrantup.com/docs/vagrantfile/)の`config.vm.provision`メソッド・コールを使用して設定される。例えば、Vagrantfileが以下の様な場合、シェル・スクリプトが有効となる。

```bash
Vagrant.configure("2") do |config|
  # ... other configuration

  config.vm.provision "shell", inline: "echo hello"
end
```

すべてのプロビジョナは、プロビジョニング設定に対する第一のパラメータとして使用される`"shell"`のような種類を持っている。それに続くのは、特定のプロビジョナを設定するための基本的なキー/値である。基本的なキー/値の代わりに、より柔軟な変数を使うための文法を持つRubyブロックを使うことも出来る。以下は、前述の例と同等の実例である。

```bash
Vagrant.configure("2") do |config|
  # ... other configuration

  config.vm.provision "shell" do |s|
    s.inline = "echo hello"
  end
end
```

ブロック／ベースの記法の恩恵は、一組のオプションの場合よりもより大きく可読性を向上することが出来ることである。加えていくつかのプロビジョナ、例えばChefプロビジョナ、はキー/値の方法では行うことの出来ない、そのブロック内から呼び出せる設定を簡単にする特別なメソッドを持っている。

一つの行に設定することの出来る属性は、その属性を上述した`inline = "echo hello"`のように`=`形式で設定する。もし、`add_recipe "foo"`のように、一つの機能呼出より多い場合は、一つの行内で指定することが出来ない。

プロビジョナは名前をつけることも出来る（1.7.0以降）。これらの名前は、プロビジョナの設定を上書きする（後述）のと同じように、出力を綺麗にするために使われる。

```bash
Vagrant.configure("2") do |config|
  # ... other configuration

  config.vm.provision "bootstrap", type: "shell" do |s|
    s.inline = "echo hello"
  end
end
```

プロビジョナに名前をつけるのは簡単である。`config.vm.provision`の第一引数が名前になる。その後の`type`オプションがプロビジョナの指定に使用される。上記では`type:"shell"`のようになっている。

## プロビジョナの実行

プロビジョナは3つの場合に実行する。初期化、`vagrant up`、`vagrant provision`および`vagrant reload --provision`である。

プロビジョナを実行したくない場合は、`--no-provision`フラグを`up`と`reload`へ受け渡すことができる。同様に、強制的にプロビジョニングを行いたい場合は、`--provision`を受け渡すことができる。

複数のプロビジョナを指定していた際に、特定の一つのプロビジョナだけを使用したい場合は`--provision-with`フラグを使うことができる。例えば、shellとPuppetプロビジョナがある場合、shellだけを実行したいならば`vagrant provision --provision-with shell`とすればよい。`--provision-with`に与える引数はプロビジョナの種類("shell"など)かプロビジョナの名前(先の"bootstrap"など)である。

## 一時または常時実行

デフォルトでは、上述の通り`--provision`フラグが設定されていなければ、プロビジョナは最初の`vagrant up`から最後の`vagrant destroy`までに一度だけしか実行されない。

任意で、プロビジョナが全ての`up`または`reload`で実行されるように設定することができる。だが、`--no-provision`フラグを明確に指定しても、ただ実行しないだけである。これを実行するためには`run`オプションに"always"を設定する。以下の通りである。

```bash
Vagrant.configure("2") do |config|
  config.vm.provision "shell", inline: "echo hello",
    run: "always"
end
```

ブロックフォーマットを使用しているならば、ブロックの外側に指定する必要がある。以下の通りである。

```bash
Vagrant.configure("2") do |config|
  config.vm.provision "shell", run: "always" do |s|
    s.inline = "echo hello"
  end
end
```

## マルチ・プロビジョナ

複数の`config.vm.provision`メソッドは複数のプロビジョナを定義する為に使用することができる。これらのプロビジョナは定義された順に実行される。これは様々な理由で有用であるが、もっとも一般的なものは、ほかのプロビジョナが引き継ぐことができるように、シェル・スクリプトがシステムの何かを起動するために使用される。

もし複数の"スコープ"レベルでプロビジョナを定義した場合（設定ブロックのグローバルな部分、[マルチ・マシン](https://www.vagrantup.com/docs/multi-machine/)定義の中、そして[プロバイダ固有の上書き](https://www.vagrantup.com/docs/providers/configuration.html)の中）、内側のスコープよりも前に外側のスコープが実行される。例えば以下のVagrantfileのようにする。

```bash
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
```

プロビジョナの順番は"foo"、"baz"、そして"bar"の順番である。(２番目が期待通りのものでないことに中止すること!)。順番は*"外から内"*である。

マルチ・プロビジョナである場合、何をいつ実行するかをよりきめ細かく制御できるように、名前とともに設定して`--provision-with`を使用する。

## プロビジョナ設定上書き

> **警告：上級者向け** プロビジョナの上書きは、すでにマルチ・マシンとプロバイダ上書きを使っているのであれば、きわめて有用な上級者向けの話題である。Vagrantを始めたばかりであれば、ここは読み飛ばすのが安全である。

[`マルチ・マシン`](https://www.vagrantup.com/docs/multi-machine/)や[`プロバイダ固有の上書き`](https://www.vagrantup.com/docs/providers/configuration.html)のような機能を使う際、Vagrantfileのグローバルな設定スコープ内で共通のプロビジョナを定義したいと思うかもしれないが、それらの特定の部分を内部的に上書きしてしまう。Vagrantはこれができるが、考慮すべき点がいくつかある。

設定を上書きするには、プロビジョナの名前を割り当てる必要がある。

```bash
Vagrant.configure("2") do |config|
  config.vm.provision "foo", type: "shell",
    inline: "echo foo"

  config.vm.define "web" do |web|
    web.vm.provision "foo", type: "shell",
      inline: "echo bar"
  end
end
```

上記では、インラインの設定は外側のプロビジョナで上書きされるため、"bar"だけが表示される。この上書きは"web"仮想マシンのスコープ内でのみ有効である。もし、他の仮想マシンが定義されていた場合、それ自身がプロビジョナを上書きしていないならば、"foo"を表示する

**順番には注意すること。**サブ・スコープ内でプロビジョナを上書きする場合、プロビジョナはそこで実行される。以下の例では、出力は"foo"のあとに"bar"が表示される。

```bash
Vagrant.configure("2") do |config|
  config.vm.provision "foo", type: "shell",
    inline: "echo ORIGINAL!"

  config.vm.define "web" do |web|
    web.vm.provision "shell",
      inline: "echo foo"
    web.vm.provision "foo", type: "shell",
      inline: "echo bar"
  end
end
```

オリジナルの順番を保持したい場合、`preserve_order: true`フラグで指定することができる。.

# ファイル・プロビジョナ

## プロビジョナ名：`"file"`

Vagrantのfileプロビジョナはホスト・マシンからゲスト・マシンへ、ファイルまたはディレクトリをアップロードすることができる。

fileプロビジョニングは単純な方法である。例えば、`git config --global`を新しい仮想マシンをプロビジョニングするたびに実行することなく、ローカルの~/.gitconfigからゲスト・マシンのVagrantユーザのホームディレクトリにコピーする。

```bash
Vagrant.configure("2") do |config|
  # ... other configuration

  config.vm.provision "file", source: "~/.gitconfig", destination: ".gitconfig"
end
```

同期フォルダとは異なり、アップロードされたファイルやディレクトリはsyncで同期されない点に注意すること。上記の例の続きとして、もし、ローカルの~/.gitconfigにさらに変更させた場合でも、ゲスト・マシンにアップロードしたコピーに即座に反映されない。

fileプロビジョナによるファイルのアップロードは、SSHやPowerShellユーザのように行われる。これらのユーザは一般的には自分自身では権限の昇格をされることはないという点で重要である。

対象とするファイルは作業用の場所にアップロードしたのち、`Shellプロビジョナ`を使用して目的の場所へ移動することを推奨する。

## オプション

ファイル・プロビジョナはたった2つのオプションしかとらない。ともに必須である。

* [`source`](https://www.vagrantup.com/docs/provisioning/file.html#source) (文字列) - アップロードしたいファイルまたはディレクトリのローカルパスを文字列で指定する。
* [`destination`](https://www.vagrantup.com/docs/provisioning/file.html#destination) (文字列) - 対象をアップロードする先となるゲスト・マシン上のリモート・パスを文字列で指定する。ファイル/フォルダはSCPを介してSSHとしてアップロードされるので、アップロード先はそのユーザが書き込み可能な必要がある。SSHユーザは`vagrant ssh-config`を実行することで決定することができ、デフォルトでは"vagrant"である。

# Shellプロビジョナ

## プロビジョナ名：`"shell"`

VagrantのShellプロビジョナは、ゲスト・マシンにスクリプトをアップロードまたは実行できるようにする。

Shellプロビジョニングは、素早く起動し運用したい新しいVagrantユーザにとって理想的であり、ChefやPuppetなどのような完全なる構成管理システムを快適だと感じないユーザーに対して強力な選択肢を提供する。

POSIX準拠のマシンに対して、ShellプロビジョナはSSHでスクリプトを実行する。Windowsゲスト・マシンに対しては、WinRMを使用して設定し、ShellプロビジョナはWinRMを介してPowerShelldでバッチ・スクリプトを実行する。

## オプション

Shellプロビジョナは様々なオプションを持つ。`inline`または`path`のうち一方が必須である。

* `inline` (文字列) - リモート・マシン上で実行するためのインライン・Shellコマンドを指定する。詳細は[インライン・スクリプト](https://www.vagrantup.com/docs/provisioning/shell.html#inline-scripts) セクションを参照のこと。
* `path` (文字列) - アップロードまたは実行するためのシェル・スクリプトへのパスを指定する。プロジェクトのVagrantfileに対する相対パス、または、リモート・スクリプト([gist](https://gist.github.com/)のような)とすることができる。

適応可能なオプションについて示す。これらは必須ではない。

* [`args`](https://www.vagrantup.com/docs/provisioning/shell.html#args) (文字列 または 列挙) - 一つの文字列のような、実行時にシェル・スクリプトに受け渡す引数。これらの引数は、コマンド・ライン上で直接打った時と同様に、エスケープ文字、クォートなどが必要であれば、明確に入力される必要がある。この場合、Vagrantはクォートで扱う。
* [`env`](https://www.vagrantup.com/docs/provisioning/shell.html#env) (ハッシュ値) - スクリプトに対する環境変数として、キー/値のペアリストを渡す。Vagrantは環境変数の値に対してクォートで扱うが、キーに対してまそのままとなる。
* [`binary`](https://www.vagrantup.com/docs/provisioning/shell.html#binary) (ブール値) - Vagrantは自動的にWindows改行文字をUnix改行文字に置き換える。この設定値がfalseである場合、Vagrantはこれを行わない。デフォルト値は"false"である。ShellプロビジョナがWinRMを介して通信する場合、これは"true"である。
* [`privileged`](https://www.vagrantup.com/docs/provisioning/shell.html#privileged) (ブール値) - シェル・スクリプトを権限を付与したユーザとして実行するか、そうでないか(`sudo`)を指定する。デフォルトでは"true"である。Windowsゲストは、WinRMの制限なしに、実際の管理者として実行するためのスケジュールされたタスクを使用する。
* [`upload_path`](https://www.vagrantup.com/docs/provisioning/shell.html#upload_path) (文字列) - シェル・スクリプトがアップロードされる先へのリモート・パスを指定する。スクリプトはSCPを介してSSHユーザとしてアップロードされる。そのため、この場所はそのユーザが書き込み可能である必要がある。デフォルトでこれは"/tmp/vagrant-shell"である。Windowsにおいては、"C:\tmp\vagrant-shell"である。
* [`keep_color`](https://www.vagrantup.com/docs/provisioning/shell.html#keep_color) (ブール値) - Vagrantは、出力が標準出力からであるか、標準エラー出力からであるかによって、自動的に緑色か赤色で表示する。この値がtrueであれば、Vagrantはこの動作を行わず、出力されるスクリプトからのそのままの色とする。
* [`name`](https://www.vagrantup.com/docs/provisioning/shell.html#name) (文字列) - 多くのShellプロビジョナがある場合に、ユーザが簡単に識別できるように、出力に表示する値。
* [`powershell_args`](https://www.vagrantup.com/docs/provisioning/shell.html#powershell_args) (文字列) - Windows上でPowerShelでプロビジョニングを行う場合にPowerShell`に受け渡す引数。
* [`powershell_elevated_interactive`](https://www.vagrantup.com/docs/provisioning/shell.html#powershell_elevated_interactive) (ブール値) - Windows上で対話モード中で昇格したスクリプトを実行する。デフォルトでは"false"。同時に`privileged`である必要がある。ユーザは作業のために対話モードでログインしている必要があるので、Windowsへのオート・ログインを有効としていることを確認すること。

# インライン・スクリプト

おろらく始めるための最も簡単な方法は、インライン・スクリプトである。インライン・スクリプトはVagrantfile内でVagrantに直接与えるスクリプトである。最もわかりやすい例は以下である。

```bash
Vagrant.configure("2") do |config|
  config.vm.provision "shell",
    inline: "echo Hello, World"
end
```

これは、プロビジョナが実行されたときにゲスト・マシン内で実行され、`echo Hello`を実行する。

小さなRubyとともに用いることで、これは、Vagrantfile内に直接シェル・スクリプトを組み込めてとても簡単である。その他の例としては、以下の通りである。

```bash
$script = <<SCRIPT
echo I am provisioning...
date > /etc/vagrant_provisioned_at
SCRIPT

Vagrant.configure("2") do |config|
  config.vm.provision "shell", inline: $script
end
```

Rubyに精通していない場合、上記はとても高度であるか異質に思えることは理解できる。しかし、恐れる必要はなく、何をやっているのかは非常に単純である。このスクリプトはグローバル変数`$script`に割り当てを行う。このグローバル変数はVagrantの設定に対してインライン・スクリプトとして受け渡される文字列となる。

もちろん、基本的な変数割り当ての外側にある、VagrantfileのRubyを不快に思うならば、実際のスクリプト・ファイルを使用することができる。これについては後述する。

Windowsゲスト・マシンにとって、 インライン・スクリプトはPowerShellである必要がある。バッチ・スクリプトはインライン・スクリプトとしては許されない。

## 外部スクリプト

Shellプロビジョナはホスト・マシン上のシェル・スクリプトへのパスを指定するオプションもとることができる。Vagrantはこのスクリプトをゲスト・マシンへアップロードし実行する。例を示す。

```bash
Vagrant.configure("2") do |config|
  config.vm.provision "shell", path: "script.sh"
end
```

上記の通り相対パスはプロジェクトのVagrantfileの位置をルートとして展開される。絶対パスも使用することができる。`~`(ホーム・ディレクトリ)と`..`（親ディレクトリ）だけでなく、絶対パスも使用することができる。

プロビジョニング処理の一部としてリモート・スクリプトを使用する場合、同様に`path`の引数としてそのURLの中に受け渡すことができる。

```bash
Vagrant.configure("2") do |config|
  config.vm.provision "shell", path: "https://example.com/provisioner.sh"
end
```

WindowsのPowerShellスクリプトのバッチを実行する場合、Windowsは実行するファイルが何であるかを決定するのに拡張子を使うため、外部パスが正しい拡張子(".bat"または"ps1")を持っているか確認すること。この拡張子を取り除いた場合、おそらく動作しない。

ゲスト・マシン上ですでに利用できるスクリプトを実行する為に、ゲスト・マシン上のリモートスクリプトを呼び出すインライン・スクリプトを使用することができる。

```bash
Vagrant.configure("2") do |config|
  config.vm.provision "shell",
    inline: "/bin/sh /path/to/the/script/already/on/the/guest.sh"
end
```

## スクリプトの引数

通常のシェル・スクリプトと同様にスクリプトをパラメータ化することができる。これらの引数はShellプロビジョナに対して指定することができる。また、これらはコマンド・ライン上で打ち込まれる文字列として指定する必要があるので、いずれも適切にエスケープされていること。

```bash
Vagrant.configure("2") do |config|
  config.vm.provision "shell" do |s|
    s.inline = "echo $1"
    s.args   = "'hello, world!'"
  end
end
```

クォートの心配をしたくないなら、列挙する形で引数を指定することもできる。

```bash
Vagrant.configure("2") do |config|
  config.vm.provision "shell" do |s|
    s.inline = "echo $1"
    s.args   = ["hello, world!"]
  end
end
```

# Anslibleプロビジョナ

## プロビジョナ名：`ansible`

VagrantのAnsibleプロビジョナは**Vagrantホストから**[Ansible](http://ansible.com/)のplaybookを`ansible-playbook`で実行することでゲストをプロビジョニングする。

> **警告：**AnsibleとVagrantをまだ深く理解していないならば、[Shellプロビジョナ](https://www.vagrantup.com/docs/provisioning/shell.html)から始めるのを推奨する。しかしながら、すでにVagrantを使いこなしているならば、VagrantはAnsibleを学ぶための素晴らしい方法となるだろう。

## 構築に対する要求事項

* **Vagrantのホスト**へ[Ansibleをインストールする](https://docs.ansible.com/intro_installation.html#installing-the-control-machine)
* Vagranのホストは[ControlPersistをサポートする](https://docs.ansible.com/faq.html#how-do-i-get-ansible-to-reuse-connections-enable-kerberized-ssh-or-have-ansible-pay-attention-to-my-local-ssh-config-file)OpenSSHの最新バージョンを提供できるのが理想である。

開発環境において、AnsibleをVagrantのホストに直接インストールするという選択肢がない場合、[Ansibleローカル・プロビジョナ](https://www.vagrantup.com/docs/provisioning/ansible_local.html)を参考にすること。

## 使い方

ここでは`ansible`(リモート)プロビジョナの特定の部分についてのみ記載する。PlaybookやInventoryなどの一般的なAnsibleの概念は[AnsibleとVagrantの紹介](https://www.vagrantup.com/docs/provisioning/ansible_intro.html)で簡単にふれている。

## 最も単純な設定

Vagrantゲストに対してAnsibleを実行するには、以下のような基本的な`Vagrantfile`設定となる。

```bash
Vagrant.configure("2") do |config|

  #
  # Run Ansible from the Vagrant Host
  #
  config.vm.provision "ansible" do |ansible|
    ansible.playbook = "playbook.yml"
  end

end
```

## オプション

ここではAnsible(リモート)プロビジョナに対する特定のオプションを示す。このプロビジョナは以下に示すオプションに加えて、[2つのAnsibleプロビジョナに対する共通のオプション](https://www.vagrantup.com/docs/provisioning/ansible_common.html)をサポートする。

* `ask_sudo_pass` (ブール値) - Ansibleに[sudoパスワードに対するプロンプト](https://docs.ansible.com/intro_getting_started.html#remote-connection-information)を要求する。デフォルトでは`false`である。
* `ask_vault_pass` (ブール値) - Ansibleに[vaultパスワードに対するプロンプト](https://docs.ansible.com/playbooks_vault.html#vault)を要求する。デフォルトでは`false`である。
* `force_remote_user` (ブール値) - 
生成されたインベントリ内で設定された、または、静的インベントリが使用されている場合に外部の変数として設定された`ansible_ssh_user`を設定するようにVagrantに要求する。すべてのAnsibleの`remote_user`パラメータは[Vagrant SSH設定](https://www.vagrantup.com/docs/vagrantfile/ssh_settings.html)の`config.ssh.username`の値によって上書きされる。  
このオプションが`false`に設定されている場合、VagrantはVagrantのSSHユーザ名をデフォルトのAnsibleリモート・ユーザとして設定するが、AnsibleのPlayまたはTaskの`remote_user`パラメータは、この設定を超えてVagrant設定を上書きする。  
デフォルトでは`true`である。  
**注意：**このオプションはVagrant 1.8.0から導入された。以前のVagrantのバージョンでは、このオプションが`false`で設定されたように振る舞う。
* `host_key_checking` (ブール値) - Ansibleに[SSHホスト鍵チェックの有効化](https://docs.ansible.com/intro_getting_started.html#host-key-checking)を要求する。  
デフォルトでは`false`である。
* [`raw_ssh_args`](https://www.vagrantup.com/docs/provisioning/ansible.html#raw_ssh_args) (文字列の列挙) - OpenSSHクライアント・オプションの一覧を適応するようにAnsibleに要求する。  
例: `['-o ControlMaster=no']`.  
これは`ANSIBLE_SSH_ARGS`環境変数を介したAnsibleに対する追加的なSSH設定へ受け渡すために使用することが出来る、その他のいかなるSSH引数(例えば [`ansible.cfg`設定ファイル](https://docs.ansible.com/intro_configuration.html#ssh-args)で定義されているもの)をも上書きする*危険なワイルドカード*である。

## ヒントとテクニック

### Ansibleの並列実行

Vagrantは`マルチ・マシン環境`を順番にプロビジョニングするように設計されているが、以下の設定パタンはAnsibleの並列性の優位性を得ることができる。

```bash
# Vagrant 1.7+ automatically inserts a different
# insecure keypair for each new VM created. The easiest way
# to use the same keypair for all the machines is to disable
# this feature and rely on the legacy insecure key.
# config.ssh.insert_key = false
#
# Note:
# As of Vagrant 1.7.3, it is no longer necessary to disable
# the keypair creation when using the auto-generated inventory.

N = 3
(1..N).each do |machine_id|
  config.vm.define "machine#{machine_id}" do |machine|
    machine.vm.hostname = "machine#{machine_id}"
    machine.vm.network "private_network", ip: "192.168.77.#{20+machine_id}"

    # Only execute once the Ansible provisioner,
    # when all the machines are up and ready.
    if machine_id == N
      machine.vm.provision :ansible do |ansible|
        # Disable default limit to connect to all the machines
        ansible.limit = "all"
        ansible.playbook = "playbook.yml"
      end
    end
  end
end
```

### 注意点

もし静的Ansibleインベントリで、この並列プロビジョニングを適用する場合、[すべての適切な秘密鍵が`ansible-playbook`コマンドに対して提供されている](https://github.com/mitchellh/vagrant/pull/5765#issuecomment-120247738)ように構成する必要がある。 同様の懸念事項としては、同一のマシンに複数の秘密鍵を使用する場合がある(see [`config.ssh.private_key_path`SSH設定](https://www.vagrantup.com/docs/vagrantfile/ssh_settings.html)を参照)。

## 強制Paramiko接続モード

Ansibleプロビジョナはネイティブ OpenSSHをサポートすることを念頭に置いて実装されており、[paramiko](https://github.com/paramiko/paramiko/) (ネイティブ Python SSHv2プロトコル・ライブラリ)に対する公式なサポートはない。

この接続モードを使用する必要が実際にある場合、次の構成例で例示されるように有効にすることができる。

自動生成インベントリを用いて
```bash
ansible.raw_arguments = ["--connection=paramiko"]
```

カスタム・インベントリを用いた場合、秘密鍵を指定する必要ばある(例 `ansible.cfg`設定ファイルを介して, `--private-key argument`引数、または、インベントリ・ファイルの一部として）

```bash
ansible.inventory_path = "./my-inventory"
ansible.raw_arguments  = [
  "--connection=paramiko",
  "--private-key=/home/.../.vagrant/machines/.../private_key"
]
```

# Ansible ローカル・プロビジョナ

## プロビジョナ名：`ansible_local`

VagrantのAnsible ローカル・プロビジョナは*ゲストマシンから直接*`ansible-playbook`を実行することで[Ansible](http://ansible.com/) playbookを用いてゲストをプロビジョニングする。

> **警告：**AnsibleとVagrantをまだ深く理解していないならば、[Shellプロビジョナ](https://www.vagrantup.com/docs/provisioning/shell.html)から始めるのを推奨する。しかしながら、すでにVagrantを使いこなしているならば、VagrantはAnsibleを学ぶための素晴らしい方法となるだろう。


## 構築に対する要求事項

Ansible ローカル・プロビジョナを [Ansible (リモート) プロビジョナ(https://www.vagrantup.com/docs/provisioning/ansible.html)と比較した際の最も優位な点は、Vagrantホストマシン上にいかなる追加ソフトウェアを要求することがないことである。

一方で、ゲストマシン上に[Ansibleは必ずインストールされている必要がある](https://docs.ansible.com/intro_installation.html#installing-the-control-machine)。

**注意：** デフォルトでは、ゲストマシン上にAnsibleがまだ存在していない場合、Vagrantは自動的にAnsibleをインストールしようとする(より詳細は`install`オプションを参照)。

## 使い方

ここでは`ansible_local`プロビジョナの特定の部分についてのみ記載する。PlaybookやInventoryなどの一般的なAnsibleの概念は[AnsibleとVagrantの紹介](https://www.vagrantup.com/docs/provisioning/ansible_intro.html)で簡単にふれている。

Ansible ローカル・プロビジョナはAnsibleのPlaybokkのファイルのすべてがゲスト・マシン上、`provisioning_path`オプションで指定された場所にあることを要求する。通常、初期状態でこれらのファイルは（Vagrantプロジェクトの一部として）ホスト／マシン上に存在する。そしてそれらはVagrant[同期フォルダ](https://www.vagrantup.com/docs/synced-folders/)によって極めて簡単に共有される。

## 最も単純な設定

VagrantのゲストからAnsibleを実行するための基本的な`Vagrantfile`の設定は以下のようになる。

```bash
Vagrant.configure("2") do |config|
  # Run Ansible from the Vagrant VM
  config.vm.provision "ansible_local" do |ansible|
    ansible.playbook = "playbook.yml"
  end
end
```

### 要求事項

* [playbook.yml](https://www.vagrantup.com/docs/provisioning/ansible_local.html#playbook_yml)ファイルはVagrantのプロジェクトのホーム・ディレクトリに格納されている。
* [デフォルトの共有ディレクトリ](https://www.vagrantup.com/docs/synced-folders/basic_usage.html)が有効(`.` → `/vagrant`)。

## オプション

ここではAnsible ローカル・プロビジョナに対する特定のオプションを示す。このプロビジョナは以下に示すオプションに加えて、[2つのAnsibleプロビジョナに対する共通のオプション](https://www.vagrantup.com/docs/provisioning/ansible_common.html)をサポートする。

* [`install`](https://www.vagrantup.com/docs/provisioning/ansible_local.html#install) (ブール値) - ゲスト／システム上にAnsibleを自動的にインストールすることを試みる。  
デフォルトでは有効である。  
Vagrantは以下のいずれかの状態で有るときに、Ansibleをインストール（またはアップグレード）しようと試みる。  
  - Ansibleがインストールされていない（または見つからない）。
  - `version`オプションが`"latest"`に設定されている
  - 現在のAnsibleのバージョンが`version`オプションと一致していない。  

**注意：**Vagrant Box上に既に存在しているかもしれない、カスタマイズされたAnsibleのセットアップをこの自動化されたインストールが置き換えるという保証はない。

* [`provisioning_path`](https://www.vagrantup.com/docs/provisioning/ansible_local.html#provisioning_path) (文字列) - Ansibleのファイルが格納されているゲスト・マシン上の絶対パス。`ansible-playbook`コマンドはこのディレクトリから実行される。  
デフォルトでは`/vagrant`。
* [`tmp_path`](https://www.vagrantup.com/docs/provisioning/ansible_local.html#tmp_path) (文字列) - Ansible ローカル・プロビジョナによってテンポラリ・ファイルが格納される、ゲスト／マシン上の絶対パス。    
デフォルトでは`/tmp/vagrant-ansible`。
* [`version`](https://www.vagrantup.com/docs/provisioning/ansible_local.html#version) (文字列) - 期待するAnsibleのバージョン 
デフォルトではこのオプションは無効。  
Ansibleバージョンが定義されていた場合(例えば`"1.8.2"`)、Ansible ローカル・プロビジョナは、インストールされたAnsibleが量級されたバージョンである時のみ、実行する  
このオプションが`"latest"`に設定された場合、バージョンチェックは適応されない。

**注意：**現在、どのバージョンのAnsibleが自動的にインストールされるべきかを指定するために、このオプションを使用することは出来なし。インストール・オプションが有効であれば、対象のオペレーティング・システムに対する最新のパッケージ化されたバージョンがインストールされる。

## ヒントとテクニック

### ゲストからのAnsible並列実行

以下の設定パタンで、一つのゲストマシン（`"controller"`)上のみからすべてのマシンに対するプロビジョニングするためにAnsibleのインストールと実行ができる

```bash
Vagrant.configure("2") do |config|

  config.vm.box = "ubuntu/trusty64"

  config.vm.define "node1" do |machine|
    machine.vm.network "private_network", ip: "172.17.177.21"
  end

  config.vm.define "node2" do |machine|
    machine.vm.network "private_network", ip: "172.17.177.22"
  end

  config.vm.define 'controller' do |machine|
    machine.vm.network "private_network", ip: "172.17.177.11"

    machine.vm.provision :ansible_local do |ansible|
      ansible.playbook       = "example.yml"
      ansible.verbose        = true
      ansible.install        = true
      ansible.limit          = "all" # or only "nodes" group, etc.
      ansible.inventory_path = "inventory"
    end
  end

end
```

`Vagrantfile`マシン定義に対応した静的`インベントリ`ファイルを生成する必要がある

```bash
controller ansible_connection=local
node1      ansible_ssh_host=172.17.177.21 ansible_ssh_private_key_file=/vagrant/.vagrant/machines/node1/virtualbox/private_key
node2      ansible_ssh_host=172.17.177.22 ansible_ssh_private_key_file=/vagrant/.vagrant/machines/node2/virtualbox/private_key

[nodes]
node[1:2]
```

最後に、SSHホスト鍵のチェックを完全に無効化するための[`ansible.cfg`ファイル](https://docs.ansible.com/intro_configuration.html#openssh-specific-settings)を生成する必要もある。詳細なSSHの設定は`ssh_args`パラメータ(例 エージェント転送等)に追加することが出来る。

```bash
[defaults]
host_key_checking = no

[ssh_connection]
ssh_args = -o ControlMaster=auto -o ControlPersist=60s -o UserKnownHostsFile=/dev/null -o IdentitiesOnly=yes
```

# CFEngine プロビジョナ

## プロビジョナ名：`cfengine`

VagrantのCFEngineプロビジョナは、[CFEngine](https://cfengine.com/)を用いてゲストをプロビジョニングをする。これはCFEngineポリシー・サーバとクライアントの双方を設定できる。また、ポリシー・サーバとクライアントの双方をを単一の[マルチ・マシンVagrantfile](https://www.vagrantup.com/docs/multi-machine/)で設定できる。

> **警告：**もし、CFEngineとVagrantをまだ深く理解していないならば、[Shellプロビジョナ](https://www.vagrantup.com/docs/provisioning/shell.html)から始めるのを推奨する。しかしながら、すでにVagrantを使いこなしているならば、VagrantはCFEngineを学ぶための素晴らしい方法となるだろう。

まずはいくつかの共通の例を見てみよう。詳細なオプションの一覧は、この章の末尾を参照のこと。

## CFEngineサーバとクライアントの構築

CFEngineプロビジョナは自動的に仮想マシン上に最新の[CFEngine Community packages](https://cfengine.com/cfengine-linux-distros)をインストールする。そして、指定に従いCFEngineの設定と起動を行う。

CFEngineポリシー・サーバとして仮想マシンを設定するのは簡単である。

```bash
Vagrant.configure("2") do |config|
  config.vm.provision "cfengine" do |cf|
    cf.am_policy_hub = true
  end
end
```

ホストは自身をポリシー・サーバとするように、自動的に[ブートストラップ](https://cfengine.com/docs/3.5/manuals-architecture-networking.html#bootstrapping)される。

CFEngineポリシー・サーバ稼働しているものをすでに持っていれば、そのIPアドレスで指定することでインストールされブートストラップされたCFEngineクライアントを手に入れることができる。

```bash
Vagrant.configure("2") do |config|
  config.vm.provision "cfengine" do |cf|
    cf.policy_server_address = "10.0.2.15"
  end
end
```

## 仮想マシンへのファイルコピー

もし、デフォルトで仮想マシンにインストールしたいポリシーまたはそのほかのファイルがあるなら、`files_path`属性を使用することができる。

```bash
Vagrant.configure("2") do |config|
   config.vm.provision "cfengine" do |cf|
      cf.am_policy_hub = true
      cf.files_path = "cfengine_files"
    end
  end
```

Vagrantプロジェクト・ディレクトリ内の`cfengine_files/`配下のすべてのファイルは、仮想マシンの`/var/cfengine/`配下に再帰的にコピーされる。

一般的な使用事例は、ポリシー・サーバ内の`/var/cfengine/masterfiles/`にあなた自身のファイルを追加することである。`cfengine_files/masterfiles/`の下にそれらのファイルが格納されていることを前提として、上述
のコードはCFEngineがインストールされた後、仮想マシンにファイルを追加する。これはブートストラップ前に行われる。

## 操作モード

デフォルトの操作モードは`:bootstrap`である。そして、これにより`Vagrantfile`内に示される情報に従ってCFEngineがブートストラップされる。`mode`を`:single_run`に設定することもできる。この場合、`run_file`パラメータで指定されたファイルを実行する為に、ホスト上で一度`cf-agent`が実行されるが、ブートストラップは行われず、定期的な実行も行われない。

奨さ操作モードは`:bootstrap`である。これを定期的に実行したとき、CFEngineのすべての恩恵を受けるだろう。

## スタンド・アローン・ファイルの実行

もし、スタンドアローン・ファイルを実行したいなら、`run_file`パラメータで指定できる。ファイルは仮想マシンにコピーされ、それ自身の`cf-agent`を使用して実行される。ファイルはその[body common control](https://cfengine.com/docs/3.5/reference-components.html#common-control)に含まれるスタンド・アローン・ポリシーであるべき点に注意すること。

もし、`mode`が`:single_run`に設定されているならば`run_file`パラメータは必須であるが、`mode`が`:bootstrap`設定された場合も同様に指定が必要である。このケースでは、ファイルはホストがブートストラップされた後に実行される。

## アルファベット順　全設定オプション

* [`am_policy_hub`](https://www.vagrantup.com/docs/provisioning/cfengine.html#am_policy_hub) (ブール値、デフォルトは`false`) - 仮想マシンが（自動的に自分自身のIPアドレスブートストラップした）CFEngine ポリシー・ハブとして設定されるかどうかを決定する。もし、仮想マシンが複数ネットワーク・インタフェースを持て、特定の一つに対してブートストラップしたい場合、`policy_server_address`と合わせて使うことができる。
* [`extra_agent_args`](https://www.vagrantup.com/docs/provisioning/cfengine.html#extra_agent_args) (文字列、デフォルトは`nil`) - 実行時に`cf-agent`に追加的な引数を受け渡す為に使用することができる。例えば、エージェントからの追加的な出力を有効にするためのオプション`-I`や`-v`を渡すために使用することができる。
* [`classes`](https://www.vagrantup.com/docs/provisioning/cfengine.html#classes) (列挙, デフォルトは`nil`) - `cf-agent`実行中に追加的なクラスを定義するために使用することができる。これらのクラスは`cf-agent`へのオプション`-D`を使用することで定義される。
* [`deb_repo_file`](https://www.vagrantup.com/docs/provisioning/cfengine.html#deb_repo_file) (文字列, デフォルトは`"/etc/apt/sources.list.d/cfengine-community.list"`) - Debianシステムで格納されたCFEngineリポジトリ情報内のファイルを指定する。
* [`deb_repo_line`](https://www.vagrantup.com/docs/provisioning/cfengine.html#deb_repo_line) (文字列、デフォルトは`"deb https://cfengine.com/pub/apt $(lsb_release -cs) main"`) - `.deb`パッケージに対して使用するリポジトリを指定する。
* [`files_path`](https://www.vagrantup.com/docs/provisioning/cfengine.html#files_path) (文字列、デフォルトは`nil`) - 仮想マシンの、デフォルトでは`/var/cfengine/`の最上位にコピーされるディレクトリを指定する。(`/var/cfengine/`の内容は置き換えされず、追加される。)。
* [`force_bootstrap`](https://www.vagrantup.com/docs/provisioning/cfengine.html#force_bootstrap) (ブール値、デフォルトは`false`) - ホストがすでにブートストラップされていても、CFEngineが再度ブートストラップするかどうかを指定する。
* [`install`](https://www.vagrantup.com/docs/provisioning/cfengine.html#install) (ブール値または`:force`、 デフォルトは`true`) - 必要に応じて仮想マシン上にCFEngineをインストールするかどうかを指定する。このパラメータを`:force`に設定した場合、マシンにすでに存在していても、CFEngineを再インストールする。
* [`mode`](https://www.vagrantup.com/docs/provisioning/cfengine.html#mode) (`:bootstrap`または`:single_run`、デフォルトは`:bootstrap`) - CFEngineがブートストラップを定期的に実行するか、一度だけとするかを指定する。`mode`が`:single_run`に設定された場合、`run_file`を設定する必要がある。
* [`policy_server_address`](https://www.vagrantup.com/docs/provisioning/cfengine.html#policy_server_address) (文字列, デフォルトなし) - CFEngineがブートストラップされる、ポリシー・サーバのIPアドレスを指定する。もし、 `am_policy_hub`が`true`に設定された場合、このパラメータはデフォルトでは仮想マシンのIPアドレスとなっている。しかし、さらに指定することができる(例えば、仮想マシンが1つ以上のネットワーク・インタフェースを持つ場合)。
* [`repo_gpg_key_url`](https://www.vagrantup.com/docs/provisioning/cfengine.html#repo_gpg_key_url) (文字列、デフォルトは`"https://cfengine.com/pub/gpg.key"`) - リポジトリから入手されたパッケージを検証する際に使用するGPG鍵を入手するためのURL。
* [`run_file`](https://www.vagrantup.com/docs/provisioning/cfengine.html#run_file) (文字列、デフォルトは`nil`) - 仮想マシンにコピーされ、`cf-agent@によって一度実行される、Vagrantプロジェクト・ディレクトリ内にあるファイルを指定するの使用することができる。もし`mode`が`:single_run`に設定されている場合、このパラメータは必須であるが、`mode`が`:bootstrap`設定された場合も同様に指定が必要である。このケースでは、ファイルはホストがブートストラップされた後に実行される。
* [`upload_path`](https://www.vagrantup.com/docs/provisioning/cfengine.html#upload_path) (文字列、デフォルトでは`"/tmp/vagrant-cfengine-file"`) - 実行される前に、(もし指定されている場合)`run_file`で仮想マシン上にコピーされるファイルをしてする。
* [`yum_repo_file`](https://www.vagrantup.com/docs/provisioning/cfengine.html#yum_repo_file) (文字列、デフォルトでは`"/etc/yum.repos.d/cfengine-community.repo"`) - RedHatシステムで格納されたCFEngineリポジトリ情報内のファイルを指定する。
* [`yum_repo_url`](https://www.vagrantup.com/docs/provisioning/cfengine.html#yum_repo_url) (文字列、デフォルトでは`"https://cfengine.com/pub/yum/"`) - `.rpm`パッケージに対して使用するリポジトリを指定する。
* [`package_name`](https://www.vagrantup.com/docs/provisioning/cfengine.html#package_name) (文字列、デフォルトでは`"cfengine-community"`) - CFEngineをインストールする為に使用するパッケージの名前を指定する。

# Chef Solo プロビジョナ

## プロビジョナ名：`chef_solo`

VagrantのChef Soloプロビジョナは[Chef](https://www.chef.io/chef/)、具体的には[Chef Solo](https://docs.chef.io/chef_solo.html)を使用してゲストをプロビジョニングできる。

Chef Soloは、Chefを経験している、Chef CookBookを持っている、Chefを学ぼうとしている人にとって理想的である。Chefは完成されたシステムであり膨大なページ数となるため、この文書ではChefの使い方やChef CookBookの書き方については言及しない。

> **警告：**ChefとVagrantをまだ深く理解していないならば、[Shellプロビジョナ](https://www.vagrantup.com/docs/provisioning/shell.html)から始めるのを推奨する。しかしながら、すでにVagrantを使いこなしているならば、VagrantはChefを学ぶための素晴らしい方法となるだろう。

## オプション

ここではChef Soloプロビジョナに対して適応できるすべてのオプションを示す。プロビジョナをどのように使用するかの詳細な例については後述する。

* [`cookbooks_path`](https://www.vagrantup.com/docs/provisioning/chef_solo.html#cookbooks_path) (文字列、または、列挙) - CookBookが格納されるパスのリスト。デフォルトではこれは"cookbooks"であり、cookbooksフォルダはVagrantfileのパスに対する相対パスであることを期待する。
* [`data_bags_path`](https://www.vagrantup.com/docs/provisioning/chef_solo.html#data_bags_path) (文字列、または、列挙) - Data Bagを格納しているパス。デフォルトではData Bagのパスは設定されていない。Chef 12以上は列挙オプションを使用することが要求される。Chef 11以下では文字列しか受け付けない。
* [`environments_path`](https://www.vagrantup.com/docs/provisioning/chef_solo.html#environments_path) (文字列) - 環境定義が配置されているパス。デフォルトでは環境フォルダは設定されていない。
* [`nodes_path`](https://www.vagrantup.com/docs/provisioning/chef_solo.html#nodes_path) (文字列、または、列挙) - (JSONフォーマットで記載された）ノード・オブジェクトが格納されているパスを示す。デフォルトではノードのパスは設定されていない。
* [`environment`](https://www.vagrantup.com/docs/provisioning/chef_solo.html#environment) (文字列) - Chefをその一部として実行したい環境を指定する。これはChef 11.6.0以降で要求され、`environments_path`がセットされる必要がある。
* [`recipe_url`](https://www.vagrantup.com/docs/provisioning/chef_solo.html#recipe_url) (文字列) - Chefがダウンロードして使用する、CookBookのアーカイブへのURL。
* [`roles_path`](https://www.vagrantup.com/docs/provisioning/chef_solo.html#roles_path) (文字列、または、列挙) - Roleが定義されているパスを示す。デフォルトではこれは空である。複数のRoleディレクトリはChef 11.8以降でサポートされる。
* [`synced_folder_type`](https://www.vagrantup.com/docs/provisioning/chef_solo.html#synced_folder_type) (文字列) - プロビジョナが適切に動作するために要求されたデータを共有するときに使用される同期フォルダの種類。デフォルトではこれはデフォルトの同期フォルダの種類が使用される。例えば、"nfs"が設定されていればNSF同期フォルダが使用される。

上述したすべてのオプションに加え、Chef Soloプロビジョナは[全Chefプロビジョナの共通オプション](https://www.vagrantup.com/docs/provisioning/chef_common.html)をサポートする。

## 実行リストの指定

Chef Soloプロビジョナを使い始める最も簡単な方法は[実行リスト](https://docs.chef.io/nodes.html#about-run-lists)で指定するだけである。以下に示す。

```bash
Vagrant.configure("2") do |config|
  config.vm.provision "chef_solo" do |chef|
    chef.add_recipe "apache"
  end
end
```

これはVagrantが"apache"のCookBookでChef Soloを実行する。デフォルトでのCookBookはプロジェクト・ルートからの相対パスで示される"cookbooks"ディレクトリ内から探索される。このディレクトリは以下のようにディレクトリ構造の探索を終える。

```bash
$ tree
.
|-- Vagrantfile
|-- cookbooks
|   |-- apache
|       |-- recipes
|           |-- default.rb
```

`add_recipe`が呼び出される順番は実行リストの順番で指定される。`add_recipe`に追加された順番が早いものは、順番の遅いものより前に実行される。

## カスタムCookBookパス

デフォルトの"cookbooks"ディレクトリを使用する代わりに、カスタムCookBookパスも`cookbooks_path`設定ディレクティブを用いて設定することもできる。

```bash
Vagrant.configure("2") do |config|
  config.vm.provision "chef_solo" do |chef|
    chef.cookbooks_path = "my_cookbooks"
  end
end
```

パスは相対パスと絶対パスの両方を使用することができる。相対パスの場合、プロジェクト・ルートに対する相対パスとなる。

設定値はパスの列挙でも可能である。

```bash
Vagrant.configure("2") do |config|
  config.vm.provision "chef_solo" do |chef|
    chef.cookbooks_path = ["cookbooks", "my_cookbooks"]
  end
end
```

## Role

Vagrantは [Chef roles](https://docs.chef.io/roles.html)によるプロビジョニングもサポートしている。これは、Roleが定義されたRoleフォルダへのパスを指定し、実行リストにRoleを追加することによって行われる。

```bash
Vagrant.configure("2") do |config|
  config.vm.provision "chef_solo" do |chef|
    chef.roles_path = "roles"
    chef.add_role("web")
  end
end
```

CookBookのパスとちょうど同じように、Roleパスは相対パスが指定された場合、プロジェクト・ルートからの相対パスとなる。

Chef 11.8.0以降では、設定値はパスの列挙も可能である。それよりまえのバージョンのChefの場合、先頭のパスのみ使用される。

**注意：**Roleファイルの名前はRole名と同じ必要がある。例えば、`web`Roleであらば、`roles_path`の中でweb.jsonまたはweb.rbである。これはChef自身が要求することであり、Vagrantによる制限ではない。

## Data Bag

[Data bag](https://docs.chef.io/data_bags.html)はChef Soloプロビジョナでもサポートされている。これはData Bagディレクトリへのパスを指定することで行われる。

```bash
Vagrant.configure("2") do |config|
  config.vm.provision "chef_solo" do |chef|
    chef.data_bags_path = "data_bags"
  end
end
```

## カスタムJSONデータ

Chefの属性に対する追加的な設定データがChef Soloに受け渡すことができる。これは、JSONに変換してChefに受け渡される、Rubyのハッシュ（辞書のようなオブジェクト）によって表現された`json`プロパティに設定することで行われる。

```bash
Vagrant.configure("2") do |config|
  config.vm.provision "chef_solo" do |chef|
    # ...

    chef.json = {
      "apache" => {
        "listen_address" => "0.0.0.0"
      }
    }
  end
end
```

ハッシュ、配列などがJSON設定オブジェクトで使用される。基本的には、どんなものでもJSONの動作ができるようにきれいに変換される。

## カスタムNode名

`node_name`プロパティに設定することでカスタムNode名を指定することができる。
これは、ある種の値に設定されることに依存するCookBookに対して有用である。

例

```bash
Vagrant.configure("2") do |config|
  config.vm.provision "chef_solo" do |chef|
    chef.node_name = "foo"
  end
end
```
# Chef Zeroプロビジョナ

## プロビジョナ名：`chef_zero`

VagrantのChef Zeroプロビジョナは [Chef](https://www.getchef.com/chef/)、具体的には[Chef Zero/local mode](https://docs.getchef.com/ctl_chef_client.html#run-in-local-mode)を用いてゲストをプロビジョニングする。

この新しいプロビジョナは、本格的なChefサーバを稼働するのと、限定的な[Chef Solo](https://www.vagrantup.com/docs/provisioning/chef_solo.html)プロビジョナとの中間に位置する。これはローカル・イン・メモリでChefサーバを稼働し、検証と鍵登録を偽装する。

> 警告：**ChefとVagrantをまだ深く理解していないならば、[Shellプロビジョナ](https://www.vagrantup.com/docs/provisioning/shell.html)から始めるのを推奨する。しかしながら、すでにVagrantを使いこなしているならば、VagrantはChefを学ぶための素晴らしい方法となるだろう。

## オプション

ここではChef Zeroプロビジョナに対して適応できるオプションのすべてを示す。プロビジョナの使い方の詳細については後述する。

* [`cookbooks_path`](https://www.vagrantup.com/docs/provisioning/chef_zero.html#cookbooks_path) (文字列、または、列挙) - CookBookが格納されるパスのリスト。デフォルトではこれは"cookbooks"であり、cookbooksフォルダはVagrantfileのパスに対する相対パスであることを期待する。
* [`data_bags_path`] (文字列、または、列挙) - Data Bagを格納しているパス。デフォルトではData Bagのパスは設定されていない。Chef 12以上は列挙オプションを使用することが要求される。Chef 11以下では文字列しか受け付けない。
* [`environments_path`](https://www.vagrantup.com/docs/provisioning/chef_solo.html#environments_path) (string) - 環境定義が配置されているパス。デフォルトでは環境フォルダは設定されていない。
* [`nodes_path`](https://www.vagrantup.com/docs/provisioning/chef_zero.html#nodes_path) (文字列、または、列挙) - (JSONフォーマットで記載された）ノード・オブジェクトが格納されているパスを示す。デフォルトではノードのパスは設定されていない。
* [`environment`](https://www.vagrantup.com/docs/provisioning/chef_zero.html#environment) (文字列) - Chefをその一部として実行したい環境を指定する。これはChef 11.6.0以降で要求され、`environments_path`がセットされる必要がある。
* [`roles_path`](https://www.vagrantup.com/docs/provisioning/chef_zero.html#roles_path) (文字列、または、列挙) - Roleが定義されているパスを示す。デフォルトではこれは空である。複数のRoleディレクトリはChef 11.8以降でサポートされる。
* [`synced_folder_type`](https://www.vagrantup.com/docs/provisioning/chef_zero.html#synced_folder_type) (文字列) - プロビジョナが適切に動作するために要求されたデータを共有するときに使用される同期フォルダの種類。デフォルトではこれはデフォルトの同期フォルダの種類が使用される。例えば、"nfs"が設定されていればNSF同期フォルダが使用される。

上述したすべてのオプションに加え、Chef Zeroプロビジョナは[全Chefプロビジョナの共通オプション](https://www.vagrantup.com/docs/provisioning/chef_common.html)をサポートする。

## 使い方

Chef Zeroプロビジョナは、基本的にはChef Soloプロビジョナと同じように設定される。より詳細な情報は[Chef Soloドキュメント](https://www.vagrantup.com/docs/provisioning/chef_solo.html)を参照のこと。

基本的な一例はこのようになる。

```bash
Vagrant.configure("2") do |config|
  config.vm.provision "chef_zero" do |chef|
    # Specify the local paths where Chef data is stored
    chef.cookbooks_path = "cookbooks"
    chef.data_bags_path = "data_bags"
    chef.nodes_path = "nodes"
    chef.roles_path = "roles"

    # Add a recipe
    chef.add_recipe "apache"

    # Or maybe a role
    chef.add_role "web"
  end
end

```

# Chef Clientプロビジョナ

## プロビジョナ名：`chef_client`

VagrantのChef Clientプロビジョナは[Chef](https://www.chef.io/chef/)、インフラストラクチャ内のノードとして登録されたVagrantマシンや存在するChefサーバに接続することでゲストをプロビジョニングできる。

もし、Chefを初めて学ぶばかりであれば、[Chef Solo]( https://www.vagrantup.com/docs/provisioning/chef_solo.html)プロビジョナから恥じれるのが良いだろう。

> **警告：**ChefとVagrantをまだ深く理解していないならば、[Shellプロビジョナ](https://www.vagrantup.com/docs/provisioning/shell.html)から始めるのを推奨する。

## 認証

Chef Clientを使用したプロビジョニングで要求される最小事項は、ChefサーバにNodeを登録できるようにする検証鍵へのパスと、ChefサーバへのURLを提供することである。

```bash
Vagrant.configure("2") do |config|
  config.vm.provision "chef_client" do |chef|
    chef.chef_server_url = "http://mychefserver.com"
    chef.validation_key_path = "validation.pem"
  end
end
```

Nodeは指定されたChefサーバに登録され、そのNodeとプロビジョニングのための適切な実行リストをダウンロードする。

## 実行リストの指定

通常、ChefサーバはNodeに対する実行リストを指定する責任がある。しかしながら、手動で指定した実行リストによってChefサーバが送付したものを上書きする。

```bash
Vagrant.configure("2") do |config|
  config.vm.provision "chef_client" do |chef|
    # Add a recipe
    chef.add_recipe "apache"

    # Or maybe a role
    chef.add_role "web"
  end
end
```

これはChefサーバ上で指定された実行リストを上書きすることを覚えておくこと。

## 環境

次に示す`environment`設定オプションを使用することで、Nodeに対する[environment](https://docs.chef.io/environments.html)を指定することができる。

```bash
Vagrant.configure("2") do |config|
  config.vm.provision "chef_client" do |chef|
    # ...

    chef.environment = "development"
  end
end
```

## そのほかの設定オプション

適応できるいくつかの設定オプションがさらにある。これらは一般的に変更する必要がないが、もしChefサーバがこれらの変数のカスタマイズを要求している場合に適応できる。

* [`client_key_path`](https://www.vagrantup.com/docs/provisioning/chef_client.html#client_key_path)
* [`node_name`](https://www.vagrantup.com/docs/provisioning/chef_client.html#node_name)
* [`validation_client_name`](https://www.vagrantup.com/docs/provisioning/chef_client.html#validation_client_name)

上記に示したすべてのオプションに加えて、Chef Clientプロビジョナは[すべてのChefプロビジョナに対する共通オプション](https://www.vagrantup.com/docs/provisioning/chef_common.html)をサポートしている。

## クリーン・アップ

Vagrant仮想マシンをChefサーバでプロビジョニングした場合、新しいChefの"node"エントリとChefの"client"エントリを、マシンのホスト名を使用して、Chefサーバ上に生成する。以下に示す設定で、ゲスト・マシンを終了したのちVagrantを自動的に設定することができる。

```bash
chef.delete_node = true
chef.delete_client = true
```

もし、上記を設定していない、もしくは`false`に設定していた場合、Chefサーバで新しいプロビジョニングをする前に、Chefサーバからこれらのエントリをきちんと削除しておく必要がある。

```bash
$ knife node delete precise64
$ knife client delete precise64
```

もし、これが失敗した場合、VagrantがChefクライアントでマシンをプロビジョニングする際に以下のエラーとなる。

```bash
HTTP Request Returned 409 Conflict: Client already exists.
```
# Chef Applyプロビジョナ

## プロビジョナ名：`chef_apply`

VagrantのChef Applyプロビジョナは [Chef](https://www.getchef.com/chef/)、具体的には[Chef Apply](https://docs.getchef.com/ctl_chef_apply.htl)を用いてゲストをプロビジョニングする。

Chef Applyは、ChefやChefエコシステムの経験がすでにある人にとって理想的である。特に、この文書ではChefの使い方やChef Recipeの書き缶については　言及しない。

> **警告：**ChefとVagrantをまだ深く理解していないならば、[Shellプロビジョナ](https://www.vagrantup.com/docs/provisioning/shell.html)から始めるのを推奨する。

## オプション

ここではChef Applyプロビジョナに対して適応できるオプションのすべてを示す。プロビジョナの使い方の詳細については後述する。

* [`recipe`}(https://www.vagrantup.com/docs/provisioning/chef_apply.html#recipe) (文字列) - ゲスト上でChef Applyを使って実行するための詳細なのRecipeの内容。
* [`log_level`](https://www.vagrantup.com/docs/provisioning/chef_apply.html#log_level) (文字列) - `chef-apply`を実行している間に使用するためのログレベル。デフォルトの値は"info"である。
* [`upload_path`](https://www.vagrantup.com/docs/provisioning/chef_apply.html#upload_path) (string) - **上級者向け！** 生成されたRecipeファイルを格納するための、ゲスト上の場所。多くの場合、この値をカスタマイズする必要性はほぼない。デフォルト値は`/tmp/vagrant-chef-apply-#`であり、`#`は衝突しないようにVagrantによって生成されたユニークなカウンタ値である。

上述したすべてのオプションに加え、Chef Soloプロビジョナは[全Chefプロビジョナの共通オプション](https://www.vagrantup.com/docs/provisioning/chef_common.html)をサポートする。

## Recipeの指定

Chef Applyプロビジョナを使い始める最も簡単な方法はインラインの[Chef Recipe](https://docs.chef.io/recipes.html)を指定するだけである。以下に示す。

```bash
Vagrant.configure("2") do |config|
  config.vm.provision "chef_apply" do |chef|
    chef.recipe = "package[apache2]"
  end
end
```

これにより、VagnraはRecipeの中身で与えられたものでChef Applyを実行する。もし、Chefに詳しいならば、これはシステム・パッケージ・プロバイダからapache2パッケージをインストールしようとすることがわかるだろう。

シングル・ラインChef Recipeは珍しく、"ヒア・ドキュメント"を使用してRecipeを使用することもできる。

```bash
Vagrant.configure("2") do |config|
  config.vm.provision "chef_apply" do |chef|
    chef.recipe = <<-RECIPE
      package "apache2"

      template "/etc/apache2/my.config" do
        # ...
      end
    RECIPE
  end
end
```

最後に、もしRecipeをプレーン・テキストとして格納したいのであれば、ファイルの中身にRecipeを設定することができる。

```bash
Vagrant.configure("2") do |config|
  config.vm.provision "chef_apply" do |chef|
    chef.recipe = File.read("/path/to/my/recipe.rb")
  end
end
```

## Role

VagrantのChef ApplyプロビジョナはRoleをサポートしていない。Roleのサポートが必要ならば、ほかのVagrant Chefプロビジョナを使用すること。

## Data Bag

VagrantのChef ApplyプロビジョナはData Bagをサポートしていない。Data Bagのサポートが必要ならば、ほかのVagrant Chefプロビジョナを使用すること。


# Dockerプロビジョナ

## プロビジョナ名：`"docker"`

VagrantのDockerプロビジョナは[Docker](https://www.docker.io/)を自動的にインストールすることができる。DockerコンテナをPullし、ブート時に実行するために適切なコンテナの設定をおこなう。

Dockerプロビジョナは、アプリケーションやサービスのようなものを配布する手段として、Dockerを使用している組織にとって理想的である。また、もし、Dockerを使い始めたばかりであれば、DockerプロビジョナはプロビジョナがDockerをインストールするのを自動化するため、最も簡単にDockerを使い始める方法を提供する。

すべてのプロビジョナと同じように、DockerプロビジョナもVagrantが持つ他のすべてのプロビジョナとともに、可能な限り最も良い方法で作業環境を構築するための順番で使用することができる。例えば、データベースやWebサーバのようなサービスをインストールするためんいPuppetを使い、アプリケーション・ランタイムのためにDockerを使うなどである。DockerプロビジョナとともにPuppetプロビジョナを使うことができるのである。

> **注意：**この文書あはDockerプロビジョナ向けである。もし、Dockerプロバイダ向けの情報を探しているのであれば、[Dockerプロバイダ文書](https://www.vagrantup.com/docs/docker/)を参照のこと。

## オプション

Dockerプロビジョナはさまざまなオプションをとる。必須のオプションはない。オプションを指定する必要がなければ、Dockerプロビジョナは（まだインストールされていなければ）Dockerをインストールするだけである。

* [`images`](https://www.vagrantup.com/docs/provisioning/docker.html#images) (array) - `docker pull`を使ってPullするためのイメージのリスト。`pull_images`も同様に使用でできる。より詳細な情報いついてはこの章の末尾で後述する。

設定できる追加的なオプションとして、様々な機能が適用でき、Dockerプロビジョナの他の側面の設定をするために呼び出すことが出来る。これらの機能の多くについて、以降で詳細を示している。

* [`build_image`](https://www.vagrantup.com/docs/provisioning/docker.html#build_image) - Dockerfileからイメージを構築する。
* [`pull_images`](https://www.vagrantup.com/docs/provisioning/docker.html#pull_images) - 与えられたイメージをPullする。これはこれらのイメージを開始はしない。
* [`run`](https://www.vagrantup.com/docs/provisioning/docker.html#run) - ブート時にコンテナの実行と起動するための設定を行う。これは一度だけしか指定できない。

## イメージの構築

プロビジョナは自動的にイメージを構築できる。イマージは設定されたコンテナが実行出来るように適切に構築され、実行する前にイメージは構築される。イメージの構築は容易である。

```bash
Vagrant.configure("2") do |config|
  config.vm.provision "docker" do |d|
    d.build_image "/vagrant/app"
  end
end
```

イメージの構築のための引数は`docker build`に与えるパスである。これはゲストマシン上に存在するパスである必要がある。もし、ゲスト/マシンにデータを取得する必要があるならば、同期フォルダを使用すること。

`build_image`機能は、2つ目のパラメータをオプションとして受ける。ここに適応可能なオプションを閉める。

* [`args`](https://www.vagrantup.com/docs/provisioning/docker.html#args) (文字列) - `docker build`に受け渡す追加的な引数。これは、イメージのタグに`-t "foo"`のように受け渡すために使用する。

## イメージのPull

DockerプロビジョナはDockerレギス取りからイメージを自動的にPullすることが出来る。Pullするイメージを指定するには2つの方法がある。ひとつ目の方法は`images:`を使った列挙である。

```bash
Vagrant.configure("2") do |config|
  config.vm.provision "docker",
    images: ["ubuntu"]
end
```

これはVagrantにレジストリから"ubuntu"のイメージを自動的にPullさせる。

イメージをPullする2つ目の方法は、`pull_images`機能を使う方法である。`pull_images`のいずれの呼出も、Pullされたイメージを追加する。`イメージ`は可変である一方、一度しか使用することができない。

補足事項として、`pull_images`機能はプロビジョナへの簡単な設定方法(1行ですべてを指定する）は使用することが出来ない。

```bash
Vagrant.configure("2") do |config|
  config.vm.provision "docker" do |d|
    d.pull_images "ubuntu"
    d.pull_images "vagrant"
  end
end
```

## コンテナの実行

イメージをPullすることに加えて、Dockerプロビジョナはコンテナの実行と開始を行うことが出来る。これは`vagrant up`の一部としてサービスをスタートさせられるということである。

コンテナの実行は`dop...end`ブロックを用いたRubyブロック記法を用いて設定することしか出来ない。コンテナの実行の例を以下に示す。

```bash
Vagrant.configure("2") do |config|
  config.vm.provision "docker" do |d|
    d.run "rabbitmq"
  end
end
```

これは、"rabbitmg"イメージでコンテナを`docker run`する。Vagrantは、直近の`rund`定義で使用されているいずれの設定も、最初のパラメータ（デフォルトではイメージ名）で上書きするために使用する点に注意すること。そのため、もし、複数のコンテナを同じイメージで実行する必要があるならば、その後、ユニークな名前で`image`オプションにおいて（それ以降に）指定する必要がある。

名前に加えて、`run`は一連のオプションを受けることができるが、すべて必須ではない。

* [`image`](https://www.vagrantup.com/docs/provisioning/docker.html#image) (文字列) - 実行するイメージ。これはデフォルトで第一引数であるが、ここでオプションとして与えることも出来る。
* `cmd` (文字列) - コンテナ内で開始するためのコマンド。指定がなければ、[`Dockerfile`内で指定された](https://www.vagrantup.com/docs.docker.io/en/latest/use/builder/#cmd)"CMD"コマンドなどのコンテナのデフォルトのコマンドを使用する。 
* `args` (文字列) - コマンド・ライン上の[docker run](https://www.vagrantup.com/docs.docker.io/en/latest/commandline/cli/#run)へのその他の引数。これらは直接Dockerに渡される素の引数である。
* [`auto_assign_name`](https://www.vagrantup.com/docs/provisioning/docker.html#auto_assign_name) (ブール値) - trueの場合、コンテナの`--name`が実行時の第一引数として設定される。 名前に"/"が含まれるものが設定された場合、(イメージ名なので）それは"-"に置き換えられる。そのため、もし`d.run "foo/bar"`を実行した場合、コンテナの名前は"foo-bar"になる。
* [`daemonize`](https://www.vagrantup.com/docs/provisioning/docker.html#daemonize) (ブール値) - trueの場合、"-d"フラグがコンテナをデーモン化するために`docker run`に与えられる。デフォルトではtrueである。
* [`restart`](https://www.vagrantup.com/docs/provisioning/docker.html#restart) (文字列) - コンテナの再起動ポリシー。デフォルトでは"always"である。

Vagrant共有ディレクトリでコンテナを実行するためのDocker設定はこのようになる。

```bash
Vagrant.configure("2") do |config|
  config.vm.provision "docker" do |d|
    d.run "ubuntu",
      cmd: "bash -l",
      args: "-v '/vagrant:/var/www'"
  end
end
```

同じイメージから複数のコンテナを実行する必要がある場合、異なる名前とそれに対する`image`パラメータを指定すること行うことが出来る。

```bash
Vagrant.configure("2") do |config|
  config.vm.provision "docker" do |d|
    d.run "db-1", image: "user/mysql"
    d.run "db-2", image: "user/mysql"
  end
end
```

## その他

ここでは、一般的にこのプロビジョナを使用するために知っておくべき、Dockerに関連した内容について記載した。

## /etc/default/dockerのカスタマイズ

このファイルをカスタマイズするには、Dockerプロビジョナの前に、このファイルを構築するShellプロビジョナを使う。Dockerプロビジョナは破壊的にこのファイルを変更することはない。

# Puppet Applyプロビジョナ

## プロビジョナ名：`puppet`

VagrantのPuppetプロビジョナは[Puppet](https://www.puppetlabs.com/puppet)を用いてゲストをプロビジョニングする。具体的には`calling puppet apply`によってPuppet Masterを持たずに行う。

> **警告：**PuppetとVagrantをまだ深く理解していないならば、[Shellプロビジョナ](https://www.vagrantup.com/docs/provisioning/shell.html)から始めるのを推奨する。しかしながら、すでにVagrantを使いこなしているならば、VagrantはPuppetを学ぶための素晴らしい方法となるだろう。

## オプション

ここではPuppetプロビジョナにたいして　適応できるオプションのすべてを示す。プロビジョナの使い方の詳細については後述する。

* [`binary_path`](https://www.vagrantup.com/docs/provisioning/puppet_apply.html#binary_path) (文字列) - Puppetの`bin/`ディレクトへのゲスト上のパス。
* [`facter`](https://www.vagrantup.com/docs/provisioning/puppet_apply.html#facter) (ハッシュ値) - Puppet実行内で適応可能な要素変数としてセットするデータのハッシュ。
* [`hiera_config_path`](https://www.vagrantup.com/docs/provisioning/puppet_apply.html#hiera_config_path) (文字列) - ホスト上のHiera設定へのパス。VagrantでHieraをどのように使うかについては後述する。
* [`manifest_file`](https://www.vagrantup.com/docs/provisioning/puppet_apply.html#manifest_file) (文字列) - Puppet実行に対するエントリ・ポイントとしてのマニュフェスト・ファイルの名前。このマニュフェスト・ファイルは以下に示すように、設定された`manifests_path`内に存在することを期待する。デフォルトでは"default.pp"である。
* [`manifests_path`](https://www.vagrantup.com/docs/provisioning/puppet_apply.html#manifests_path) (文字列) - マニュフェスト・ファイルのあるディレクトリへのパス。これはデフォルトでは"manifests"である。
* [`module_path`](https://www.vagrantup.com/docs/provisioning/puppet_apply.html#module_path) (文字列) - もしあるのであれば、Puppetモジュールを持つディレクトリのホスト上のパス。
* [`environment`](https://www.vagrantup.com/docs/provisioning/puppet_apply.html#environment) (文字列) - Puppet環境の名前
* [`environment_path`](https://www.vagrantup.com/docs/provisioning/puppet_apply.html#environment_path) (文字列) - ホスト・ディスク上の環境fileを含むディレクトリへのパス。
* [`options`](https://www.vagrantup.com/docs/provisioning/puppet_apply.html#options) (文字列の列挙) - Puppet実行中、起動可能なPuppetへ受け渡すための追加的なオプション。
* [`synced_folder_type`] (文字列) 適切に動作する為にプロビジョナに対して、
プロビジョナが適切に動作する為に要求されるデータを共有するときに使用する同期フォルダの種類。デフォルトではこれは、デフォルトの同期フォルダ種類が使用される。例えば、これをNFS同期フォルダを使うために、"nfs"と設定することができる。
* [`synced_folder_args`] (array) - 同期フォルダに受け渡す引数。例えば、rsync同期コマンドに対する['-a', '--delete', '--exclude=fixtures']など。
* [`temp_dir`](https://www.vagrantup.com/docs/provisioning/puppet_apply.html#temp_dir) (文字列) - ゲスト・マシンに格納されることになる、Puppetの実行に関連するすべてのデータのあるディレクトリ(マニュフェスト・ファイルやモジュールなど)。
* [`working_directory`](https://www.vagrantup.com/docs/provisioning/puppet_apply.html#working_directory) (文字列) - Puppetが実行されたときに、作業用ディレクトリとなるゲスト上のパス。Hiera設定内で相対パスが使用されるために、これは通常設定されるだけである。

> もし、`environment`と`environment_path`だけが指定された場合、`environment.conf`ファイル内でマニュフェストが指定しているものを解析し、使用する。もし、`manifests_path`と`manifest_file`が環境オプションとともに指定された場合、環境からのマニュフェストは指定された`manifest_file`によって上書きされる。もし、`manifests_path`と`manifest_file`が環境なしで指定された場合、古い非環境モードが使用される(Puppet 4以降では失敗する).

## 最小限の設定

Puppetプロビジョナで始める最も近い道はこのようにする。

```bash
Vagrant.configure("2") do |config|
  config.vm.provision "puppet"
end
```

デフォルトでは、Vagrantはプロジェクト・ルートに対する相対パスであらわされる"manifests"フォルダの中にあるマニュフェストをみてPuppetを設定する。そして、エントリ・ポイントとして"default.pp"マニフェストを使用する。これは、もし下記のようなディレクトリ・ツリーであった場合、Vagrantfileの1行でPuppetを開始できることを意味する。

```bash
$ tree
.
|-- Vagrantfile
|-- manifests
|   |-- default.pp
```

## カスタム・マニュフェスト設定

もちろん、好きな通りにマニュフェストに名前を付けたり、配置することができる。Puppetが`manifests_path`に基づいてマニュフェストを探すための、2つのディレクトリを上書きすることができる。マニュフェストファイルは`manifest_file`に基づいてエントリポイントとして使用される。

```bash
Vagrant.configure("2") do |config|
  config.vm.provision "puppet" do |puppet|
    puppet.manifests_path = "my_manifests"
    puppet.manifest_file = "default.pp"
  end
end
```

パスは相対パス、絶対パスが指定できる。相対パスの場合、プロジェクト・ルートに対する相対パスとなる。

すでにリモート・マシン上にある、Shellプロビジョナによってそこに配置された、マニュフェスト・パスを指定することもできる。この場合、Vagrantはマニュフェスト・ディレクトリをアップロードしようとしない。リモート・マニュフェスト・パスを指定するには、以下のような記法を用いる。

```bash
Vagrant.configure("2") do |config|
  config.vm.provision "puppet" do |puppet|
    puppet.manifests_path = ["vm", "/path/to/manifests"]
    puppet.manifest_file = "default.pp"
  end
end
```

これは、多少変わった構文である、しかし、一組（2つの要素の列挙）が"/pash/to/manifests"の"vm"内にパスが配置されることを示す。

## 環境

もし、Puppet 4以降を使用している場合、[Puppet環境](https://docs.puppetlabs.com/puppet/latest/reference/environments.html) を使用し、環境の名前や環境ファイルにローカル・ディスク上のパスを指定し、プロビジョニングすることができる。

```bash
Vagrant.configure("2") do |config|
  config.vm.provision "puppet" do |puppet|
    puppet.environment_path = "../puppet/environments"
    puppet.environment = "testenv"
  end
end
```

デフォルトのマニュフェストは、環境内の`manifests`ディレクトリである。環境が`environment.conf`を持つ場合、そこからマニュフェスト・パスを取得する。相対パスは、環境のディレクトリに対して相対的であるとされる。もし、`environment.conf内で設定されたマニュフェストが、`$codedir`や`$environment`などのPuppet変数を使用する場合、それぞれ`environment_path`の親ディレクトリと`environment`に置き換えられる。

## モジュール

Vagrantは[Puppetモジュール](https://docs.puppetlabs.com/guides/modules.html)でのプロビジョニングもサポートしている。これは、モジュールが配置されているモジュール・フォルダへのパスを指定することで行われる。マニュフェスト・ファイルはエントリ・ポイントとして使用される。

```bash
Vagrant.configure("2") do |config|
  config.vm.provision "puppet" do |puppet|
    puppet.module_path = "modules"
  end
end
```

マニュフェスト・パスとまったく同様に、モジュール・パスは相対パスを与えたとき、プロジェクト・ルートに対する相対パスとなる。

## カスタムFacter

[Facter](https://puppetlabs.com/facter)によって示されるFacterのカスタマイズも同様に指定することができる。

```bash
Vagrant.configure("2") do |config|
  config.vm.provision "puppet" do |puppet|
    puppet.facter = {
      "vagrant" => "1"
    }
  end
end
```

上記により、Puppetマニュフェストの`$vagrant`変数は"1"になる。

## Hieraの設定

[Hiera](https://docs.puppetlabs.com/hiera/1/)の設定もサポートしている。`hiera_config_path`はホスト上にあるHiera設定ファイルへのパスを指定する。もし、Hiera設定ファイル内の`:datadir`設定が相対パスであれば、`working_directory`はゲスト内のディレクトリを指定するために相対パスを使う必要がある。.

```bash
Vagrant.configure("2") do |config|
  config.vm.provision "puppet" do |puppet|
    puppet.hiera_config_path = "hiera.yaml"
    puppet.working_directory = "/tmp/vagrant-puppet"
  end
end
```

`hiera_config_path`は相対パスまたは絶対パスで指定する。相対パスであれば、プロジェクト・ルートに対する相対パスとなる。`working_directory`はゲスト内で絶対パスである。

## 追加的なオプション

Puppetは多くのコマンド・ライン・フラグをサポートする。基本的に、コマンド・ラインで設定値を上書きすることができる。Puppetに強力さと柔軟さを与えるために、Vagrantはカスタム・コマンド・ライン・フラグを許している。
コマンド・ライン・フラグは以下のように使用する。

```bash
Vagrant.configure("2") do |config|
  config.vm.provision "puppet" do |puppet|
    puppet.options = "--verbose --debug"
  end
end
```

# Puppet Agentプロビジョナ

## プロビジョナ名：`puppet_server`

VagrantのPuppet Agentプロビジョナは[Puppet](https://www.puppetlabs.com/puppet)を使用してプロビジョニングをする。具体的には、Puppet Agentを呼び出すことで、Pupput Masterに接続し、モジュールとマニュフェストの一式をそこへ取得する。

> **警告：**もし、PuppetとVagrantをまだ深く理解していないならば、[shell provisioner](https://www.vagrantup.com/docs/provisioning/shell.html)から始めるのを推奨する。しかしながら、すでにVagrantを使いこなしているならば、VagrantはPuppetを学ぶための素晴らしい方法となるだろう。

## オプション

`puppet_server`プロビジョナは様々なオプションをとることができる。必須オプションはない。指定できるオプションを以下に示す。

* [`binary_path`](https://www.vagrantup.com/docs/provisioning/puppet_agent.html#binary_path) (文字列) - ゲスト上のPuppetの`bin/`ディレクトリへのパスを指定する。
* [`client_cert_path`](https://www.vagrantup.com/docs/provisioning/puppet_agent.html#client_cert_path) (文字列) - Nodeのクライアント証明書へのディスク上のパス。デフォルトは無しであり、この場合、クライアント証明書はアップロードされない。
* [`client_private_key_path`](https://www.vagrantup.com/docs/provisioning/puppet_agent.html#client_private_key_path) (文字列) - Nodeのクライアント秘密鍵へのディスク上のパス。デフォルトでは無しであり、この場合、クライアント秘密鍵はアップロードされない。
* [`facter`](https://www.vagrantup.com/docs/provisioning/puppet_agent.html#facter) (ハッシュ) - Puppetを実行する為に指定できる、追加的なFacter要素
* [`options`](https://www.vagrantup.com/docs/provisioning/puppet_agent.html#options) (文字列、または、列挙) - Puppetが起動したときに`puppet agent`に受け渡すための、追加的なコマンド・ライン・オプション。
* [`puppet_node`](https://www.vagrantup.com/docs/provisioning/puppet_agent.html#puppet_node) (文字列) - Nodeの名前。これが設定されていなければ、`config.vm.hostname`で設定されていれば、そのホスト名を使おうとする。そうでなければ、Box名が使用される。
* [`puppet_server`](https://www.vagrantup.com/docs/provisioning/puppet_agent.html#puppet_server) (文字列) - Puppetサーバのホスト名。デフォルトでは"puppet"が使用される。

## Puppet Masterの指定

Puppet Agentプロビジョナの最も素早い始め方は、Puppet Masterの位置を指定することである。

```bash
Vagrant.configure("2") do |config|
  config.vm.provision "puppet_server" do |puppet|
    puppet.puppet_server = "puppet.example.com"
  end
end
```

デフォルトでは、Vagrantはゲスト・マシンのローカル・ドメイン上の"puppet"と名前のついたホストを探す。

## Node名の設定

Agentレジスタとして使用されているNode名はカスタマイズ可能である。Puppetは、Nodeが起動しようとするカタログをコンパイルするためのプロセスの一部として、Node名を使用するので、重要であることを覚えておくこと。

Node名はゲスト・マシンのホスト名のデフォルトとなるが、Vagrantfileを使用することでカスタマイズすることができる。

```bash
Vagrant.configure("2") do |config|
  config.vm.provision "puppet_server" do |puppet|
    puppet.puppet_node = "node.example.com"
  end
end
```

## 追加的なオプション

Puppetは多くのコマンド・ライン・フラグをサポートする。基本的に、コマンド・ラインで設定値を上書きすることができる。Puppetに強力さと柔軟さを与えるために、Vagrantはカスタム・コマンド・ライン・フラグを許している。
コマンド・ライン・フラグは以下のように使用する。


```bash
Vagrant.configure("2") do |config|
  config.vm.provision "puppet_server" do |puppet|
    puppet.options = "--verbose --debug"
  end
end
```

# Saltプロビジョナ

## プロビジョナ名：`salt`

VagrantのSaltプロビジョナは[Salt](http://saltstack.com/) Statesを使用することでゲストをプロビジョニングする。

Salt statesは現在のマシンがどうあるべきか、例えば、パッケージがインストールされているべき、サービスを実行している、などのの状態を記載した、または任意の内容を持つ[YAML](https://en.wikipedia.org/wiki/YAML)文書である。

## Masterなしのクイック・スタート

以下は、Master無しのSingle MinionでSaltを動作させるための基本的なVagrantfileの例である。

```bash
  Vagrant.configure("2") do |config|
    ## Choose your base box
    config.vm.box = "precise64"

    ## For masterless, mount your salt file root
    config.vm.synced_folder "salt/roots/", "/srv/salt/"

    ## Use all the defaults:
    config.vm.provision :salt do |salt|

      salt.masterless = true
      salt.minion_config = "salt/minion"
      salt.run_highstate = true

    end
  end
```

この設定はSaltのルートとしてフォルダを共有し、minionファイルを上書きコピーし、そして、`state.highstate`をマシン上で実行する。minionファイルは、マスター無し設定とするために`file_client: local`の行を含む必要がある。

## インストール・オプション

* [`install_master`](https://www.vagrantup.com/docs/provisioning/salt.html#install_master) (ブール値) - マシンにsalt-masterをインストールする。Windowsのゲスト・マシンはサポートしていない。
* [`no_minion`](https://www.vagrantup.com/docs/provisioning/salt.html#no_minion) (ブール値) - Minionをインストールしない。デフォルトでは`false`である。Windowsゲスト・マシンはサポートしていない。
* [`install_syndic`](https://www.vagrantup.com/docs/provisioning/salt.html#install_syndic) (ブール値) - salt-syndicをインストールする。デフォルトでは`false`である。Windowsゲスト・マシンはサポートしていない。
* [`install_type`](https://www.vagrantup.com/docs/provisioning/salt.html#install_type) (stable | git | daily | testing) - ディストリビューションのStableパッケージ・マネージャ、git tree-ish、daily ppa、または、テスト用リポジトリのどこからインストールするかを指定する。
* [`install_args`](https://www.vagrantup.com/docs/provisioning/salt.html#install_args) (develop) - gitによるインストールを行うとき、branch、tag、または、tree-ishを指定できる。Windowsではサポートしていない。
* [`always_install`](https://www.vagrantup.com/docs/provisioning/salt.html#always_install) (ブール値) - Saltバイナリがすでに検出された場合でも、インストールを行う。デフォルトでは`false`である。
* [`bootstrap_script`](https://www.vagrantup.com/docs/provisioning/salt.html#bootstrap_script) (文字列) - カスタマイズされたsalt-bootstrap.shスクリプトへのパス。Windowsゲスト・マシンはサポートしていない。
* [`bootstrap_options`](https://www.vagrantup.com/docs/provisioning/salt.html#bootstrap_options) (文字列) - bootstrapスクリプトに受け渡す、追加的なコマンド・ライン・オプション。
* [`version`](https://www.vagrantup.com/docs/provisioning/salt.html#version) (文字列、 デフォルト値："2015.5.2") - インストールされるMinionのバージョン。Windowsゲスト・マシンでのみサポートする。

## Minionオプション

これらのオプションは`no_minion`が`false`の場合のみ作用する。

* [`minion_config`] (文字列、デフォルト値："salt/minion") - カスタムSalt Minion設定ファイルへのパス。
* [`minion_key`](https://www.vagrantup.com/docs/provisioning/salt.html#minion_key) (文字列) - Minion鍵へのパス。
* [`minion_id`](https://www.vagrantup.com/docs/provisioning/salt.html#minion_id) (文字列) - Minionに対するユニークな識別名。Master無し、または、Preseeding鍵のために使用する。
* [`minion_pub`](https://www.vagrantup.com/docs/provisioning/salt.html#minion_pub) (salt/key/minion.pub) - Minion公開鍵へのパス。
* `grains_config` (文字列) - カスタムSalt Grainファイルへのパス。Windowsでは、Masterとの[通信に失敗](https://github.com/saltstack/salt/issues/22796)するので、Minionは`ipc_mode: tcp`を設定する必要がある。
* [`masterless`](https://www.vagrantup.com/docs/provisioning/salt.html#masterless) (ブール値) - ローカル・モードでstate.highstateを呼び出す。提供するときは、`minion_id`と`pillar_data`使用する。

## Masterオプション

これらのオプションは`install_master`が`true`であるときのみ作用する。Windowsゲスト・マシンはサポートしていない。

* [`master_config`](https://www.vagrantup.com/docs/provisioning/salt.html#master_config) (文字列、デフォルト値："salt/master") - カスタムSalt Master設定ファイルへのパス。
* [`master_key`](https://www.vagrantup.com/docs/provisioning/salt.html#master_key) (salt/key/master.pem) - Master鍵へのパス
* [`master_pub`](https://www.vagrantup.com/docs/provisioning/salt.html#master_pub) (salt/key/master.pub) - Master公開鍵へのパス
* [`seed_master`](https://www.vagrantup.com/docs/provisioning/salt.html#seed_master) (ディクショナリ型) - 使用する前にそれをPreseedingすることによって、Masterに鍵をアップロードする。例：`{minion_name:/path/to/key.pub}`

## Stateの実行

以下に示すいずれかが、プロビジョニングの間、実際にStateを実行する為に使用されることになる。

* [`run_highstate`](https://www.vagrantup.com/docs/provisioning/salt.html#run_highstate) (ブール値) - vagrant up時に`state.highstate`を実行する。どのようなマシンに対しても適用することができる。

## Runnerの実行

以下に示すいずれかが、プロビジョニングの間、実際にRunnerを実行する為に使用されることになる。

* [`run_overstate`](https://www.vagrantup.com/docs/provisioning/salt.html#run_overstate) (boolean) - vagrant up時に`state.over`を実行する。Masterに対してのみ適用することができる。これは、統合によって置き換えられる。Windowsゲスト・マシンはサポートされていない。
* [`orchestrations`](https://www.vagrantup.com/docs/provisioning/salt.html#orchestrations) (ブール値) - vagrant up時に`state.orchestrate`を実行する。Masterに対してのみ適用することができる。これは、統合によって置き換えられる。Windowsゲスト・マシンはサポートされていない。

## 出力制御

これらは、Stateの実行についての出力を制御する為に使用される。

* [`colorize`](https://www.vagrantup.com/docs/provisioning/salt.html#colorize) (ブール値) - もし、treuの場合、出力が色付けされる。デフォルトではfalseである。
* [`log_level`](https://www.vagrantup.com/docs/provisioning/salt.html#log_level) (文字列) - 出力の詳細度。デフォルトでは"debug"である。"all"、"garbage"、"trace"、"debug"、"info"、"warning"のいずれかを設定する。`verbose`が"true"に設定されている必要がある。

## Pillarデータ

pillarコマンドを使用することで、プロビジョニングの間に使用するための`pillar`データをエクスポートすることができる。呼び出しのたびに、データはマージされるので、複数回の呼び出しを安全にすることができる。データはハッシュ、または、リストでのみ受け渡す。ここに例を示す。

```bash
  config.vm.provision :salt do |salt|
  
    # Export hostnames for webserver config
    salt.pillar({
      "hostnames" => {
        "www" => "www.example.com",
        "intranet" => "intranet.example.com"
      }
    })

    # Export database credentials
    salt.pillar({
      "database" => {
        "user" => "jdoe",
        "password" => "topsecret"
      }
    })

    salt.run_highstate = true

  end
```

## Preseeding鍵

Preseeding鍵はMasterを使用してのプロビジョニングを制御する方法として推奨される。Saltがインストールされたマシン上では、必須である.pubと.pemを生成するために`salt-key --gen-keys=[minion_id]`を実行する。

より上級な段階の詳細な設定例については、[プラグイン](https://github.com/saltstack/salty-vagrant/tree/develop/example)の原文を参照のこと。

# 関連記事

* 前の記事：[【Vagrantドキュメント意訳】08.Box詳細](http://qiita.com/ringo0321/items/f76da11503c627205c52)
* 次の記事：[【Vagrantドキュメント意訳】10.ネットワーク](http://qiita.com/ringo0321/items/4ebc0ac3bb98240f65ce)