第4章 OpenShift Enterprise 2 との比較

OpenShift Container Platform 3 は OpenShift バージョン 3 (v3) のアーキテクチャーをベースにしており、OpenShift バージョン 2 (v2) とは非常に異なる製品です。OpenShift v2 と同じ用語が数多く v3 でも使用されており、同じ機能が実行されますが、異なる用語が使用される場合もあり、背景で実行される内容は非常に異なる場合がありますが、OpenShift 自体は依然としてアプリケーションプラットフォームとして機能します。

このトピックでは、バージョンの違いを詳しく説明し、OpenShift のユーザーの OpenShift v2 から OpenShift v3 への移行を支援します。

ギア vs コンテナー

ギアは OpenShift v2 のコアコンポーネントです。カーネルの namespace、cGroups および SELinux などのテクノロジーで、スケーラビリティーが高く、セキュアなコンテナーアプリケーションプラットフォームを OpenShift ユーザーに提供します。ギア自体はコンテナーテクノロジーの 1 つの形態です。

OpenShift v3 は、ギアのアイデアを次のレベルに進化させ、v2 コンテナーテクノロジーの進化したバージョンとして Docker を使用します。このコンテナーアーキテクチャーは OpenShift v3 の中核となります。

Kubernetes

OpenShift v2 のアプリケーションは通常は複数のギアを使用するのに対し、OpenShift v3 のアプリケーションは複数のコンテナーを使用します。OpenShift v2 では、ギアのオーケストレーション、スケジューリングおよび配置は、OpenShift Broker ホストが処理していました。OpenShift v3 では、マスターホストに Kubernetes を統合してコンテナーのオーケストレーションを駆動します。

アプリケーションは依然として OpenShift の中心的な要素です。OpenShift v2 では、アプリケーションが単一のユニットで、カートリッジタイプ 1 つに対して 1 つの Web フレームワークで構成されていました。たとえば、アプリケーションに PHP 1 つと MySQL 1 つを含めることはできますが、Ruby 1 つ、PHP 1 つ、および MySQL 2 つを含めることはできませんでした。また、MySQL などのデータベースカートリッジだけで機能させることもできませんでした。

アプリケーションの範囲を制限することで、OpenShift が環境変数を使用してアプリケーション内のすべてのコンポーネントをシームレスにリンクすることができます。たとえば、Web フレームワークはすべて OPENSHIFT_MYSQL_DB_HOST および OPENSHIFT_MYSQL_DB_PORT 変数を使用して MySQL に接続する方法を把握しますが、このリンクはアプリケーション内に限られており、連携して機能するように設計されたカートリッジ内でしか機能しませんでした。2 つのアプリケーション間で MySQL インスタンスを共有するなど、アプリケーションのコンポーネント間でリンクする方法はありませんでした。

他の PaaSes の大半は、Web フレームワークだけに制限され、他の種類のコンポーネントについては外部サービスに依存しますが、OpenShift v3 ではさらに多くのアプリケーショントポロジーや管理が可能です。

OpenShift v3 では、サービスをリンクする概念として「アプリケーション」という用語を使用しています。コンポーネントは必要な数だけいくつでも持つことができ、プロジェクト 内でコンテナー化したり、柔軟にリンクしたり、オプションで、グループ化や構造化のためにラベルを付けたりできます。この更新されたモデルは、MySQL インスタンスをスタンドアロンで使用したり、JBoss コンポーネント間で共有したりすることを可能にします。

柔軟にリンクするとは、任意の 2 つのコンポーネントをリンクできることを意味します。コンポーネントの 1 つが環境変数をエクスポートでき、他方がこれらの環境変数の値を使用できる限り (また環境変数名が変換される可能性があります)、ベースにするイメージを変更せずに 2 つのコンポーネントをリンクすることができます。そのため、両方をフォークし、互換性を持たせるように設定を変更せずに、任意のデータベースおよび Web フレームワークの最適にコンテナー化された実装を直接使用できるようになります。

これは OpenShift 上には何でもビルドできることを意味し、OpenShift の主要な目的と合致しています。OpenShift の主要な目的とは、反復可能なライフサイクルに基づいてアプリケーション全体をビルドするためにコンテナーベースのプラットフォームとして機能することにあります。

OpenShift v2 のカートリッジの概念の代わりに、OpenShift v3 ではイメージ が使用されるようになりました。

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 外にある場合もあります。ソースはイメージから切断されているので、イメージとソースの選択は異なる操作となります (ソースの設定はオプションです)。

ビルド

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

ルーティング

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

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

OpenShift v3 の マスター は、OpenShift v2 のブローカーホストとよく似ていますが、通常 etcd が各マスターホストにインストールされるので、OpenShift v2 のブローカーが使用する MongoDB および ActiveMQ の階層は不要になりました。

プロジェクト は基本的には v2 のドメインに相当します。