Cloud Application Management for Platforms ( CAMP ) は、 Platform as a Service (PaaS) システムのコンテキストでアプリケーションを管理するための仕様です。CAMP は、高レベルの PaaS システムのニーズに対応するように設計されています。このシステムでは、消費者 (通常は開発者またはアプリケーション管理者) がアプリケーション成果物 (コード、データ、グラフィックなど) を提供し、これらの成果物をアプリケーションとして実現するために必要なプロバイダー提供のサービスを指定します。これらのサービスをサポートするために使用されるインフラストラクチャ (コンピューティング、ストレージ、およびネットワーク) の詳細は、PaaS システムのプロバイダーによって消費者には表示されません。
概要

CAMP では以下を定義します。
- アプリケーションを構成する成果物、それらの成果物を実行または利用するために必要なサービス、および成果物とそれらのサービスとの関係を記述するドメイン固有の言語。
- アプリケーションとその構成コンポーネント、およびそれらのコンポーネントによって使用されるサービス、さらに実行時のステータス情報、構成情報、および PaaS システムを記述するメタデータを表すリソース モデル。
- これらのリソースを操作し、それによって基盤となるアプリケーションの状態を変更するためのRESTfulプロトコル。
モチベーション
ほとんどの PaaS システムは、何らかの形のアプリケーション管理APIを提供します。これらの API は、アプリケーションをクラウドにアップロードしたり、アプリケーションの実行に使用するサービスを設定したり、アプリケーションを起動したり、アプリケーションの状態とパフォーマンスを監視したり、アプリケーションを停止したりするために使用されます。これらの API は通常、Web アプリケーションやコマンド ライン ツールの背後に隠れています。この種の API は「me too」テクノロジです。その存在は実用的な PaaS システムを提供するための必須の前提条件ですが、競合他社よりも優れた管理 API を提供することにはほとんど利点がありません。アプリケーション管理 API の強さだけを理由に PaaS オファリングを選択した人はいません。一方、すべての PaaS システムがカスタム アプリケーション管理 API を提供するという事実は、いくつかの問題を引き起こします。
- このような API を使用するために作成された監視システムや管理システム、継続的インテグレーションシステムなどは、顧客が PaaS システムを変更または追加したい場合、書き直す必要があります。これにより、PaaS プロバイダー間の切り替えコストが増加し、PaaS を使用する価値が低下します。
- PaaS 環境をターゲットとする統合開発環境は、個別にケースバイケースで対応する必要があります (たとえば、各 PaaS システムにカスタム コネクタを提供するなど)。これにより、初期の開発作業が増えるだけでなく、各コネクタを維持するための「技術的負債」も蓄積されます。
- アプリケーション管理 API の品質は差別化要因ではないため、管理 API の設計や調整に費やす時間は良い投資とは言えません。プラットフォーム プロバイダーは、基本的なコンセンサス API を実装することで、時間とリソースを節約できます。付加価値機能は、この基本 API の拡張機能として実装できます。
歴史
キャンプ1.0
CAMP 1.0 [1]は、CloudBees、Cloudsoft Corporation、Huawei、Oracle、Rackspace、Red Hat、Software AGの共同作業によって開発されました。[2] 2012年8月に公開されました。
キャンプ1.1
2012年8月、CAMP 1.0はOASIS標準を作成する目的でOASIS CAMP技術委員会に提出されました。この技術委員会はOASIS委員会仕様を作成しました。[3] CAMP TCは、その憲章に従って、OASIS標準として仕様を承認するようにOASISに依頼する前に、CAMP v1.1の相互運用可能な実装の証拠を2つ待っています。
CAMP 実装
キャンプ
OASIS CAMP 技術委員会の作業と並行して開発された nCAMP は、CAMP v1.1 仕様の概念実証実装です。nCAMP は、実用的な PaaS システムではなく、CAMP 仕様の概念と構成をテストするための手段として機能することを目的としていました。nCAMP は、Tomcat と MySQL を使用して、MySQL をデータベースとして使用できる Java サーブレット ベースの Web アプリケーションをサポートするシンプルなシステムを提供します。[4]
プロジェクト ソルム
Solum は、クラウド サービスの利用を容易にし、開発者のアプリケーション開発プロセスに統合できるように設計された OpenStack 関連の Stackforge プロジェクトです。Solum のリソース モデルとプラン スキーマは CAMP に基づいていますが、完全に CAMP に準拠しているわけではありません。ネイティブの Solum API に加えて、 追加の CAMP 準拠 API [5]を提供するための作業が現在進行中です。
アパッチブルックリン
Apache Brooklyn は、自律型ブループリントを通じてアプリケーションをモデリング、監視、管理するためのフレームワークです。Apache Brooklyn ブループリントは、CAMP v1.1 Public Review Draft 01 に準拠しています。
参考文献
- ^ プラットフォーム向けクラウド アプリケーション管理バージョン 1.0、2012 年 8 月
- ^ InfoQ、「CAMP 1.0 – PaaS アプリケーション管理用のオープン API」2012 年 8 月 31 日。
- ^ プラットフォーム向けクラウド アプリケーション管理バージョン 1.1、委員会仕様 01、2014 年 11 月 9 日。http://docs.oasis-open.org/camp/camp-spec/v1.1/cs01/camp-spec-v1.1-cs01.pdf
- ^ 「クラウド インフラストラクチャはどのように機能しますか?」2023 年 6 月 5 日閲覧。
- ^ CAMP 1.1 API サポート
外部リンク
- OASIS プラットフォーム向けクラウド アプリケーション管理 (CAMP) TC
- CAMP in 7 スライド: エピソード 2
- IPv4 クラウド VPS
