第2章 Source-to-Image (S2I)
2.1. 概要
以下のトピックには、OpenShift Container Platform のユーザーに提供される、さまざまな S2I (Source-to-Image) 対応のイメージに関する情報が含まれます。
2.2. .NET Core
2.2.1. .NET Core を使用する利点
.NET Core は、自動メモリー管理および最新のプログラム言語が搭載された、汎用の開発プラットフォームです。.NET Core では、効率的に高品質のアプリケーションをビルドできます。.NET Core は、認定済みのコンテナー経由で Red Hat Enterprise Linux (RHEL 7) および OpenShift Container Platform から利用できます。.NET Core は以下の機能を提供します。
- マイクロサービスベースのアプローチに従う機能。この機能では、.NET でビルドされているコンポーネントと、Java でビルドされているコンポーネントがありますが、Red Hat Enterprise Linux や OpenShift Container Platform でサポートされている一般的なプラットフォームにおいてすべて実行可能です。
- Windows で新しい .NET Core ワークロードをより簡単に開発する機能。Red Hat Enterprise Linux または Windows Server のいずれかでデプロイおよび実行が可能です。
- 基礎となるインフラストラクチャーが Windows Server のみに依存することなしに、.NET アプリケーションを実行できる異種のデータセンター。
- OpenShift Container Platform から .NET、Java、Ruby および Python などの一般的な開発フレームワークの多くにアクセスできる機能。
2.2.2. サポートされているバージョン
- .NET Core バージョン 2.1
- .NET Core バージョン 2.0
- .NET Core バージョン 1.1
- .NET Core バージョン 1.0
- Red Hat Enterprise Linux (RHEL) 7 および OpenShift Container Platform バージョン 3.3 以降でサポートされています。
.NET Core バージョン 2.1 関連のリリースの詳細は、『Release Notes for Containers』を参照してください。
バージョン 1.1 および 1.0 (rh-dotnetcore11
および rh-dotnetcore10
) には project.json ビルドシステム (1.0.0-preview2
SDK) が同梱されています。RHEL システム以外にこの SDK をインストールする方法については、『version 1.1 Release Notes』の既知の問題についての章を参照してください。
2.2.3. イメージ
RHEL 7 イメージは、Red Hat レジストリーから入手できます。
$ docker pull registry.access.redhat.com/dotnet/dotnet-21-rhel7 $ docker pull registry.access.redhat.com/dotnet/dotnet-20-rhel7 $ docker pull registry.access.redhat.com/dotnet/dotnetcore-11-rhel7 $ docker pull registry.access.redhat.com/dotnet/dotnetcore-10-rhel7
RHEL S2I イメージ上の .NET Core 向けのイメージストリーム定義は、OpenShift Container Platform のインストール時に追加されるようになりました。
2.2.4. ビルドプロセス
S2I は、ソースコードをコンテナーに挿入し、コンテナーにソースコードの実行を準備をさせることで、実行準備が整ったイメージを生成します。S2I では、以下の手順を実行します。
- ビルダーイメージからコンテナーを起動します。
- アプリケーションソースをダウンロードします。
- ビルダーイメージコンテナーにスクリプトとアプリケーションソースをストリーミングします。
- (ビルダーイメージから) assemble スクリプトを実行します。
- 最終的なイメージを保存します。
ビルドプロセスの詳細の説明については、「S2I ビルドプロセス」を参照してください。
2.2.5. 環境変数
.NET Core イメージは、複数の環境変数をサポートします。この環境変数を設定して、.NET Core アプリケーションのビルド動作を制御することができます。
S2I ビルド設定または .s2i/environment ファイルに、ビルドの動作を制御する環境変数を設定して、ビルドの手順で利用できるようにする必要があります。
変数名 | 説明 | デフォルト |
---|---|---|
|
実行するプロジェクトを選択します。これは、プロジェクトファイル (例: csproj または fsproj) か、単一のプロジェクトファイルを含むフォルダーでなければなりません。 |
|
|
ビルド時のデフォルトの SDK バージョンを選択します。ソースリポジトリーに global.json ファイルがある場合には、これが優先されます。 |
イメージで利用可能な、一番古い SDK バージョン |
|
実行するアセンブリーを選択します。これには、 |
csproj ファイルの名前 |
|
復元操作時に使用する NuGet パッケージソースをスペース区切りの一覧で指定します。これは、NuGet.config ファイルで指定したすべてのソースよりも優先されます。 | |
|
アプリケーションをビルドする前にインストールする .NET ツールの一覧を指定します。固有のバージョンをインストールするには、パッケージ名の最後に | |
|
アプリケーションをビルドする前にインストールする NPM パッケージの一覧を指定します。 | |
|
テストするテストプロジェクトの一覧を指定します。これは、プロジェクトファイルか、または単一のプロジェクトファイルを含むフォルダーでなければなりません。 | |
|
|
|
|
dotnet ビルドコマンドの詳細レベルを指定します。これを設定した場合には、環境変数がビルドの開始時に出力されます。変数は、msbuild の詳細値 ( | |
|
アプリケーションのビルド時および実行時に使用する HTTP/HTTPS プロキシーを設定します。 | |
|
ビルドプロセス中にパッケージをダウンロードするカスタムの NPM レジストリーミラーを使用します。 | |
|
この変数を |
|
2.2.6. .NET Core ソースからのアプリケーションのクイックデプロイ
.NET イメージストリーム は最初にインストールする必要があります。標準インストールを実行した場合には、イメージストリームは存在します。
サンプルのリポジトリーに対して oc new-app
を実行すると、イメージを使用してアプリケーションをビルドできます。
$ oc new-app registry.access.redhat.com/dotnet/dotnet-21-rhel7~https://github.com/redhat-developer/s2i-dotnetcore-ex#dotnetcore-2.1 --context-dir=app $ oc new-app registry.access.redhat.com/dotnet/dotnet-20-rhel7~https://github.com/redhat-developer/s2i-dotnetcore-ex#dotnetcore-2.0 --context-dir=app $ oc new-app registry.access.redhat.com/dotnet/dotnetcore-11-rhel7~https://github.com/redhat-developer/s2i-dotnetcore-ex#dotnetcore-1.1 --context-dir=app $ oc new-app registry.access.redhat.com/dotnet/dotnetcore-10-rhel7~https://github.com/redhat-developer/s2i-dotnetcore-ex#dotnetcore-1.0 --context-dir=app
oc new-app
コマンドは、OpenShift Container Platform 3.3 より .NET Core ソースを検出できます。
2.2.7. .NET Core テンプレート
.NET イメージテンプレート および .NET イメージストリームは先に インストールする必要があります。標準インストールを実行した場合にはテンプレートとイメージストリームは存在します。これは、以下のコマンドで確認できます。
$ (oc get -n openshift templates; oc get -n openshift is) | grep dotnet
OpenShift Container Platform には .NET Core イメージのテンプレートが含まれており、サンプルアプリケーションを簡単にデプロイしやすくなります。
dotnet/dotnet-21-rhel7
で実行する .NET Core のサンプルアプリケーション は、以下のコマンドでデプロイ可能です。
$ oc new-app --template dotnet-example -p DOTNET_IMAGE_STREAM_TAG=dotnet:2.1 -p SOURCE_REPOSITORY_REF=dotnetcore-2.1
dotnet/dotnetcore-10-rhel7
で実行する .NET Core のサンプルアプリケーション は以下のコマンドでデプロイ可能です。
$ oc new-app --template dotnet-example
PostgreSQL をデータベースとして使用した .NET Core MusicStore アプリケーション は、以下のコマンドでデプロイ可能です。
$ oc new-app --template=dotnet-pgsql-persistent
2.3. Node.js
2.3.1. 概要
OpenShift Container Platform には 、Node.js アプリケーションのビルドおよび実行用に S2I が有効な Node.js イメージが含まれています。Node.js S2I ビルダーイメージは、必要な依存関係を使用してアプリケーションソースをアセンブルし、Node.js アプリケーションを含む新規イメージを作成します。このように作成されるイメージは、OpenShift Container Platform または Docker で実行可能です。
2.3.2. バージョン
現在、OpenShift Container Platform では、Node.js のバージョン 0.10、4 および 6 を提供しています。
2.3.3. イメージ
これらのイメージには 2 つのフレーバーがあり、ニーズに合わせて選択できます。
- RHEL 7
- CentOS 7
RHEL 7 ベースのイメージ
RHEL 7 イメージは、Red Hat レジストリーから入手できます。
$ docker pull registry.access.redhat.com/openshift3/nodejs-010-rhel7 $ docker pull registry.access.redhat.com/rhscl/nodejs-4-rhel7
CentOS 7 ベースのイメージ
このイメージは、Docker Hub で入手できます。
$ docker pull openshift/nodejs-010-centos7
これらのイメージを使用するには、イメージレジストリーから直接アクセスするか、ご自身の OpenShift Container Platform Docker レジストリーにプッシュしてください。さらに、Docker レジストリーまたは外部の場所に、対象イメージを参照するイメージストリームを作成することもでき、OpenShift Container Platform リソースがこのイメージストリームを参照できるようになります。提供されている全 OpenShift Container Platform イメージについてイメージストリームの定義例があります。
2.3.4. ビルドプロセス
S2I は、ソースコードをコンテナーに挿入し、コンテナーにソースコードの実行を準備をさせることで、実行準備が整ったイメージを生成します。S2I では、以下の手順を実行します。
- ビルダーイメージからコンテナーを起動します。
- アプリケーションソースをダウンロードします。
- ビルダーイメージコンテナーにスクリプトとアプリケーションソースをストリーミングします。
- (ビルダーイメージから) assemble スクリプトを実行します。
- 最終的なイメージを保存します。
ビルドプロセスの詳細の説明については、「S2I ビルドプロセス」を参照してください。
2.3.5. 設定
Node.js イメージは、環境変数を複数サポートし、環境変数を設定することで Node.js のラインタイムの設定や動作を制御できます。
イメージの一部としてこれらの環境変数を設定するには、ソースコードリポジトリーの中にある .s2i/environment ファイルに配置するか、ビルド設定の sourceStrategy
定義の環境セクションに定義します。
また、新規アプリケーションの作成時に既存のイメージを使用するか、デプロイメント設定などの既存のオブジェクトの環境変数を更新して環境変数を設定できます。
ビルドの動作を制御する環境変数は、s2i ビルド設定または .s2i/environment ファイルの一部として設定して、ビルドの手順で利用できるようにする必要があります。
変数名 | 説明 |
---|---|
|
|
|
デバッグポート。 |
|
カスタムの NPM レジストリーのミラー URL。全 NPM パッケージはビルドプロセス中にミラーリンクからダウンロードされます。 |
2.3.6. ホットデプロイ
ホットデプロイでは、新しい S2I ビルドを生成する必要なしに、アプリケーションに変更をすばやく加え、デプロイすることができます。アプリケーションのソースコードに加えられた変更を即座に検出するには、環境変数を DEV_MODE=true
に指定してビルドイメージを実行する必要があります。
新規アプリケーションの作成時または既存オブジェクトの環境変数の更新時に、新しい環境変数を設定できます。
DEV_MODE=true
の環境変数は、開発時またはデバッグ時にのみ使用するようにしてください。この変数の実稼働環境での使用は推奨されていません。
実行中の Pod のソースコードを変更するには、コンテナーにしてリモートシェルを開きます。
$ oc rsh <pod_id>
実行中のコンテナーに入ると、現在のディレクトリーは、ソースコードが配置されている /opt/app-root/src に変わります。
2.4. Perl
2.4.1. 概要
OpenShift Container Platform には 、Perl アプリケーションのビルドおよび実行用に S2I が有効な Perl イメージが含まれています。Perl S2I ビルダーイメージは、必要な依存関係を使用してアプリケーションソースをアセンブルし、Perl アプリケーションを含む新規イメージを作成します。このように作成されたイメージは、OpenShift Container Platform または Docker のいずれかで実行可能です。
2.4.2. バージョン
現時点で、OpenShift Container Platform は Perl バージョン 5.16、5.20 および 5.24 をサポートしています。
2.4.3. イメージ
イメージには 2 つのフレーバーがあり、ニーズに合わせて選択できます。
- RHEL 7
- CentOS 7
RHEL 7 ベースのイメージ
RHEL 7 イメージは、Red Hat レジストリーから入手できます。
$ docker pull registry.access.redhat.com/openshift3/perl-516-rhel7 $ docker pull registry.access.redhat.com/rhscl/perl-520-rhel7 $ docker pull registry.access.redhat.com/rhscl/perl-524-rhel7
CentOS 7 ベースのイメージ
Perl 5.16 の CentOS イメージは、Docker Hub で入手できます。
$ docker pull openshift/perl-516-centos7
これらのイメージを使用するには、イメージレジストリーから直接アクセスするか、ご自身の OpenShift Container Platform Docker レジストリーにプッシュしてください。さらに、Docker レジストリーまたは外部の場所に、対象イメージを参照するイメージストリームを作成することもでき、OpenShift Container Platform リソースがこのイメージストリームを参照できるようになります。提供されている全 OpenShift Container Platform イメージについてのイメージストリームの定義例があります。
2.4.4. ビルドプロセス
S2I は、ソースコードをコンテナーに挿入し、コンテナーにソースコードの実行を準備をさせることで、実行準備が整ったイメージを生成します。S2I では、以下の手順を実行します。
- ビルダーイメージからコンテナーを起動します。
- アプリケーションソースをダウンロードします。
- ビルダーイメージコンテナーにスクリプトとアプリケーションソースをストリーミングします。
- (ビルダーイメージから) assemble スクリプトを実行します。
- 最終的なイメージを保存します。
ビルドプロセスの詳細の説明については、「S2I ビルドプロセス」を参照してください。
2.4.5. 設定
Perl イメージは多数の環境変数を複数サポートし、環境変数を設定することで Perl のラインタイムの設定や動作を制御できます。
イメージの一部としてこれらの環境変数を設定するには、ソースコードリポジトリーの中にある .s2i/environment ファイルに配置するか、ビルド設定の sourceStrategy
定義の環境セクションに定義します。
また、新規アプリケーションの作成時に既存のイメージを使用するか、デプロイメント設定などの既存のオブジェクトの環境変数を更新して環境変数を設定できます。
ビルドの動作を制御する環境変数は、s2i ビルド設定または .s2i/environment ファイルの一部として設定して、ビルドの手順で利用できるようにする必要があります。
変数名 | 説明 |
---|---|
|
|
|
この変数は、cpanminus が依存関係のインストールに使用するミラーの URL を指定します。デフォルトではこの URL は指定されていません。 |
|
これを |
|
StartServers ディレクティブは、起動時に作成される子サーバープロセスの数を設定します。デフォルトは 8 です。 |
|
Apache により処理される同時要求の数。デフォルトは 256 ですが、メモリーに制限がある場合は自動的に数値が下がります。 |
2.4.6. ログへのアクセス
アクセスログは、標準出力にストリーミングされるので、oc logs
コマンドを使用して表示可能です。エラーログは /tmp/error_log ファイルに保存されているので、コンテナーにアクセスする oc rsh
コマンドを使用して表示できます。
2.4.7. ホットデプロイ
ホットデプロイでは、新しい S2I ビルドを生成する必要なしに、アプリケーションに変更をすばやく加え、デプロイすることができます。このイメージでホットデプロイを有効化するには、PERL_APACHE2_RELOAD
環境変数を true
に設定する必要があります。たとえば、oc new-app
コマンドを参照してください。oc set env
コマンドを使用して、既存オブジェクトの環境変数を更新できます。
このオプションは、開発またはデバッグの時にだけ使用するようにしてください。実稼働環境でこの設定をオンにすることは推奨しません。
実行中の Pod でソースコードを変更するには、oc rsh
コマンドを使用して、コンテナーに入ります。
$ oc rsh <pod_id>
実行中のコンテナーに入った後に、現在のディレクトリーを、ソースコードが配置されている /opt/app-root/src に設定します。
2.5. PHP
2.5.1. 概要
OpenShift Container Platform には 、PHP アプリケーションのビルドおよび実行用に S2I が有効な PHP イメージが含まれています。PHP S2I ビルダーイメージは、必要な依存関係を使用してアプリケーションソースをアセンブルし、PHP アプリケーションを含む新規イメージを作成します。このように作成されたイメージは、OpenShift Container Platform または Docker のいずれかで実行可能です。
2.5.2. バージョン
現時点で、OpenShift Container Platform では、PHP のバージョン 5.5、5.6 および 7.0 を提供しています。
2.5.3. イメージ
これらのイメージには 2 つのフレーバーがあり、ニーズに合わせて選択できます。
- RHEL 7
- CentOS 7
RHEL 7 ベースのイメージ
RHEL 7 イメージは、Red Hat レジストリーから入手できます。
$ docker pull registry.access.redhat.com/openshift3/php-55-rhel7 $ docker pull registry.access.redhat.com/rhscl/php-56-rhel7 $ docker pull registry.access.redhat.com/rhscl/php-70-rhel7
CentOS 7 ベースのイメージ
PHP 5.5 および 5.6 の CentOS イメージは、Docker Hub で入手できます。
$ docker pull openshift/php-55-centos7 $ docker pull openshift/php-56-centos7
これらのイメージを使用するには、イメージレジストリーから直接アクセスするか、ご自身の OpenShift Container Platform Docker レジストリーにプッシュしてください。さらに、Docker レジストリーまたは外部の場所に、対象イメージを参照するイメージストリームを作成することもでき、OpenShift Container Platform リソースがこのイメージストリームを参照できるようになります。
提供される全 OpenShift Container Platform イメージに対して イメージストリームの定義例 があります。
2.5.4. ビルドプロセス
S2I は、ソースコードをコンテナーに挿入し、コンテナーにソースコードの実行を準備をさせることで、実行準備が整ったイメージを生成します。S2I では、以下の手順を実行します。
- ビルダーイメージからコンテナーを起動します。
- アプリケーションソースをダウンロードします。
- ビルダーイメージコンテナーにスクリプトとアプリケーションソースをストリーミングします。
- (ビルダーイメージから) assemble スクリプトを実行します。
- 最終的なイメージを保存します。
ビルドプロセスの詳細の説明については、「S2I ビルドプロセス」を参照してください。
2.5.5. 設定
PHP イメージは数多くの環境変数を複数サポートし、環境変数を設定することで PHP のラインタイムの設定や動作を制御できます。
イメージの一部としてこれらの環境変数を設定するには、ソースコードリポジトリーの中にある .s2i/environment ファイルに配置するか、ビルド設定の sourceStrategy
定義の環境セクションに定義します。
また、新規アプリケーションの作成時に既存のイメージを使用するか、デプロイメント設定などの既存のオブジェクトの環境変数を更新して環境変数を設定できます。
ビルドの動作を制御する環境変数は、s2i ビルド設定または .s2i/environment ファイルの一部として設定して、ビルドの手順で利用できるようにする必要があります。
以下の環境変数は、php.ini ファイルに同等のプロパティー値を設定します。
変数名 | 説明 | デフォルト |
---|---|---|
|
PHP で対応する必要のあるエラー、警告、注意を PHP に通知します。 |
E_ALL & ~E_NOTICE |
|
PHP がエラー、注意、警告を出力するかどうか、さらに出力先を制御します。 |
ON |
|
PHP の起動シーケンス時に発生した表示エラーを通常の表示エラーとは別に処理するようにします。 |
OFF |
|
|
OFF |
|
対象のエラーに関連するドキュメントにエラーをリンクします。 |
ON |
|
PHP ソースファイルへのパス |
.:/opt/openshift/src:/opt/rh/php55/root/usr/share/pear |
|
セッションデータファイルの場所 |
/tmp/sessions |
|
アプリケーションのドキュメントルートを定義するパス (例: /public) |
/ |
以下の環境変数は、opcche.ini ファイルに同等のプロパティー値を設定します。
変数名 | 説明 | デフォルト |
---|---|---|
|
OPcache 共有メモリーのストレージサイズ |
16M |
|
更新のスクリプトタイムスタンプをどの頻度で確認するかを秒単位で指定します。0 に指定すると、OPcache はすべての要求の更新を確認します。 |
2 |
以下を設定して PHP 設定の読み込みに使用するディレクトリー全体を上書きすることも可能です。
変数名 | 説明 |
---|---|
|
php.ini ファイルにパスを設定します。 |
|
追加の .ini 設定ファイルのスキャンへのパス |
デフォルトの 'packagist.org' ではなく、カスタムの Composer リポジトリーのミラー URL を使用して、パッケージをダウンロードできます。
変数名 | 説明 | COMPOSER_MIRROR |
---|
2.5.5.1. Apache 設定
アプリケーションの DocumentRoot
がソースディレクトリーの /opt/openshift/src にネストされている場合には、独自の .htaccess ファイルで、デフォルトの Apache の動作を置き換え、アプリケーションの要求の処理方法を指定することができます。.htaccess ファイルは、アプリケーションソースのルートに配置する必要があります。
2.5.6. ログへのアクセス
アクセスログは、標準出力にストリーミングされるので、oc logs
コマンドを使用して表示可能です。エラーログは /tmp/error_log ファイルに保存されているので、コンテナーにアクセスする oc rsh
コマンドを使用して表示できます。
2.5.7. ホットデプロイ
ホットデプロイでは、新しい S2I ビルドを生成する必要なしに、アプリケーションに変更をすばやく加え、デプロイすることができます。アプリケーションのソースコードに加えられた変更を即座に検出するには、環境変数を OPCACHE_REVALIDATE_FREQ=0
に指定してビルドイメージを実行する必要があります。
たとえば、oc new-app
コマンドを参照してください。oc env
コマンドを使用して、既存オブジェクトの環境変数を更新できます。
このオプションは、開発またはデバッグの時にだけ使用するようにしてください。実稼働環境でこの設定をオンにすることは推奨しません。
実行中の Pod でソースコードを変更するには、oc rsh
コマンドを使用して、コンテナーに入ります。
$ oc rsh <pod_id>
実行中のコンテナーに入った後に、現在のディレクトリーを、ソースコードが配置されている /opt/app-root/src に設定します。
2.6. Python
2.6.1. 概要
OpenShift Container Platform には 、Python アプリケーションのビルドおよび実行用に S2I が有効な Python イメージが含まれています。Python S2I ビルダーイメージは、必要な依存関係を使用してアプリケーションソースをアセンブルし、Python アプリケーションを含む新規イメージを作成します。このように作成されたイメージは、OpenShift Container Platform または Docker で実行可能です。
2.6.2. バージョン
現時点では、OpenShift Container Platform では、Python のバージョン 2.7、3.3、3.4 および 3.5 を提供しています。
2.6.3. イメージ
これらのイメージには 2 つのフレーバーがあり、ニーズに合わせて選択できます。
- RHEL 7
- CentOS 7
RHEL 7 ベースのイメージ
RHEL 7 イメージは、Red Hat レジストリーから入手できます。
$ docker pull registry.access.redhat.com/rhscl/python-27-rhel7 $ docker pull registry.access.redhat.com/openshift3/python-33-rhel7 $ docker pull registry.access.redhat.com/rhscl/python-34-rhel7 $ docker pull registry.access.redhat.com/rhscl/python-35-rhel7
CentOS 7 ベースのイメージ
これらのイメージは、Docker Hub で入手できます。
$ docker pull centos/python-27-centos7 $ docker pull openshift/python-33-centos7 $ docker pull centos/python-34-centos7 $ docker pull centos/python-35-centos7
これらのイメージを使用するには、イメージレジストリーから直接アクセスするか、ご自身の OpenShift Container Platform Docker レジストリーにプッシュしてください。さらに、Docker レジストリーまたは外部の場所に、対象イメージを参照する イメージストリームを作成することもでき、OpenShift Container Platform リソースがこのイメージストリームを参照できるようになります。提供されている全 OpenShift Container Platform イメージについてイメージストリームの定義例 があります。
2.6.4. ビルドプロセス
S2I は、ソースコードをコンテナーに挿入し、コンテナーにソースコードの実行を準備をさせることで、実行準備が整ったイメージを生成します。S2I では、以下の手順を実行します。
- ビルダーイメージからコンテナーを起動します。
- アプリケーションソースをダウンロードします。
- ビルダーイメージコンテナーにスクリプトとアプリケーションソースをストリーミングします。
- (ビルダーイメージから) assemble スクリプトを実行します。
- 最終的なイメージを保存します。
ビルドプロセスの詳細の説明については、「S2I ビルドプロセス」を参照してください。
2.6.5. 設定
Python イメージは多数の環境変数を複数サポートし、環境変数を設定することで Python のラインタイムの設定や動作を制御できます。
イメージの一部としてこれらの環境変数を設定するには、ソースコードリポジトリーの中にある .s2i/environment ファイルに配置するか、ビルド設定の sourceStrategy
定義の環境セクションに定義します。
また、新規アプリケーションの作成時に既存のイメージを使用するか、デプロイメント設定などの既存のオブジェクトの環境変数を更新して環境変数を設定できます。
ビルドの動作を制御する環境変数は、s2i ビルド設定または .s2i/environment ファイルの一部として設定して、ビルドの手順で利用できるようにする必要があります。
変数名 | 説明 |
---|---|
|
この変数は、アプリケーションを起動する Python インタープリターに渡すファイル名を指定します。デフォルトでは、この変数は app.py に設定されています。 |
|
この変数は WSGI 呼び出し可能なオブジェクトを指定します。この変数のパターンは |
|
この変数は、gunicorn 設定 で有効な Python ファイルへのパスを指定します。 |
|
空でない値に設定して、ビルド時に |
|
空でない値に設定して、生成されたイメージの実行時に |
|
ビルドプロセス時に必要なパッケージをダウンロードするための、カスタムのインデックス URL またはミラーを使用するように、この変数を設定します。これは、requirements.txt ファイルに記載のパッケージにのみ影響があります。 |
|
これを設定して、ワーカー 数のデフォルト設定を変更します。デフォルトでは、これは利用可能なコアに 4 をかけた数字に設定されています。 |
2.6.6. ホットデプロイ
ホットデプロイでは、新しい S2I ビルドを生成する必要なしに、アプリケーションに変更をすばやく加え、デプロイすることができます。Django を使用する場合は、ホットデプロイメントはカスタマイズなしに使用できます。
Gunicorn を使用したホットデプロイメントを有効にするには、reload
オプション を true に設定して、リポジトリーに Gunicorn 設定ファイルが配置されているようにします。設定ファイルは、APP_CONFIG
環境変数を使用して指定します。たとえば、oc new-app
コマンドを参照してください。oc set env
コマンドを使用して、既存オブジェクトの環境変数を更新できます。
このオプションは、開発またはデバッグの時にだけ使用するようにしてください。実稼働環境でこの設定をオンにすることは推奨しません。
実行中の Pod でソースコードを変更するには、oc rsh
コマンドを使用して、コンテナーに入ります。
$ oc rsh <pod_id>
実行中のコンテナーに入った後に、現在のディレクトリーを、ソースコードが配置されている /opt/app-root/src に設定します。
2.7. Ruby
2.7.1. 概要
OpenShift Container Platform には 、Ruby アプリケーションのビルドおよび実行用に S2I が有効な Ruby イメージが含まれています。Ruby S2I ビルダーイメージは、必要な依存関係を使用してアプリケーションソースをアセンブルし、Ruby アプリケーションを含む新規イメージを作成します。このように作成されたイメージは、OpenShift Container Platform または Docker で実行可能です。
2.7.2. バージョン
現時点で、OpenShift Container Platform では、Ruby のバージョン 2.0、2.2 および 2.3 を提供しています。
2.7.3. イメージ
これらのイメージには 2 つのフレーバーがあり、ニーズに合わせて選択できます。
- RHEL 7
- CentOS 7
RHEL 7 ベースのイメージ
RHEL 7 イメージは、Red Hat レジストリーから入手できます。
$ docker pull registry.access.redhat.com/openshift3/ruby-20-rhel7 $ docker pull registry.access.redhat.com/rhscl/ruby-22-rhel7 $ docker pull registry.access.redhat.com/rhscl/ruby-23-rhel7
CentOS 7 ベースのイメージ
これらのイメージは、Docker Hub で入手できます。
$ docker pull openshift/ruby-20-centos7 $ docker pull openshift/ruby-22-centos7 $ docker pull centos/ruby-23-centos7
これらのイメージを使用するには、イメージレジストリーから直接アクセスするか、ご自身の OpenShift Container Platform Docker レジストリーにプッシュしてください。さらに、Docker レジストリーまたは外部の場所に、対象イメージを参照する イメージストリームを作成することもでき、OpenShift Container Platform リソースがこのイメージストリームを参照できるようになります。提供されている全 OpenShift Container Platform イメージについてイメージストリームの定義例 があります。
2.7.4. ビルドプロセス
S2I は、ソースコードをコンテナーに挿入し、コンテナーにソースコードの実行を準備をさせることで、実行準備が整ったイメージを生成します。S2I では、以下の手順を実行します。
- ビルダーイメージからコンテナーを起動します。
- アプリケーションソースをダウンロードします。
- ビルダーイメージコンテナーにスクリプトとアプリケーションソースをストリーミングします。
- (ビルダーイメージから) assemble スクリプトを実行します。
- 最終的なイメージを保存します。
ビルドプロセスの詳細の説明については、「S2I ビルドプロセス」を参照してください。
2.7.5. 設定
Ruby イメージは多数の環境変数を複数サポートし、環境変数を設定することで Ruby のラインタイムの設定や動作を制御できます。
イメージの一部としてこれらの環境変数を設定するには、ソースコードリポジトリーの中にある .s2i/environment ファイルに配置するか、ビルド設定の sourceStrategy
定義の環境セクションに定義します。
また、新規アプリケーションの作成時に既存のイメージを使用するか、デプロイメント設定などの既存のオブジェクトの環境変数を更新して環境変数を設定できます。
ビルドの動作を制御する環境変数は、s2i ビルド設定または .s2i/environment ファイルの一部として設定して、ビルドの手順で利用できるようにする必要があります。
変数名 | 説明 |
---|---|
|
この変数は、Ruby アプリケーションがデプロイされる環境を指定します。たとえば |
|
この変数は、Ruby on Rails アプリケーションがデプロイされる環境を指定します。たとえば |
|
この変数は |
|
この変数は、Puma のスレッドプールで利用可能な最小および最大スレッド数を指定します。 |
|
この変数は、Puma の クラスターモード で起動されるワーカープロセスの数を示します (Puma が 3 つ以上のプロセスを実行する場合)。明示的に設定されていない場合には、デフォルトの動作で |
|
ビルドプロセス時に必要な gem パッケージをダウンロードするための、カスタムの RubyGems ミラー URL を使用するようにこの変数を設定します。注意: この環境変数は、Ruby 2.2+ イメージでのみ利用可能です。 |
2.7.6. ホットデプロイ
ホットデプロイでは、新しい S2I ビルドを生成する必要なしに、アプリケーションに変更をすばやく加え、デプロイすることができます。このイメージでホットデプロイメントを有効にする方法は、アプリケーションの種類により異なります。
Ruby on Rails アプリケーション
Ruby on Rails アプリケーションの場合は、RAILS_ENV=development
環境変数を実行中の Pod に渡して、ビルド済みの Rails アプリケーションを実行します。既存のデプロイメント設定では、oc set env
コマンドを使用できます。
$ oc set env dc/rails-app RAILS_ENV=development
他のタイプの Ruby アプリケーション (Sinatra、Padrino など)
他のタイプの Ruby アプリケーションでは、アプリケーションは実行中のコンテナー内でソースコードが変更されるたびに、サーバーを再読み込みできる gem でビルドする必要があります。
開発モードでアプリケーションを実行できるようにするには、選択した gem で Web サーバーを起動し、ソースコードへの変更の有無を確認するように、S2I run スクリプトを変更する必要があります。
S2I run スクリプトでアプリケーションイメージをビルドした後に、RACK_ENV=development
環境変数でイメージを実行します。たとえば、oc new-app
コマンドを確認します。oc set env
コマンドを使用して、既存オブジェクトの環境変数を更新することができます。
このオプションは、開発またはデバッグの時にだけ使用するようにしてください。実稼働環境でこの設定をオンにすることは推奨しません。
実行中の Pod でソースコードを変更するには、oc rsh
コマンドを使用して、コンテナーに入ります。
$ oc rsh <pod_id>
実行中のコンテナーに入った後に、現在のディレクトリーを、ソースコードが配置されている /opt/app-root/src に設定します。
2.8. S2I イメージのカスタマイズ
2.8.1. 概要
S2I ビルダーイメージには通常、assemble と run スクリプトが含まれていますが、これらのスクリプトのデフォルトの動作はすべてのユーザーに適さない場合があります。以下のトピックでは、デフォルトのスクリプトなど、S2I ビルダーの動作をカスタマイズするいくつかの方法について説明します。
2.8.2. イメージに埋め込まれたスクリプトの呼び出し
一般的に、ビルダーイメージでは、最も一般的なユースケースを含む、独自の S2I スクリプトが提供されます。これらのスクリプトで各自のニーズが満たされない場合に向け、S2I には .s2i/bin ディレクトリーにカスタムのスクリプトを追加して上書きできる手段があります。ただし、カスタムのスクリプトを追加すると、標準のスクリプトを完全に置き換えられます。これは許容範囲の場合もありますが、シナリオによっては、イメージに含まれるスクリプトのロジックを保持しつつ、スクリプトの前 (または後) にコマンドをいくつか実行する必要がある場合があります。そのような場合には、カスタムのロジックを実行し、イメージ内のデフォルトのスクリプトに追加のタスクを委譲するラッパースクリプトを作成できます。
ビルダーイメージ内のスクリプトの場所を判断するには、io.openshift.s2i.scripts-url
ラベルの値を確認します。以下のように docker inspect
を使用してください。
$ docker inspect --format='{{ index .Config.Labels "io.openshift.s2i.scripts-url" }}' openshift/wildfly-100-centos7 image:///usr/libexec/s2i
openshift/wildfly-100-centos7 ビルダーイメージを確認し、対象のスクリプトが /usr/libexec/s2i ディレクトリーにあることを確認できます。
この情報を基にして、呼び出しをラップし、独自のスクリプトからこれらのスクリプトを呼び出します。
例2.1 .s2i/bin/assemble スクリプト
#!/bin/bash echo "Before assembling" /usr/libexec/s2i/assemble rc=$? if [ $rc -eq 0 ]; then echo "After successful assembling" else echo "After failed assembling" fi exit $rc
以下の例では、メッセージを出力するカスタムの assemble スクリプトを表示し、イメージから標準の assemble スクリプトを実行して、assemble スクリプトの終了コードに応じて別のメッセージを出力します。
run スクリプトをラップする場合には、スクリプトの呼び出しに exec
を実行して、シグナルが正しく処理されるようにする必要があります。残念ながら、exec
を使用すると、デフォルトのイメージ実行スクリプトを呼び出した後に追加でコマンドを実行できなくなります。
例2.2 .s2i/bin/run スクリプト
#!/bin/bash echo "Before running application" exec /usr/libexec/s2i/run