2016.06.16

Habitat ファーストインプレッション

Habitat

次世代システム研究室の DevOps ネタ担当の M. Y. です。

Chef の開発元である Chef Software, Inc. が、6月15日（米国時間では14日）に、新しいオープンソースプロダクト “Habitat” をリリースしました。公開されたデモやチュートリアルを一通り触ってみて、どういうものかわかってきたので、今回はこの Habitat をご紹介します。

Habitat とは何か？

Habitat のサイトを見ても、「Habitat とは何か？」を簡潔に述べた説明は見当たりませんでした。そのため、まずは私の個人的な理解を簡単に説明します。細かい点で間違いなどあるかもしれませんが、ご容赦ください。

Habitat とは、アプリケーションと、そのアプリケーションの管理自動化ロジックを一緒にパッケージングするための新しいフレームワークです。以下は、Habitat を使って構築したシステムのイメージ図です。

Habitat

Habitat では、Package と呼ばれる単位でアプリケーションを配布します。Package の実態は、拡張子 hart の tarball です。この tarball には、配布したいアプリケーションのバイナリと、そのアプリケーションを管理するためのスクリプトや設定ファイルが含まれます。このスクリプトや設定ファイルのことを、Habitat では Plan と呼びます。このように、アプリケーションと、その管理ロジックをパッケージングする点が、Habitat の大きな特徴です。

ちなみに、Plan を作成する際には、大本になる plan.sh という bash スクリプト（！）を必ず用意する必要があります。設定の大本が bash というのはちょっと驚きました。Habitat のサイトのドメインが habitat.sh なのは、これが理由かもしれませんね。まあ、余談でした。

管理者は、“hab” というコマンドを使って、アプリケーションのデプロイ、起動、停止、設定変更などを行うことができます。例えば hab sup start <パッケージ名> というコマンドを実行すると、パッケージがリポジトリ（Habitat では Depot と呼びます）から自動的にダウンロードされて、OS上にデプロイされます。

hab を使ってデプロイされたアプリケーションは Service と呼ばれます。また、アプリケーションのデプロイ時に、Supervisor と呼ばれるプロセスも同時に起動されます。この Supervisor は Service の起動だけでなく、アプリケーションの設定変更などを行う機能も持ちます。ただし、設定変更などの具体的な方法が予め Plan に記載されている場合に限ります。

更に、Package の設定次第では、Supervisor 同士でネットワークを構成することができます。このネットワークは Ring と呼ばれます。Ring と呼ばれますが、リング状のネットワークと言うよりは P2P ネットワークのようです。更に、Ring のなかでは、Supervisor 間の論理的な関係（Habitat では Topology と呼ぶ）を定義できます。例えば、leader/follower などの関係を定義できます。これは、サービスの起動順序の制御などに利用できます。

まとめると、Habitat を使ってアプリケーションをデプロイすると、Supervisor と Service がセットで動作します。Habitat の根幹はこのセットを作ることだけなので、Habitat の Package は、ベアメタルにも、VM にも、コンテナにもデプロイできます。例えば、Docker にデプロイしたい場合は hab pkg export docker コマンドを使うと、Supervisor と Service を同梱した Docker image を生成できます。

以上が、Habitat の基本的な概念についての、簡単な説明でした。

Habitat について、現在試せること

hab コマンドの動作をちょっと見てみたい、という方向けには、Web ブラウザ上で動作するデモが Habitat – Demo にて公開されています。

また、Mac および Linux 向けのバイナリが Habitat – Download にて公開されています。このバイナリを実際に動かすチュートリアルは Habitat – Tutorials にあります。

それぞれの内容を、簡単にご紹介します。また、わかりにくい点についていくつか補足します。

デモ

URL：Habitat – Demo

このデモは、以下のシナリオを含んでいます。ダミーのコンソールが表示されており、このコンソールにコマンドを入力すると、habitat コマンドの結果を確認できます。
  • Redis のパッケージ “core/redis” をデプロイする
  • hab コマンドを使って、設定ファイルの内容を確認する
  • hab コマンドを使って、設定を一時的に変更する（設定のテストのため）
  • hab コマンドを使って、更新後の設定ファイルを、Ring 上の全ての Redis に適用する
  • hab コマンドを使って、leader/follower topology の Service Group を構成する
デモのページを開くと表示されるコンソールは、以下のような、若干見慣れない表示をしています。これは Studio と呼ばれる Habitat 独自のコンソールです。hab studio enter を実行すると Docker コンテナが生成され、そのコンテナに接続されて、このコンソールが表示されます（2016-06-18追記：Docker が起動するのは Mac の場合だけで、Linux の場合は chroot を使って実行するようです。参考）。

Habitat

なぜそんなことをする必要があるのか？ それは、Package をビルドするためには、ホストOSと切り離されたクリーンな環境があったほうがよいから、ということのようです。また、studio を閉じてしまえば、ビルド時に自動生成されたファイルも勝手に消える、というメリットもあります。

チュートリアル

URL：Habitat – Tutorials

このチュートリアルは、個人的にはとてもわかりにくいと思います……。ただ、何をするチュートリアルなのか事前に知っていれば、理解の助けになるかもしれません。

このチュートリアルの内容と、各ページの対応関係は以下の通りです。
  • hab をインストールする（Set up your environment）
  • このチュートリアルで想定する、既存の Web アプリのサンプルを作る（Review the source files）
    • このステップで作っているのはあくまで既存の Web アプリのサンプルであり、Habitat 固有のファイルはまだ何も作っていないことに注意してください
    • 手順が書かれていませんが、ここで作ったファイルを tarball に固めて、どこかのサーバ（S3 など）にアップロードする必要があります
    • また、解凍したら mytutorialapp-0.1.0 ディレクトリができるように圧縮する必要があります。そうしないと、次のステップで失敗します
  • 上記の Web アプリをパッケージ化するための Plan を作る（Creating your first plan の前半）
    • Mac の場合、ハッシュ値は shasum -a 256 で計算できます
  • 上記の Plan から Package を作る（Creating your first plan の後半）
  • 上記の Plan を改善する（Add hooks to your plan, Add configuration to your plan）
  • 改善後の Plan から Package を作る（Run your service の前半）
  • Package から Docker image を作り、この Docker image からコンテナを起動する（Run your service の後半）
余談ですが、このチュートリアルがわかりづらいのは、Mac 環境で実行できない処理をスキップしているからではないか……と後から気付きました。Package を作る手順の次に、その Package をデプロイする手順があればわかりやすいと思うのですが、Mac 上では Supervisor が直接動作しないので、それはできません。

更に余談ですが、Mac 上で Vagrant & VirtualBox & “centos/7” box を動かして、この CentOS 上に hub をインストールすることも試してみました。しかし、私が試した時は、このパターンでも Supervisor の起動に失敗しました。何だかまだ、色々とつまづきポイントがありそうです……。

ファーストインプレッション

Chef との関係

Habitat 独自の概念が多く、最初は面食らいました。ただ、「Habitat とは何か？」の章に書いたようなイメージが頭のなかにできてからは、インフラに依存しないシンプルなアプリケーション管理フレームワークとして、こういう方向性はありかもしれない、と関心しました。

ただ、（Chef Software, Inc. ではなくてソフトウェアとしての）Chef と Habitat の関係がよくわかりませんでした。Chef は大規模かつ複雑なシステム、Habitat はそれ以外、という感じで住み分けるのでしょうか？ あるいは、両者を組み合わせてうまく使う機能が、今後追加されていくのでしょうか？

Habitat のサイトを探し回ってみたのですが、Chef に関する記述は、Chef Delivery というデータフローエンジンとの連携機能に関する説明（Continuous deployment with Habitat）しか見当たりませんでした。

HashiCorp のツール群との関係

個人的には、少し前に Otto の調査をしたこともあり、Otto と似ているかな、と思いました。

あわせて読みたい：HashiCorp製品（Vagrant, Consul, Atlas, Otto）の活用による開発環境構築の自動化について発表しました | GMOインターネット 次世代システム研究室

アプリケーションをパッケージ化して、設定ファイルにアプリケーション間の依存関係を記述させる、という点は、Habitat と Otto で共通しています。Habitat の場合は plan.sh、Otto の場合は Appfile ですね。

ただ、Otto はマイクロサービスを大きくコンセプトとして掲げており、アプリケーションごとに別のコンテナとして動作させることを想定して作られています。一方、Habitat はそんな感じがしません。1台のベアメタルサーバ上に、複数の Package をデプロイすることもできます。例えば、チュートリアルのなかでは、Web アプリケーションと一緒に Node.js をインストールさせるために、”core/node” という Package への依存関係を plan.sh に書かせています。

良く言えば Habitat のほうが柔軟、と言えるのですが、悪く言えば Package をどのような単位で分けるべきかわかりづらいです。実際の開発に使い始めたら、Package の分け方で混乱しそうな気がします。

また、Otto はクラスタ化のために Consul を使っていますが、Habitat の設定変更の機能は Consul & Consul Template を連想させます。必要な機能が Habitat にオールインワンで入っているのは良いですが、既に実績のある Consul のようなツールを置き換えるほどのメリットがあるのか、まだ良くわからないところです。

その他もろもろ

hab をダウンロードして解凍すると、”hab” という実行ファイルが1個だけ出てきます。実行ファイルだけを1個だけ配布して、それ以外の必要なファイルはあとから自動的にダウンロードする、というのは運用管理ツールの配布方法としてすっかり一般的になりましたね。ただ、Bintray の仕様で URL に $latest が入っていて、VM から直接ダウンロードするときに不便でした。私は自分で $latest を 0.7.0 に直してダウンロードしました。

この手の実行ファイルだけ配布されるソフトは Go で実装されている、というイメージが強かったのですが、Habitat は Rust で実装されています。GitHub（habitat-sh/habitat） でソースコードが公開されているので、Rust に興味のある方はかなり参考になるのではないでしょうか。

最後に

今回は、構成管理ツール Chef の開発元で有名な Chef Software, Inc. が新たにリリースした Habitat を簡単にご紹介しました。

色々と否定的なことも書きましたが、Habitat は開発元の知名度が高く、今風なコンセプトで開発された、今後に期待できるプロダクトです。今後も、引き続き動向をウォッチしていきたいと思います。

参考文献

次世代システム研究室では、グループ全体のインテグレーションを支援してくれるアーキテクトを募集しています。インフラ設計、構築経験者の方、次世代システム研究室にご興味を持って頂ける方がいらっしゃいましたら、ぜひ 募集職種一覧 からご応募をお願いします。

皆さんのご応募をお待ちしています。

  • Twitter
  • Facebook
  • はてなブックマークに追加

グループ研究開発本部の最新情報をTwitterで配信中です。ぜひフォローください。

 
  • AI研究開発室
  • 大阪研究開発グループ

関連記事