Red Hat Training
A Red Hat training course is available for OpenShift Online
スタートガイド
OpenShift Online のスタートガイド
概要
第1章 概要
OpenShift Online 3 は Red Hat のアプリケーションホスティングプラットフォームであり、開発者がパブリッククラウド環境でコンテナーベースの Web アプリケーションを迅速にビルドし、起動し、スケーリングできるようにします。
以下のトピックを確認し、アプリケーション開発者 として OpenShift Online 3 の使用を開始しましょう。
- Web コンソールを使用して基本的なウォークスルーを実行し、最初のプロジェクトおよびアプリケーションを作成します。
- 基本を超えた手順 (Beyond the Basics) を CLI を使用して実行します。
- Eclipse ツールを使用して OpenShift Online に接続します。
- OpenShift Online 2 をご存知の場合は、OpenShift Online 3 で導入されたいくつかのアーキテクチャーおよび用語変更について確認してください。
第2章 プランの選択
2.1. プランおよび登録の確認
2.1.1. Red Hat OpenShift Online
OpenShift Online Starter と OpenShift Online Pro プランの相違点を確認し、登録プロセスを完了します。
登録時に、有効な 1 回限り使用できるプロモーションクーポンを利用できます。
登録後は、アカウントをカスタマイズします。
2.1.2. Red Hat Fuse Online
Red Hat Fuse Online は、ビジネスユーザーが統合ソリューションを迅速に構築できるようにするためのローコード統合プラットフォームです。
Red Hat Fuse Online は Red Hat OpenShift Online でホストされるため、すぐに稼働することができます。また、OpenShift がサポートされるいずれの場所（Red Hat のマネージドクラウド、パブリッククラウド、またはプライベートクラウド) にもデプロイできます。詳細を確認し、テクノロジープレビューにサインアップしてください。
2.2. その他の学習コンテンツ
OpenShift テクノロジーの詳細について、Red Hat OpenShift の Interactive Learning Portal および Kubernetes By Example を参照してください。
2.3. 次のステップ： 基本的なウォークスルー
登録後は、Basic Walkthrough に進み、単純なプロジェクトを稼働させる方法を確認します。
第3章 プランの管理
3.1. OpenShift Online プランの管理
3.1.1. アドオンによるプランのカスタマイズ
アドオンを使用してプランをカスタマイズすることができます。
Active Subscriptions ページで、Manage Subscription リンクをクリックします。
- Current Plan 見出しで Change をクリックします。
Current Plan ページで、メモリー、ストレージ、終了メモリーおよびサポートオプションを管理します。追加コストのリソースを追加します。
Manage Memory、 Manage Storage、 Manage Terminating Memory、または Manage Support をクリックしてそれぞれのワークフローに従います。
3.1.2. プランのアップグレード
プランを OpenShift Online Starter から OpenShift Online Pro にアップグレードするには、manage.openshift.com にアクセスします。
既存のすべてのオブジェクトのエクスポート方法については、「Creating a Template from Existing Objects」を参照してください。
OpenShift Online Starter ユーザーの場合、利用規約に違反すると、アカウントはサービス契約条件に違反すると、アカウントが終了し、サブスクリプションを作成できなくなります。
3.1.3. クーポンの適用
有効な 1 回限り使用できるプロモーションクーポンを利用できます (該当する場合)。
登録プロセス後も、クーポンを利用できます。
- Active Subscriptions ページから、Manage Subscriptions をクリックします。
- 次の Subscriptions ページで、 Coupons 見出しの横にある Manage をクリックします。
- 次の Subscription Coupons ページで、すでに使用されているクーポンが表示されます (該当する場合)。新規クーポンを適用するには、Apply New Coupon をクリックしてワークフローを完了します。
第4章 基本的なウォークスルー
4.1. 概要
本書では、OpenShift Online で簡単なプロジェクトを稼働させる方法を示します。
以下のセクションでは、OpenShift Online Web コンソールを使用して Welcome ページや現在のヒットカウント (データベースに保存) を提供するサンプル Node.js アプリケーションが含まれるプロジェクトを作成する方法について説明します。これには、2 つの Pod を作成する必要があります。
- 1 つは Node.js アプリケーションをホストするための Pod です。
- もう 1 つは MongoDB データベースをホストするための Pod です。
チュートリアルでは、以下があることが前提となります。
4.2. セットアップ
このセクションでは、GitHub で OpenShift Node.js サンプルアプリケーションを フォーク し、アプリケーションをデプロイおよび編集できるようにローカルマシンにリポジトリーのクローンを作成します。
GitHub で、openshift/nodejs-ex リポジトリーに移動します。ページの右上にある Fork をクリックします。
次に、ローカルマシンで以下のコマンドを実行してサンプルアプリケーションのクローンを作成し、新規ディレクトリーに移動します。
$ git clone https://github.com/<your_github_username>/nodejs-ex $ cd nodejs-ex
これで終了です。これで、元の openshift/nodejs-ex サンプルアプリケーションの Git リポジトリーのフォークが作成され、ローカルマシンにコピーが作成されました。
4.3. Web コンソールの使用
Web コンソールのトピックを参照し、そのコンポーネントについて確認してください。
4.4. 新規アプリケーションの作成
このセクションでは、Web コンソールを使用して最初のアプリケーションを OpenShift Online にデプロイします。
OpenShift Online Web コンソールの Welcome ページに移動し、Create Project をクリックして最初のプロジェクトを作成します。
注記OpenShift Online Starter では、現時点で単一プロジェクトのみを作成できます。すでにプロジェクトがある場合は、これを削除してから続行する必要があります。
既存のプロジェクトを削除するには、Welcome ページのプロジェクト名の横にあるごみ箱アイコンをクリックします。
my-projectをプロジェクトの一意の名前に置き換えます (例:<your_github_username>-example)。表示名および説明は空白のままにすることができます。
JavaScript オプションをクリックします。
nodejs-mongodb-example Quickstart テンプレートを選択します。
次の画面で、Git Repository URL パラメーターのユーザー名を GitHub のユーザー名に置き換えます。その他のすべてのパラメーターに指定されるデフォルト値を使用します。
最後に、ページの下部にスクロールし、Create をクリックしてアプリケーションをデプロイします。
注記Web コンソールの「Overview」ページでは、作成した新規リソースを表示し、ビルドやデプロイメントの進捗を確認できます。MongoDB Pod が作成されている間も、Pod のステータスは保留中と表示されます。次に、MongoDB Pod が起動し、新たに割り当てられた IP アドレスが表示されます。
4.5. 自動化ビルドの設定
このセクションでは、フォークしたリポジトリーにコードの変更をプッシュするたびにアプリケーションの再ビルドを自動トリガーするように GitHub Webhook を設定します。これを実行するには、アプリケーションから Github Webhook URL を Github リポジトリーに追加する必要があります。以下の場所からこの Webhook を取得します。
アプリケーションの作成後に表示される Next Steps ページの下部に、Making code changes というセクションが表示されます。ページの下部からペイロード URL をコピーし、提供されている GitHub プロジェクトの Webhook 設定ページへのリンクをたどります。
OpenShift Online Web コンソールで、以下を実行します。
- アプリケーションが含まれるプロジェクトに移動します。
- Browse タブをクリックし、Builds をクリックしてから Node.js アプリケーションのビルドの名前をクリックします。
-
Configuration タブで、GitHub webhook URL の横にある
をクリックし、GitHub webhook をコピーします。
次に、Webhook を Github リポジトリーに追加します。
GitHub で、プロジェクトについて GitHub Webhook 設定の Add webhook をクリックします。ペイロード URL を Payload URL フィールドに貼り付けます。Content type フィールドが、デフォルトの application/x-www-form-urlencoded の代わりに application/json に設定されることを確認します。次に、Add webhook をクリックし、Webhook のプロジェクトへの追加を終了します。
GitHub では OpenShift Online サーバーへの ping を試行し、通信が正常に実行されることを確認します。これが正しく設定されている場合、GitHub の新規 Webhook URL の横に緑色のチェックマークが表示されます。チェックマークの上にマウスをかざして、最終配信のステータスを表示します。
フォークされたリポジトリーにコード変更をプッシュする次回のタイミングで、アプリケーションが自動的に再ビルドされます。
4.6. 実行中のアプリケーションの表示
このセクションでは、Web ブラウザーを使用して実行中のアプリケーションを表示します。
Web コンソールで、プロジェクトの Overview ページを表示し、アプリケーションの Web アドレスを判別します。NODEJS-MONGODB-EXAMPLE サービスの下に表示される Web アドレスをクリックし、新規ブラウザータブでアプリケーションを開きます。
プロジェクトに設定したすべてのルートについては、常に Web コンソールで見つけることができます。
- Web コンソールで、作成したアプリケーションが含まれるプロジェクトに移動します。
- Browse タブをクリックしてから Routes をクリックします。
- ホスト名をクリックして、ブラウザーの新規タブでアプリケーションを開きます。
4.7. コード変更のプッシュ
このセクションでは、ローカルコードの変更をアプリケーションにプッシュする方法を説明します。
- ローカルマシンで、テキストエディターを使用し、 nodejs-ex/views/index.html ファイルのサンプルアプリケーションのソースを開きます。
コードの変更をアプリケーション内から表示できるようにします。たとえば、219 行目のタイトルを変更します。
Git に変更をコミットし、変更を GitHub リポジトリーにプッシュします。
$ git add views/index.html $ git commit -m “Updates heading on welcome page” $ git push origin master
- webhook が正しく設定されている場合には、変更を基に、アプリケーションは即座にリビルドされます。Web ブラウザーを使用してアプリケーションを表示し、変更を確認します。
その後は、コードの更新をプッシュするだけで良く、残りは OpenShift Online が処理します。
4.8. アプリケーションのスケーリング
OpenShift Online Starter ユーザーはアプリケーションをスケーリングできません。OpenShift Online Pro ユーザーのみがこれを行えます。
このセクションでは、アプリケーションが追加のトラフィックボリュームを処理できるように Node.js サービスのインスタンスを追加します。
Web コンソールで、プロジェクトの Overview ページを表示します。NODEJS-MONGODB-EXAMPLE サービスの下にある上矢印をクリックし、Node.js アプリケーションのレプリカを追加します。
nodejs-mongodb-example Quickstart は、Pod ごとに 512 MiB のメモリーを使用するように設定されます。OpenShift Online Pro クォータでは、MongoDB データベースに加えて nodejs-mongodb-example Pod の最大 3 つのレプリカを許可します (合計 2 GiB)。
Web コンソールでクォータの使用状況をいつでも確認できます。
- Web コンソールで、作成したアプリケーションが含まれるプロジェクトに移動します。
- Settings タブをクリックし、Quota compute-resources というセクションにスクロールし、使用状況を表示します。
4.9. 次のステップ： 基本を超えた手順 (Beyond the Basics)
次に、OpenShift Online CLI を使用して 基本を超えた手順 (Beyond the Basics) を実行し、個別のイメージを使用して同じアプリケーションを作成します。
第5章 基本を超えた手順 (Beyond the Basics)
5.1. 概要
本書では、まず基本的なウォークスルーのトピックで、近道を使わずに (long way) 同じサンプルプロジェクトを取得する方法を説明しています。
OpenShift バージョン 3 のコアとなる概念に慣れていない場合は、まず新機能について参照する必要があるかもしれません。このバージョンの OpenShift は、バージョン 2 とは大きく異なります。
以下のセクションでは、Welcome ページや現在のヒットカウント (データベースに保存) を提供するサンプル Node.js アプリケーションが含まれるプロジェクトを作成する方法について説明します。これには、2 つの Pod を作成する必要があります。
- 1 つは Node.js アプリケーションをホストするための Pod です。
- もう 1 つは MongoDB データベースをホストするための Pod です。
チュートリアルでは、以下があることが前提となります。
5.2. セットアップ
このセクションでは、GitHub で OpenShift Node.js サンプルアプリケーションを フォーク し、アプリケーションをデプロイおよび編集できるようにローカルマシンにリポジトリーのクローンを作成します。
基本的なウォークスルーのトピックに従って openshift/nodejs-ex リポジトリーをすでにフォークしている場合は、この手順を省略できます。
GitHub で、openshift/nodejs-ex リポジトリーに移動します。ページの右上にある Fork をクリックします。
次に、ローカルマシンで以下のコマンドを実行してサンプルアプリケーションのクローンを作成し、新規ディレクトリーに移動します。
$ git clone https://github.com/<your_github_username>/nodejs-ex $ cd nodejs-ex
これで終了です。これで、元の openshift/nodejs-ex サンプルアプリケーションの Git リポジトリーのフォークが作成され、ローカルマシンにコピーが作成されました。
5.3. OpenShift CLI のインストール
このセクションでは、OpenShift CLI をインストールします。OpenShift CLI は、アプリケーションを管理するためのコマンドだけでなく、システムの各コンポーネントと対話する低レベルのツールも公開しています。
まず、OpenShift Online Web コンソールの About ページから OpenShift Online CLI をダウンロードします。
CLI は、Linux (32 または 64 ビット)、Mac OS X、および Windows で利用できます。CLI をダウンロードしたら、以下の手順に戻ります。
次に、アーカイブを展開または解凍し、
ocバイナリーをPATH上のディレクトリーに移動します。注記Linux または Mac OS X の
PATHを確認するには、ターミナルを開いて以下を実行します。$ echo $PATH
Windows でこれを確認するには、コマンドプロンプトを開き、以下を実行します。
C:\> path
インストール後に、コマンドシェルから
ocコマンドを使用できます。次に、OpenShift Online Web コンソールの About ページに移動します。
現在のセッショントークンと共に表示される
oc loginコマンドをコピーし、CLI から OpenShift Online にログインします。$ oc login https://<your_cluster_ID>.openshift.com --token=<your_session_token>
oc loginコマンドは、最初に OpenShift Online CLI を設定するのに最適な方法です。この情報は CLI 設定ファイルに自動的に保存され、その後のコマンドで使用されます。
5.4. ソースコードからの新規アプリケーションの作成
このセクションでは、Web コンソールを使用して最初のアプリケーションを OpenShift Online にデプロイします。
まず、新規プロジェクトを作成します。以下の
<project_name>を<your_github_username>-exampleなどのプロジェクトの一意の名前に置き換えます。$ oc new-project <project_name>
新規プロジェクトの作成後、新規プロジェクトの namespace に自動的に切り替えられます。
基本的なウォークスルーのトピックに従っている場合、最初のプロジェクトはすでに作成されています。プロジェクト namespace に切り替え、元のサンプルアプリケーションをクリアする必要があります。
以下のコマンドを使用して、既存のプロジェクトの名前を検索します。
$ oc get projects
次に、プロジェクト namespace に切り替えます。
$ oc project <your_project_name>
次に、プロジェクトの既存オブジェクトをすべて削除します。
$ oc delete all --all
以下のコマンドを使用して、既存の Persistent Volume Claim（永続ボリューム要求、PVC）の名前を検索します。
$ oc get pvc
最後に、以下を使用して既存の Persistent Volume Claim（永続ボリューム要求、PVC）を削除します。
$ oc delete pvc mongodb
次に、nodejs-ex ソースコードファイルのフォークされたコピーから新規アプリケーションを作成します。
$ oc new-app https://github.com/<your_github_username>/nodejs-ex --name nodejs-mongodb-example
注記--nameオプションは、oc new-appコマンドで作成されるすべてのリソースにnodejs-mongodb-exampleの名前を適用します。これにより後に管理が容易になります。ツールは、ソースコードを検査し、ソースコードをビルドできる適切なイメージを見つけ、ビルドされる新規アプリケーションイメージのイメージストリームを作成してから、正しいビルド設定、 デプロイメント設定 およびサービスの定義を作成します。
oc new-appコマンドは、必要なすべての依存関係が確認された後にビルドを開始し、イメージが利用可能になるとアプリケーションを自動的にデプロイします。
Web コンソールのプロジェクトの Overview ページでは、作成されている新規リソースを表示し、ビルドやデプロイメントの進捗を監視できます。Node.js Pod が実行されている間に、ビルドは完了します。
oc status コマンドを使用して新規 nodejs アプリケーションのステータスを確認し、oc get pods で Pod がいつ稼働するかを確認することもできます。
oc get services コマンドは、サービスが実行されている IP アドレスを示します。デプロイ先のデフォルトポートは 8080 です。
5.5. ルートの設定
このセクションでは、Node.js サービスを外部要求に公開するようにルートを設定します。
まず、以下を使用してサービス名 (
nodejs-mongodb-example) を検索します。$ oc get services
次に、サービスを外部要求に公開するためのルートを作成します。
$ oc expose service/nodejs-mongodb-example
これで、以下を使用してサービスの外部ホスト/ポートを確認できます。
$ oc get routes
最後に、アプリケーションのルート HOST/PORT をコピーして、これをブラウザーに貼り付けてアプリケーションを表示します。
5.6. データベースのプロビジョニング
このセクションでは、MongoDB サービスをプロジェクトに追加します。
アプリケーションのインデックスページを表示する際に、Request information に No database configured と表示される場合があります。MongoDB サービスを追加して修正します。
以下を使用して、OpenShift Online が提供する MongoDB データベースをプロジェクトに追加します。
$ oc new-app mongodb-persistent \ -p MONGODB_USER=admin \ -p MONGODB_PASSWORD=secret \ -p MONGODB_ADMIN_PASSWORD=super-secret
注記-pフラグは、mongodb-persistent データベーステンプレートで使用されるパラメーター値を設定します。- 次のセクションに移動する前に、MongoDB サービスの名前をメモします。
5.7. 環境変数の設定
このセクションでは、Node.js サービスを新しい MongoDB サービスに接続するように設定します。
MongoDB サービスを使用できるように環境変数
MONGO_URLを Node.js Web サービスに追加し、「Page view count」機能を有効にする必要があります。以下を実行します。$ oc set env dc/nodejs-mongodb-example MONGO_URL='mongodb://admin:secret@<MongoDB-service-name>:27017/sampledb'
注記同じプロジェクトのサービスには、自動的に解決可能な DNS 名があります。
以下は例になります。
$ oc set env dc/nodejs-mongodb-example MONGO_URL='mongodb://admin:secret@mongodb-persistent:27017/sampledb'
次に、
oc statusを実行して、更新されたデプロイメントが開始されていることを確認します。デプロイメントの完了後に、MongoDB データベースに保存される現在のヒットカウントを表示する Node.js Welcome ページが表示されます。注記プロジェクト内のすべての Pod に設定された環境変数の一覧を取得するには、以下を実行します。
$ oc set env pods --all --list
5.8. 自動化ビルドの設定
このセクションでは、フォークしたリポジトリーにコードの変更をプッシュするたびにアプリケーションの再ビルドを自動トリガーするように GitHub Webhook を設定します。
最初に、以下のコマンドを実行して、ビルド設定に関連付けれた Webhook URL を表示します。
$ oc describe buildConfig nodejs-mongodb-example
上記のコマンドで出力される webhook GitHub URL をコピーします。Webhook URL は以下の形式になります。
http://<openshift_api_host:port>/osapi/v1/namespaces/<namespace>/buildconfigs/frontend/webhooks/<your_secret_key>/github
次に、GitHub のフォークされたリポジトリーに移動してから以下を実行します。
- Settings をクリックします。
- Webhooks & Services をクリックします。
- Add webhook をクリックします。
- Webhook URL を Payload URL フィールドに貼り付け、 Add webhook をクリックして保存します。
これで終了です。フォークされた GitHub リポジトリーにコードの変更をプッシュすると、アプリケーションが自動的に再ビルドされるようになりました。
5.9. コード変更のプッシュ
このセクションでは、ローカルコードの変更をアプリケーションにプッシュする方法を説明します。
- ローカルマシンで、テキストエディターを使用し、 nodejs-ex/views/index.html ファイルのサンプルアプリケーションのソースを開きます。
コードの変更をアプリケーション内から表示できるようにします。たとえば、219 行目のタイトルを変更します。
Git に変更をコミットし、変更を GitHub リポジトリーにプッシュします。
$ git add nodejs-ex/views/index.html $ git commit -m "Updates heading on welcome page" $ git push origin master
- webhook が正しく設定されている場合には、変更を基に、アプリケーションは即座にリビルドされます。Web コンソールのプロジェクトの Overview ページでは、ビルドやデプロイメントの進捗を確認できます。デプロイメントが完了したら、Web ブラウザーを使用してアプリケーションを表示し、変更を確認します。
その後は、コードの更新をプッシュするだけで良く、残りは OpenShift Online が処理します。
5.10. 失敗通知
各プロジェクトについて、停止または失敗したデプロイメント、停止したビルド、停止または失敗した Persistent Volume Claim（永続ボリューム要求、PVC）を含む、各種の失敗に関するメール通知 を受け取ることを選択できます。
5.11. 次のステップ
以下のセクションでは、OpenShift Online 3 の初期手順を完了した後に実行するいくつかのステップについて説明します。
5.11.1. OpenShift Online の使用に関する考慮事項
5.11.2. 他の Quickstart
OpenShift Online 2 と同様に、OpenShift Online 3 は開発者向けに、すぐにアプリケーション開発を開始していただけるように、適切な実装とチュートリアルと共に、追加設定なしで使用できる言語およびデータベースを提供します。言語サポートは、Quickstart テンプレートを軸として展開され、このテンプレートはビルダーイメージを活用します。
新規アプリケーションの作成についてのトピックを確認し、以下の言語の Quickstart テンプレートを使用してみてください。
OpenShift Online が提供する他のイメージには以下が含まれます。
さらに、JBoss Middleware では広範囲に及ぶ OpenShift Online テンプレートを利用できます。
特に xPaaS サービスで利用可能な技術は以下のとおりです。
- JBoss EAP 6 が提供する Java EE 6 Application Server
- JBoss Fuse および JBoss A-MQ が提供する統合およびメッセージサービス
- JBoss Data Grid が提供する Data Grid サービス
- JBoss BRMS が提供する Real Time Decision Service
- Tomcat 7 および Tomcat 8 が提供する Java Web Server 3.0
上記の各オファリングについては、一連の組み合わせが提供されます。
- HTTP のみ vs HTTP および HTTPS
- データベースを必要としない場合や、MongoDB、PostgreSQL または MySQL のいずれかを使用する場合
- A-MQ との統合 (必要な場合)
5.11.3. rsync の使用
oc rsync を使用してコンテナーのリモートディレクトリーへの/からのローカルファイルのコピーを実行するための手順については、「Copying Files」を参照してください。
5.11.4. 自動スケーリングの設定
メトリクスに基づいてレプリケーションコントローラーまたはデプロイメント設定のスケーリングを自動的に増減する手順については、「Pod Autoscaling」を参照してください。
自動スケーリングについては、OpenShift ブログの記事を参照することもできます。
5.11.5. 『開発者ガイド』の参照情報
追加の情報については、『Developer Guide』を参照してください。たとえば、開発プロセスのプランニングや、新規アプリケーショントピックの作成についてのトピックから参照することができます。
5.11.6. トラブルシューティング
一般的なヒントおよび提案について確認してください。
第6章 OpenShift Online 2 と 3 の比較
6.1. 概要
OpenShift Online 3 は OpenShift バージョン 3 (v3) のアーキテクチャーをベースにしており、OpenShift バージョン 2 (v2) とは非常に異なる製品です。OpenShift v2 と同じ用語が数多く v3 でも使用されており、同じ機能が実行されますが、異なる用語が使用される場合もあり、背景で実行される内容は非常に異なる場合があります。ただし、OpenShift はアプリケーションプラットフォームとして依然として機能します。
このトピックでは、バージョンの違いを詳しく説明し、OpenShift のユーザーの OpenShift v2 から OpenShift v3 への移行を支援します。
6.2. アーキテクチャーの変更
ギア 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 を統合してコンテナーのオーケストレーションを駆動します。
6.3. アプリケーション
アプリケーションは依然として 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 の主要な目的とは、反復可能なライフサイクルに基づいてアプリケーション全体をビルドするためにコンテナーベースのプラットフォームとして機能することにあります。
6.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 では、テンプレートを使用してイメージに任意の数のルートを設定できます。これらのルートを使用すると、システムルートとユーザーエイリアスを区別することなく、公開するスキーム、ホスト、パスを任意に変更できます。
6.5. ブローカー vs マスター
OpenShift v3 のマスターは、OpenShift v2 のブローカーホストと似ています。ただし、通常は etcd が各マスターホストにインストールされるので、OpenShift v2 のブローカーが使用する MongoDB および ActiveMQ の階層は不要になりました。
6.6. ドメイン vs プロジェクト
プロジェクトは基本的には v2 のドメインに相当します。
