More than 5 years have passed since last update.

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

Last updated at 2016-07-09Posted at 2016-05-01

はじめに

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

プロビジョニング

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

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

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

過去に構成管理システムを使ったことがないなら、プロビジョニング用に基本的なシェル・スクリプトから使い始めることを推奨する。

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

プロビジョニングの発生

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

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

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

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

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

設定

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

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

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

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

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以降）。これらの名前は、プロビジョナの設定を上書きする（後述）のと同じように、出力を綺麗にするために使われる。

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"を設定する。以下の通りである。

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

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

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

マルチ・プロビジョナ

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

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

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を始めたばかりであれば、ここは読み飛ばすのが安全である。

マルチ・マシンやプロバイダ固有の上書きのような機能を使う際、Vagrantfileのグローバルな設定スコープ内で共通のプロビジョナを定義したいと思うかもしれないが、それらの特定の部分を内部的に上書きしてしまう。Vagrantはこれができるが、考慮すべき点がいくつかある。

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

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"が表示される。

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ユーザのホームディレクトリにコピーする。

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

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

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

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

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

オプション

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

source (文字列) - アップロードしたいファイルまたはディレクトリのローカルパスを文字列で指定する。
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コマンドを指定する。詳細はインライン・スクリプトセクションを参照のこと。
path (文字列) - アップロードまたは実行するためのシェル・スクリプトへのパスを指定する。プロジェクトのVagrantfileに対する相対パス、または、リモート・スクリプト(gistのような)とすることができる。

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

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

インライン・スクリプト

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

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

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

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

$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はこのスクリプトをゲスト・マシンへアップロードし実行する。例を示す。

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

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

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

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

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

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

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

スクリプトの引数

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

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

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

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のplaybookをansible-playbookで実行することでゲストをプロビジョニングする。

**警告：**AnsibleとVagrantをまだ深く理解していないならば、Shellプロビジョナから始めるのを推奨する。しかしながら、すでにVagrantを使いこなしているならば、VagrantはAnsibleを学ぶための素晴らしい方法となるだろう。

構築に対する要求事項

VagrantのホストへAnsibleをインストールする
VagranのホストはControlPersistをサポートするOpenSSHの最新バージョンを提供できるのが理想である。

開発環境において、AnsibleをVagrantのホストに直接インストールするという選択肢がない場合、Ansibleローカル・プロビジョナを参考にすること。

使い方

ここではansible(リモート)プロビジョナの特定の部分についてのみ記載する。PlaybookやInventoryなどの一般的なAnsibleの概念はAnsibleとVagrantの紹介で簡単にふれている。

最も単純な設定

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

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プロビジョナに対する共通のオプションをサポートする。

ask_sudo_pass (ブール値) - Ansibleにsudoパスワードに対するプロンプトを要求する。デフォルトではfalseである。
ask_vault_pass (ブール値) - Ansibleにvaultパスワードに対するプロンプトを要求する。デフォルトではfalseである。
force_remote_user (ブール値) -
生成されたインベントリ内で設定された、または、静的インベントリが使用されている場合に外部の変数として設定されたansible_ssh_userを設定するようにVagrantに要求する。すべてのAnsibleのremote_userパラメータはVagrant SSH設定の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ホスト鍵チェックの有効化を要求する。
デフォルトではfalseである。
raw_ssh_args (文字列の列挙) - OpenSSHクライアント・オプションの一覧を適応するようにAnsibleに要求する。
例: ['-o ControlMaster=no'].
これはANSIBLE_SSH_ARGS環境変数を介したAnsibleに対する追加的なSSH設定へ受け渡すために使用することが出来る、その他のいかなるSSH引数(例えば ansible.cfg設定ファイルで定義されているもの)をも上書きする危険なワイルドカードである。

ヒントとテクニック

Ansibleの並列実行

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

# 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コマンドに対して提供されているように構成する必要がある。同様の懸念事項としては、同一のマシンに複数の秘密鍵を使用する場合がある(see config.ssh.private_key_pathSSH設定を参照)。

強制Paramiko接続モード

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

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

自動生成インベントリを用いて

ansible.raw_arguments = ["--connection=paramiko"]

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

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 playbookを用いてゲストをプロビジョニングする。

**警告：**AnsibleとVagrantをまだ深く理解していないならば、Shellプロビジョナから始めるのを推奨する。しかしながら、すでにVagrantを使いこなしているならば、VagrantはAnsibleを学ぶための素晴らしい方法となるだろう。

構築に対する要求事項

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

一方で、ゲストマシン上にAnsibleは必ずインストールされている必要がある。

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

使い方

ここではansible_localプロビジョナの特定の部分についてのみ記載する。PlaybookやInventoryなどの一般的なAnsibleの概念はAnsibleとVagrantの紹介で簡単にふれている。

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

最も単純な設定

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

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ファイルはVagrantのプロジェクトのホーム・ディレクトリに格納されている。
デフォルトの共有ディレクトリが有効(. → /vagrant)。

オプション

ここではAnsible ローカル・プロビジョナに対する特定のオプションを示す。このプロビジョナは以下に示すオプションに加えて、2つのAnsibleプロビジョナに対する共通のオプションをサポートする。

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

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

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

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

ヒントとテクニック

ゲストからのAnsible並列実行

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

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マシン定義に対応した静的インベントリファイルを生成する必要がある

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ファイルを生成する必要もある。詳細なSSHの設定はssh_argsパラメータ(例エージェント転送等)に追加することが出来る。

[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を用いてゲストをプロビジョニングをする。これはCFEngineポリシー・サーバとクライアントの双方を設定できる。また、ポリシー・サーバとクライアントの双方をを単一のマルチ・マシンVagrantfileで設定できる。

**警告：**もし、CFEngineとVagrantをまだ深く理解していないならば、Shellプロビジョナから始めるのを推奨する。しかしながら、すでにVagrantを使いこなしているならば、VagrantはCFEngineを学ぶための素晴らしい方法となるだろう。

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

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

CFEngineプロビジョナは自動的に仮想マシン上に最新のCFEngine Community packagesをインストールする。そして、指定に従いCFEngineの設定と起動を行う。

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

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

ホストは自身をポリシー・サーバとするように、自動的にブートストラップされる。

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

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

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

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

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に含まれるスタンド・アローン・ポリシーであるべき点に注意すること。

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

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

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

Chef Solo プロビジョナ

プロビジョナ名：`chef_solo`

VagrantのChef SoloプロビジョナはChef、具体的にはChef Soloを使用してゲストをプロビジョニングできる。

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

**警告：**ChefとVagrantをまだ深く理解していないならば、Shellプロビジョナから始めるのを推奨する。しかしながら、すでにVagrantを使いこなしているならば、VagrantはChefを学ぶための素晴らしい方法となるだろう。

オプション

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

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

上述したすべてのオプションに加え、Chef Soloプロビジョナは全Chefプロビジョナの共通オプションをサポートする。

実行リストの指定

Chef Soloプロビジョナを使い始める最も簡単な方法は実行リストで指定するだけである。以下に示す。

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"ディレクトリ内から探索される。このディレクトリは以下のようにディレクトリ構造の探索を終える。

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

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

カスタムCookBookパス

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

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

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

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

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

Role

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

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名と同じ必要がある。例えば、webRoleであらば、roles_pathの中でweb.jsonまたはweb.rbである。これはChef自身が要求することであり、Vagrantによる制限ではない。

Data Bag

Data bagはChef Soloプロビジョナでもサポートされている。これはData Bagディレクトリへのパスを指定することで行われる。

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プロパティに設定することで行われる。

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に対して有用である。

例

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、具体的にはChef Zero/local modeを用いてゲストをプロビジョニングする。

この新しいプロビジョナは、本格的なChefサーバを稼働するのと、限定的なChef Soloプロビジョナとの中間に位置する。これはローカル・イン・メモリでChefサーバを稼働し、検証と鍵登録を偽装する。

警告：**ChefとVagrantをまだ深く理解していないならば、Shellプロビジョナから始めるのを推奨する。しかしながら、すでにVagrantを使いこなしているならば、VagrantはChefを学ぶための素晴らしい方法となるだろう。

オプション

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

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

上述したすべてのオプションに加え、Chef Zeroプロビジョナは全Chefプロビジョナの共通オプションをサポートする。

使い方

Chef Zeroプロビジョナは、基本的にはChef Soloプロビジョナと同じように設定される。より詳細な情報はChef Soloドキュメントを参照のこと。

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

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、インフラストラクチャ内のノードとして登録されたVagrantマシンや存在するChefサーバに接続することでゲストをプロビジョニングできる。

もし、Chefを初めて学ぶばかりであれば、Chef Soloプロビジョナから恥じれるのが良いだろう。

**警告：**ChefとVagrantをまだ深く理解していないならば、Shellプロビジョナから始めるのを推奨する。

認証

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

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サーバが送付したものを上書きする。

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を指定することができる。

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

    chef.environment = "development"
  end
end

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

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

上記に示したすべてのオプションに加えて、Chef ClientプロビジョナはすべてのChefプロビジョナに対する共通オプションをサポートしている。

クリーン・アップ

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

chef.delete_node = true
chef.delete_client = true

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

$ knife node delete precise64
$ knife client delete precise64

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

HTTP Request Returned 409 Conflict: Client already exists.

Chef Applyプロビジョナ

プロビジョナ名：`chef_apply`

VagrantのChef Applyプロビジョナは Chef、具体的にはChef Applyを用いてゲストをプロビジョニングする。

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

**警告：**ChefとVagrantをまだ深く理解していないならば、Shellプロビジョナから始めるのを推奨する。

オプション

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

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

上述したすべてのオプションに加え、Chef Soloプロビジョナは全Chefプロビジョナの共通オプションをサポートする。

Recipeの指定

Chef Applyプロビジョナを使い始める最も簡単な方法はインラインのChef Recipeを指定するだけである。以下に示す。

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を使用することもできる。

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を設定することができる。

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を自動的にインストールすることができる。DockerコンテナをPullし、ブート時に実行するために適切なコンテナの設定をおこなう。

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

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

**注意：**この文書あはDockerプロビジョナ向けである。もし、Dockerプロバイダ向けの情報を探しているのであれば、Dockerプロバイダ文書を参照のこと。

オプション

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

images (array) - docker pullを使ってPullするためのイメージのリスト。pull_imagesも同様に使用でできる。より詳細な情報いついてはこの章の末尾で後述する。

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

build_image - Dockerfileからイメージを構築する。
pull_images - 与えられたイメージをPullする。これはこれらのイメージを開始はしない。
run - ブート時にコンテナの実行と起動するための設定を行う。これは一度だけしか指定できない。

イメージの構築

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

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

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

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

args (文字列) - docker buildに受け渡す追加的な引数。これは、イメージのタグに-t "foo"のように受け渡すために使用する。

イメージのPull

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

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行ですべてを指定する）は使用することが出来ない。

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ブロック記法を用いて設定することしか出来ない。コンテナの実行の例を以下に示す。

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

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

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

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

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

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パラメータを指定すること行うことが出来る。

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を用いてゲストをプロビジョニングする。具体的にはcalling puppet applyによってPuppet Masterを持たずに行う。

**警告：**PuppetとVagrantをまだ深く理解していないならば、Shellプロビジョナから始めるのを推奨する。しかしながら、すでにVagrantを使いこなしているならば、VagrantはPuppetを学ぶための素晴らしい方法となるだろう。

オプション

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

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

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

最小限の設定

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

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

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

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

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

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

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はマニュフェスト・ディレクトリをアップロードしようとしない。リモート・マニュフェスト・パスを指定するには、以下のような記法を用いる。

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環境を使用し、環境の名前や環境ファイルにローカル・ディスク上のパスを指定し、プロビジョニングすることができる。

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モジュールでのプロビジョニングもサポートしている。これは、モジュールが配置されているモジュール・フォルダへのパスを指定することで行われる。マニュフェスト・ファイルはエントリ・ポイントとして使用される。

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

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

カスタムFacter

Facterによって示されるFacterのカスタマイズも同様に指定することができる。

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

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

Hieraの設定

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

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はカスタム・コマンド・ライン・フラグを許している。
コマンド・ライン・フラグは以下のように使用する。

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を使用してプロビジョニングをする。具体的には、Puppet Agentを呼び出すことで、Pupput Masterに接続し、モジュールとマニュフェストの一式をそこへ取得する。

**警告：**もし、PuppetとVagrantをまだ深く理解していないならば、shell provisionerから始めるのを推奨する。しかしながら、すでにVagrantを使いこなしているならば、VagrantはPuppetを学ぶための素晴らしい方法となるだろう。

オプション

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

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

Puppet Masterの指定

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

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を使用することでカスタマイズすることができる。

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

追加的なオプション

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

Saltプロビジョナ

プロビジョナ名：`salt`

VagrantのSaltプロビジョナはSalt Statesを使用することでゲストをプロビジョニングする。

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

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

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

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

Minionオプション

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

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

Masterオプション

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

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

Stateの実行

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

run_highstate (ブール値) - vagrant up時にstate.highstateを実行する。どのようなマシンに対しても適用することができる。

Runnerの実行

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

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

出力制御

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

colorize (ブール値) - もし、treuの場合、出力が色付けされる。デフォルトではfalseである。
log_level (文字列) - 出力の詳細度。デフォルトでは"debug"である。"all"、"garbage"、"trace"、"debug"、"info"、"warning"のいずれかを設定する。verboseが"true"に設定されている必要がある。

Pillarデータ

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

  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]を実行する。

より上級な段階の詳細な設定例については、プラグインの原文を参照のこと。

前の記事：【Vagrantドキュメント意訳】08.Box詳細
次の記事：【Vagrantドキュメント意訳】10.ネットワーク

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

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

はじめに

プロビジョニング

プロビジョニングの発生

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

設定

プロビジョナの実行

一時または常時実行

マルチ・プロビジョナ

プロビジョナ設定上書き

ファイル・プロビジョナ

プロビジョナ名："file"

オプション

Shellプロビジョナ

プロビジョナ名："shell"

オプション

インライン・スクリプト

外部スクリプト

スクリプトの引数

Anslibleプロビジョナ

プロビジョナ名：ansible

構築に対する要求事項

使い方

最も単純な設定

オプション

ヒントとテクニック

Ansibleの並列実行

注意点

強制Paramiko接続モード

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

プロビジョナ名：ansible_local

構築に対する要求事項

使い方

最も単純な設定

要求事項

オプション

ヒントとテクニック

ゲストからのAnsible並列実行

CFEngine プロビジョナ

プロビジョナ名：cfengine

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

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

操作モード

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

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

Chef Solo プロビジョナ

プロビジョナ名：chef_solo

オプション

実行リストの指定

カスタムCookBookパス

Role

Data Bag

カスタムJSONデータ

カスタムNode名

Chef Zeroプロビジョナ

プロビジョナ名：chef_zero

オプション

使い方

Chef Clientプロビジョナ

プロビジョナ名：chef_client

認証

実行リストの指定

環境

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

クリーン・アップ

Chef Applyプロビジョナ

プロビジョナ名：chef_apply

オプション

Recipeの指定

Role

Data Bag

Dockerプロビジョナ

プロビジョナ名："docker"

オプション

イメージの構築

イメージのPull

コンテナの実行

その他

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

Puppet Applyプロビジョナ

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

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

プロビジョナ名：`ansible`

プロビジョナ名：`ansible_local`

プロビジョナ名：`cfengine`

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

プロビジョナ名：`chef_solo`

プロビジョナ名：`chef_zero`

プロビジョナ名：`chef_client`

プロビジョナ名：`chef_apply`

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

プロビジョナ名：`puppet`

プロビジョナ名：`puppet_server`

プロビジョナ名：`salt`