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

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

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

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

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

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

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

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

--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 は Docker、Pipeline または Source「ビルドストラテジー」のいずれを使用すべきかを自動的に「検出」します。また、Source ビルドの場合は、「適切な言語のビルダーイメージを検出します」。

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

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

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

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

言語検出

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

言語の検出後、new-app は、検出言語に一致する supports アノテーションが指定された 「イメージストリーム」タグか、または検出言語の名前に一致するイメージストリームがないかどうか、OpenShift Container Platform サーバーを検索します。一致するものが見つからない場合には、new-app は Docker 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

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

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

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

$ oc new-app mysql

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

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

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

$ oc new-app my-stream:v1

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

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

$ 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=-

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

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

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

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

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

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

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

$ cat ruby.env | oc new-app openshift/ruby-23-centos7 --build-env-file=-

$ oc new-app https://github.com/openshift/ruby-hello-world -l name=hello-world

$ oc new-app https://github.com/openshift/ruby-hello-world \
    -o yaml > myapp.yaml
$ vi myapp.yaml
$ oc create -f myapp.yaml

$ oc new-app https://github.com/openshift/ruby-hello-world --name=myapp

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

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

$ oc new-app ruby+mysql

$ oc new-app \
    ruby~https://github.com/openshift/ruby-hello-world \
    mysql \
    --group=ruby+mysql

$ oc new-app --search php

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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