第4章 OpenShift Enterprise 2 との比較

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

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

ギア vs コンテナー

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

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

Kubernetes

OpenShift v2 のアプリケーションは一般的に複数のギアを使用するので、OpenShift v3 のアプリケーションは複数のコンテナーを予想通り使用します。OpenShift v2 では、ギアのオーケストレーション、スケジューリング、配置は、OpenShift ブローカーホストが処理していました。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 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 では、アプリケーションは、最低でも Web フレームワーク 1 つに git リポジトリーが 1 つ必要でした。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 のドメインに相当します。