プラグインを使って新しいアプリケーションを IBM PureSystems にデプロイする: 第 2 回

実在の SugarCRM ソリューションの有効化プロジェクトから学んだ教訓

IBM PureSystems はアプリケーション、サービス、ハードウェア、さらには (ベスト・プラクティス・パターンという形で) 専門家の高度な知見までもまとめて提供する、エンタープライズ・レベルのエキスパート・インテグレーテッド・クラウド・システムです。IBM PureSystems を導入すると、クラウド・コンピューティングが新しいレベルへと引き上げられます。IBM PureSystems を利用するようにアプリケーションを準備する 1 つの方法は、このシステムとアプリケーションとの間を橋渡しするプラグインを作成することです。連載の第 1 回では、SugarCRM を IBM PureSystems 上で実行可能にするために行った開発作業について説明しました。今回の記事では、この作業から学んだ教訓を取り上げます。

Chin Huang, Cloud Solutions Architect, IBM

Chin Huang は、IT およびソフトウェア・アーキテクチャーを専門とするクラウド・ソリューション・アーキテクトです。IaaS プラットフォーム、SaaS インテグレーション、アナリティクス・クラウド、Web サービス、IWD プラグインを含む拡張ソリューションの開発で専門的経験を積んでいる彼は、認定クラウド・コンピューティング・ソリューション・アドバイザーであり、10 以上の技術雑誌で著作活動を行っています。彼は、カリフォルニア州シリコン・バレー在住です。



Ton Ngo (ton@us.ibm.com), Cloud Solutions Architect, IBM

author photoTon Ngo は、カリフォルニア州サンノゼにある IBM Silicon Valley Lab に勤務するクラウド・ソリューション・アーキテクト兼シニア開発者です。最近では、シンガポールの南洋理工大学のハイパフォーマンス・コンピューティング・クラウド、そしてカナダ・ロイヤル銀行のテストおよび開発クラウドのアーキテクトを務めました。その前は、IBM T.J. Watson Research Center と Almaden Research Center での計 17 年間の研究者としての経歴を持ち、さまざまなテーマの研究論文を発表しています。



2012年 6月 07日

この連載の第 1 回では、IBM Cloud 研究所チームの専門家たちが、独立系サービス・ベンダー (ISV) アプリケーションである SugarCRM を IBM PureSystems 上で実行可能にするために行った開発作業について説明しました。SugarCRM は LAMP (Linux、Apache、MySQL、PHP) スタックを必要とする PHP アプリケーションですが、LAMP はそのままの IBM PureSystems ではサポートされません。そのため、チームは新しいパターン・タイプと、Linux および IBM AIX のベース・イメージを基にアプリケーションのモデル化、デプロイメント、操作をサポートする一連のプラグインを開発しました。今回の記事では、このプロジェクトから学んだ教訓を取り上げます。

この記事を読む前に第 1 回を読んでおくと参考になりますが、必須ではありません。

既存のサード・パーティー・アプリケーションである SugarCRM 用のプラグインを開発する中で学んだ教訓は、以下のトピックにまとめることができます。

  • 複数のプラットフォームのサポート
  • MySQL および DB2 の管理
  • スクリプトの開発
  • プラグインのデバッグ
  • ライフサイクル・スクリプトの実行
  • 削除不可能なプラグインの削除
  • 個々のプラグインのインポートとパッケージ化されたプラグインのインポート
  • バージョンを利用することによる開発の迅速化
  • 大容量バイナリーの処理
  • ベース・イメージの拡張

複数のプラットフォームのサポート

IBM PureSystems プラグインは、基本的にプラットフォームに依存しません。プラグインの開発者は、プラグインおよびアプリケーションのライフサイクルにおけるさまざまなフェーズで複数のプラットフォームをサポートするように、実行計画を作成しなければなりません。そうしなければ、進行中の開発、保守、デバッグなどの作業がたちまちのうちに困難を極めてきます。

私たちのプロジェクトでは、以下の事項が特に重要となります。

  • プラットフォームのサポートおよび要件の宣言
  • 複数のプラットフォームに対応したファイルおよびスクリプトの編成
  • 複数のプラットフォームに対応したプラグインを実現するために必要なファイルの取り込み
  • プラットフォームに依存しないスクリプトとプラットフォーム固有のスクリプトの作成
  • サポートされるプラットフォームとサポートされないプラットフォームの管理

ここからは、以上の分野のそれぞれについて詳しく検討します。

プラットフォームのサポートおよび要件の宣言

プラグイン構成ファイル config.json には、パッケージ・インスタンスごとの requires セクションがあります。1 つのプラグインが複数のプラットフォームを同じファイル・セットでサポートするとしたら、プラットフォームを宣言する必要はありません。

一方、私たちのプロジェクトのように、Linux と AIX のファイルおよびスクリプトに大きな違いがある場合には、メモリーや CPU などの他の属性に加え、arch 節を使用することで、ある特定のプラットフォームをサポートするようにパッケージの定義が限定されていることを示してください。最終的な結果を見ればわかるように、私たちのパッケージには、それぞれに個別のシステム要件およびパーツを持つ 2 つのパッケージ定義があります。

複数のプラットフォームに対応したファイルおよびスクリプトの編成

プラグイン内のフォルダー構造は、パッケージ定義と密接に関係します。保守を容易にするためには、常に、複数のプラットフォームに同じファイルとスクリプトのセットを使用することを検討してください。第 1 回の「設計と開発」で説明しているように、このプロジェクトでは、ディレクトリー名を見ればどのプラットフォームであるかがわかるようにしました。

複数のプラットフォームに対応したプラグインを実現するために必要なファイルの取り込み

プラグイン構成のユーザー・インターフェースは、プラグインの config_meta.json ファイルに定義されます。宣言型の手法は、ユーザー・インターフェースの作成を容易にしますが、要件の異なる複数のプラットフォームをサポートするための柔軟性に関しては制約があります。

第 1 回の「ソリューションのパッケージ化」に記載されている Linux 用のファイル・リストと、それよりも遥かに長い AIX 用のファイル・リストを基に私たちが決定したのは、各機能プラグインに対して事前定義されたフォルダー構造にすべての前提条件ファイルを圧縮してパッケージ化した、1 つのファイルを共通の入力として取ることです。この設計では、プラグインは Linux と AIX の両方をサポートしますが、クラウド管理者はターゲット・プラットフォームに最低限必要なファイルだけを収集することができます。

プラットフォームに依存しないスクリプトとプラットフォーム固有のスクリプトの作成

Linux プラットフォームと AIX プラットフォームには可能な限り同じスクリプトのセットを作成するというのが原則ですが、私たちのプロジェクトでは PHP を稼働させるプロセスが根本的に異なっていることから、最終的に 2 つのセットを作成することになりました。

それでもなお、私たちはコマンドおよびスクリプトに関するプラットフォームの制約を知ることの重要性を学びました。例えば AIX では、シェル・スクリプトの先頭行は #!/bin/bash ではなく、#!/bin/sh または #!/bin/ksh でなければなりません。また、tar コマンドには -z オプションがないため、tar の前には gunzip を使用する必要があります。

サポートされるプラットフォームとサポートされないプラットフォームの管理

当初、私たちがクラウド・デプロイメントのターゲット・プラットフォームとしたのは System p でした。けれども、事業計画上およびスケジュール上のさまざまな理由から、System x もサポートしなければならないことが判明しました。

仮想アプリケーション・パターンはプラットフォームに依存しません。したがって、複数のプラットフォームをサポートしなければならないとしても、モデル化の側面には影響を与えませんが、この要件はプラグイン実装には影響します。なぜなら、プラグイン実装ではすべてのプラットフォームを完全にサポートしなければならないためです。

私たちのプロジェクトの場合、リソースが限られていたことから、サポート・マトリクスを完全に網羅することは不可能でした。この制約のため、サポートされていないプラットフォームでパターンをデプロイできなかった場合に、予期せぬユーザー・エクスペリエンスとなるリスクが生じます。こうした状況に対する次善策として、私たちは現在、サポートされるプラットフォームに関連する名前を付けたテンプレート (例えば、「SugarCRM with DB2 on AIX」) を提供しています。


MySQL および DB2 の管理

MySQL と DB2 は、技術的には SugarCRM アプリケーションのバックエンド・データベースという同じ役割を果たします。私たちは開発期間を短縮するために、同じような Velocity テンプレートを使用して MySQL と DB2 をモデル化し、変換しました。その一方、この 2 つのソフトウェアそれぞれを所有する提供元がどこであるかが、このソリューションでサポートするトポロジーおよび実装に大きく影響しています。DB2 は IBM が提供していることから、当然、このソリューションは DB2 プラグインをそのまま統合できるように設計されています。これについては、第 1 回の「既存のプラグインを再利用する」で説明しています。

対照的に、既存の MySQL のサポートには疎結合の手法を適用しています。


スクリプトの開発

SugarCRM に必要なソフトウェア・スタックをベース・イメージにインストールする際にわかったことは、ベース・イメージには足りないパッケージ (RPM) が多数あることです。したがって、足りない RPM については、プラグインに組み込んでインストールされるようにしなければなりません。

ソリューションの 1 つとして考えられるのは、アクティベーションの際に、自動的に依存関係を満足させて、不足しているパッケージはインストールするサービスを提供することです。この場合、プラグインの実装は単純に前提条件パッケージをリストアップするだけでよく、これらのパッケージを処理する必要はありません。

私たちが遭遇したエラーは、2 つのロールの間での競合状態に関係するものです (競合状態は、プロセスの出力または結果が、他のイベントのシーケンスまたはタイミングに予想外に大きく依存している場合に発生します)。重要な点は、2 つの異なるロールそれぞれのライフサイクル・スクリプトが並行して呼び出されることです。したがって、ライフサイクル・スクリプトで共有リソースを管理する際には競合が発生しないように注意しなければなりません。

一例を挙げると、私たちはあるロールのスクリプトが Apache を起動中に、別のロールのスクリプトが Apache を停止していることを発見しました。この競合により、Apache が正常に動作しないという予期せぬ動作を招く結果となっていたわけです。共有されるサービスまたはリソースを識別して、これらの共有サービスおよび共有リソースを適切に管理するコードを設計する必要があります。


プラグインのデバッグ

シェル・スクリプトを開発するなかで気付いたことは、Eclipse でスクリプトを編集し、プラグインをビルドし、IBM PureSystems でプラグインを削除し、それから再デプロイするまでのサイクルをひと通り終えるには、あまりにも時間がかかることです。さらに、プラグインを使用する VM とパターンにしても、削除してから作成し直さなければなりません。

実際の開発作業では、スクリプトの開発を迅速化する PDK (Plugin Development Kit) のデバッグ・サポートを利用しました。このサポートを利用するために、必要な成果物と基本スクリプト・ファイルのすべてをプラグインに追加し、その上でデバッグ・コンポーネントと一緒にパターンをデプロイして 1 つの環境を作成しました。この環境では、ストア・ハウス内に成果物を格納し、アクティベーション・ディレクトリー内に JSON ファイルを格納します。私たちはこの環境で VM にアクセスしてスクリプトを個別に呼び出し、追加の開発およびデバッグ作業を行いました。そして、デバッグを終えたスクリプトは Eclipse プロジェクトにコピーしました。


ライフサイクル・スクリプトの実行

Python によるライフサイクル・スクリプトを開発するにあたって、開発者が細心の注意を払わなければならないのは、各スクリプトの実行をトリガーするライフサイクル・イベントです。スクリプトの中には、VM の存続期間全体を通して一度しか実行されないものもあれば、さまざまなライフサイクル・イベントで実行されるものもあります。

例えば、install.py は初期化の時点で一度だけ実行されますが、configure.py、start.py、および stop.py は VM が再起動される際にも毎回呼び出されます。

私たちのプロジェクトでは、Apache、PHP、およびデータベースのすべてが適切に構成された後に、データベース・リンク・プラグインの changed.py スクリプト内で実行される SugarCRM のインストールに関する特定の要件がありました。それは、SugarCRM コンテンツをセットアップして構成するために、このインストール・スクリプトを一度だけ実行するという要件です。VM の再起動時に changed.py が呼び出されるたびに、インストール・スクリプトが実行されるようであってはなりません。

Python コード内で role 属性を指定することで、インストール状況を示すことができます。インストールが繰り返し実行されていないことを確認するには、changed.py で、インストールの完了時に SugarCRM によって生成された永続ファイルの有無を調べます。

ライフサイクル・スクリプトについての詳細は、IBM Workload Deployer インフォメーション・センターおよび「Plug-in development guide」を参照してください。


削除不可能なプラグインの削除

開発中に、IBM PureSystems でプラグインを削除できない状況には何度も直面しました。原因は、プラグインの要素のなかに、まだ使用中のものがあったためです。エラー・メッセージが通知する内容は、プラグインが使用中であるというだけで、どこで、どのように使用されているかについての情報は提供されません。けれども私たちは、プラグインに関連するデプロイ済みアプリケーション・インスタンス、アプリケーション・パターン、およびアプリケーション・テンプレートを完全にクリーンアップすることで、通常はこのエラーを解消できることを学びました。


個々のプラグインのインポートとパッケージ化されたプラグインのインポート

最終的にはすべてのプラグインをパターン・タイプにパッケージ化しましたが、開発中には個々のプラグインを IBM PureSystems にインポートするほうが、より効率的で時機を得ていることを学びました。ただし、個々のプラグインを構成して使用できるようにするためには、プライマリー・パターン・タイプを別途インポートしなければならないことに変わりはありません。

この遅延バインディング・メカニズムを使用することで、誰もがパターン・タイプや他のプラグインに影響を及ぼすことなく、1 つのプラグインだけを変更してデバッグすることが可能になります。さらに、プラグインのなかにはサイズの大きいファイル・セットを伴い、再度インポートして再び使用できるようにするにはあまりにも時間がかかるものもあるため、このメカニズムによる開発サイクルの期間短縮はなおさら有効です。

そうは言っても、IBM PureSystems でプライマリー・パターン・タイプが削除されると、個々にインポートしたプラグインを構成することも、削除することもできなくなるという事態に陥ることも確かです。こうした事態は、ある開発者がパターン・タイプを更新している最中に、別の開発者がプラグインを削除しようとした場合に起こり得ます。プライマリー・パターン・タイプが戻された後は、問題の発生したプラグインを完全に管理できるようになります。プライマリー・パターン・タイプにパッケージ化されたプラグインの場合には、常にパターン・タイプとセットで移動されるため、このような問題はありません。

私たちは IBM PureSystems 製品チームに、個別にインポートされた従属プラグインが 1 つもない場合に限り、パターン・タイプを削除できるようにすることを提言しました。この機能は、今後のリリースで実現されるはずです。


バージョンを利用することによる開発の迅速化

各パターン・タイプには、major.minor 形式のバージョンがあります。開発中に、パターン・タイプの複数のバージョンをデプロイして比較したいと思ったこと、あるいは単にパターン・タイプのクリーンアップ・サイクルを繰り返すのを避けようとしたことは、一度だけではありません。私たちは、パターン・タイプを作成してインストールするには、別のメジャー・バージョンを使用したほうが好都合であるという結論に辿り着きました。

パターン・タイプにパッケージ化されたプラグインにも新しいメジャー・バージョンが必要です。これらのプラグインは、新しいパターン・タイプを参照しなければなりません。例えば、現在インストールされているパターン・タイプのバージョンが 1.0.0.1 であり、新しいパターン・タイプのバージョンが 2.0.0.1 だとすると、そこにパッケージ化されているプラグインは、config.json で以下のサンプル・セグメントのように構成する必要があります。

	"name": "sugarcrm",
	"version": "2.0.0.2",
	"patterntypes": {
	"primary": {
	"sugarcrm": "2.0"
	}   
	},

この手法により、新規パターン・タイプの実装を簡単に検証できるだけでなく、複数の開発者が同じ IBM PureSystems 環境を共有できるようにもなります。


サイズの大きいバイナリー・ファイルの処理

前に説明したライセンスに関する考慮事項により、いくつかのソフトウェアについては、プラグインとは別にパッケージ化して、プラグインのデプロイ時にアップロードする必要があります。通常、この作業を行うのは一度だけです。けれども、速度の遅いネットワークを使用している場合をはじめ、プラグインの開発中にサイズの大きい 500MB 規模のバイナリー・ファイルを繰り返しアップロードすることはできない場合もあります。

プラグイン開発チームが用いた手法は、バイナリー・ファイルをプラグインとは別にロードできるように改変したビルド・プロセスを使用するというものです。この手法は、内部の開発環境で使用することができます。現在、プラグイン開発チームはこのビルド・プロセスをすべてのプラグイン開発者が使用できるように取り組んでいるところです。


ベース・イメージの拡張

アプリケーションの前提条件ソフトウェア一式を提供するために検討されることの多いトレード・オフは、ソフトウェアをベース・イメージにインストールするか、あるいはベース・イメージに統合するかどうかです。IBM PureSystems ではユーザーがベース・イメージを拡張できるようになっているため、私たちは SugarCRM に必要な RPM を使用して新規のベース・イメージを作成することを検討しました。このようにすれば、プラグインがベース・イメージでの変更から隔離されるため、初期開発作業だけでなく、将来的な保守作業も単純化されます。

けれども、このようにカスタマイズされたベース・イメージがすべてのパターンの共通ベース・イメージとなることから、この手法が実際に上手く行くかどうかは定かではありません。ベース・イメージを (おそらく ICON などのイメージ・ビルド・ツールを併用して) 柔軟に関連付けることができれば、プラグインの設計に新しい可能性が広がると思いますが、一般的に言って、ユーザーにとっては 1 つのベース・イメージを使用するほうが簡単なので、この機能の追加には慎重な検討が必要です。


まとめ

第 1 回と今回の記事にわたり、既存の SugarCRM ソリューションを IBM PureSystems 上で実行可能にしてデプロイするためのプラグインを作成する上で、私たちチームがテンプレートとして用いた設計時の考慮事項を具体的に説明しました。また、私たちが行った開発作業をひと通り説明するとともに、このプロジェクトから学んだ教訓について詳しく説明しました。

この実際の経験が、皆さんが既存のアプリケーション用の IBM PureSystems プラグインを作成する際の作業を大幅に楽にする結果となることを願っています。

SugarCRM ソリューションの使用ケースのテストに成功した後、私たちはこのソリューションが「IBM PureSystems 対応」であると宣言しました。このプロジェクトは、複雑なプラグインを開発するにあたっての貴重な経験をもたらしてくれただけでなく、以下に挙げる意義深い結果をもたらしてくれたと考えています。

  • IBM PureSystems で非標準のソフトウェア・スタックをベースに最初のアプリケーション・パターンを実現しました。これにより、有力な ISV はソフトウェアを IBM PureSystems カタログの一部として提供できるようになり、IBM PureSystems と SugarCRM の両方の成功に寄与するはずです。
  • IBM PureSystems は、用意されている既製のアプリケーション・パターンだけに制限されていないことを明らかに実証しました。新規プラグインを開発することにより、ユーザーや ISV の新しいアプリケーションを IBM PureSystems に統合し、IBM PureSystems の能力を活かすことができます。
  • IBM PureSystems でのプラグイン開発のサポートを厳密に実践しました。アプリケーション・パターンのカタログを充実させるためには、プラグインの開発が強固にサポートされていなければなりません。私たちが現行の IBM ソフトウェアが対応しているのとは異なるシナリオに応じたプラグイン・フレームワークを公開したことによって、IBM PureSystems チームは改善の必要がある領域を特定することができました。その改善の取り組みは、今後の開発に役立つであろう数々の新機能を生み出しています。

IBM PureSystems は、ベースとなるインフラストラクチャーを気にすることなく、ユーザーがアプリケーション・パターンに専念できるようにすることで、クラウドでの生産性を大幅に向上させる可能性をもたらします。新しいプラグインが増えて、ユーザーが豊富な選択肢のなかからアプリケーション・パターンを選択できるようになることによって、IBM PureSystems の成功が確実になるだろうと、私たちは考えています。

謝辞

このプロジェクトに多大な支援を提供してくださった方々に感謝の意を表します。

  • IBM Cloud 研究所チームおよび HiPODS チームの Willy Chiu 氏、Larry Hsiung 氏、Thomas Truong 氏、Jeffrey Coveyduc 氏、Kai Young 氏、Nauman Fakhar 氏、Chris Kiernan 氏、Raymond Wong 氏
  • IBM Workload Deployer 開発チームの Steve Ims 氏、Lin Sun、Ted Kirby 氏
  • IBM Database as a Service 開発チームの Ning Wang 氏、Qi Rong Wang 氏
  • IBM Innovation Center チームの Nasser Momtaheni 氏、Joseph Peterson 氏、Rodney Johnson 氏
  • SugarCRM の Stas Malyshev 氏

参考文献

学ぶために

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

  • IBM SmarterCloud Enterprise に用意された製品イメージを調べてください。

議論するために

コメント

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, Information Management
ArticleID=819306
ArticleTitle=プラグインを使って新しいアプリケーションを IBM PureSystems にデプロイする: 第 2 回
publish-date=06072012