コード化でDevOpsを支えるHashiCorpのツールと開発背景

HashiCorpとは？

「HashiCorp」という名前を知らなくても、Vagrantというツールの名前なら聞いたことがある、もしくはすでにお使いの方もいらっしゃるのではないでしょうか。Vagrantは仮想化された開発環境を簡単に立ちあげられるため、開発者サイドにとってはおなじみのツールです。このVagrantを開発したMitchell Hashimoto氏が創業した会社の名前がHashiCorpです。

HashiCorpが提供するツールは、開発者向けのものだけでなく、運用担当者向けのものもあります。連載初回の今回は、HashiCorpとは何であり、どのようなツールを、どのような考えで提供しているのかを紹介します。

HashiCorpの沿革

きっかけはVagrantの開発がスタート地点でした。Mitchell Hashimoto氏が2010年にVagrantバージョン0.1をリリースした後、2012年にVagrantをはじめとしたソフトウェアをサポートするための会社をArmon Dadgar氏と設立しました。設立の目的は、アプリケーションの開発・デプロイ・運用に至るデータセンター管理に、革命をもたらすことです。その後、2013年にPackerとSerf、2014年にVagrant CloudやConsul、Terraformと、開発から運用まで使えるツール群を立て続けに発表しました。そして2014年末には、これまでに発表したツールを包括する新サービスATLASの発表を行っています。

図1：HashiCorpの沿革とツール（クリックで拡大）

開発から運用まで支えるツール群

現在、HashiCorpからは5つのツール群が提供されています。以下では、それぞれの概要と役割を紹介します。

Vagrant

Vagrantは、仮想環境上に自動的にOSやアプリケーションの実行環境を整えます。設定ファイルを使うことで、特定のアプリケーションやミドルウェアのセットアップも自動的に行えます。「vagrant up」とコマンドを実行するだけで、環境が使えるようになります。それだけでなく、その設定ファイルを使えば、他の環境でも同様の実行環境を得られます。このVagrantは、HashiCorp創設者のMitchell氏による最初のツールです。

Packer

Packerは、複数の仮想化環境・クラウド環境に対応した仮想マシン・イメージを作成、起動するためのツールです。それぞれの環境に合わせてマシン・イメージを迅速に自動生成するため、複数の環境に対応したイメージを用意する手間が省けます。AWSのAMI（マシン・イメージ）だけでなく、VMwareやOracle VM VirtualBoxの形式にも対応しています。

Terraform

Terraformは、クラウド環境上のインフラ構築や設定を、コードを使って自動化するためのツールです。あらかじめ設定ファイル上で、インフラのあるべき状態を定義します。そうすることで、複数台で構成されるアプリケーションの実行基盤もコマンドを用いて簡単に作成・変更・削除できます。AWSやGoogle Cloud、DigitalOcean等のクラウドに対応していますが、それ以外のクラウド環境への対応も進んでいます。また、活発な機能改善も行われています。

Serf

Serfは、複数のサーバで構成されるクラスタの情報を管理し、クラスタを構成するサーバ上で同じコマンドを一斉に実行するためのツールです。各サーバでSerfを動作させ、お互いに通信を行ってクラスタを構成します。このクラスタの参加・離脱や任意のタイミングでコマンドを実行できるほか、ホスト名やIPアドレス等を環境変数で取得し、ミドルウェアや監視ツールの設定を、クラスタ構成にあわせ自動的に変更できます。

Consul

Consulは、サービスの検出（service discovery）やサービスに対する監視を行い、状況を知るだけでなく、状況変化に応じて任意のコマンドを実行できるツールです。Serfを基盤としていますが、可用性を高めるために複数台でサーバを構成します。キー・バリュー・ストアの機能、HTTPのRESTインターフェースや、DNSインターフェース機能を持ちます。システムが稼働した後の運用時、異常検出や自動復旧を行いたい時に役立ちます。

各ツールの連携を進めるATLAS

2014年末にHashiCorpが発表したATLASは、開発から運用に至るまで、これまで紹介したツール群を包括する役割を持つ新サービスです。

ATLASの目指すところ

ATLASはどのような役割を提供しているのでしょうか。サイトには「アプリケーションの開発、デプロイ、保守をどこでも。開発から本番運用に至るまで、1つのコンソールと、1つのワークフローで」と紹介されています。言い替えますと、これまで提供されてきたそれぞれのツールがATLASを通して1つにつながることを意味しています（図2参照）。これまでのHashiCorpのツールは、それぞれ独立した機能・役割を持つものであり、つながりはありませんでした。それらのツールを、ATLASというプラットフォームを通して統合することができます。

図2：ATLASと各ツールの関係（クリックで拡大）

HashiCorpの開発思想

HashiCorpはどのような意図で、これらのサービスやツールを提供してきたのでしょうか。これについては、同社の開発思想が書かれたブログ記事「The Tao of HashiCorp」（＝HashiCorpの道という意味）から読み取れます。この記事の中で、HashiCorpのビジョンやロードマップ、プロダクト設計のための基礎として、複数の要素を発表しています。以下では、その記事の概要を紹介します。

目標はワークフローの解決であり、技術ではない

HashiCorpの手法は、根底にある技術よりも、ワークフロー（業務上の流れ）をどうやって解決するかにおかれています。まず目標を決めて、そこに至るまでのワークフローを検討します。そして、その仕事を単純にするためにツールが存在しなければ、HashiCorpが作るというものです。その際、新しい技術を導入するかどうかの判断は、効率的なユーザ経験をもたらすかどうかが基準となり、技術的に新しいかどうかではありません。

Unix哲学の影響を受けた設計方針

HashiCorpのツールは、それぞれが十分に1つの機能を果たすように設計されています。これはUnix哲学の「Simple, Modular, Composable」（単純、モジュール型、組みあわせ可能）といった姿勢による影響を受けています。問題解決にあたっては課題を1つ1つの要素に分解し、それらをツールの機能に落とし込み、各ツールがつながって問題解決に至るという考えです。個々のツールは、APIを通じて他のツールと通信できるように、独立したものとして扱われます。そうすることで、ソフトウェアでよくみられるような、機能拡張による複雑化を避けられます。

イミュータブル・インフラストラクチャとコード化

Immutability（イミュータビリティ）は「変わることがないという性質」を示す言葉です。これは、開発環境におけるバージョン管理システムに近い考え方ではないでしょうか。コードを一度コミットしてしまえば、そのコミット内容は固定（fix）されます。バージョンで管理されるので、バージョンのロールバック（巻き戻し）も可能ですし、変更の経緯も分かります。これらをソースコードだけでなく、サーバやアプリケーションの状態にも適用する考えが、イミュータブル・インフラストラクチャです。インフラ構築の情報がコード化されバージョン管理されていれば、構築当時の担当者が不在の場合や社内に適切な情報が記録されていなくても、状況の把握が容易になります。

コード化を通じた自動化

一般的なシステムにおいて、インフラに対して手動で変更を加えると、システムの規模を拡大する際や、変更を加える際の手間が大変になりがちです。この課題を解決するために自動的に行う方法がありますが、それに対してHashiCorpは「コード化」という手法を提案します。コード化された知識の利点は、システムによって自動実行できることだけではありません。人間にとっても状態がコードで読みやすいものとなり、その結果生産性を向上し、人的ミスを減らすことにもつながります。

まとめ

今回はHashiCorp製ツールの概要や、その開発思想を見てきました。HashiCorpのツール1つ1つは別々の機能を持っていますが、それらの目的は別々ではなく、開発と運用の境界線上における問題、いわゆるDevOpsを促すためのルールでもあるとご理解いただけたのではないかと思います。次回以降は、それぞれのツールの実践的な使い方を紹介していきます。

HashiCorpの提供するツールの大きな特徴は、開発者だけでなく、運用担当者も使える点ではないでしょうか。この連載では、ツールに対する知識だけでなく、実際に手を動かしながら理解を深めていければと思っています。そして、今後のクラウド・コンピューティングが生み出す未来について思いを馳せつつ、みなさんの仕事を良くするきっかけとなれば、それはとても嬉しいなって思っています。