アジャイル DevOps: インフラストラクチャーの自動化

インフラストラクチャーの自動化とは、環境をスクリプト化するプロセスです。このプロセスには、オペレーティング･システムのインストールから、インスタンスへのサーバーのインストールと構成、さらにインスタンスとソフトウェアとの間の相互通信方法の構成などの、さまざまな作業が含まれます。環境をスクリプト化することで、同じ 1 つの構成を単一ノードにも、数千のノードにも適用できるようになります。

インフラストラクチャーの自動化は通称、構成管理、IT 管理、プロビジョニング、スクリプト化されたインフラストラクチャー、システム構成管理とも呼ばれています。この他にも多くの重複する言い回しがありますが、その要点は同じです。つまり、インフラストラクチャーとその構成を 1 つまたは複数のスクリプトとして記述することで、極めて間違いが起こりにくい方法で環境を複製できるということです。インフラストラクチャーを自動化すると、権限を与えられたすべてのチーム・メンバーが優れた開発プラクティス (自動化されたテストとバージョン管理など) をインフラストラクチャーに適用するかたわらで、スクリプトを変更できるため、開発部門と運用部門の双方にアジリティーをもたらします。

この 10 年の間に、インフラストラクチャーの自動化をサポートするオープンソースおよび商用のツールが登場しました。そのうち、オープンソースのツールには Bcfg2、CFEngine、Chef、Puppet などがあります。これらのツールは、クラウドでも、仮想環境や物理環境でも使用することができます。この記事では、最もよく使われているオープンソースのインフラストラクチャー自動化ツールである、Chef と Puppet に焦点を当てます。これらのツールの複雑な部分について説明することはしませんが、この 2 つの類似点と相違点を説明するとともに、代表的なサンプル・コードを記載します。インフラストラクチャー自動化ツールのセットアップ手順と使い方を説明した詳しい例として、この記事では Puppet をクラウド環境で実行する方法を解説する動画も併せて提供しています。

Chef と Puppet はどちらも、環境をスクリプト化するために Ruby のドメイン特化言語 (DSL (Domain-Specific Language)) を使用します。Chef は Ruby の内部 DSL として表現されます。Puppet ユーザーは主に Ruby の外部 DSL (同じく Ruby で作成されています) を使用します。多くの場合、この 2 つのツールは Linux システムの自動化に使用されていますが、Windows のサポートも備えています。Puppet には Chef よりも大きなユーザー・ベースがあり、古い時代遅れのオペレーティング・システムに対するサポートもより充実しています。Puppet では、他のタスクへの依存関係を設定することができます。この 2 つのツールは両方とも、べき等です。つまり、同じ構成の場合には、何度実行しても常に同じ結果になります。

Chef

2009年頃から見かけるようになった Chef は、Puppet と CFEngine の影響を受けています。Chef がサポートしているプラットフォームには、Ubuntu、Debian、RHEL/CentOS、Fedora、Mac OS X、Windows 7、Windows Server などがあります。Chef は使いやすいと言われることが多いですが、Ruby 開発者の間では特にそう言われています。というのも、Chef ではあらゆるものが Ruby スクリプトとして定義され、Ruby 開発者が作業し慣れているモデルに従うためです。Chef には熱烈なユーザー・ベースがあります。Chef コミュニティーは急速に成長しており、ユーザーが互いに使用できるクックブックを次々と開発しています。

Chef の仕組み

Chef では、Chef サーバー、ノード、そして Chef ワークステーションという 3 つのコア・コンポーネントが互いにやりとりをします。Chef は、自動化されたステップ (「アクション」と呼ばれます) をノード上で実行する「レシピ」で構成された「クックブック」を実行して、ソフトウェアをインストールして構成したり、ファイルを追加したりします。Chef サーバーには、多数のノードを管理するための構成データが格納されます。ノードは、Chef サーバーに格納された構成ファイルやリソースを、必要に応じて抽出します。リソースの例には、File、Package、Cron、Execute などがあります。

ユーザーが Chef サーバーを操作するには、「Knife」という Chef のコマンドライン・インターフェースを使用します。ノードには、1 つ以上の「ロール」を割り当てることができます。ロールは 1 つのノードに対して属性 (ノード固有の設定) とレシピを定義し、それらを複数のノードに適用することができます。これらのレシピは、他のレシピを実行することもできます。「実行リスト」と呼ばれる、ノードの一連のレシピは、リストに記載された順に実行されます。Chef ワークステーションは、ローカルの Chef リポジトリーと Knife がインストールされたインスタンスです。

表 1 に Chef のコア・コンポーネントの説明を記載します。

表 1. Chef のコンポーネント

サンプル・コード

リスト 1 に、Tomcat クックブックの一部となっているレシピ内の service リソースの使用例を示します。このように、Chef のようなツールを使用すれば、プラットフォーム固有の構成を行ってサーバー構成を管理することができます。

リスト 1. Chef のレシピ

service "tomcat" do
  service_name "tomcat6"
  case node["platform"]
  when "centos","redhat","fedora"
    supports :restart => true, :status => true
  when "debian","ubuntu"
    supports :restart => true, :reload => true, :status => true
  end
  action [:enable, :start]
end

リスト 2 に、Tomcat クックブックの属性を定義します。この例では、Tomcat サーバーにいくつかの外部ポートを定義して使用できるようにしています。上記に記載されている以外のタイプの属性には、ディレクトリー、オプション、ユーザー、その他の構成の値があります。

リスト 2. Chef の属性

default["tomcat"]["port"] = 8080
default["tomcat"]["ssl_port"] = 8443
default["tomcat"]["ajp_port"] = 8009

Chef は (外部 DSL と対比すると) Ruby 言語を拡張して、多数のノードに一度に構成を適用するためのモデルを提供します。Chef は明示的な依存関係管理を抜きにした命令型モデルを使用するため、開発分野で経験を重ねてきたユーザーは、環境をスクリプト化しているときに Chef に関心を寄せるようになる傾向があります。

上に戻る

Puppet

Puppet は、2005 年から使用されています。Google、Twitter、Oracle、Rackspace をはじめ、多くの組織では、Puppet を使用してインフラストラクチャーを管理しています。Chef と比べると、Puppet は習得するのに時間がかかりますが、サポートしている Windows および *nix 環境の種類は充実しています。また、大規模で活発なユーザー・コミュニティーもあります。Puppet は、システム環境で何万ものインスタンスを実行している数千の組織で使用されてきました。

Puppet の仕組み

Puppet では、「Puppet マスター」と呼ばれるマスター・サーバーの概念を使用しています。Puppet マスターはノード全体にわたる構成を一元管理し、ノードをタイプごとにグループ化します。例えば、Jenkins WAR で Tomcat を実行している一連の Web サーバーがある場合、Puppet マスターではこれらの Web サーバーをまとめて 1 つのグループにします。「Puppet エージェント」は、システム上でデーモンとして実行されます。これにより、インフラストラクチャーの変更を複数のノードに同時にデプロイすることが可能になります。Puppet エージェントはデプロイメント・マネージャーと同じように機能しますが、アプリケーションをデプロイするのではなく、インフラストラクチャーの変更をデプロイします。

Puppet には、「facter」という名前のツールが組み込まれています。システムに関するメタデータを格納する facter は、サーバーをフィルタリングするために使用することができます。例えば、facter を使用すれば、ノードのホスト名を判別することができます。MCollective は、Puppet を統合するデプロイメント・ツールです。MCollective を使用して、インフラストラクチャーの変更をすべてのノードにデプロイすることができます。

表 2 に、Puppet の主要なコンポーネントを記載します。

表 2. Puppet の主要コンポーネント

サンプル・コード

リスト 3 は、ノードにインストールするパッケージを記述する Puppet マニフェストの例です。Puppet は、これらのパッケージをインストールするのに最善の方法と実行順序を決定します。

リスト 3. パッケージのインストールに関する Puppet マニフェスト

class system {
  package { "rubygems": ensure => "installed" }

  package { "make": ensure => "installed" }
  package { "gcc": ensure => "installed" }
  package { "gcc-c++": ensure => "installed" }
  package { "ruby-devel": ensure => "installed" }
  package { "libcurl-devel": ensure => "installed" }
  package { "zlib-devel": ensure => "installed" }
  package { "openssl-devel": ensure => "installed" }
  package { "libxml2-devel": ensure => "installed" }
  package { "libxslt-devel": ensure => "installed" }
}

リスト 4 に抜粋する Puppet マニフェストのスニペットには、インフラストラクチャーをスクリプト化する際に使用できる、タイプの異なるリソースの例 (パッケージとサービス) が示されています。

リスト 4. httpd に関する Puppet マニフェスト

class httpd {
  package { 'httpd-devel':
    ensure => installed,
  }
  service { 'httpd':
    ensure => running,
    enable => true,
    subscribe => Package['httpd-devel'],
  }
}

Puppet は、明示的な依存関係管理を使用した宣言型モデルを採用しています。そのため、システム管理の経験を持ち、環境のスクリプト化をしようとするエンジニアは、最初に Puppet をツールの候補として検討する傾向があります。

上に戻る

コードとしてのインフラストラクチャー

今回の記事ではサンプル・コードを通して、インフラストラクチャーはもはや、個々のノードに合わせて個別に手作業で適用する必要はないことを説明しました。インフラストラクチャーを自動化することで、追加作業を行うことなく、インフラストラクチャーをスケールアップ/スケールダウンすることが可能になります。インフラストラクチャーがスクリプトの形でモデル化されていれば、アプリケーション・コードとまったく同じようにバージョン管理を行い、テストすることができます。

次回の記事では、一時環境を作成する場合のパターンと手法について説明します。一時環境とは、アジャイル DevOps に伴う「豊かさマインド」(つまり、不足しているものはないという考え方) を採用した、作成されてから 24 時間以内に破棄される環境のことです。

参考文献

学ぶために

• 「The Chef, the Puppet, and the Sexy IT Admin」(Cade Metz著、Wired、2011年10月): Chef および Puppet の詳細と DevOps との関連について読んでください。
• DevOps: ウィキペディアで、DevOps ムーブメントの背後にある方法論および動機について説明しています。
• Chef Basics: Chef の開発者たちが Chef について紹介しています。
• 「Automating Web App Deployments with Opscode Chef and iControl」: ネットワーク構築企業の F5 が、Chef をどのように利用しているかを説明しています。
• 「A survey of system configuration tools」(Thomas Delaet、Wouter Joosen、Bart Vanbrabant 著、24th Large System Administration Conference の議事録、2010年): この文書とプレゼンテーションでは、Chef と Puppet を含む 11 のオープンソースおよび商用システム構成ツールを評価するためのフレームワークを紹介しています。
• さまざまな IBM 製品および IT 業界についての話題に絞った developerWorks の Technical events and webcasts で時代の流れをキャッチしてください。
• 無料の developerWorks Live! briefing に参加して、IBM の製品およびツールについての情報や IT 業界の動向についての情報を迅速に把握してください。
• Twitter で developerWorks をフォローしてください。
• developerWorks の on-demand demos で、初心者向けの製品のインストールとセットアップから、熟練開発者向けの高度な機能に至るまで、さまざまに揃ったデモを見てください。

製品や技術を入手するために

• Chef: Chef にはいくつかの「フレーバー」が用意されています。
• Puppet: Puppet Enterprise をダウンロードしてください。
• IBM Tivoli Provisioning Manager: Tivoli Provisioning Manager は物理サーバー、仮想サーバー、ソフトウェア、ストレージ、およびネットワークを自動化して、動的なインフラストラクチャーを実現します。
• IBM Tivoli System Automation for Multiplatforms: Tivoli System Automation for Multiplatforms は、エンタープライズ規模のアプリケーションおよび IT サービスの高可用性および自動化を実現します。
• ご自分に最適な方法で IBM 製品を評価してください。評価の方法としては、製品の試用版をダウンロードすることも、オンラインで製品を試してみることも、クラウド環境で製品を使用することもできます。また、SOA Sandbox では、数時間でサービス指向アーキテクチャーの実装方法を効率的に学ぶことができます。

議論するために

• developerWorks コミュニティーに参加してください。ここでは他の developerWorks ユーザーとのつながりを持てる他、開発者によるブログ、フォーラム、グループ、ウィキを調べることができます。
• developerWorks の Agile Transformation コミュニティーでは、組織がアジャイル開発の原則に基づく基礎を固めるために役立つニュース、ディスカッション、トレーニングを提供しています。

コメント

• 

  IBM PureSystems

  IBM がどのように IT に革命をもたらしているのかをご自身でお確かめください

• 

  Knowledge path

  developerWorks の Knowledge path シリーズでは、テーマ別の学習資料をご提供しています

• 

  ソフトウェア評価版: ダウンロード

  developerWorksでIBM製品をお試しください！

上に戻る