![閉じる [x]](http://dw1.s81c.com/i/c.gif){kind=small}
この連載の第 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 は、技術的には 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
PureSystems の詳細を学んでください。
- developerWorks で IBM
PureSystems のリソースを見つけてください。
- IBM Cloud でのタスクの実行方法についての詳細は、以下のリソースにアクセスしてください。
- 「Windows インスタンスとの間でのファイルのアップロードとダウンロード」
- 「Windows Server 2008 R2 に IIS Web サーバーをインストールする」
- 「Linux のコマンド・ラインを使用して IBM Cloud にインスタンスを作成する」
- 「Windows のコマンド・ラインを使用して IBM Cloud にインスタンスを作成する」
- 「IBM Cloud を利用して企業のネットワークを拡張する」
- 「IBM Cloud での高可用性アプリケーション」
- 「カスタム・インスタンスのクラウド・イメージをオンザフライでパラメーター化する」
- 「Windows-targeted approaches to IBM Cloud provisioning」
- 「Rapid Deployment Service を使用して製品をデプロイする」
- 「Integrate your authentication policy using a proxy」
- 「Linux Logical Volume Manager を構成する」
- 「複雑なトポロジーをデプロイする: IBM Cloud でデプロイメント・ユーティリティー･ツールを使用する」
- 「別々の VLAN にまたがる: パブリック VLAN とプライベート VLAN にまたがるインスタンスをプロビジョニングし、構成する」
- 「Android 機器からセキュアにアクセスする」
- 「IBM SmartCloud Enterprise のデータを復旧する」
- 「クラウドの仮想マシン・インスタンスをセキュアにする」
- developerWorks
のクラウド開発者向けリソースで、クラウド開発プロジェクトを作成しているアプリケーションおよびサービス開発者たちの知識と経験を調べて共有してください。
- IBM SmarterCloud
Enterprise にアクセスする方法を調べてください。SmarterCloud での開発は、IBM PureSystems
用の開発を実践する最良の方法です。
製品や技術を入手するために
- IBM SmarterCloud Enterprise
に用意された製品イメージを調べてください。
議論するために
- developerWorks
のクラウド・コンピューティング・グループの一員になってください。
- developerWorks でクラウドに関する優れたブログのすべてを読んでください。
- 専門家のネットワークであるとともに、互いにつながりを持ち、共有、協力するためのコミュニティー・ツールが集められている
developerWorks
コミュニティーに参加してください。
