Subscribed unsubscribe Subscribe Subscribe

@kyanny's blog

Write down what I learnt. Opinions are my own.

インフラ系トレンド私的まとめ

社内勉強会でいろいろ教えてもらったのでメモ。トレンドと呼ぶには一、二年遅い。なお自分の考えを整理するために書いているものなので正確さは保証しませんしツッコミも不要です。

前提: 仮想マシンと仮想マシンイメージ

VirtualBox とか、 AWS なら AMI とか。ホストマシン上で動作しているものが仮想マシンで、仮想マシンイメージは仮想マシンのスナップショットだったり、それをもとに新しい仮想マシンを作れる雛形だったり、くらいに理解しておけばよい。

Vagrant と Packer

仮想マシンと仮想マシンイメージの技術があるおかげで、作業環境(Mac とか Windows とか)上でプロダクション環境により近い環境を手軽に用意できるようになた。しかし仮想マシンの管理(起動したり、設定を変えたり)は手作業でやる必要があった(VirtualBox なら GUI でぽちぽちやったりとか) Vagrant はそこを解決するツール。

Vagrant は仮想マシンイメージの設計書をテキストファイルに書いて管理できる。また VirtualBox や VMWare などベンダー固有の仮想マシン技術ごとに異なる詳細に対する wrapper としての面もあり、 Vagrantfile と vagrant コマンドという統一インタフェースを用意したことに強みがある。

Vagrant を使えば作業環境上に開発環境を手軽に作れるが、そのままではプロダクション環境で起動可能な仮想マシンを作れない。そこを埋めるのが Packer で、 Vagrant で納得いくまで仕上げた設計書(Vagrantfile)をもとに AMI なりを作って、開発環境と同じ仮想マシンをプロダクション環境で動かすことができる。

Vagrant/Packer と Docker の関係

Docker は Vagrant+Packer と結果的にだいたい同じことを実現する。技術的には Vagrant/Packer が仮想マシンを扱う対象としているのに対し、 Docker は Linux Container をベースとするコンテナを扱う対象としている点が異なる(レイヤーが一段違う)。コンテナは物理でも仮想でも、ホスト内で独立して動作する環境で、仮想マシンに比べて軽量なので必要なリソースが少なく済んだりというメリットがあるが、一般人が使う典型的なユースケースではどっちでも得られる結果には大差ない、と思ってよい。

もう一つの違いは、 Vagrant/Packer は VirtualBox や AMI といったベンダー固有技術に対する wrapper で、それらのツールを使った結果得られる成果物はベンダー固有技術を使うものであるのに対し、 Docker はそれ自体が各種ベンダー固有技術から自由なテクノロジである、とうたっている点だが、 Docker 自体がベンダー固有技術なので特に何の問題解決にもなっていない。

Vagrantfile と Dockerfile も、書き方によって同じようなことは実現できる、という部分もかぶっているといえばかぶっている。

Vagrant/Docker と Chef/Puppet/Ansible の関係

仮想マシンにせよコンテナにせよ、即起動可能なものの雛形を作り管理するのが Vagrant なり Docker なりの担うところで、雛形を作る時点でその実行環境内で必要なソフトウェアのインストールやサーバの設定などが済んでいるのであれば別途構成管理ツールを使わなくてもよい。だが手作業でいろいろインストールして仕上げた仮想マシンはいろいろ汚れていそうで作り直しが難しいし、そもそも定型作業が多いから自動化すべき、ということで構成管理ツールも使いましょう、ということになる。

どうせ構成管理ツールを使うのなら Vagrantfile/Dockerfile ではそれらのツールがカバーしている設定はやらず、仮想マシン/コンテナの起動までにとどめておき、実行環境内部のもろもろはより適したツールに任せる、という住み分け方なのだとおさえておけばよい。

Terraform

Vagrant+Packer にせよ Docker にせよ、個々の仮想マシン/コンテナをどう管理するか?に主眼を置いているもので、仮想マシン/コンテナが動作するホストマシンは別途セットアップして動作させる必要があり、これらのツールはその領域をカバーしない。 AWS でならマネジメントコンソールでぽちぽちやったり、 API を使って何かしら自動化したりするのが一般的らしいが、煩雑かつ手作業が必要な部分が残ってしまっているし自動化ツールを自前で用意できる余裕がないところもある、だからそういうツールを作ったぜ、というのが Terraform だ。

Terraform は AWS や GCP のようなクラウド上でホストマシンを稼働させたり、仮想ネットワークを作ったり、というのをテキストファイルで設定管理でき、かつ統一インタフェースを提供することでベンダー固有の詳細を抽象化してくれる wrapper で、 Vagrant と似ている。どちらも Hashicorp 製品なので同じ思想に基づいているのだろう。 AWS CloudFormation がほぼ同じ役割を(AWS 上限定で)行うものらしい。つまり Terraform 自体がベンダー固有技術を抽象化した存在で、 CloudFormation のない GCP や Microsoft Azure なり向けの CloudFormation 相当の存在、と思ってよい。

なお CloudFormation と AWS OpsWorks の違いは、 CloudFormation が AWS の各種サービスを組み合わせて使うためのテンプレートを用意できる・自動化できるツールなのに対し、 OpsWorks は chef-solo レシピ適用の自動化、みたいな感じなのでやはりレイヤーが一段違うというか守備範囲の広さに違いがある、くらいに把握しておけばよい。

結論
  • 無理して Docker を使う必要はない。 Vagrant で満足してるなら Docker を併用しなくても一向に構わない。
  • 個人の作業用仮想マシンを作る程度の用途ならば構成管理ツールも無理して使わなくてよい。ただし仕事で使う環境(プロダクションでもそうでなくても)を用意する際には「職人のインフラエンジニアによる手作業」はもはやありえないので構成管理ツールの使い方はある程度習熟し理解を深める必要がある。
  • Terraform がどのくらい嬉しいツールなのかは、自分がこれまで AWS マネジメントコンソールでの作業すらろくすっぽやってないので、苦労してきてないこともあり、まだ評価できない。
  • これらのツールは総じてスケールが大きく、特に事例紹介などでは余計にその傾向が強まるため、「問題意識はぼんやりわかるけど無駄に大げさに解決しようとしすぎてないか?それとも俺の理解が浅すぎるだけで実際にはやはりこれが大げさにならないほど難しい問題の解決に取り組んでいるのだろうか...」という悩み・もやもやをずいぶん長い間抱いてきたが、ようやく少しクリアになってよかった。