speg03の雑記帳

主に未来の自分のために試したことなどを記録しています

Vagrant meetupに行って来ました

概要

Vagrant meetup 〜作者 Hashimoto氏の来日講演〜

2013年7月12日(金)に株式会社VOYAGE GROUP様の会場にて、Vagrantの開発者であるMitchell Hashimotoさんの講演を聞いて来ました。

「Vagrantについてのお話」として話された内容のメモと、そのあと所感などについて書きます。

（合わせて読みたい） 「Vagrant」は仮想環境をプログラミングするツール。同一環境をどこにでも、いくつでもすぐに作成可能。Vagrant meetup 2013 - Publickey

Vagrantについてのお話

Vagrant

  • vagrant up とコマンドを打つだけで簡単に仮想環境が手に入る。
  • 最近のOSSでは、Vagrantで使用する設定ファイル(Vagrantfile)を公開している場合も多く、簡単にそのアプリケーションを試すことができるようになっている。

Vagrantのユースケース

Consistency

  • 開発を行っているローカルマシンと実際に稼働するプロダクション環境は異なる。違いを埋める必要がある。
  • 丁寧すぎるREADME（手順書）は読むのも実行するのも大変。
    • ヒューマンエラーを引き起こす。
    • メンテナンスが困難。
    • インストール作業で次から次に依存するパッケージが足りないとエラーが出る。
    • 設定漏れが発生する。
  • Vagrantは、どんな環境でも、誰がやっても同じように環境が構築できる。

Iterative

環境構築を行うシェルスクリプトがあるとして、 1. スクリプトを修正したら 2. サーバを新しく立ち上げて 3. スクリプトを適用して 4. 出来上がった環境を確認する。

サーバを立ち上げてスクリプトを適用し終わるまで、ひどい場合だと30分以上もかかるかもしれない。環境ができあがる30分間ずっと待っているなんていうのは生産性が低すぎる。

Vagrantはこの環境構築サイクルを繰り返し行うことが簡単にできるようになっている。

Isolation

  • 開発、テスト、プロダクションのそれぞれの環境を共通した操作で構築できる。
  • 特定の環境に特化していない。
  • 再利用性が高い。

Safe Experimentation

  • 試しに環境を作ってすぐ捨てられる。
  • トライ＆エラーがしやすい。

実績

  • 多くの企業でも使用されており、安定していて、成熟してきている。

最高の開発フロー

The Tao of Vagrant

  • Vagrantは空気のような存在。
  • vagrant up とするだけでステージング環境でもプロダクション環境でも構築できる。
  • Vagrant使っていればチーム間、企業間で同じフロー、知見を共有することができる。
  • 「僕の環境では動いているよ！」がなくなる。

Vagrantの機能

Synced folder

  • Vagrantを起動したホストとゲスト間での共有フォルダ機能。
  • Vagrantで作成した環境からホスト側のフォルダをマウントする。
  • ホスト側から好きなエディタを使ってファイルを編集することができる。

Networking

  • Vagrantfileにネットワークの設定を書いておけば起動時に設定してくれる。
  • 好きなブラウザやデバッガからアクセスすることができるようになる。

Provisioning

Multi-Machine

  • Vagrantfileに複数のVM設定を記述することができる。
  • プロダクション環境のモデル化を行える。

Vagrantの歴史、ロードマップ

Vagrantのこれまで

  • 2010年 バージョン0.1
    • VirtualBoxのみ。
    • chef-soloのプロビジョニングのみ。
    • ゲストはUbuntuのみ。
  • 2012年 バージョン1.0
    • プロビジョニングにPuppet/CFEngine対応。
    • ゲストはLinuxなら何でも。
  • 2013年 バージョン1.1

Vagrant 2.0へのパス

  • バージョン1.0時代のVagrantfileでも使用できるようにする。（後方互換性）
  • バージョン1.3+
    • Boxの自動構築に対応。
    • ゲストにMac、Windows対応。

Multi-Providerについて

Vagrantがもともと扱えるVirtualBoxはどんな状況でも使えるというわけではない。バージョン1.1から他のProviderに対応した。AWS (EC2), RackSpace, LXC, VMware。

  • ローカルで開発して、リモートで別のProviderを使ってテストするという使い方ができる。
  • vagrant up でステージング環境もプロダクション環境も構築する。
  • LXCを使うとVagrant in Vagrantなんていうことも可能。
  • 企業向けにはVMwareが使える。
  • 同じVagrantfileを複数のProviderに対して使用することができる。
  • パフォーマンス最適化のために各Provider向けにオプション（CPU、メモリなど）を設定することも可能。

Packerについて

Packer

  • Hashimotoさんが作成されたBoxを作るためのツール。
  • 2013年6月にリリースされた。
  • 下準備をしたBoxを用意するのと、下準備を行うためのスクリプトを用意するのはケースバイケース。
    • Boxを作ると変更するのに手間がかかってしまう。
    • スクリプトであまりに多すぎる下準備をするとそれ自体の実行で時間がかかってしまう。
  • PackerはBoxの作成を自動化することで、アジャイル性を損なわないようにすることを目指す。

全体の所感

Vagrantはちょこちょこ使っているので、今回のお話はすんなり聞くことができました。

vagrant upの手軽さ

vagrant up とするだけで簡単に環境を立ち上げられるという話。

これは本当に手軽で、LXCのDockerや、フォーラムのDiscourseは自分でも試してみたことがありますが本当に簡単です。

Boxの作成

Boxを自分で作成したことは今までなかったのですが、ある程度、環境が固まってきてチーム内などで共有する場合には、Boxを作ってしまった方が良さそうという気がしました。今までは vagrantup.com などで公開されている、ほぼ素のUbuntuのBoxをベースにして、手作業で下準備を行い、スナップショットを取っておくという使い方をしていました。

Packerを使うと同じひな形から別のProvider向けのBoxを作成できるという話があったので、そういった場合や、OSのインストールからBoxを作成したい場合に使うものなのだと思います。

ただ、Packerやveewee（少し前からあるまた別のBox作成ツール）は、個人的に少しとっつきにくいイメージがあります。VirtualBoxのUbuntuやCentOSで良ければ vagrantup.com や opscode/bento などでほぼ素のBoxが提供されているため、それをベースにして下準備を行ったものを vagrant package でBoxにするのが良い気がします。

プロダクション環境での利用について

Multi-Provider機能を使って開発環境とプロダクション環境を同じ操作で構築するというのはあくまで理想形かなと思います。というのは、プロダクション環境を構築するために使うのはまだ少し難しそうな気がしました。

お話の中でもされていましたが、AWSに対してはネットワーク設定が無視されてしまうようです。また、Vagrantで立ち上げた環境はvagrantユーザやinsecureな認証キーが含まれているので、プロダクション環境で使う場合には、そういった不要な設定などを無効にする後始末が必要になるのではないかなという気がしています。

最後に

今回はVagrant開発者であるHashimotoさんから直接お話を聞くことのできる貴重な機会でした。開発フローや今後のロードマップなど参考になる内容も聞くことができたので良かったと思います。

Hashimotoさんの最後のスライドにもありましたが、まとめはやはりこれで。

「Vagrantを使いましょう！」