カスタム仮想クラウド・イメージをビルドするためのシステムを確立する

IBM Image Construction and Composition Tool を利用する方法

仮想イメージを使用することで、ユーザーは望ましいソフトウェア環境をフリーズドライして、迅速かつ一貫した方法で配布することができます。このことから、企業はデータ・センター内でのソフトウェア・デリバリーを改善する手段として仮想イメージに頼るようになってきています。けれども仮想イメージの利用規模を広げるにつれ、さまざまな難題が持ち上がってきます。例えば、単一のイメージに組み込むコンテンツの量や、仮想イメージを作成する最善の方法を決定しなければなりません。この記事ではこれらの難題について検討し、その多くに対処してクラウド内での仮想イメージを体系的な方法で作成できるようにするツール IBM Image Construction and Composition Tool (ICCT) を紹介します。ICCT は無料でダウンロードすることができます (「参考文献」を参照)。

Dustin Amrhein, Technical Evangelist, IBM

Author photoDustin Amrhein は、WebSphere Application Server 開発チームのメンバーとして IBM に入社しました。この開発チームに在籍している間は、主に Web サービス・インフラストラクチャーと Web サービス・プログラミング・モデルに取り組んでいました。また、Java ランタイム用の RESTful なサービスのフレームワーク開発も行いました。現在の役割は、WebSphere Client Technical Professional です。


developerWorks
        プロフェッショナル著者レベル

Vanessa Grose, Advisory Software Engineer, IBM

Author photoVanessa は、IBM に入社して System i Java 仮想マシンの開発に携わった後、AIM (Application Integration Middleware) Customer Programs 組織の一員となりました。現在は、IBM Java 技術、WebSphere Application Server、および WebSphere CloudBurst Appliance を中心に、AIM ポートフォリオの製品に関する教育とトレーニングを担当し、顧客のフィードバックを収集する役割を担っています。彼女は最近、ミネソタ大学でコンピューター・サイエンスの理学士号を取得しました。



2012年 1月 20日 (初版 2011年 3月 22日)

自分のためでも、他人が使うためでも、ソフトウェア環境を構築して配布する仕事に携わっているとしたら、この仕事がいかに困難なものであるかは痛いほどわかるはずです。従来の方法では、その環境の要件を収集し、ソフトウェアをインストールし、それぞれのコンポーネントを構成して 1 つに統合した後、すべてが上手く行くよう祈るしかありません。このプロセスは時間に制約され、エラーが発生しやすく、正直なところ非常に苛立たしいものになりがちです。

基本的なソフトウェア環境をインストールして構成する作業そのものが競争上の優位になると考える人は多くはないでしょう。むしろ、アプリケーション開発などの生産的な仕事を行えるようにするために、基本的なソフトウェア環境をインストールおよび構成するのです。皆さんがこの作業の位置づけを理解しているのと同様に、ここ数年の間、多くの企業でもソフトウェア環境を配布する際の改善策が必要であることを認識するようになってきました。

この認識を踏まえ、多くの企業が環境の構築および配布に伴う従来からの課題を克服する手段として、仮想イメージを採用するようになっています。従来のインストール方法と比べると、仮想イメージには柔軟性が欠けるかもしれません。けれども、この柔軟性の不足を補うために、仮想イメージではインストール済み環境をフリーズドライし、ある程度の範囲で環境を構成できるようになっています。

これが何を意味するかと言うと、仮想イメージを使用すれば、環境のインストールおよび構成タスクを行うのは一度で済むということです。

さらに、仮想イメージによって、構成済みの環境を迅速に完成させることが可能になります。必要な作業は、仮想イメージを起動することだけです。すると、必要なコンポーネントがすでにインストールされたマシンを手に入れられます。

以上の明らかな利点により、仮想イメージの導入はますます広がりを見せています。しかしその一方で、仮想イメージの普及によって新たな問題が生じます。それは、仮想イメージを提供する方法に起因する問題です。

新たな手法を導入すると、新たな問題が発生します

構成済みの環境をわずか数分で立ち上げられるという利点は、仮想イメージの使用を魅力的な選択肢にしています。この魅力と、新しいイメージを作成するのも基本イメージからイメージを派生させるのも比較的簡単であるという事実を組み合わせてみてください。すると、数多くのイメージが作成されることになる理由がわかってきます。

このような無秩序な仮想イメージの増殖は、一般に「(仮想イメージの) スプロール」と呼ばれ、ソフトウェア環境の管理コストを瞬く間に増大させることになります。これは当然、望ましい結果ではありません。この意味で、企業はインベントリーにある仮想イメージの全体数を注意深く見守る必要があります。これは口で言うのは簡単ですが、実行に移すとなると、かなり難しいことです。

多くの場合、イメージの作成者は、ユーザーがデプロイするだけで作業を始められるように仮想イメージを作成します。そのために、作成者は一般に、ソフトウェア・コンポーネントと大量の構成を静的に取り込んだイメージをビルドします。これは一見したところ当たり前の手法のように思えますが、問題が生じる可能性があります。それは特に、取り込まれた構成が限られた使用状況に固有の構成である場合に言えることです。作成者が作成するイメージに、コンポーネントと特定の使用状況に固有の構成が含まれているとしたら、その特定のシナリオ以外にイメージを使用できる可能性が低くなってしまいます。

このような手法が、イメージを瞬く間に増殖させる (仮想イメージのスプロールの) 原因になります。図 1 では、ミドルウェア・アプリケーション環境の仮想イメージというコンテキストで、この問題が浮き彫りにされています。

図 1. 固有の構成が増加することによる増殖
固有の構成が増加することによる増殖

ミドルウェア・アプリケーション環境には各種のコンポーネントとそれぞれに関連付けられた構成が必要であるため、仮想イメージの問題を検討するにはもってこいの例です。図 1 に示されているように、ミドルウェア・アプリケーション環境には以下のコンポーネントが含まれます。

  • オペレーティング・システム
  • ミドルウェア・ソフトウェア
  • アプリケーション
  • ユーザー固有の構成

ユーザーまたは使用状況に固有の構成に至るまで、ありとあらゆるコンポーネントを組み込んだ仮想イメージをビルドするという手法を採ることは確かにできますが、そのような手法ではほぼ間違いなく、数多くのイメージを作成 (そして管理) する羽目になります。

一方、オペレーティング・システムだけが含まれるイメージをビルドすることも可能ですが、その場合、ユーザーが他のかなりの数のコンポーネントをインストールして構成しなければならないため、ユーザーがイメージを使用する価値が下がります。

最善の答えは、この 2 つの中間あたりにあります。アプリケーション・ミドルウェアのイメージをビルドする場合、その仮想イメージには、アプリケーション環境に必要なミドルウェア・ソフトウェア・コンポーネントのすべてが組み込まれるのが通常です。仮想イメージにユーザー固有のコンテンツが組み込まれていなければ、そのイメージによって数多くの状況をサポートできる可能性が高くなるため、仮想イメージのインベントリーを妥当なレベルに維持しやすくなります。

この手法は、仮想イメージの数を管理する上で役立つと同時に、価値の基準をユーザーに置くことができるものの、この手法ならではの問題があります。それは、ユーザー構成が仮想イメージに直接組み込まれないことから、仮想イメージの使いやすさが損なわれるという問題です。ユーザーはイメージを起動した後、一連の構成手順を実行してからでないと、その環境で作業をすることができません。ターゲット環境の複雑さによっては、構成手順にかなりの時間がかかる場合や、デプロイメント環境が違うと構成手順を再現するのが難しくなる場合もあります。このような問題は仮想イメージのユーザーを苛立たせ、仮想イメージが約束する価値提案を色あせたものにしてしまいます。

以上の説明からわかるように、有用で使いやすい仮想イメージをビルドしながらも、インベントリーを妥当なレベルに維持するのは簡単なことではありません。ただし、簡単ではないものの、不可能なことではありません。


仮想イメージをビルドするためのより望ましい方法

前述のとおり、仮想イメージを使用する上での第一の難題は、インベントリーを管理しやすいレベルに維持する一方でイメージのユーザーにかなりの価値を提供する、という難題です。この難題に取り組むには、仮想イメージのビルドに対して慎重な方法を採らなければなりません。そのためには、以下の基本的な質問に対して答を用意しなければなりません。

  • どのようなコンテンツを仮想イメージに直接インストールするのか?
  • 仮想イメージに直接インストールしない必須コンテンツ (ユーザー構成など) をどのように扱うのか?

イメージに直接インストールするコンテンツ

仮想イメージをビルドする際の最初のステップは、イメージに焼き付けるコンテンツを特定することです。これは必ずしも簡単なプロセスではありません。さらに、特定のコンテンツをイメージにインストールするかどうかについて、常に白黒はっきりとした答えがあるわけでもありません。

概して、以下のカテゴリーに分類されるコンテンツが、イメージに直接インストールするコンテンツの有力な候補となります。

サイズの大きなコンポーネント
オペレーティング・システムとその他、サイズがかなり大きいソフトウェアは、仮想イメージに直接インストールしてください。仮想イメージを起動してから、このようなコンポーネントをインストールするとなると、環境全体を提供するまでにかかる時間が長くなり、仮想イメージの利点の多くが台無しになってしまいます。
共通コンポーネント
すべてのソフトウェア環境ではないとしても、その多くに共通するコンポーネントを特定してください。例えば、アンチウィルス・ソフトウェアやモニタリング・エージェント、あるいはオフィス・ツールなどの共通するコンポーネントをイメージにインストールすれば、ユーザーの時間が節約されるだけでなく、ユーザーの環境が標準から逸脱したり、非準拠になったりする可能性も低くなります。
時間のかかる構成
実行するのにかなりの時間がかかる構成アクションが、イメージに直接含めるのにふさわしい候補となる場合も珍しくありません。構成アクションをイメージに含めることで、ユーザーはその作業を行わなくて済むようになるため、すぐにイメージを使用し始められるようになります。

上記の 3 つのカテゴリーに当てはまるコンテンツを仮想イメージに焼き付けることで、環境を提供するのが迅速化されること、そして構成の負担がユーザーから取り除かれることによる価値がもたらされます。

仮想イメージに直接インストールしないコンテンツの扱い: 理想的ではないソリューション

明らかにおわかりのように、上記の 3 つのカテゴリーは、仮想イメージ・ユーザーの要求の一部しか表していません。具体的に言うと、以下の点については対処されていません。

  • ユーザーがそれぞれの使用状況に応じた固有の構成を適用する必要があること。
  • 一部の構成 (例えば IP アドレス) は、それぞれのデプロイメントに応じて変わってくること。

上記のような構成は、イメージに静的に焼き付けるべきではないか、焼き付けるのは不可能であるかのどちらかです。だからと言って、このような構成を考慮しなくてもよいというわけではありません。これらの構成に対処するには、イメージの起動後に必要な構成ステップをユーザーに示すための説明あるいはスクリプトを提供するという方法がありますが、これは理想的なソリューションではありません。なぜなら、イメージをデプロイするユーザー側で、デプロイメント後のステップを手動で行わなければならないためです。

仮想イメージに直接インストールしないコンテンツの扱い: 動的仮想イメージを作成する

デプロイメント後の構成ステップをユーザーに実行させるよりも望ましい方法は、動的仮想イメージを作成することです。動的仮想イメージの基礎となる特殊な起動スクリプト一式を組み込み、これらのスクリプトに、イメージをデプロイするたびに必要となる動的構成アクティビティーを実行させます。動的構成アクティビティーには、IP アドレスの更新、以前にインストールされたソフトウェアでの構成アクションの実行、サイズの小さいコンテンツのインストールなど、さまざまなアクションを含めることができます。

イメージでは、これらのスクリプトを起動フレームワークの中に取り込まなければなりません。この起動フレームワークには以下の役割があります。

  • スクリプトが自動的に呼び出されることを確実にする。
  • ユーザー入力をスクリプトの実行に渡す手段を提供する。

図 2 に、上記で説明したイメージのビルド手法を図解します。

図 2. 有効なイメージ・ビルド手法
有効なイメージ・ビルド手法

図 2 に示されているように、イメージをビルドするには、基本ソフトウェア・コンテンツを仮想イメージにインストールするところから始めます。その後、起動フレームワーク (Open Virtualization Format をサポートするフレームワークなど) 内に取り込む動的構成スクリプトを提供します。

起動フレームワークは、スクリプトの呼び出しを自動化するとともに、ユーザーがデプロイ時に提供する入力のメカニズムを定義します。この慎重な手法で、静的コンテンツと動的構成のバランスを取ることにより、ユーザーのニーズをサポートするイメージを提供しながらも、仮想イメージのインベントリーを管理可能なレベルに維持できるようになります。


この手法を実装する前に

仮想イメージのビルド手法の概念を把握することと、その手法を実際に実装することはまったく別物です。この手法を実装するにはツールが必要であり、そのツールは少なくとも以下の質問に対する答えを出せるものでなければなりません。

  • サーバーやストレージなどの既存のエンタープライズ・リソースをどのように利用するのか?
  • ソフトウェア環境の構築に関して、組織内の通常の役割分担にどのように対処するのか?
  • どうしたらイメージのビルド時の起動タスクとデプロイ時の起動タスクを効果的に分離できるのか?

少なくともこれらの質問に対して答えを出せるツールを探しているのであれば、もうそれ以上探す必要はありません。今や IBM ICCT (Image Construction and Composition Tool) が、IBM Workload Deployer 3.1、IBM SmartCloud Provisioning 1.2、そして IBM SmartCloud Enterprise に組み込まれているからです。


IBM Image Construction and Composition Tool

IBM ICCT (Image Construction and Composition Tool) は、クラウド環境にデプロイする仮想イメージをビルドするためのツールです。このツールを Linux システムにインストールしてから 1 つまたは複数のクラウド (IBM Workload Deployer あるいは IBM SmartCloud Provisioning、IBM SmartCloud Enterprise など) に接続するか、直接 Vmware ESX に接続してください。ICCT は新しいイメージを作成するためのビルド環境として既存のクラウド・リソースと統合されます。お望みであれば、提供される IBM Image Construction and Composition Tool イメージのインスタンスを IBM SmartCloud Enterprise 上にデプロイすることで、IBM SmartCloud Enterprise 上でイメージをビルドすることもできます。

概要: イメージを作成する

ICCT を使用してイメージを作成するには、まずオペレーティング・システムから取り掛かります。バンドルと呼ばれるソフトウェア・コンテンツを使ってオペレーティング・システムをカスタマイズした上で、新しいイメージ・パッケージを生成します。

ICCT 内では、複数のユーザーがイメージのビルドに使用するためのコンテンツに貢献することができます。例えば、オペレーティング・システムのエキスパートが、企業の認定する標準動作環境を基にオペレーティング・システムの定義を作成し、ソフトウェア・スペシャリストがソフトウェア・コンテンツに必要なインストールおよび構成アクションをカプセル化したバンドル・パッケージを定義するなどです。そのため、イメージのビルド担当者が必要なオペレーティング・システムとソフトウェア・コンポーネントを組み合わせる際に、オペレーティング・システムやソフトウェア・インストールに関する詳細を把握している必要はありません。

ICCT はオペレーティング・システムの定義、ソフトウェア・バンドルの作成、そしてイメージのビルドというそれぞれのタスクを互いに独立させることで、組織における現在の役割とスキルをイメージ・ビルドの領域に簡単にマッピングすることができます。それは、以下のようなマッピングです。

  • オペレーティング・システムのスペシャリストは、オペレーティング・システム層に専念する。
  • ソフトウェア・スペシャリストは、規定のオペレーティング・システムをベースにコンポーネントを追加することに専念する。
  • イメージのビルド担当者は、エンタープライズ・クラウド内に新規デプロイメントを作成するために必要なソフトウェアと規定のオペレーティング・システムを組み合わせることに専念する。

概要: インストールおよび構成を管理する

ソフトウェアのインストールおよび構成タスクは、IBM ICCT 内で管理することができます。

ICCT で使用するための基本オペレーティング・システム・イメージを作成すると、ICCT がそのイメージに、ビルド時のアクションとデプロイ時の (構成) アクションの動的分離を可能にする起動フレームワークを組み込みます。

ICCT 内でソフトウェア・バンドルを定義するときには、インストール・タスクと構成タスクのそれぞれを、互いに依存させることなく指定します。インストール・タスクはイメージのビルド・プロセスで 1 回だけ実行され、構成タスクはイメージをデプロイするたびに毎回実行されます。インストール・タスクと構成タスクを切り分けることで、イメージ・カタログのサイズを減らして、イメージの管理を簡易化することができます。

次のセクションでは、イメージをビルドするために基本オペレーティング・システムを作成し、ソフトウェア・バンドルを定義し、最後にイメージ・パッケージを生成するまでのプロセスについて詳しく探ります。そして ICCT 内でのこの主要なワークフローによって、一貫性のあるカスタマイズされた仮想イメージをビルドすることが可能になり、インストール・タスクとユーザー構成タスクを管理しやすく分離できるようになる仕組みを説明します。


ICCT でカスタム・イメージをビルドする方法

図 3 に、ICCT によってサポートされる対話の概要を示します。

図 3. ICCT でイメージをビルドする際のフロー
ICCT でイメージをビルドする際のフロー

ICCT は、IBM Workload Deployer 3.1 あるいは IBM SmartCloud Provisioning 1.2 (ベータ版) で提供されているので、Linux 環境に ICCT をインストールしてください。IBM SmartCloud Enterprise 上で直接 ICCT のインスタンスを起動することもできます。イメージをビルドする際にはクラウド環境 (IBM Workload Deployer あるいは IBM SmartCloud Provisioning、IBM SmartCloud Enterprise) にアクセスします。ICCT は直接 VMware ESX を扱うこともできます。これらのリソース (クラウド・プロバイダー) が、オペレーティング・システムをインスタンス化し、カスタマイズしたバンドル・コンテンツをインストールするための環境を ICCT に提供します。

基本オペレーティング・システムを作成する

注: alphaWorks の Image Construction and Composition Tool は、VMware 環境または IBM Smart Business Development and Test on the IBM Cloud にデプロイする RedHat Linux イメージのビルドをサポートします。

イメージをビルドする際は常に、オペレーティング・システムから取り掛かります。VMware ESX イメージの場合には、組織のオペレーティング・システム要件に従った独自のカスタム・オペレーティング・システムをビルドする必要があります。ICCT では、基本オペレーティング・システムを作成する方法として、以下の 2 つのいずれかを指定することができます。

  1. ISO および Kickstart ファイルを使用する方法
  2. インストール済みオペレーティング・システムがすでに含まれる仮想マシンから作成する方法

図 3 のステップ 1 からステップ 3 には以下のフローが示されています。

  1. ISO と Kickstart ファイル、またはオペレーティング・システム仮想マシンを使用します。
  2. VM を作成し、OS をインストールします。
  3. 基本 OS イメージを取り込みます。

基本オペレーティング・システムのイメージ作成を ICCT の 1 つの領域内で一元管理することで、組織内の既存のスキルを利用して、企業の標準に基づく適切なオペレーティング・システム層を構築することができます。つまり、さまざまなデプロイ済み環境で、オペレーティング・システム・レベルでの一貫性が保証されるということです。

オペレーティング・システム・イメージには、コアとなるオペレーティング・システムのコンテンツおよび構成を定義するだけでなく、デプロイ時にオペレーティング・システムのカスタマイズを可能にする起動フレームワークも含まめる必要があります。それには、IP アドレスを割り当て、ユーザー・アカントを構成し、ネットワーク・インターフェースをセットアップするなどの作業も必要です。ICCT は、仮想イメージに含める起動フレームワークを提供します。

標準オペレーティング・システム構成をイメージとして体系化した後は、これを基本イメージとして、カスタム・ソフトウェア・バンドルをそこに追加していきます。

ソフトウェア・バンドルを定義する

ICCT 内では、イメージ内で使用できるソフトウェアがバンドルに記述されています。バンドルの仕様は、ソフトウェアの前提条件、そしてソフトウェアをインストール、構成、およびリセットするための各タスクを定義します。

バンドルを作成するには、そのバンドルに含まれるそれぞれのソフトウェアがどのように機能するかについての専門的な知識が必要となります。そのため、図 3 のステップ 4 (4. Create bundle (バンドルの作成)) に示されているように、この作業はソフトウェア・スペシャリストが行うのが通常です。

ソフトウェア・スペシャリストはバンドル内に、そのバンドルに含まれるソフトウェアの要件、インストール情報、構成タスク、およびリセット・アクションを定義することができます。仮想イメージに含める、サイズの大きいコンポーネントや共通コンポーネントは、すべてソフトウェア・バンドルとして定義するのが賢明です。ミドルウェア製品はいずれも、バンドルに含める有力な候補となります。これに該当するのは、IBM WebSphere Application Server Community Edition や IBM License Metric Tool Server、そしてセキュリティー・コンプライアンス・モニタリング・ソフトウェアやアンチウィルス・エージェントなどの共通ソフトウェア・パッケージなどです。

ICCT でバンドルを定義する際には、ユーザー・インターフェースが明示的にインストール・パラメーターと構成パラメーターを区別します。

インストール・パラメーター
バンドルのインストール・データには、バンドルを仮想イメージにインストールするときに実行する必要があるタスクが記述されています。インストール・タスクはイメージのビルド時に 1 回だけ行われ、このタスクによってインストールされたソフトウェアはイメージの恒久的なコンポーネントとなります。一般に、時間のかかるタスクや長時間実行されるタスクはインストール・タスクとして定義する必要があります。

典型的なインストール・タスクには、インストール・バイナリーをイメージにコピーするというタスクや、ソフトウェアのインストール・プログラムを実行するというタスクなどがあります。

バンドルのインストール引数は、パラメーター化してイメージのビルド・プロセス中に構成できる入力として、公開することができます。例えば、ソフトウェア・パッケージのインストール先をイメージのビルド時に構成できるようにする必要がある場合には、インストール先を示す引数を定義し、そのプロパティーの値をバンドルのインストール・スクリプトで使用します。パラメーター化されたインストール引数を使用すれば、インストール要件が変わっても、同じ 1 つのソフトウェア・バンドルでそれぞれのカスタム・イメージをビルドすることができます。

構成パラメーター
バンドル定義の構成セクションに指定するのは、バンドルのインストール済みソフトウェアをデプロイする際の構成オプションおよび起動スクリプトです。インストール・タスクはイメージのビルド時に実行されますが、ソフトウェア・バンドルの構成タスクはイメージをデプロイするたびに実行されます。

デプロイされたソフトウェアの構成パラメーターのなかに、イメージのデプロイ担当者がカスタマイズしなければならないパラメーターがある場合 (例えば管理パスワードやポート定義など)、バンドル定義のなかで、これらのパラメーターに構成可能であるというマークを付けることができます。

イメージのデプロイ時には、デプロイ担当者がこれらの構成パラメーターの値を指定することができます。すると、起動エンジン内でバンドルによって提供されたスクリプトは、指定されたパラメーターを使用してソフトウェアをカスタマイズすることができます。パラメーターと構成スクリプトを組み合わせて使用することで、カスタム構成をイメージに焼き付ける代わりに、デプロイ時にソフトウェアのインスタンス化されたプロファイルを定義することができます。

この動的な構成機能により、作成しなければならないカスタム・イメージの数が大幅に減り、その結果、仮想イメージ・ライブラリーの管理コストが劇的に削減されます。

ICCT 内で、バンドルはソフトウェアのビルド時のアクションとデプロイ時のタスクを取り込んで分離できる柔軟なメカニズムを提供します。ソフトウェア・スペシャリストの知識がバンドルに直接カプセル化されるので、そのソフトウェア・バンドルを使用するイメージのビルド担当者は、ソフトウェアのインストールおよび構成に関する専門知識を持っている必要はありません。ビルド担当者は、該当するオペレーティング・システムとソフトウェア・バンドルを選択して組み合わせるだけで、カスタマイズされた仮想イメージを作成することができます。

カスタム・イメージ・パッケージを生成する

ICCT は、IBM Workload Deployer 3.1 あるいは IBM SmartCloud Provisioning 1.2、VMware vSphere などを使用してデプロイメント用の OVA (Open Virtual Format Archive) イメージを生成します。さらに、IBM SmartCloud Enterprise パブリック・クラウドにも新しいイメージを作成します。

イメージのビルド担当者が新しいイメージ・パッケージを作成する際の一般的なステップは、以下のとおりです。

  1. 基本オペレーティング・システム・イメージを拡張します。
  2. ソフトウェア・バンドルを使用してイメージをカスタマイズします。
  3. イメージを指定のクラウド・プロバイダーの中で同期させます。
  4. イメージの構成を確認します。
  5. イメージを取り込んで、以降のデプロイメントで使用できるようにします。

上記のプロセスは、図 3 のステップ 5 からステップ 10 に該当します。オペレーティング・システムのスペシャリストとソフトウェア・スペシャリストの専門知識はすでにツール内に取り込まれているため、イメージのビルド担当者がコンポーネントの構成方法を詳しく調べる必要はありません。したがって、ビルド担当者は迅速かつ簡単にオペレーティング・システム・イメージとソフトウェア・バンドルを組み合わせることができます。

新しいイメージをビルドするには、まず、基本オペレーティング・システムの定義を選択し、そこにソフトウェア・バンドルを追加して拡張します (ステップ 5)。前述のとおり、ソフトウェア・バンドルにはパラメーター化されたインストール・データを含めることができます。そしてイメージを拡張する段階で、使用しているバンドルで構成可能なインストール・パラメーターをカスタマイズすることによって、ビルドするイメージの要件を満たすことができます。

イメージのオペレーティング・システムとバンドルの構成を保存したら、次はイメージを同期させる必要があります (ステップ 6)。イメージの同期化プロセスでは、ICCT がオペレーティング・システム・イメージをクラウド・プロバイダーにコピーし、新しい仮想マシンでオペレーティング・システムを起動します。そして、組み込まれたソフトウェア・バンドルのインストール・タスクを開始します。インストール・タスクが実行されるのは、この時だけです。ICCT はこの時点で構成タスクをイメージに組み込みますが、構成タスクはイメージがデプロイされるまでは実行されません。

同期化プロセスが完了した後は、仮想マシンにログインして、バンドルに定義したソフトウェアが正しくインストールされていることを確認するのが適切なプラクティスです。

同期化の完了後、新しいイメージを取り込みます (ステップ 7)。

  • IBM SmartCloud Provisioning あるいは IBM Workload Deployer、IBM SmartCloud Enterprise に直接接続している場合は、イメージはカタログ内にあり、新しいデプロイメントに使用することができます。
  • ローカル VMware ESX クラウド・プロバイダーを使用している場合は、ICCT から、取り込んだイメージを OVA パッケージとしてエクスポートします (図 3 のステップ 8)。この新しい OVA には、IBM Workload Deployer または VMware vSphere のいずれかにイメージをインポートするために必要なすべてのデータが含まれているため、イメージをプライベート・クラウドにデプロイできるようになっています。

ターゲットとするクラウド環境に関わらず、これらのイメージをインスタンス化する際には、イメージのソフトウェア・バンドルで構成可能なデータとしてマークを付けた構成データをどれでもカスタマイズすることができます。


まとめ

この記事では仮想イメージをビルドするための、より望ましい方法について検討しました。焦点を当てたのは、イメージ・インベントリーを管理しやすいレベルに維持すると同時に、多くのユーザーに (特に、イメージをどれだけ幅広く使用できるかという点で) 最大限の価値をもたらす方法です。私たちが提案した手法は、仮想イメージに直接インストールするべきコンテンツと、直接インストールするべきではないコンテンツの判断をすることから始まります。それに加え、仮想イメージにインストールするコンテンツを動的に構成する方法も紹介しました。突き詰めていくと、この記事で説明したのは、極めて再利用性の高いカスタム・クラウド・イメージをビルドする方法であり、ユーザー側で最小限の作業を行うことで最大限の価値をもたらすイメージをビルドする方法です。

そのソリューションとして提案したのが、Image Construction and Composition Tool です。有用かつ使いやすい仮想イメージを簡単なプロセスでビルドできるようにするこのツールによって、仮想イメージ・ライブラリーを制御された状態に保つことができます。また ICCT では、ビルドするイメージに、認定オペレーティング・システムやその他の必須コンテンツなどの、サイズが大きく複雑なコンテンツを直接焼き付けることができます。ICCT によってビルドされたイメージは、デプロイ時に柔軟にカスタマイズできる起動エンジンとなります。つまり、起動中に、イメージおよびそのソフトウェア・バンドルに定義されたオプションに基づき、環境に合わせてカスタマイズ・パラメーターを指定することができます。そのため、起動プロセス中に 1 つの仮想イメージがさまざまな形を取るようにすることが可能なため、単一のイメージでさまざまな使用シナリオに対応できるというわけです。

参考文献

学ぶために

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

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Cloud computing, WebSphere, Tivoli (service management)
ArticleID=647210
ArticleTitle=カスタム仮想クラウド・イメージをビルドするためのシステムを確立する
publish-date=01202012