Vagrant のプロビジョナーに ansible_local を使う

ここのところ、カウンターの話題でお茶を濁していましたが、ようやっとまとまった時間が取れて、久しぶりに Vagrant で VirtualBox の仮想マシンを自動生成なんぞして遊んでみました。

んで、プロビジョニングに ansible を使いたいな~と思いつつ、Windows 上に ansible を入れ込むのは骨だなぁ、Windows Subsystem for Linux(WSL)の ubuntu で入れるのかなぁ、でも面倒だなぁ。とだらだらと思いつつ、Web 上を彷徨っていると、最近の Vagrant では「ansible_local」というプロビジョナーが追加になったとの情報に接し、どんなものか触ってみました。

導入

……何も必要ありません。ッてもちろん、Vagrant と VirtualBox、加えてネットが無いなら、Vagrant の box ファイルは必要ですが、それ以上は特に必要ありません。

そもそも ansible_local とはどんなものか

「何も必要ない」理由は簡単です。

プロビジョナー ansible の場合は、ホスト側で ansible が動いて、ゲスト OS にプロビジョニングを施すわけですが、ansible_local の場合は、Vagrant が自動的にホスト側にある playbook を ゲスト側に送り込み、ゲスト側で ansible を実行してくれます。

しかも、ゲスト側にさえ、特に準備が必要ありません(少なくとも CentOS で検証した限りでは)。つまり、カスタマイズした Box ファイルを用意したりする必要はありません。

プロビジョニング時に、ゲスト OS に ansible が無い場合、自動的に ansible をインストールし、その上で playbook が実行されます。もちろん、epel-release パッケージを含め、依存関係は解決されます。

検証

box ファイルは、CentOS 公式の「centos/7」を利用しました。

適当なディレクトリを作成し、Windows コマンドプロンプトで、カレントディレクトリを作成したディレクトリにうつし、まずは下記を実行して Vagrantfile のひな形を作成します。

作成した Vagrantfile を元に、まずは Shell でプロビジョニングを書いて追記した結果が、以下の通りです。

vagrant up してみて、vagrant ssh で中に入って、yum update してみても何も無い(プロビジョニング済みである)ことを確認します。

次に、Vagrantfile を以下のようにしてみます。

そして、カレントディレクトリに provision ディレクトリを作成し、以下の内容で vagrant.yml を作成します。

一旦仮想マシンを破棄して作り直します。

先ほどと同じく、vagrant ssh で中に入って、yum update してみても何も無い(プロビジョニング済みである)ことを確認できたら成功です。

考察

 

vagrant のプロビジョナーとしての「ansible_local」を「ansible」との対比で考えると、以下の利点欠点があるかもしれません。

利点

  • Windows から使える。
  • 準備がほぼ必要ない。

欠点

  • プロビジョニングによって、必要無い(かもしれない)ansible と、その依存パッケージがゲスト OS にインストールされる。

まぁ、私にとっては「Windows から使える」という利点は大きく、またガッツリ開発系ではなくて、チョッと手元で Linux ディストリビューションの動作を確認する、という使い方がメインなので、ansible の勉強もかねて、良い感じかも知れません。


コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください