Red Hat Training

A Red Hat training course is available for OpenShift Online

2.3. 環境全体におけるアプリケーションのプロモート

2.3.1. 概要

アプリケーションのプロモーションとは、さまざまなランタイム環境でのアプリケーションの移動を意味します。通常は、移動により成熟度が向上していきます。たとえば、あるアプリケーションが開発環境からスタートし、ステージング環境へと進み、さらなるテストが行われ、最後に実稼働環境へとプロモートされます。アプリケーションに変更が加えられると、変更が開発環境に加えられ、ステージング環境および実稼働環境へとプロモートされます。

「アプリケーション」は、単に Java、Perl、および Python などで記述された単なるソースコードを意味する訳ではありません。静的 Web コンテンツ、統合スクリプト、または言語固有のランタイムの関連する設定以上のものを指します。これは、それらの言語固有のランタイムによって使用されるアプリケーション固有のアーカイブ以上のものを指します 。

OpenShift Online および Kubernetes と Docker を統合した基盤という環境では、追加のアプリケーションのアーティファクトとして以下が含まれます。

  • メタデータと関連ツールの豊富なセットを含む Docker コンテナーイメージ。
  • アプリケーションで使用されるためにコンテナーに挿入される 環境変数。

  • 以下の OpenShift Online の API オブジェクト (リソース定義としても知られています。 「Core Concepts」を参照してください)。

    • アプリケーションで使用されるためにコンテナーに挿入されます。
    • OpenShift Online のコンテナーおよび Pod の管理方法を指定します。

OpenShift Online でのアプリケーションのプロモート方法を検討するため、本トピックでは以下を扱います。

  • アプリケーション定義に導入される新規アーティファクトの詳細。
  • アプリケーションのプロモーションパイプラインの各種環境を区別する方法。
  • 新規アーティファクトを管理する方法およびツールについて。
  • 各種の概念、構成、方法およびツールをアプリケーションのプロモートに適用する実例。

2.3.2. アプリケーションコンポーネント

2.3.2.1. API オブジェクト

OpenShift Online および Kubernetes リソース定義 (アプリケーションインベントリーに新規に導入された項目) に関連して、アプリケーションのプロモートについて検討する際に API オブジェクトの設計ポイントについて留意しておくべき 2 つの主要な点があります。

1 つ目の点として、すべての API オブジェクトは、OpenShift Online ドキュメント全体で強調されているように JSON または YAML のいずれかで表現することができます。 そのため、これらのリソース定義は従来のソースコントロールおよびスクリプトを使用して容易に管理できます。

2 つ目の点として、API オブジェクトは、システムの必要とされる状態を指定するオブジェクトの部分とシステムのステータスまたは現在の状態を反映する部分で構成されるように設計されています。これはインプットおよびアウトプットとして捉えることができます。インプット部分は JSON または YAML で表現され、ソースコントロール管理 (SCM) のアーティファクトとして適合します。

注記

API オブジェクトのインプット部分つまり仕様部分は、インスタンス化の際に テンプレート処理による変数置換を実行できるため、完全に静的または動的に機能する点に留意してください。

API オブジェクトに関する上記の点により、JSON または YAML ファイルの表現を使ってアプリケーションの設定をコードとして処理することができます。

ほぼすべての API オブジェクトについて、組織はこれらをアプリケーションのアーティファクトとみなすことができます。以下は、アプリケーションのデプロイおよび管理に最も関連するオブジェクトです。

BuildConfigs
これはアプリケーションのプロモーションのコンテキストにおける特殊なリソースです。BuildConfig はとくに開発者の観点ではアプリケーションの一部ではありますが、BuildConfig は通常パイプラインでプロモートされません。これはパイプラインで (他のアイテムと共に) プロモートされる イメージ を作成します。
テンプレート
アプリケーションのプロモーションの観点では、Templates はとくにパラメーター化機能を使ってリソースを所定のステージング環境でセットアップするための開始ポイントとしての役割を果たします。ただしアプリケーションがプロモーションのパイプラインを移動する際に、インスタンス化の後に追加の変更が生じる可能性が高くなります。詳細については、シナリオおよび実例 を参照してください。
ルート
ルートは最も典型的なリソースで、アプリケーションプロモーションパイプラインのステージごとに異なります。アプリケーションの各種ステージに対するテストの際に、アプリケーションへのアクセスが Route 経由で行われるためです。また、ホスト名だけでなく Route の HTTP レベルのセキュリティーに関しても、手動指定や自動生成のオプションがある点に留意してください。
サービス
(初期ステージでの個々の開発者の便宜を考慮する場合など) 所定のアプリケーションプロモーションステージで Routers および Routes を避ける理由がある場合、アプリケーションは Cluster の IP アドレスおよびポート経由でアクセスできます。これらを使用した場合、ステージ間のアドレスおよびポートの管理の一部が必要となる可能性があります。
エンドポイント
特定のアプリケーションレベルのサービス (たとえば、多くの企業におけるデータベースのインスタンスなど) は OpenShift Online で管理されない場合があります。そのような場合に、独自に Endpoints を作成して、関連する Service (Service のセレクターフィールドは除外) に必要な修正を加えると、(環境をどのようにプランニングするかにより異なりますが) アクティビティーがステージ間で重複または共有されます。
シークレット
Secrets でカプセル化された機密情報は、その情報関連の対応するエンティティー (OpenShift Online が管理する Service または OpenShift Online 外で管理する外部サービス) が共有されると、ステージ環境間で共有されます。このエンティティーの異なるバージョンがアプリケーションのプロモートパイプラインの各ステージにある場合には、パイプラインの各ステージで固有の Secret を維持するか、それをパイプラインの移動時に変更する必要がある場合があります。また Secret を SCM に JSON または YAML として保存する場合、機密情報を保護するための暗号化フォームが必要となることがあるので注意してください。
DeploymentConfigs
このオブジェクトは、所定のアプリケーションのプロモーションパイプラインステージの環境を定義し、そのスコープを設定する際の最も重要なリソースになります。これはアプリケーションの起動方法を管理します。各種ステージ間で共通する部分がありますが、アプリケーションプロモーションパイプラインの移動に伴い、このオブジェクトには変更が加えられます。 この変更には、各ステージの環境の違いを反映させるための修正や、アプリケーションがサポートする必要のある各種シナリオのテストを容易にするためのシステム動作の変更が含まれます。
ImageStreams, ImageStreamTags、および ImageStreamImage
イメージ および イメージストリーム の各セクションで説明されているように、これらのオブジェクトは、コンテナーイメージの管理に関連して OpenShift Online の追加要素の中核を成しています。
ServiceAccounts および RoleBindings
アプリケーション管理において、OpenShift Online や外部サービスでの他の API オブジェクトに対するパーミッション管理は必要不可欠です。Secrets と同様に、ServiceAccounts および RoleBindings オブジェクトのアプリケーションプロモーションパイプラインのステージ間での共有方法は、各種の異なる環境を共有するか、分離するかなどの各自のニーズによって異なります。
PersistentVolumeClaims
データベースのようなステートフルなサービスに関連して、これらが異なるアプリケーションプロモーションステージ間で共有される程度は、組織がアプリケーションデータのコピーを共有または隔離する方法に直接関連します。
ConfigMap
Pod 設定の Pod 自体からの分離 (環境変数スタイルの設定など) に関連して、これらは Pod の動作に一貫性をもたせる場合に各種のステージング環境で共有することができます。またこれらをステージごとに変更して Pod 動作を変更することも可能です ( 通常アプリケーションの各種の側面はステージごとに検証されます)。

2.3.2.2. イメージ

前述のように、コンテナーイメージはアプリケーションのアーティファクトです。実際、新しいアプリケーションのアーティファクト、イメージ、およびイメージの管理は、アプリケーションのプロモーションに関する主要な要素です。場合によっては、イメージがアプリケーションの全体をカプセル化し、アプリケーションプロモーションフローがイメージの管理のみで構成されることがあります。

通常イメージは SCM システムでは管理されません (アプリケーションのバイナリーが以前のシステムで管理されていなかったのと同様です)。ただしバイナリーと同様に、インストール可能なアーティファクトおよび対応するリポジトリー (RPM、RPM リポジトリー、Nexus など) は SCM と同様のセマンティクスで生成されるので、SCM に似たイメージ管理の構成および専門用語が導入されました。

  • Image registry == SCM server
  • Image repository == SCM repository

イメージはレジストリーに存在するので、アプリケーションプロモーションでは、適切なイメージがレジストリーに存在し、そのイメージで表されるアプリケーションを実行する必要のある環境からアクセスできるようにします。

イメージを直接参照するよりも、アプリケーションの定義は通常イメージストリームに参照を抽象化します。これは、イメージストリームがアプリケーションコンポーネントを構成する別の API オブジェクトになることを意味します。イメージストリームについての詳細は、「Core Concepts」を参照してください。

2.3.2.3. 概要

これまでノート、イメージ、および API オブジェクトのアプリケーションのアーティファクトについて OpenShift Online 内のアプリケーションプロモーションのコンテキストで説明しました。 次は、アプリケーションをプロモーションパイプラインの各種ステージの どこで 実行するのかを見ていきます。

2.3.3. デプロイメント環境

このコンテキストでのデプロイメント環境は、CI/CD パイプラインの特定ステージでアプリケーションが実行される固有のスペースを表します。通常の環境には、開発、テスト、ステージング および 実稼働環境 などが含まれます。環境の境界については、以下のように様々な方法で定義できます。

  • 単一プロジェクト内のラベルおよび独自の名前を使用する
  • クラスター内の固有のプロジェクトを使用する
  • 固有のクラスターを使用する

上記の 3 つ方法すべてを利用できることが想定されます。

2.3.3.1. 留意事項

通常デプロイメント環境の構成を検討する際は、以下のヒューリスティックな側面について検討します。

  • プロモーションフローの各種ステージで許可するリソース共有の度合い
  • プロモーションフローの各種ステージで必要な分離の度合い
  • プロモーションフローの各種ステージの中心からの位置 (またはどの程度地理的に分散しているか)

さらに OpenShift Online のクラスターおよびプロジェクトがイメージレジストリーにどのように関係するかについて以下の重要な点に留意してください。

  • 同一クラスター内の複数のプロジェクトは同一のイメージストリームにアクセスできる。
  • 複数のクラスターが同一の外部レジストリーにアクセスできる。
  • OpenShift Online の内部イメージレジストリーがルート経由で公開される場合、クラスターはレジストリーのみを共有できる。

2.3.3.2. 概要

デプロイメント環境が定義された後、パイプライン内のステージの記述を含むプロモーションフローを実装できます。以下では、これらのプロモーションフローの実装を構成する方法およびツールについて説明します。

2.3.4. 方法およびツール

基本的にアプリケーションのプロモートとは、前述のアプリケーションのコンポーネントをある環境から別の環境に移動するプロセスのことです。アプリケーションのプロモートの自動化に関する全体的なソリューションを検討する前に、各種コンポーネントを手動で移動する場合に使用できるツールの概要について以下のサブセクションで見ていきましょう。

注記

ビルドおよびデプロイメントの両方のプロセスにおいて多数の挿入ポイントを利用できます。これらは BuildConfig および DeploymentConfig API オブジェクトで定義されます。これらのフックにより、データベースなどのデプロイされたコンポーネントおよび OpenShift Online クラスター自体と対話できるカスタムスクリプトの呼び出しが可能となります。

したがって、フック内からイメージタグ操作を実行するなど、このようなフックを使用して、アプリケーションを環境間で効果的に移動するコンポーネント管理操作を実行できます。ただし、これらのフックポイントの使用は、環境間でアプリケーションコンポーネントを移動する場合よりも、所定の環境でアプリケーションのライフサイクル管理を行う場合に適しています (アプリケーションの新バージョンがデプロイされる際のデータベーススキーマの移行に使用するなど)。

2.3.4.1. API オブジェクトの管理

1 つの環境で定義されるリソースは、新しい環境へのインポートに備えて JSON または YAML ファイルの内容としてエクスポートされます。したがって JSON または YAML としての API オブジェクトの表現は、アプリケーションパイプラインで API オブジェクトをプロモートする際の作業単位として機能します。このコンテンツのエクスポートやインポートには oc CLI を使用します。

ヒント

OpenShift Online のプロモーションフローには必要ないですが、JSON または YAML はファイルに保存されるので、SCM システムを使用したコンテンツの保存や取得について検討することができます。これにより、ブランチの作成、バージョンに関連する各種ラベルやタグの割り当てやクエリーなど、SCM のバージョン関連の機能を活用できるようになります。

2.3.4.1.1. API オブジェクトステートのエクスポート

API オブジェクトの仕様は、oc export で取り込む必要があります。この操作は、オブジェクト定義から環境に固有のデータを取り除き (現在の namespace または割り当てられた IP アドレスなど)、異なる環境で再作成できるようにします (オブジェクトのフィルターされていないステートを出力する oc get 操作とは異なります)。

oc label を使用すると、API オブジェクトに対するラベルの追加、変更、または削除が可能になり、ラベルがあれば、操作 1 回で Pod のグループの選択や管理ができるので、プロモーションフロー用に収集されたオブジェクトを整理するのに有用であることが分かります。oc label を使用すると、適切なオブジェクトをエクスポートするのが簡単になります。 また、オブジェクトが新しい環境で作成された場合にラベルが継承されるので、各環境のアプリケーションコンポーネントの管理も簡素化されます。

注記

API オブジェクトには、Secret を参照する DeploymentConfig などの参照が含まれることがよくあります。API オブジェクトをある環境から別の環境へと移動する際、これらの参照も新しい環境へと移動することを確認する必要があります。

同様に DeploymentConfig などの API オブジェクトには、外部レジストリーを参照する ImageStreams の参照が含まれることがよくあります。API オブジェクトをある環境から別の環境へと移動する際、このような参照が新しい環境内で解決可能であることを確認する必要があります。つまり、参照が解決可能であり、ImageStream は新しい環境でアクセス可能なレジストリーを参照できる必要があります。詳細については、「イメージの移動」および「プロモートの注意事項」を参照してください。

2.3.4.1.2. API オブジェクトステートのインポート
2.3.4.1.2.1. 初期作成

アプリケーションを新しい環境に初めて導入する場合は、API オブジェクトの仕様を表現する JSON または YAML を使用し、oc create を実行して適切な環境で作成するだけで十分です。oc create を使用する場合、--save-config オプションに留意してください。アノテーション一覧にオブジェクトの設定要素を保存しておくことで、後の oc apply を使用したオブジェクトの変更が容易になります。

2.3.4.1.2.2. 反復修正

各種のステージング環境が最初に確立されると、プロモートサイクルが開始し、アプリケーションがステージからステージへと移動します。アプリケーションの更新には、アプリケーションの一部である API オブジェクトの修正を含めることができます。API オブジェクトは OpenShift Online システムの設定を表すことから、それらの変更が想定されます。それらの変更の目的として以下のケースが想定されます。

  • ステージング環境間における環境の違いについて説明する。
  • アプリケーションがサポートする各種シナリオを検証する。

oc CLI を使用することで、API オブジェクトの次のステージ環境への移行が実行されます。API オブジェクトを変更する oc コマンドセットは充実していますが、本トピックではオブジェクト間の差分を計算し、適用する oc apply に焦点を当てます。

とりわけ oc apply は既存のオブジェクト定義と共にファイルまたは標準入力 (stdin) を入力として取る 3 方向マージと見ることができます。以下の間で 3 方向マージを実行します。

  1. コマンドへの入力
  2. オブジェクトの現行バージョン
  3. 現行オブジェクトにアノテーションとして保存された最新のユーザー指定オブジェクト定義

その後に既存のオブジェクトは結果と共に更新されます。

オブジェクトがソース環境とターゲット環境間で同一であることが予期されていない場合など、API オブジェクトの追加のカスタマイズが必要な場合に、oc set などの oc コマンドは、アップストリーム環境から最新のオブジェクト定義を適用した後に、オブジェクトを変更するために使用できます。

使用方法についての詳細は、「シナリオおよび実例」を参照してください。

2.3.4.2. イメージおよびイメージストリームの管理

OpenShift Online のイメージも一連の API オブジェクトで管理されます。ただし、イメージの管理はアプリケーションのプロモートにおける非常に中心的な部分であるため、イメージに最も直接的に関係するツールおよび API オブジェクトについては別途扱います。イメージのプロモートの管理には、手動および自動の方法を使用できます (パイプラインによるイメージの伝搬) 。

2.3.4.2.1. イメージの移動
注記

イメージの管理に関する注意事項すべての詳細については、「イメージの管理」のトピックを参照してください。

2.3.4.2.1.1. ステージング環境がレジストリーを共有する場合

ステージング環境が同じ OpenShift Online レジストリーを共有する場合 (すべてが同じ OpenShift Online クラスター上にある場合など)、アプリケーションのプロモートパイプラインのステージ間でイメージを 移動する 基本的な方法として、以下の 2 つ操作を実行できます。

  1. 1 つ目は、 docker tag および git tag と類似する oc tag コマンドにより、OpenShift Online のイメージストリームを特定のイメージへの参照で更新できます。また、あるイメージストリームから別のイメージストリームへとイメージの特定のバージョンへの参照をコピーすることも可能で、クラスター内の複数の異なるプロジェクト全体でもコピーが可能です。
  2. 2 つ目として、oc import-image は外部レジストリーとイメージストリーム間の橋渡しの機能を持ちます。レジストリーから所定のイメージのメタデータをインポートし、これを イメージストリームタグ としてイメージストリームに保存します。プロジェクトの各種の BuildConfigs および DeploymentConfigs がこれらの特定のイメージを参照できます。
2.3.4.2.1.2. ステージング環境が異なるレジストリーを使用する場合

ステージング環境が異なる OpenShift Online レジストリーを活用している場合、より高度な使用方法が見られます。内部レジストリーへのアクセス で、手順を詳細に説明していますが、まとめると以下のようになります。

  1. OpenShift Online のアクセストークンの取得と関連して docker コマンドを使用し、docker login コマンドに指定します。
  2. OpenShift Online レジストリーにログインした後、docker pull、docker tag および docker push を使用してイメージを移行します。
  3. イメージがパイプラインの次の環境のレジストリーで利用可能になってから、必要に応じて oc tag を使用してイメージストリームを設定します。
2.3.4.2.2. デプロイ

変更対象が基礎となるアプリケーションイメージであるか、アプリケーションを設定する API オブジェクトであるかを問わず、プロモートされた変更を認識するにはデプロイメントが通常必要になります。アプリケーションのイメージが変更される場合 (アップストリームからのイメージのプロモートの一環としての oc tag 操作または docker push の実行による場合など)、DeploymentConfig の ImageChangeTriggers が新規デプロイメントをトリガーできます。同様に DeploymentConfig API オブジェクト自体が変更されている場合、API オブジェクトがプロモーション手順によって更新されると (例: oc apply)、ConfigChangeTrigger がデプロイメントを開始できます。

それ以外の場合に、手動のデプロイメントを容易にする oc コマンドには以下が含まれます。

  • oc rollout: デプロイメント管理の新しいアプローチです (停止と再開のセマンティクスおよび履歴管理に関する充実した機能を含む)。
  • oc rollback: 以前のデプロイメントに戻すことができます。 プロモーションのシナリオでは、新しいバージョンのテストで問題が発生した場合には、以前のバージョンで問題がないかどうかを確認する必要がある場合があります。
2.3.4.2.3. Jenkins でのプロモーションフローの自動化

アプリケーションをプロモートする際に環境間での移動が必要なアプリケーションのコンポーネントを理解し、コンポーネントを移動する際に必要な手順を理解した後に、ワークフローのオーケストレーションおよび自動化を開始できます。OpenShift Online は、このプロセスで役立つ Jenkins イメージおよびプラグインを提供しています。

OpenShift Online Jenkins のイメージについては、イメージの使用 で詳細に説明されています。これには Jenkins と Jenkins パイプラインの統合を容易にする OpenShift Online プラグインのセットも含まれます。また、パイプラインビルドストラテジー により、Jenkins Pipeline と OpenShift Online との統合が容易になります。 これらすべてはアプリケーションのプロモートを含む、CI/CD の様々な側面の有効化に焦点を当てています。

アプリケーションのプロモート手順の手動による実行から自動へと切り替える際には、以下の OpenShift Online が提供する Jenkins 関連の機能に留意してください。

  • OpenShift Online は、OpenShift Online クラスターでのデプロイメントを非常に容易なものとするために高度にカスタマイズされた Jenkins のイメージを提供します。
  • Jenkins イメージには OpenShift Pipeline プラグインが含まれます。これはプロモーションワークフローを実装する構成要素を提供します。これらの構成要素には、イメージストリームの変更に伴う Jenkins ジョブのトリガーやそれらのジョブ内でのビルドおよびデプロイメントのトリガーも含まれます。
  • OpenShift Online の Jenkins Pipeline のビルドストラテジーを使用する BuildConfigs により、Jenkinsfile ベースの Jenkins Pipeline ジョブの実行が可能になります。パイプラインジョブは Jenkins における複雑なプロモーションフロー用の戦略を構成するものであり、OpenShift Pipeline プラグインにより提供される手順を利用できます。
2.3.4.2.4. プロモーションについての注意事項
2.3.4.2.4.1. API オブジェクト参照

API オブジェクトは他のオブジェクトを参照することができます。この一般的な使用方法として、イメージストリームを参照するDeploymentConfig を設定します (他の参照関係も存在する場合があります)。

ある環境から別の環境へと API オブジェクトをコピーする場合、すべての参照がターゲット環境内で解決できることが重要となります。以下のような参照のシナリオを見てみましょう。

  • プロジェクトに「ローカル」から参照している場合。この場合、参照オブジェクトは、プロジェクトを参照しているオブジェクトと同じプロジェクトに存在します。通常の方法として、参照しているオブジェクトと同じプロジェクト内にあるターゲット環境に参照オブジェクトをコピーできることを確認します。

  • 他のプロジェクトのオブジェクトを参照する場合。これは、共有プロジェクトのイメージストリームが複数のアプリケーションプロジェクトによって使用されている場合によくあるケースです (「イメージの管理」を参照してください)。この場合、参照するオブジェクトを新しい環境にコピーする際、ターゲット環境内で解決できるように参照を随時更新しなければなりません。以下が必要になる場合があります。

    • 共有されるプロジェクトの名前がターゲット環境では異なる場合、参照先のプロジェクトを変更する。
    • 参照されるオブジェクトを共有プロジェクトからターゲット環境のローカルプロジェクトへと移動し、主要オブジェクトをターゲット環境へと移動する際に参照をローカルルプロジェクトをポイントするよう更新する。
    • 参照されるオブジェクトのターゲット環境へのコピーおよびその参照の更新の他の組み合わせ。

通常は、新しい環境にコピーされるオブジェクトによって参照されるオブジェクトを確認し、参照がターゲット環境で解決可能であることを確認することをお勧めします。それ以外には、参照の修正を行うための適切なアクションを取り、ターゲット環境で参照されるオブジェクトを利用可能にすることができます。

2.3.4.2.4.2. イメージレジストリー参照

イメージストリームはイメージレポジトリーを参照してそれらが表すイメージのソースを示唆します。イメージストリームがある環境から別の環境へと移動する場合、レジストリーおよびレポジトリーの参照も変更すべきかどうかを検討することが重要です。

  • テスト環境と実稼働環境間の分離をアサートするために異なるイメージレジストリーが使用されている場合。
  • テスト環境および実稼働環境に対応したイメージを分離するために異なるイメージレポジトリーが使用されている場合。

上記のいずれかが該当する場合、イメージストリームはソース環境からターゲット環境にコピーされる際に、適切なイメージに対して解決されるよう変更される必要があります。これは、あるレジストリーおよびレポジトリーから別のレジストリーおよびレポジトリーへとイメージをコピーするという シナリオおよび実例に説明されている手順の追加として行われます。

2.3.4.3. 概要

現時点で、以下が定義されています。

  • デプロイされたアプリケーションを構成する新規アプリケーションアーティファクト。
  • アプリケーションのプロモーションアクティビティーと OpenShift Online によって提供されるツールおよびコンセプトとの相関関係。
  • OpenShift Online と CI/CD パイプラインエンジン Jenkins との統合。

このトピックにおける残りの部分では、OpenShift Online 内のアプリケーションのプロモーションフローのいくつかの例について扱います。

2.3.5. シナリオおよび実例

Docker、Kubernetes および OpenShift Online のエコシステムにより導入された新規アプリケーションアーティファクトのコンポーネントを定義した上に、このセクションでは OpenShift Online によって提供される方法およびツールを使用してこれらのコンポーネントを環境間でプロモートする方法を説明します。

アプリケーションを構成するコンポーネントにおいて、イメージは主要なアーティファクトです。これを前提とし、かつアプリケーションのプロモーションに当てはめると、中心的なアプリケーションのプロモーションパターンとなるのがイメージのプロモーションであり、この場合にイメージが作業単位となります。ほとんどのアプリケーションプロモーションシナリオでは、プロモーションパイプラインを使用したイメージの管理および伝搬が行われます。

単純なシナリオでは、パイプラインを使用したイメージの管理および伝搬のみを扱います。プロモーションシナリオの対象範囲が広がるにつれ、API オブジェクトを筆頭とする他のアプリケーションアーティファクトがパイプラインで管理および伝搬されるアイテムのインベントリーに含まれます。

このトピックでは、手動および自動の両方のアプローチを使用して、イメージおよび API オブジェクトのプロモートに関する特定の実例をいくつか紹介します。最初にアプリケーションのプロモーションパイプラインの環境のセットアップに関して、以下の点に留意してください。

2.3.5.1. プロモーションのセットアップ

アプリケーションの初期リビジョンの開発が完了すると、次の手順として、プロモーションパイプラインのステージング環境に移行できるようにアプリケーションのコンテンツをパッケージ化します。

  1. 最初に、表示されるすべての API オブジェクトを移行可能なものとしてグループ化し、共通の label を適用します。 

    labels:
  promotion-group: <application_name>

    前述のように oc label コマンドは、さまざまな API オブジェクトのラベルの管理を容易にします。

    ヒント

    OpenShift Online テンプレートに API オブジェクトを最初に定義する場合、プロモート用にエクスポートする際にクエリーに使用する共通のラベルがすべての関連するオブジェクトにあることを簡単に確認できます。

  2. このラベルは後続のクエリーで使用できます。たとえば、アプリケーションの API オブジェクトの移行を行う以下の oc コマンドセットの呼び出しについて検討しましょう。 

    $ oc login <source_environment>
$ oc project <source_project>
$ oc export dc,is,svc,route,secret,sa -l promotion-group=<application_name> -o yaml > export.yaml
$ oc login <target_environment>
$ oc new-project <target_project> 1
$ oc create -f export.yaml
    1
    または、すでに存在している場合は oc project <target_project> を実行します。
    注記

    oc export コマンドでは、イメージストリーム用に is タイプを含めるかどうかは、パイプライン内の異なる環境全体でイメージ、イメージストリーム、およびレジストリーの管理方法をどのように選択するかによって変わってきます。この点に関する注意事項を以下で説明しています。イメージの管理 のトピックも参照してください。

  3. プロモーションパイプラインの各種のステージング環境で使用されるそれぞれのレジストリーに対して機能するトークンを取得する必要があります。各環境について以下を実行します。

    1. 環境にログインします。 

      $ oc login <each_environment_with_a_unique_registry>

    2. 以下を実行してアクセストークンを取得します。 

      $ oc whoami -t
    3. 次回に使用できるようにトークン値をコピーアンドペーストします。

2.3.5.2. 繰り返し可能なプロモーションプロセス

パイプラインの異なるステージング環境での初回のセットアップ後に、プロモーションパイプラインを使用したアプリケーションの反復を検証する繰り返し可能な手順のセットを開始できます。これらの基本的な手順は、ソース環境のイメージまたは API オブジェクトが変更されるたびに実行されます。

更新後のイメージの移動→更新後の API オブジェクトの移動→環境固有のカスタマイズの適用

  1. 通常、最初の手順ではアプリケーションに関連するイメージの更新をパイプラインの次のステージにプロモートします。前述のように、ステージング環境間で OpenShift Online レジストリーが共有されるかどうかが、イメージをプロモートする上での主要な差別化要因となります。

    1. レジストリーが共有されている場合、単に oc tag を使用します。 

      $ oc tag <project_for_stage_N>/<imagestream_name_for_stage_N>:<tag_for_stage_N> <project_for_stage_N+1>/<imagestream_name_for_stage_N+1>:<tag_for_stage_N+1>

    2. レジストリーが共有されていない場合、ソースおよび宛先の両方のレジストリーにログインする際、各プロモーションパイプラインレジストリーに対してアクセストークンを使用でき、アプリケーションイメージのプル、タグ付け、およびプッシュを随時実行できます。

      1. ソース環境レジストリーにログインします。 

        $ docker login -u <username> -e <any_email_address> -p <token_value> <src_env_registry_ip>:<port>

      2. アプリケーションのイメージをプルします。 

        $ docker pull <src_env_registry_ip>:<port>/<namespace>/<image name>:<tag>

      3. アプリケーションのイメージを宛先レジストリーの場所にタグ付けし、宛先ステージング環境と一致するように namespace、名前、タグを随時更新します。 

        $ docker tag <src_env_registry_ip>:<port>/<namespace>/<image name>:<tag> <dest_env_registry_ip>:<port>/<namespace>/<image name>:<tag>

      4. 宛先ステージング環境レジストリーにログインします。 

        $ docker login -u <username> -e <any_email_address> -p <token_value> <dest_env_registry_ip>:<port>

      5. イメージを宛先にプッシュします。 

        $ docker push <dest_env_registry_ip>:<port>/<namespace>/<image name>:<tag>
        ヒント

        外部レジストリーからイメージの新バージョンを自動的にインポートするために、oc tag コマンドで --scheduled オプションを使用できます。これを使用する場合、ImageStreamTag が参照するイメージは、イメージをホストするレジストリーから定期的にプルされます。

  2. 次に、アプリケーションの変化によってアプリケーションを構成する API オブジェクトの根本的な変更や API オブジェクトセットへの追加と削除が必要となるケースがあります。アプリケーションの API オブジェクトにこのような変化が生じると、OpenShift Online CLI はあるステージング環境から次の環境へと変更を移行するための広範囲のオプションを提供します。

    1. プロモーションパイプラインの初回セットアップ時と同じ方法で開始します。 

      $ oc login <source_environment>
$ oc project <source_project>
$ oc export dc,is,svc,route,secret,sa -l promotion-group=<application_name> -o yaml > export.yaml
$ oc login <target_environment>
$ oc <target_project>

    2. 単に新しい環境でリソースを作成するのではなく、それらを更新します。これを実行するための方法がいくつかあります。

      1. より保守的なアプローチとして、oc apply を使用し、ターゲット環境内の各 API オブジェクトに新しい変更をマージできます。これを実行することにより、--dry-run=true オプションを実行し、オブジェクトを実際に変更する前に結果として得られるオブジェクトを確認することができます。 

        $ oc apply -f export.yaml --dry-run=true

        問題がなければ、apply コマンドを実際に実行します。 

        $ oc apply -f export.yaml

        apply コマンドはより複雑なシナリオで役立つ追加の引数をオプションで取ります。詳細については oc apply --help を参照してください。

      2. または、よりシンプルで積極的なアプローチとして、oc replace を使用できます。この更新および置換についてはドライランは利用できません。最も基本的な形式として、以下を実行できます。 

        $ oc replace -f export.yaml

        apply と同様に、replace はより高度な動作については他の引数をオプションで取ります。詳細は、oc replace --help を参照してください。

  3. 直前の手順では、導入された新しい API オブジェクトは自動的に処理されますが、API オブジェクトがソースの環境から削除された場合には、 oc delete を使用してこれらをターゲットの環境から手動で削除する必要があります。

  4. ステージング環境ごとに必要な値が異なる可能性があるため、API オブジェクトで引用された環境変数を調整する必要がある場合があります。この場合は oc set env を使用します。 

    $ oc set env <api_object_type>/<api_object_ID> <env_var_name>=<env_var_value>
  5. 最後に、oc rollout コマンドまたは、上記の「デプロイメント」のセクションで説明した他のメカニズムを使用して、更新したアプリケーションの新規デプロイメントをトリガーします。

2.3.5.3. Jenkins を使用した反復可能なプロモーションプロセス

OpenShift Online の Jenkins Docker イメージで定義された OpenShift サンプルジョブは、Jenkins 構成ベースの OpenShift Online でのイメージのプロモーションの例です。このサンプルのセットアップは OpenShift Origin ソースリポジトリー にあります。

このサンプルには以下が含まれます。

  • CI/CD エンジンとして Jenkins の使用。
  • OpenShift Pipeline plug-in for Jenkins の使用。このプラグインでは、Jenkins Freestyle および DSL Job ステップとしてパッケージされた OpenShift Online の oc CLI が提供する機能サブセットを提供します。oc バイナリーは、OpenShift Online 用の Jenkins Docker イメージにも含まれており、Jenkins ジョブで OpenShift Online と対話するために使用することも可能です。
  • OpenShift Online が提供する Jenkins のテンプレート。一時ストレージおよび永続ストレージの両方のテンプレートがあります。
  • サンプルアプリケーション: OpenShift Origin ソースリポジトリー で定義されます。 このアプリケーションは ImageStreams、ImageChangeTriggers、ImageStreamTags、BuildConfigs およびプロモーションパイプラインの各種ステージに対応した別個の DeploymentConfigs と Services を利用します。

以下では、OpenShift のサンプルジョブを詳細に検証していきます。

  1. 最初のステップ は、oc scale dc frontend --replicas=0 の呼び出しと同じです。この手順は、実行されている可能性のあるアプリケーションイメージの以前のバージョンを終了させるために実行されます。
  2. 2 番目のステップ は oc start-build frontend の呼び出しと同じです。
  3. 3 番目のステップ は oc rollout latest dc/frontend の呼び出しと同じです。
  4. 4 番目のステップ は、このサンプルの「テスト」を行います。このステップでは、アプリケーションに関連するサービスがネットワークからアクセス可能であることを確認します。背後で、OpenShift Online サービスに関連する IP アドレスやポートにソケット接続を試みます。当然のこととして別のテストを追加することも可能です (OpenShift Pipepline plug-in ステップを使用しない場合は、Jenkins Shell ステップを使用して、OS レベルのコマンドとスクリプトを使用してアプリケーションをテストします)。
  5. 5 番目のステップ は、アプリケーションがテストに合格したことを前提としているため、イメージは「Ready (使用準備完了)」としてマークされます。このステップでは、新規の prod タグが 最新の イメージをベースにしたアプリケーションイメージ用に作成されます。フロントエンド の DeploymentConfig でそのタグに対して ImageChangeTrigger が 定義されている場合には、対応する「実稼働」デプロイメントが起動されます。
  6. 6 番目と最後のステップ は検証のステップで、プラグインは OpenShift Online が「実稼働」デプロイメントの必要な数のレプリカを起動したことを確認します。