第2章 アプリケーションライフサイクル管理

2.1. 開発プロセスの計画

2.1.1. 概要

OpenShift Container Platform はアプリケーションをビルドし、デプロイできるように設計されています。OpenShift Container Platform を開発プロセスにどの程度組み込むかに応じて、以下から選択できます。

  • OpenShift Container Platform プロジェクト内での開発にフォーカスし、アプリケーションをゼロからビルドし、その後の継続的な開発とライフサイクルの管理を行うために OpenShift Container Platform を使用する。
  • 別の環境ですでに開発したアプリケーション (例: バイナリー、コンテナーイメージ、ソースコード) を OpenShift Container Platform にデプロイする。

2.1.2. 開発環境としての OpenShift Container Platform の使用

Deploying then developing on OpenShift Container Platform

OpenShift Container Platform を直接使用してアプリケーションの開発をゼロから行うことができます。この種類の開発プロセスを計画する場合には、以下の手順を考慮してください。

初期計画

  • アプリケーションの機能は?
  • どのプログラミング言語を使用して開発するか?

OpenShift Container Platform へのアクセス

  • この時点で、ご自身または組織内の管理者が OpenShift Container Platform をインストールする必要があります。

開発

  • 各自が選択するエディターまたは IDE を使用して、アプリケーションの基本的なスケルトンを作成します。このスケルトンは、OpenShift Container Platform が「アプリケーションの種類」について認識できるように適切に作成されている必要があります。
  • コードを Git リポジトリーにプッシュします。

生成

管理

  • アプリケーションコードの開発を開始します。
  • アプリケーションが正常にビルドされることを確認します。
  • 引き続きコードをローカルで開発し、コードを改良します。
  • コードを Git リポジトリーにプッシュします。
  • 追加の設定が必要かどうかを確認します。追加のオプションについて『開発者ガイド』で確認してください。

検証

  • アプリケーションは数多くの方法で検証できます。変更をアプリケーションの Git リポジトリーにプッシュし、OpenShift Container Platform を使用してアプリケーションの再ビルドおよび再デプロイを行うことができます。または、rsync でホットデプロイを実行して、コードの変更を実行中の Pod で同期できます。

2.1.3. アプリケーションの OpenShift Container Platform へのデプロイ

Developing then deploying on OpenShift Container Platform

アプリケーション開発ストラテジーの別の可能性として、ローカルで開発してから OpenShift Container Platform を使用して完全に開発されたアプリケーションをデプロイする方法があります。アプリケーションコードを先に準備してからビルドし、完了後に OpenShift Container Platform インストールにデプロイする場合は、以下の手順を使用します。

初期計画

  • アプリケーションの機能は?
  • どのプログラミング言語を使用して開発するか?

開発

  • 任意のエディターまたは IDE を使用してアプリケーションコードを開発します。
  • アプリケーションコードをローカルでビルドしてテストします。
  • コードを Git リポジトリーにプッシュします。

OpenShift Container Platform へのアクセス

  • この時点で、ご自身または組織内の管理者が OpenShift Container Platform をインストールする必要があります。

生成

検証

  • 前述の生成手順においてビルドおよびデプロイしたアプリケーションが OpenShift Container Platform で正常に実行されていることを確認します。

管理

  • 納得の行く結果が得られるまで、アプリケーションコードの開発を続けます。
  • 新たにプッシュされたコードを受け入れるには、アプリケーションを OpenShift Container Platform で再ビルドします。
  • 追加の設定が必要かどうかを確認します。追加のオプションについて『開発者ガイド』で確認してください。

2.2. 新規アプリケーションの作成

2.2.1. 概要

OpenShift CLI または web コンソールのいずれかを使用して、ソースまたはバイナリーコード、イメージおよびテンプレート (あるいは両方) を含むコンポーネントから新規の OpenShift Container Platform アプリケーションを作成できます。

2.2.2. CLI を使用したアプリケーションの作成

2.2.2.1. ソースコードからのアプリケーションの作成

new-app コマンドでは、ローカルまたはリモートの Git リポジトリーのソースコードからアプリケーションを作成できます。

ローカルディレクトリーの Git リポジトリーを使用してアプリケーションを作成するには、以下を実行します。

$ oc new-app /path/to/source/code
注記

ローカルの Git リポジトリーを使用する場合には、OpenShift Container Platform クラスターがアクセス可能な URL を参照する origin という名前のリモートが必要です。認識されているリモートがない場合は、new-app により「バイナリービルド」が作成されます。

リモート Git リポジトリーを使用してアプリケーションを作成するには、以下を実行します。

$ oc new-app https://github.com/sclorg/cakephp-ex

プライベートのリモート Git リポジトリーを使用してアプリケーションを作成するには、以下を実行します。

$ oc new-app https://github.com/youruser/yourprivaterepo --source-secret=yoursecret
注記

プライベートのリモート Git リポジトリーを使用する場合には、--source-secret フラグを使用して、既存の「ソースクローンのシークレット」を指定できます。これは、BuildConfig に挿入され、リポジトリーにアクセスできるようになります。

--context-dir フラグを指定することで、ソースコードリポジトリーのサブディレクトリーを使用できます。リモート Git リポジトリーおよびコンテキストのサブディレクトリーを使用してアプリケーションを作成する場合は、以下を実行します。

$ oc new-app https://github.com/sclorg/s2i-ruby-container.git \
    --context-dir=2.0/test/puma-test-app

また、リモートの URL を指定する場合には、以下のように URL の最後に #<branch_name> を追加することで、使用する Git ブランチを指定できます。

$ oc new-app https://github.com/openshift/ruby-hello-world.git#beta4

new-app コマンドは、ビルド設定 (BuildConfig)を作成し、これはソースコードからイメージという新規のアプリケーションを作成します。new-app コマンドは通常、デプロイメント設定 (DeploymentConfig)を作成して新規のイメージをデプロイするほか、サービスを作成してイメージを実行するデプロイメントへの負荷分散したアクセスを提供します。

OpenShift Container Platform は DockerPipeline または Source ビルドストラテジー のいずれを使用すべきかを自動的に 検出 します。また、Source ビルドの場合は、適切な言語のビルダーイメージを検出します

ビルドストラテジーの検出

新規アプリケーションの作成時に Jenkinsfile がソースリポジトリーの root または指定されたコンテキストディレクトリーに存在する場合に、OpenShift Container Platform は Pipeline ビルドストラテジー を生成します。または、Dockerfile がある場合、OpenShift Container Platform は Docker ビルドストラテジー を生成します。あるいは、Source ビルドストラテジー を生成します。

ビルドストラテジーを上書きするには、--strategy フラグを dockerpipeline または source のいずれかに設定してください。

$ oc new-app /home/user/code/myapp --strategy=docker
注記

oc コマンドを使用するには、ビルドソースを含むファイルがリモートの git リポジトリーで利用できる必要があります。ソースのすべてのビルドには、git remote -v を使用する必要があります。

言語検出

Source ビルドストラテジーを使用する場合に、new-app はリポジトリーの root または指定したコンテキストディレクトリーに特定のファイルが存在するかどうかで、使用する言語ビルダーを判別しようとします。

表2.1 new-app が検出する言語

言語ファイル

dotnet

project.json*.csproj

jee

pom.xml

nodejs

app.jsonpackage.json

perl

cpanfileindex.pl

php

composer.jsonindex.php

python

requirements.txtsetup.py

ruby

Gemfile, Rakefileconfig.ru

scala

build.sbt

golang

Godepsmain.go

言語の検出後、new-app は OpenShift Container Platform サーバーで、検出言語と一致して supports アノテーションが指定された イメージストリーム タグか、または検出された言語の名前に一致するイメージストリームの有無を検索します。一致するものが見つからない場合には、new-appDocker Hub レジストリー で名前をベースにした検出言語と一致するイメージの検索を行います。

~ をセパレーターとして使用し、イメージ (イメージストリームまたはコンテナーの仕様) とリポジトリーを指定して、ビルダーが特定のソースリポジトリーを使用するようにイメージを上書きすることができます。この方法を使用すると、ビルドストラテジーの検出 および 言語の検出 は実行されない点に留意してください。

たとえば、リモートリポジトリーのソースを使用して myproject/my-ruby イメージストリームを作成する場合は、以下を実行します。

$ oc new-app myproject/my-ruby~https://github.com/openshift/ruby-hello-world.git

ローカルリポジトリーのソースを使用して openshift/ruby-20-centos7:latest コンテナーのイメージストリームを作成するには、以下を実行します。

$ oc new-app openshift/ruby-20-centos7:latest~/home/user/code/my-ruby-app
注記

言語の検出では、リポジトリーのクローンを作成し、検査できるように Git クライアントをローカルにインストールする必要があります。Git が使用できない場合、<image>~<repository> 構文を指定し、リポジトリーで使用するビルダーイメージを指定して言語の検出手順を回避することができます。

-i <image> <repository> 呼び出しでは、アーティファクトのタイプを判別するために new-apprepository のクローンを試行する必要があります。そのため、これは Git が利用できない場合には失敗します。

同様に、-i <image> --code <repository> 呼び出しを使用するには、image がソースコードのビルダーとして使用されるか、またはデータベースイメージの場合のように別個にデプロイされる必要があるかどうかを判別するために、new-apprepository のクローンを作成する必要があります。

2.2.2.2. イメージからアプリケーションを作成する方法

既存のイメージからアプリケーションのデプロイが可能です。イメージは、OpenShift Container Platform サーバー内のイメージストリーム、指定したレジストリー内またはDocker Hub レジストリー 内のイメージ、またはローカルの Docker サーバー内のイメージから取得できます。

new-app コマンドは、渡された引数に指定されたイメージの種類を判断しようとしますが、イメージがコンテナーイメージ (--docker-image の引数を使用) なのか、またはイメージストリーム (-i|--image の引数を使用) なのか、new-app に明示できます。

注記

ローカル Docker リポジトリーからイメージを指定した場合、同じイメージが OpenShift Container Platform のクラスターノードでも利用できることを確認する必要があります。

たとえば、DockerHub MySQL イメージからアプリケーションを作成するには、以下を実行します。

$ oc new-app mysql

プライベートのレジストリーのイメージを使用してアプリケーションを作成する場合には、コンテナーイメージの仕様全体を以下のように指定します。

$ oc new-app myregistry:5000/example/myimage
注記

イメージを含むレジストリーが SSL でセキュリティー保護 されていない場合には、クラスター管理者は、OpenShift Container Platform ノードホストの Docker デーモンが、対象のレジストリーを参照する --insecure-registry フラグを指定して実行されていることを確認する必要があります。また、--insecure-registry フラグを指定して、セキュアでないレジストリーからイメージを取得されていることを、new-app に示す必要があります。

以下のように、既存の イメージストリーム および任意の イメージストリームタグ でアプリケーションを作成することができます。

$ oc new-app my-stream:v1

2.2.2.3. テンプレートからのアプリケーションの作成

テンプレート名を引数として指定することで、事前に保存した テンプレート またはテンプレートファイルからアプリケーションを作成することができます。たとえば、サンプルアプリケーションテンプレート を保存し、これを利用してアプリケーションを作成できます。

保存したテンプレートからアプリケーションを作成する場合、以下を実行します。

$ oc create -f examples/sample-app/application-template-stibuild.json
$ oc new-app ruby-helloworld-sample

事前に OpenShift Container Platform に保存することなく、ローカルファイルシステムでテンプレートを直接使用するには、以下の -f|--file 引数を使用します。

$ oc new-app -f examples/sample-app/application-template-stibuild.json

テンプレートパラメーター

テンプレート をベースとするアプリケーションを作成する場合、以下の -p|--param 引数を使用してテンプレートで定義したパラメーター値を設定します。

$ oc new-app ruby-helloworld-sample \
    -p ADMIN_USERNAME=admin -p ADMIN_PASSWORD=mypassword

パラメーターをファイルに保存しておいて、--param-file を指定して、テンプレートをインスタンス化する時にこのファイルを使用することができます。標準入力からパラメーターを読み込む場合は、以下のように--param-file=- を使用します。

$ cat helloworld.params
ADMIN_USERNAME=admin
ADMIN_PASSWORD=mypassword
$ oc new-app ruby-helloworld-sample --param-file=helloworld.params
$ cat helloworld.params | oc new-app ruby-helloworld-sample --param-file=-

2.2.2.4. アプリケーション作成における追加修正

new-app コマンドは、OpenShift Container Platform オブジェクトを生成します。このオブジェクトにより、作成されるアプリケーションがビルドされ、デプロイされ、実行されます。通常、これらのオブジェクトはインプットソースリポジトリーまたはインプットされたイメージに由来する名前を使用して現在のプロジェクトに作成されますが、new-app によりこの動作を修正することができます。

new-app で作成したオブジェクトのセットは、ソースリポジトリー、イメージまたはテンプレートなどのインプットとして渡されるアーティファクトによって異なります。

表2.2 new-app 出力オブジェクト

オブジェクト説明

BuildConfig

BuildConfig は、コマンドラインで指定された各ソースリポジトリーに作成されます。BuildConfig は使用するストラテジー、ソースのロケーション、およびビルドの出力ロケーションを指定します。

ImageStreams

BuildConfig では、通常 2 つの ImageStreams が作成されます。1 つ目は、インプットイメージを表します。Source ビルドでは、これはビルダーイメージです。Docker ビルドでは、これは FROM イメージです。2 つ目は、アウトプットイメージを表します。コンテナーイメージが new-app にインプットとして指定された場合に、このイメージに対してもイメージストリームが作成されます。

DeploymentConfig

DeploymentConfig は、ビルドの出力または指定されたイメージのいずれかをデプロイするために作成されます。new-app コマンドは、結果として生成される DeploymentConfig に含まれるコンテナーに指定されるすべての Docker ボリュームに emptyDir ボリュームを作成します。

Service

new-app コマンドは、インプットイメージで公開ポートを検出しようと試みます。公開されたポートで数値が最も低いものを使用して、そのポートを公開するサービスを生成します。new-app 完了後に別のポートを公開するには、単に oc expose コマンドを使用し、追加のサービスを生成するだけです。

その他

テンプレート のインスタンスを作成する際に、他のオブジェクトがテンプレートに基づいて生成される可能性があります。

2.2.2.4.1. 環境変数の指定

テンプレートソース または イメージ からアプリケーションを生成する場合、-e|--env 引数を使用し、ランタイムに環境変数をアプリケーションコンテナーに渡すことができます。

$ oc new-app openshift/postgresql-92-centos7 \
    -e POSTGRESQL_USER=user \
    -e POSTGRESQL_DATABASE=db \
    -e POSTGRESQL_PASSWORD=password

変数は、--env-file 引数を使用してファイルから読み取ることもできます。

$ cat postgresql.env
POSTGRESQL_USER=user
POSTGRESQL_DATABASE=db
POSTGRESQL_PASSWORD=password
$ oc new-app openshift/postgresql-92-centos7 --env-file=postgresql.env

さらに --env-file=- を使用することで、標準入力で環境変数を指定することもできます。

$ cat postgresql.env | oc new-app openshift/postgresql-92-centos7 --env-file=-

詳細については、「環境変数の管理」を参照してください。

注記

-e|--env または --env-file 引数で渡される環境変数では、new-app 処理の一環として作成される BuildConfig オブジェクトは更新されません。

2.2.2.4.2. ビルド環境変数の指定

テンプレートソース または イメージ からアプリケーションを生成する場合、--build-env 引数を使用し、ランタイムに環境変数をビルドコンテナーに渡すことができます。

$ oc new-app openshift/ruby-23-centos7 \
    --build-env HTTP_PROXY=http://myproxy.net:1337/ \
    --build-env GEM_HOME=~/.gem

変数は、--build-env-file 引数を使用してファイルから読み取ることもできます。

$ cat ruby.env
HTTP_PROXY=http://myproxy.net:1337/
GEM_HOME=~/.gem
$ oc new-app openshift/ruby-23-centos7 --build-env-file=ruby.env

さらに --build-env-file=- を使用して、環境変数を標準入力で指定することもできます。

$ cat ruby.env | oc new-app openshift/ruby-23-centos7 --build-env-file=-
2.2.2.4.3. ラベルの指定

ソースイメージ または テンプレート からアプリケーションを生成する場合、-l|--label 引数を使用し、作成されたオブジェクトにラベルを追加できます。ラベルを使用すると、アプリケーションに関連するオブジェクトを一括で選択、設定、削除することが簡単になります。

$ oc new-app https://github.com/openshift/ruby-hello-world -l name=hello-world
2.2.2.4.4. 作成前の出力の表示

new-app が作成する内容についてのドライランを確認するには、yaml または json の値と共に -o|--output 引数を使用できます。次にこの出力を使用して、作成されるオブジェクトのプレビューまたは編集可能なファイルへのリダイレクトを実行できます。問題がなければ、oc create を使用して OpenShift Container Platform オブジェクトを作成できます。

new-app アーティファクトをファイルに出力するには、これらを編集し、作成します。

$ oc new-app https://github.com/openshift/ruby-hello-world \
    -o yaml > myapp.yaml
$ vi myapp.yaml
$ oc create -f myapp.yaml
2.2.2.4.5. 別名でのオブジェクトの作成

通常 new-app で作成されるオブジェクトの名前はソースリポジトリーまたは生成に使用されたイメージに基づいて付けられます。コマンドに --name フラグを追加することで、生成されたオブジェクトの名前を設定できます。

$ oc new-app https://github.com/openshift/ruby-hello-world --name=myapp
2.2.2.4.6. 別のプロジェクトでのオブジェクトの作成

通常 new-app は現在のプロジェクトにオブジェクトを作成しますが、-n|--namespace 引数を使用してアクセス可能な別のプロジェクトにオブジェクトを作成することができます。

$ oc new-app https://github.com/openshift/ruby-hello-world -n myproject
2.2.2.4.7. 複数のオブジェクトの作成

new-app コマンドは、複数のパラメーターを new-app に指定して複数のアプリケーションを作成できます。コマンドラインで指定するラベルは、この単一コマンドで作成されるすべてのオブジェクトに適用され、環境変数はソースまたはイメージから作成されるすべてのコンポーネントに適用されます。

ソースリポジトリーおよび Docker Hub イメージからアプリケーションを作成するには、以下を実行します。

$ oc new-app https://github.com/openshift/ruby-hello-world mysql
注記

ソースコードリポジトリーおよびビルダーイメージが別個の引数として指定されている場合、new-app はソースコードリポジトリーのビルダーとしてそのビルダーイメージを使用します。これを意図していない場合は、~ セパレーターを使用してソースに必要なビルダーイメージを指定します。

2.2.2.4.8. 単一 Pod でのイメージとソースのグループ化

new-app コマンドにより、単一 Pod に複数のイメージをまとめてデプロイできます。イメージのグループ化を指定するには + セパレーターを使用します。--group コマンドライン引数をグループ化する必要のあるイメージを指定する際に使用することもできます。ソースリポジトリーからビルドされたイメージを別のイメージと共にグループ化するには、そのビルダーイメージをグループで指定します。

$ oc new-app ruby+mysql

ソースからビルドされたイメージと外部のイメージをまとめてデプロイするには、以下を実行します。

$ oc new-app \
    ruby~https://github.com/openshift/ruby-hello-world \
    mysql \
    --group=ruby+mysql
2.2.2.4.9. イメージ、テンプレート、および他の入力の検索

イメージ、テンプレート、および oc new-app コマンドの他の入力内容を検索するには、--search フラグおよび --list フラグを追加します。たとえば、PHP を含むすべてのイメージまたはテンプレートを検索するには、以下を実行します。

$ oc new-app --search php

2.2.3. Web コンソールを使用したアプリケーションの作成

  1. 必要なプロジェクトで Add to Project をクリックします。

    Add to Project
  2. プロジェクト内にあるイメージの一覧またはサービスカタログからビルダーイメージを選択します。

    Browse Catalog
    注記

    以下に示すように、builder タグがアノテーションに一覧表示されている イメージストリームタグ のみが一覧に表示されます。

    kind: "ImageStream"
    apiVersion: "v1"
    metadata:
      name: "ruby"
      creationTimestamp: null
    spec:
      dockerImageRepository: "registry.redhat.io/openshift3/ruby-20-rhel7"
      tags:
        -
          name: "2.0"
          annotations:
            description: "Build and run Ruby 2.0 applications"
            iconClass: "icon-ruby"
            tags: "builder,ruby" 1
            supports: "ruby:2.0,ruby"
            version: "2.0"
    1
    ここに builder タグを含めると、この ImageStreamTag がビルダーとして Web コンソールに表示されます。
  3. 新規アプリケーション画面で設定を変更し、オブジェクトをアプリケーションをサポートするように設定します。

    Configuration Wizard

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

2.3.1. 概要

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

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

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

  • メタデータと関連ツールの豊富なセットを含む コンテナーイメージ
  • アプリケーションで使用されるためにコンテナーに挿入される 環境変数
  • 以下の OpenShift Container Platform の API オブジェクト (リソース定義としても知られています。「Core Concepts」を参照してください)。

    • アプリケーションで使用されるためにコンテナーに挿入される API オブジェクト。
    • OpenShift Container Platform によるコンテナーおよび Pod の管理方法を指示する API オブジェクト。

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

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

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

2.3.2.1. API オブジェクト

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

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

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

注記

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

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

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

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

2.3.3. デプロイメント環境

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

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

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

2.3.3.1. 留意事項

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

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

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

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

2.3.3.2. 概要

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

2.3.4. 方法およびツール

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

注記

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

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

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

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

ヒント

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

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

API オブジェクトの仕様は、oc get --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 Container Platform システムの設定を表すことから、それらの変更が想定されます。それらの変更の目的として以下のケースが想定されます。

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

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

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

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

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

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

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

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

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

2.3.4.2.1. イメージの移動
注記

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

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

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

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

ステージング環境が異なる OpenShift Container Platform レジストリーを活用している場合、より高度な使用方法が見られます。

内部レジストリーへのアクセス で、手順を詳細に説明していますが、まとめると以下のようになります。

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

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

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

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

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

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

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

  • OpenShift Container Platform は、OpenShift Container Platform クラスターでのデプロイメントを非常に容易なものとするために高度にカスタマイズされた Jenkins のイメージを提供します。
  • Jenkins イメージには OpenShift Pipeline プラグインが含まれます。これはプロモーションワークフローを実装する構成要素を提供します。これらの構成要素には、イメージストリームの変更に伴う Jenkins ジョブのトリガーやそれらのジョブ内でのビルドおよびデプロイメントのトリガーも含まれます。
  • OpenShift Container Platform の 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 Container Platform によって提供されるツールおよびコンセプトとの相関関係。
  • OpenShift Container Platform と CI/CD パイプラインエンジン Jenkins との統合。

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

2.3.5. シナリオおよび実例

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

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

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

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

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

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

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

    labels:
      promotion-group: <application_name>

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

    ヒント

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

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

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

    oc get --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 Container Platform レジストリーが共有されるかどうかが、イメージをプロモートする上での主要な差別化要因となります。

    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 Container Platform CLI はあるステージング環境から次の環境へと変更を移行するための広範囲のオプションを提供します。

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

      $ oc login <source_environment>
      $ oc project <source_project>
      $ oc get -o yaml --export dc,is,svc,route,secret,sa -l promotion-group=<application_name> > 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 Container Platform の Jenkins Docker イメージ で定義された OpenShift サンプル ジョブは、Jenkins 構成ベースの OpenShift Container Platform でのイメージのプロモーションの例です。このサンプルのセットアップは OpenShift Origin ソースリポジトリー にあります。

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

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

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

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