Translate

2013年6月24日月曜日

OpenShiftのアーキテクチャ概要を翻訳する

CloudFoundryだけでなく、そろそろOpenShiftも
なんぞやということくらいはわかっていないと
社会についていけなくなるかもしれない..


なので、アーキテクチャについてだけドキュメントを翻訳して
勉強してみた。


なお、原本は以下のサイトです。

OpenShift
Architecture Overview
https://www.openshift.com/wiki/architecture-overview


翻訳内容についてはat your own riskで参照下さい。


---------------

アーキテクチャ概要


OpenShift Origin


OpenShift Origin はアプリケーションの作成、配置、管理をクラウドの内部で可能にします。OpenShift Originは、ディスクスペース、CPUリソース、メモリ、ネットワーク接続、ApacheもしくはJBossサーバを提供します。開発されるアプリケーションのタイプによって、テンプレートファイルシステムレイアウトが提供されます（例えば、PHP、Python、Ruby/Rails）。またアプリケーションのために１つの制限されたDNSも管理します。

プラットフォーム概要






2つの基本機能単位、インターフェイスを提供するブローカ(Broker)と、アプリケーションフレームワークを提供するカートリッジ(Cartridges)に分類されます。

  • ブローカ(Broker)は、すべてのアプリケーション管理アクティビティのための単一の接続ポイントです。ブローカはユーザログイン、DNS、アプリケーションの状態、アプリケーションの一般的なオーケストレーションに責任を持ちます。顧客は直接ブローカへ接続詞ません；代わりにRESTベースAPI経由で、Webコンソール、CLIツール、もしくはJBossツールを使ってブローカとやりとりをおこないます。
  • カートリッジ(Cartridges)は、ユーザアプリケーションを実行するために必要な実際の機能を提供します。現在、JBoss、PHP、Rubyなどの多くの言語カートリッジがあり、同様にPostgres、MySQL、Mongoなどのような多くのDBカートリッジがあります。


システムリソースとアプリケーションコンテナ



プラットフォームにより提供されるシステムリソースとセキュリティコンテナはギア(Gears)とノード(Nodes)です。

  • ギア(Gears)：ギアは、１つ以上のカートリッジを実行するためのリソース制約のあるコンテナを提供します。カートリッジに対して、RAM容量や有効なディスク容量の制限があります。
  • ノード(Nodes)：リソース共有を有効にするために、複数のギアを単一の物理マシンもしくは仮想マシン上で実行します。このマシンをノードと呼びます。すべてのアプリケーションが同時に有効にはならないため、一般的にギアはノード上にオーバーアロケートされます。


アプリケーション

 

  • ドメイン(Domain)：ドメインはDNSに直接関係しているわけではない；代わりに、すべてのアプリケーションや定義されたユーザのために一意な名前空間を提供する。ドメイン名はアプリケーション名に追加され、最終的なアプリケーションURLを編成する。
  • アプリケーション名(Application Name)：アプリケーションの名称を識別する。アプリケーションへアクセスするための最終的なURLは、https://[アプリケーション名]-[ドメイン].rhcloud.com 形式となる。
  • エイリアス(Aliases)：ユーザはプラットフォームにてエイリアスを登録することでアプリケーションのDNS名を提供することができる。
  • アプリケーションの依存関係(Application Dependencies)：ユーザはカートリッジを特定してアプリケーション実行要求を行う。現在２つのタイプのカートリッジがある。
  • フレームワークカートリッジ(Framework Cartridges)は、Webページを提供する機能をもつ主なカートリッジである。すべてのアプリケーションは１つのフレームワークカートリッジを保有し無くてはならない。
  • エンベデッドカートリッジ(Embedded Cartridges)は、DBやDBウェブインターフェイスのような支援カートリッジである。多くのエンベデッドカートリッジは、単一のアプリケーションとして追加可能である。
  • アプリケーションGITリポジトリ(Application GIT Repository)：各アプリケーションは、１つのGITリポジトリを取得する。ユーザはリポジトリ上のコードを修正し、git pushを実行することで、コードをデプロイする。
注意：
近い将来、どちらのカートリッジを一緒にコロケートされそしてスケールされるべきかについての論述を支持して、エンベデッドvsフレームワークカートリッジは削除することになります。
アプリケーションとカートリッジ記述子についてのセクションを参照して下さい。


主なユーザとのやりとり


1. 単純なアプリケーション構築


このフローは単純なPHPアプリケーションの構築およびデプロイをおこなうケースを説明している。



2. Jenkinsを使ったアプリケーションのデプロイ


OpenShift OriginもまたすべてのアプリケーションのためにJenkinsベースのビルドワークフローを提供します。Jenkinsサーバは、ユーザギアの１つが使用する、分離したアプリケーションとして実行します。Jenkinsビルダエージェントもまた、SSH/REST APIを使ってブローカやビルドされたアプリケーションとやり取りを行う、分離したアプリケーションとして実行します。



4. ディスクリプタを使ったアプリケーションの記述


アプリケーションディスクリプタはアプリケーションビルドの宣言的手法の１つです。ディスクリプタは、name（名前）、version（バージョン）、depenmdencies（依存）などの属性を含んだYAMLファイルです。またそして、アプリケーションが要求されるアーキテクチャも含んでいます。ブローカ/コントローラはディスクリプタYAMLを使いアプリケーションの新規構築や変更を行うことができます、そしてディスクリプタ内のフィールド操作を多くのユーティリティREST APIが提供します。アプリケーションやカートリッジディスクリプタについては後続の章で詳細説明があります。





ディスクリプタからアプリケーションをビルドするために、ブローカはディスクリプタを解釈しアプリケーションのdependency(依存)をリゾルブします。それぞれのdependency(依存)はカートリッジディスクリプタに含まれているカートリッジによって満たされます。アプリケーションディスクリプタのように、カートリッジディスクリプタはコンポーネントやカートリッジに寄ってサポートされる機能を定義します。

アプリケーションやカートリッジディスクリプタを使用することで、ブローカは一緒にコンポーネントをグループ化することができ、またどのギアをインスタンス化するかなどを決めることができます。


論理ビュー



パッケージ構造


パッケージ依存関係とプラグイン選択に関する情報のために「パッケージ構造」を参照して下さい。

StickShift


StickShiftは、OpenShift OriginプラットフォームのコアAPIパートです。PaaSプラットフォームの作成やカートリッジのデプロイのために必要なすべての基本APIを提供します。３つのパートで構成しています。

  1. コントローラ(Controller)は、REST API、ビジネスロジック、PaaSプラットフォームの状態管理を含む Rails エンジン(プラグイン)である。またDNS管理、認証、データ/状態ストレージ、そしてブローカとノードの間のコミュニケーションのためのプラグインAPIの集合でもある。
  2. ノード(Node)は、ギアやアプリケーションコンポーネントのライフサイクルの管理に必要なAPIの基本的な集合を含む。
  3. 共通(Common)は、コントローラやノードコンポーネントが使用するデータ構造を含む。

Proxyポート




Proxyポートは、ロードバランシングや関連するアプリケーションギアに提供するために内部サービスを露出させることを許可する。

それぞれのギアは５つのProxyポートを割り当てることができます。これらはルータブルアドレスとして露出するので、関連するギアは分離されたノード上にあっても接続することが可能です。

Proxyポートはシステムサービスとして実行中のHAProxyにより有効化され、低水準TCP接続をproxyへ設定されます；Webロードバランシングサービスを提供するHAProxyの対置として。将来的にそれらは、アプリケーションディスクリプタによって記述されるTCP接続を提供する基礎メカニズムとなります。

Proxyポートはノード集合の外部から直接アクセスすることができません。



ギアファイルシステムレイアウト

 .                                              
 ├── git
 # ギア git リポジトリ。
 # Webフレームワークカートリッジにより初期設定される。
 │   └── [アプリケーション名].git
 |       |
 # ユーザによる変更を避けるためルートによって所有される
 # 唯一のフックディレクトリ。
 │       ├── hooks                           
 |       |   |                                  
 |       |   |                                  
 │       │   └── pre-receive
 # Post受信フックをビルドやデプロイに割り当てる
 │       └── ... その他のgitディレクトリ     
 └── [アプリケーション名]
 # Jenkinsが行うクローンやアプリケーションのビルドのための
 # CIディレクトリ
     ├── ci               
 # ノード再起動時のアプリケーションの開始・停止を行う
 # コントロールスクリプト。
     ├── kraman3a_ctl.sh
     ├── <カートリッジ名>
     │   └── <カートリッジ固有の設定> 
     ├── data                                   
     │   └── ... 短命データストレージ
     ├── run                                    
     │   └── ... 実行のためのPID ファイル
     ├── logs                                   
     │   └── ... 全カートリッジのログファイル
     ├── sessions                               
     │   └── ... アプリケーションセッション情報
     ├── tmp                                    
     │   └── ... アプリケーション一次データ
     ├── repo -> runtime/repo                   
     └── runtime                                
         └── repo
 # 自身を持たないPHPのようなカートリッジの依存管理のための
 # プラットフォームサポート
             ├── deplist.txt                       
             |                                  
             ├── ... デプロイ済みアプリケーションコード
             └── README

ディスクリプタ


アプリケーションディスクリプタ


この章では、ユーザが、依存関係定義やスケーリングアーキテクチャ、各アプリケーションへの接続を定義するために、どのようにしてアプリケーションディスクリプタを構築するかを説明します。

用語：

  • Name:アプリケーション名(必須)
  • Version:アプリケーションのバージョン(必須)
  • Requires:依存関係リスト。カートリッジ名か性能のどちらか。
  • Cartridge:性能を提供するためのコンポーネント動作のパッケージされた集合
  • Connections:各々通信する必要のある２つのコンポーネントを指定する(Eg:PHPは直接関係がないがお互い通信が必要)
  • Group Override:関連のないカートリッジを同じギア上にグループ化させるための定義に使用される。本質的にそれらは一緒にエンベデッドする。これらのコンポーネントは一緒にスケールする。
  • Gear:コンポーネントが動作可能なCPU単位、メモリ、ディスク容量

単純なディスクリプタ：

 Name: myapp
 Version: 1.0
 Requires: php-1.0, mysql, mongodb
 Connections:
   - php-1.0, mysql
   - php-1.0, mongodb
 Group override:
   - php-1.0, mysql
上記のディスクリプタは、アプリケーション名"myapp"が php-1.0、mysql、mongodbに依存している事を示しています。PHP、MySQKおよびPHP、MongoDBはお互いに通信が必要となります。MongoDBが自身のギア上で動作している間、PHPおよびMySQLは同一のギア上でエンベデッドカートリッジとして動作します。

カートリッジディスクリプタ


この章ではいかにしてパートナ/カートリッジ開発者がディスクリプタを使ってそれらのカートリッジの能力を定義するかについて説明します。システム内のそれらの視点はアプリケーション開発社と異なっており、それらはより先進的な機能を露出させます。

用語:

  • バージョン(Version)、ベンダ(Vendor)、ライセンス(License)：メタ情報フィールドはシステムが直接使用しない
  • 内部要求(Requires native)：内部/実行時固有 パッケージ依存関係(RPM)
  • 提供者(Providers)：カートリッジに寄って提供される能力リスト
  • プロファイル(Profile)：カートリッジは、同一区画のソフトウェアに異なるアーキテクチャを提供するために、プロファイル内にグループを作ることが可能である(例：MySQL はマスタ-マスタおよびマスタ-スレーブプロファイルを提供することができる)
  • パブリッシャ(Publishers)：接続エンドポイントのリストはコンポーネントから情報を獲得するためにインボーク可能なものをフックする（例：mysql カートリッジは、インボーク時JDBC接続文字列を提供する、JDBCエンドポイントを提供することができる）
  • サブスクライバ(SubScribers)：接続エンドポイントのリストは、コンポーネントへ情報を提供するためにインボーク可能なものをフックする（例：jbossカートリッジは、インボーク時やデータソースとして設定されたJDBC文字列で提供された時にJDBCエンドポイントをサブスクライブすることができる)
  • 接続タイプ(Connection types)：パブリッシャおよびサブスクライバは、どうやってお互いリンクするかを元にした接続タイプを定義する。Cloud-SDKは、いくつかのビルトインタイプを提供する(NET:TCP、NET:UNIX、FILESYSTEMなど)
  • グループ(Groups)：プロビジョニングを目的としたコンポーネントのグループ化。各グループは一意のギアタイプで提供される。グループ範囲内のすべてのコンポーネントは同一ギア集合に配置される
  • ComponentRef：どちらのコンポーネントがグループの一部であるかを定義するグループ下の１エントリ
  • 設定順序(Configure-Order)：カートリッジの中やその依存関係の中のコンポーネントに対して設定順序の定義が可能である
  • 開始順序(Start-Order)：カートリッジの中やその依存関係の中のコンポーネントに対して開始順序の定義が可能である

ディスクリプタの例：


 Name: mysql-server
 Version: 1.0
 Native-Requires: mysql-server
 Provides: mysql
 Profiles:
  simple:
    Components:
      master:
        Provides:
          jdbc-uri:
            Type: NET:TCP:JDBC
  master-master:
    ...

上記のディスクリプタは、カートリッジ名"mysql-server"でmysqlの能力を定義しています。mysql-server RPMのインストールや実行に依存しています。またシンプルな場合とマスタ-マスタの場合の２つのプロファイルを定義しています。シンプルプロファイルは、"NET;TCP:JDBC"タイプのパブリッシャを提供する"master"という名前の１つのコンポーネントを保持しています。

接続タイプ


それぞれの（パブリッシャとサブスクライバの）接続は１つの接続タイプを定義し無くてはなりません。このタイプは、提供・消費されるデータを示す１つの分離された文字列です。Cloud-SDKはその他新しいタイプを提供する既存タイプのサブクラスを保持しています。

  • NET:TCP - ホスト名、ポートを提供する
  • NET:UNIX - UNIXソケットへのパスを提供する
  • FILESYSTEM - ローカルシステムのリソースへのパスを提供する
  • FILESYSTEM:SHARED - クラスタファイルシステム上のリソースへのパスを提供する

コネクタ確立


コンポーネントの設定・開始・終了中、パブリッシャコネクはインボークされているものをフックして、それぞれのギア上の各コンポネント情報がサブスクライブ中のコネクタへパスされます。コンポネントのギア割り当て：あるアプリケーションがカートリッジを使用している場合、そのコンポーネントはいくつかのファクターに依存する同一もしくは異なったギアの集合へ配置されます：

  • コンポーネントが同一のカートリッジの一部であり、カートリッジディスクリプタが同一グループである要求を行う場合、コンポーネントは同一ギア上に配置される
  • NET:UNIX、FILESYSTEM、NET:TCP:INTERNALのいずれかのタイプでコンポーネント間の接続が確立される場合、コンポーネントは同一のギア集合上に配置される
  • あるグループ内のエントリが、カートリッジ/アプリケーションエィスクリプタがコロケートされる要求を行うフィールドをオーバライドする場合、コンポーネントは同一のギア集合上に配置される

アプリケーション/カートリッジディスクリプタのランタイムレゾリューション


この章ではどのようにしてCloud-SDKがアプリケーションや依存関係やギアへの割り当てを組み合わせるかを説明します。

用語(ブローカ上の実行時の状態ストレージ)：実行時階層は、アプリケーションディスクリプタやカートリッジディスクリプタから情報を使用する推敲フェーズ中に構築されます。

  • コンポーネントインスタンス - コンポーネントインスタンスは、カートリッジ/アプリケーションディスクリプタ内に定義されたコンポーネントごとに生成される。コンポーネントインスタンスは、カートリッジ数、プロファイル、コンポーネント名を保持する
  • グループインスタンス - コンポーネントインスタンスと類似して、グループインスタンスは、カートリッジ/アプリケーションディスクリプタ内に定義されたコンポーネントごとに生成される。その結果として起こる、元のカートリッジやプロファイルのトラックを保持するカートリッジインスタンスやグループの一部であるギアのトラックもマタ保持する。グループ範囲内のすべてのギアは同一のコンポーネント集合を実行している
  • ギア-

用語（ノード上の実行モデル）：

  • ApplicationContainer：Cloud-SDKのノードサイド上のギアをあらわす
  • UnixUser：Cloud-SDKのノードサイド上のUNIXユーザをあらわす

ディスクリプタの推敲


ディスクリプタの推敲には２つの基本ステップがあります。効果があるのであれば、これらのステップは組み合わせることもあります。

  • すべての依存関係を解決しコンポーネントインスタンスやグループインスタンスの実行時構造を構築する
  • 通信やグルーピングのオーバライドを元にしてグループを組み合わせる

2012年4月27日(金) 10:00 matwoodが更新
投稿者 日付:

0 件のコメント:

コメントを投稿

登録: コメントの投稿 (Atom)

ClaudeをOpenAI O1のように思考させるDifyサンプルを試す

 Difyの「探索」タブにはさまざまなサンプルが載っており、その１つに「Thinking Claude (OpenAI O1 Alternative)」というものがある。   このサンプルがどういうものか、未だに自分でも解けない以下の問題をためしに聞いてみることにした。 『人類の...