4.4. カートリッジ vs イメージ

OpenShift v3 より、イメージ が OpenShift v2 のカートリッジの概念に置き換わりました。

OpenShift v2 のカートリッジはアプリケーションのビルドにおける中心的な要素です。各カートリッジは、必要なライブラリー、ソースコード、ビルドメカニズム、接続ロジック、ルーティングロジックを事前定義済みの環境と共に提供し、アプリケーションの各種コンポーネントを実行していました。

ただし、カートリッジには欠点があります。カートリッジには、開発者のコンテンツとカートリッジのコンテンツの違いが明確でないことや、ユーザーにはアプリケーションの各ギアにあるホームディレクトリーの所有権がないことなどの不利な点がありました。また、カートリッジは大規模なバイナリーの配信メカニズムとして最適ではありませんでした。カートリッジ内から外部の依存関係を使用できましたが、これをあえて実行するとカプセル化の利点が活かすができません。

パッケージ化の観点では、イメージはカーリッジよりも多くのタスクを実行し、より優れたカプセル化機能や柔軟性を提供します。ただし、カートリッジには、イメージに含まれないビルド、デプロイ、ルーティングのロジックが含まれています。OpenShift v3 では、これらの追加ニーズは Source-to-Image (S2I) および テンプレートの設定 で対応しています。

依存関係

OpenShift v2 では、カートリッジの依存関係は、カートリッジマニフェストの Configure-Order または Requires で定義されていました。OpenShift v3 では、Pod が自らを事前に定義された状態にする宣言型のモデルを使用します。インストール時間の順序付けではなく、適用される明示的な依存関係がランタイム時に実行されます。

たとえば、開始前に別のサービスを利用可能な状態にしておく必要がある場合があります。このような依存関係チェックは、2 つのコンポーネントの作成時のみではなく常に適用できます。そのため、依存関係チェックをランタイムにプッシュすることで、システムを長期にわたって正常な状態に保つことができます。

コレクション

OpenShift v2 のカートリッジはギア内に共同で配置されますが、OpenShift v3 の イメージ は、 コンテナー と 1 対 1 でマッピングされます。 コンテナーは、共同配置のメカニズムとして Pod を使用します。

ソースコード

OpenShift v2 では、アプリケーションには 1 つ以上の Web フレームワークと 1 つの git リポジトリー必要でした。OpenShift v3 では、ソースからビルドするイメージを選択でき、そのソースは OpenShift 外にある場合もあります。ソースはイメージから切断されているので、イメージとソースの選択は異なる操作となります (ソースの設定はオプションです)。

Build

OpenShift v2 では、ビルドはアプリケーションギアで行われていました。そのため、リソースの制約によりスケーリングできないアプリケーションの場合にはダウンタイムが発生していました。v3 では、個別のコンテナーで ビルド が行われます。また OpenShift v2 のビルド結果では、rsync を使用してギアを同期していました。v3 では、ビルド結果はまずイミュータブルなイメージとして最初にコミットされ、内部レジストリーに公開されます。後で、そのイメージを使用してクラスター内の任意のノードで起動したり、将来の日付でロールバックしたりすることができます。

ルーティング

OpenShift v2 では、アプリケーションに拡張性を持たせるか、およびアプリケーションのルーティング層が高可用性 (HA) を確保するために有効にされるかどうかについて直接選択する必要がありました。OpenShift v3 では、単純にアプリケーションコンポーネントを 2 つ以上のレプリカにスケールアップすることで、 ルート を HA 対応のファーストクラスのオブジェクトとして使用することができます。アプリケーションを再作成したり、DNS エントリーを変更したりする必要はありません。

ルート自体はイメージから切断されています。以前のバージョンでは、カートリッジによりデフォルトのルートセットが定義され、アプリケーションにエイリアスを追加できました。OpenShift v3 では、テンプレートを使用してイメージに任意の数のルートを設定できます。これらのルートを使用すると、システムルートとユーザーエイリアスを区別することなく、公開するスキーム、ホスト、パスを任意に変更できます。