2.3.2. アプリケーションコンポーネント
2.3.2.1. API オブジェクト
OpenShift Container Platform および Kubernetes リソース定義（アプリケーションインベントリーに新規に導入された項目）に関連して、アプリケーションのプロモートについて検討する場合に API オブジェクトの設計ポイントで留意しておくべき 2 つの主要な点があります。
1 つ目の点として、すべての API オブジェクトは、OpenShift Container Platform ドキュメント全体で強調されているように JSON または YAML のいずれかで表現できるので、これらのリソース定義は従来のソースコントロールおよびスクリプトを使用して容易に管理できます。
また、API オブジェクトは、システムの必要な状態を指定するオブジェクトの部分とシステムのステータスまたは現在の状態を反映する部分で構成されるように設計されています。これはインプットおよびアウトプットとして考えることができます。インプット部分は JSON または YAML で表現され、ソースコントロール管理(SCM)のアーティファクトとして適合します。
API オブジェクトのインプット部分または仕様部分は、インスタンス化のタイミングで テンプレート処理による変数置換 が可能であるため、完全に静的または動的に機能する点に留意してください。
API オブジェクトに関する上記の点により、JSON または YAML ファイルの表現を使ってアプリケーションの設定をコードとして処理できます。
ほぼすべての API オブジェクトについて、組織はこれらをアプリケーションのアーティファクトとみなすことができます。以下は、アプリケーションのデプロイおよび管理に最も関連するオブジェクトです。
- BuildConfigs
-
これはアプリケーションのプロモーションのコンテキストにおける特殊なリソースです。
BuildConfigはとくに開発者の観点ではアプリケーションの一部ではありますが、BuildConfigは通常パイプラインでプロモートされません。これはパイプラインで（他のアイテムと共に）プロモートされるイメージを作成します。 - テンプレート
-
アプリケーションのプロモーションの観点では、
Templatesはとくにパラメーター化機能を使ってリソースを所定のステージング環境でセットアップするための開始点として機能します。ただしアプリケーションがプロモーションのパイプラインを通過する場合でも、インスタンス化の後に追加の変更が生じる可能性が高くなります。詳細は、「シナリオおよび実例」を参照してください。 - ルート
-
ルートは、最も一般的なリソースで、アプリケーションのさまざまなステージに対するテスとは、
Routeを使用してアプリケーションにアクセスするので、アプリケーションのプロモーションパイプラインのステージごとに異なります。また、ホスト名だけでなくRouteの HTTP レベルのセキュリティーに関しても、手動指定や自動生成のオプションがある点に留意してください。 - サービス
-
初期ステージでの個々の開発者の便宜を考慮する場合など、所定のアプリケーションプロモーションステージで
ルーターおよびルートを避ける理由がある場合には、アプリケーションはクラスターの IP アドレスおよびポート経由でアクセスできます。これらを使用した場合、ステージ間のアドレスおよびポートの管理の一部が必要となる可能性があります。 - Endpoints (エンドポイント)
-
アプリケーションレベルのサービス（多くの企業によっては、データベースのインスタンスなど）は OpenShift Container Platform で管理されない場合があります。そのような場合に、独自に
エンドポイントを作成して、関連するサービス（サービスのセレクターフィールドを省略）に必要な修正を加えると、（環境をどのようにプランニングするかにより異なりますが）アクティビティーがステージ間で重複または共有されます。 - シークレット
-
シークレットでカプセル化された機密情報は、その情報関連の対応するエンティティー（OpenShift Container Platform が管理するサービスまたは OpenShift Container Platform 外で管理する外部サービス）が共有されると、ステージ環境間で共有されます。このエンティティーの異なるバージョンがアプリケーションのプロモーションパイプラインの各ステージにある場合には、パイプラインの各ステージで固有のSecretを維持するか、パイプラインを通過する際に変更を加える必要がある場合があります。またSecretを SCM に JSON または YAML として保存する場合には、機密情報を保護するための暗号化フォームが必要となる場合があります。 - DeploymentConfigs
- このオブジェクトは、アプリケーションの起動方法を制御するため、所定のアプリケーションのプロモーションパイプラインステージの環境を定義し、そのスコープを設定する時の最も重要なリソースになります。各種ステージ間で共通する部分がありますが、アプリケーションプロモーションパイプラインの移動に伴い、このオブジェクトには当然変更が加えられます。この変更には、各ステージの環境の違いを反映させるための修正や、アプリケーションがサポートする必要のある各種シナリオのテストを容易にするためのシステム動作の変更が含まれます。
- ImageStreams, ImageStreamTags、および ImageStreamImage
- イメージ および Image Streams の各セクションで説明されているように、これらのオブジェクトは、コンテナーイメージの管理に関連して OpenShift Container Platform の追加要素の中核となります。
- ServiceAccounts および RoleBindings
-
アプリケーション管理において、OpenShift Container Platform や外部サービスでの他の API オブジェクトに対するパーミッション管理は必要不可欠です。
Secretsと同様に、ServiceAccountsおよびRoleBindingsオブジェクトのアプリケーションプロモーションパイプラインのステージ間での共有方法は、各種環境を共有または分離する必要性によって異なる可能性があります。 - PersistentVolumeClaims
- データベースのようなステートフルなサービスに関連して、どの程度異なるアプリケーションプロモーションステージ間で共有されるかは、組織がアプリケーションデータのコピーを共有または分離する方法に直接関係します。
- ConfigMap
-
Pod設定のPod自体から分離（環境変数スタイルの設定など）するのに便利です。これらはPodの動作に一貫性をもたせる必要がある場合などに各種のステージング環境で共有することができます。また、これらはステージ間で変更してPod動作を修正することもできます（通常はアプリケーションのさまざまな側面はステージごとに検証されます）。
