第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.2
  • .NET Core バージョン 2.1
  • .NET Core バージョン 1.1
  • .NET Core バージョン 1.0
  • Red Hat Enterprise Linux (RHEL) 7 および OpenShift Container Platform バージョン 3.3 以降でサポートされています。

.NET Core バージョン 2.2 関連のリリースの詳細は、『Release Notes for Containers』を参照してください。

.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.redhat.io/dotnet/dotnet-22-rhel7
$ docker pull registry.redhat.io/dotnet/dotnet-21-rhel7
$ docker pull registry.redhat.io/dotnet/dotnetcore-11-rhel7
$ docker pull registry.redhat.io/dotnet/dotnetcore-10-rhel7

RHEL S2I イメージ上の .NET Core 向けのイメージストリーム定義は、OpenShift Container Platform のインストール時に追加されるようになりました。

2.2.4. ビルドプロセス

S2I は、ソースコードをコンテナーに挿入し、コンテナーにソースコードの実行を準備をさせることで、実行準備が整ったイメージを生成します。S2I では、以下の手順を実行します。

  1. ビルダーイメージからコンテナーを起動します。
  2. アプリケーションソースをダウンロードします。
  3. ビルダーイメージコンテナーにスクリプトとアプリケーションソースをストリーミングします。
  4. (ビルダーイメージから) assemble スクリプトを実行します。
  5. 最終的なイメージを保存します。

ビルドプロセスの詳細のまとめについては、「S2I ビルドプロセス」を参照してください。

2.2.5. 環境変数

.NET Core イメージは、複数の環境変数をサポートします。この環境変数を設定して、.NET Core アプリケーションのビルド動作を制御することができます。

注記

S2I ビルド設定または .s2i/environment ファイルに、ビルドの動作を制御する環境変数を設定して、ビルドの手順で利用できるようにする必要があります。

表2.1 NET Core 環境変数

変数名説明デフォルト

DOTNET_STARTUP_PROJECT

実行するプロジェクトを選択します。これは、プロジェクトファイル (例: csproj または fsproj) か、単一のプロジェクトファイルを含むフォルダーでなければなりません。

.

DOTNET_ASSEMBLY_NAME

実行するアセンブリーを選択します。これには、.dll の拡張子を 含めないでください。これは、csproj で指定した出力アセンブリー名に設定します (PropertyGroup/AssemblyName)。

csproj ファイルの名前

DOTNET_RESTORE_SOURCES

復元操作時に使用する NuGet パッケージソースをスペース区切りの一覧で指定します。これは、NuGet.config ファイルで指定したすべてのソースよりも優先されます。

 

DOTNET_TOOLS

アプリケーションをビルドする前にインストールする .NET ツールの一覧を指定します。固有のバージョンをインストールするには、パッケージ名の最後に @<version> を追加します。

 

DOTNET_NPM_TOOLS

アプリケーションをビルドする前にインストールする NPM パッケージの一覧を指定します。

 

DOTNET_TEST_PROJECTS

テストするテストプロジェクトの一覧を指定します。これは、プロジェクトファイルか、または単一のプロジェクトファイルを含むフォルダーでなければなりません。dotnet test はアイテムごとに呼び出されます。

 

DOTNET_CONFIGURATION

Debug または Release モードでアプリケーションを実行します。この値は、Release または Debug のいずれかに指定する必要があります。

Release

DOTNET_VERBOSITY

dotnet ビルドコマンドの詳細レベルを指定します。これを設定した場合には、環境変数がビルドの開始時に出力されます。変数は、msbuild の詳細値 (q[uiet]m[inimal], n[ormal]d[etailed] および diag[nostic]) の 1 つに設定できます。

 

HTTP_PROXYHTTPS_PROXY

アプリケーションのビルド時および実行時に使用する HTTP/HTTPS プロキシーを設定します。

 

NPM_MIRROR

ビルドプロセス中にパッケージをダウンロードするカスタムの NPM レジストリーミラーを使用します。

 

ASPNETCORE_URLS

この変数を http://*:8080 に設定して ASP.NET Core がイメージが公開するポートを使用するように設定します。この値の変更は推奨 していません

http://*:8080

DOTNET_RM_SRC

true に設定されると、ソースコードはイメージに組み込まれません。

 

DOTNET_SSL_DIRS

追加で信頼する SSL 証明書を使ってフォルダーおよびファイルの一覧を指定するために使用されます。証明書は、ビルド時に実行される各プロセス、およびビルドされたアプリケーションを含め、ビルド後にイメージで実行されるすべてのプロセスで信頼されます。使用される項目には、/ で開始される絶対パスまたはソースリポジトリーのパスを指定できます (証明書など)。

 

DOTNET_RESTORE_DISABLE_PARALLEL

true に設定されている場合、複数プロジェクトを並行して復元する操作を無効にします。これにより、ビルドコンテナーが CPU 制限の値が低く設定された状態で実行されている場合にも復元タイムアウトのエラーが減少します。

false

DOTNET_INCREMENTAL

true に設定される場合、NuGet パッケージがインクリメンタルビルドに再利用できるように保持されます。

false

DOTNET_PACK

true に設定される場合、tar.gz ファイルが公開されたアプリケーションを含む /opt/app-root/app.tar.gz に作成されます。

 

2.2.6. .NET Core ソースからのアプリケーションのクイックデプロイ

重要

.NET イメージストリーム は最初にインストールする必要があります。標準インストールを実行した場合には、イメージストリームは存在します。

サンプルのリポジトリーに対して oc new-app を実行すると、イメージを使用してアプリケーションをビルドできます。

$ oc new-app registry.redhat.io/dotnet/dotnet-22-rhel7~https://github.com/redhat-developer/s2i-dotnetcore-ex#dotnetcore-2.2 --context-dir=app
$ oc new-app registry.redhat.io/dotnet/dotnet-21-rhel7~https://github.com/redhat-developer/s2i-dotnetcore-ex#dotnetcore-2.1 --context-dir=app
$ oc new-app registry.redhat.io/dotnet/dotnetcore-11-rhel7~https://github.com/redhat-developer/s2i-dotnetcore-ex#dotnetcore-1.1 --context-dir=app
$ oc new-app registry.redhat.io/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-22-rhel7 で実行する .NET Core のサンプルアプリケーション は以下のコマンドでデプロイ可能です。

$ oc new-app --template dotnet-example -p DOTNET_IMAGE_STREAM_TAG=dotnet:2.2 -p SOURCE_REPOSITORY_REF=dotnetcore-2.2

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 またはコンテナーランタイムで実行可能です。

2.3.2. バージョン

現在、OpenShift Container Platform では、Node.js のバージョン 0.104 および 6 を提供しています。

2.3.3. イメージ

これらのイメージには 2 つのフレーバーがあり、ニーズに合わせて選択できます。

  • RHEL 7
  • CentOS 7

RHEL 7 ベースのイメージ

RHEL 7 イメージは、Red Hat レジストリーから入手できます。

$ docker pull registry.redhat.io/openshift3/nodejs-010-rhel7
$ docker pull registry.redhat.io/rhscl/nodejs-4-rhel7

CentOS 7 ベースのイメージ

このイメージは、Docker Hub で入手できます。

$ docker pull openshift/nodejs-010-centos7

これらのイメージを使用するには、イメージレジストリー から直接アクセスするか、ご自身の OpenShift Container Platform コンテナーイメージレジストリー にプッシュしてください。さらに、コンテナーイメージレジストリーまたは外部の場所に、対象イメージを参照する イメージストリーム を作成することもでき、OpenShift Container Platform リソースがこのイメージストリームを参照できるようになります。提供されている全 OpenShift Container Platform イメージに対して イメージストリームの定義例 があります。

2.3.4. ビルドプロセス

S2I は、ソースコードをコンテナーに挿入し、コンテナーにソースコードの実行を準備をさせることで、実行準備が整ったイメージを生成します。S2I では、以下の手順を実行します。

  1. ビルダーイメージからコンテナーを起動します。
  2. アプリケーションソースをダウンロードします。
  3. ビルダーイメージコンテナーにスクリプトとアプリケーションソースをストリーミングします。
  4. (ビルダーイメージから) assemble スクリプトを実行します。
  5. 最終的なイメージを保存します。

ビルドプロセスの詳細のまとめについては、「S2I ビルドプロセス」を参照してください。

2.3.5. 設定

Node.js イメージは、環境変数を複数サポートし、環境変数を設定することで Node.js のラインタイムの設定や動作を制御できます。

イメージの一部としてこれらの環境変数を設定するには、ソースコードリポジトリーの中にある .s2i/environment ファイル に配置するか、ビルド設定の sourceStrategy 定義の 環境セクション に定義します。

また、新規アプリケーションの作成時に 既存のイメージを使用するか、デプロイメント設定などの 既存のオブジェクトの環境変数を更新して 環境変数を設定できます。

注記

ビルドの動作を制御する環境変数は、s2i ビルド設定または .s2i/environment ファイルの一部として設定して、ビルドの手順で利用できるようにする必要があります。

表2.2 開発モードの環境変数

変数名説明

DEV_MODE

true に設定されている場合には、ホットデプロイを有効にし、デバッグポートを開きます。さらに、ツールに対して、イメージが開発モードであることを指定します。デフォルトは false です。

DEBUG_PORT

デバッグポート。DEV_MODE が true に設定されている場合のみ有効です。デフォルトは 5858 です。

NPM_MIRROR

カスタムの 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 またはコンテナーランタイムで実行可能です。

2.4.2. バージョン

現在、OpenShift Container Platform は Perl バージョン 5.165.20 および 5.24 をサポートします。

2.4.3. イメージ

イメージには 2 つのフレーバーがあり、ニーズに合わせて選択できます。

  • RHEL 7
  • CentOS 7

RHEL 7 ベースのイメージ

RHEL 7 イメージは、Red Hat レジストリーから入手できます。

$ docker pull registry.redhat.io/openshift3/perl-516-rhel7
$ docker pull registry.redhat.io/rhscl/perl-520-rhel7
$ docker pull registry.redhat.io/rhscl/perl-524-rhel7

CentOS 7 ベースのイメージ

Perl 5.16 の CentOS イメージは、Docker Hub で入手できます。

$ docker pull openshift/perl-516-centos7

これらのイメージを使用するには、イメージレジストリー から直接アクセスするか、ご自身の OpenShift Container Platform コンテナーイメージレジストリー にプッシュしてください。さらに、コンテナーイメージレジストリーまたは外部の場所に、対象イメージを参照する イメージストリーム を作成することもでき、OpenShift Container Platform リソースがこのイメージストリームを参照できるようになります。提供されている全 OpenShift Container Platform イメージに対して イメージストリームの定義例 があります。

2.4.4. ビルドプロセス

S2I は、ソースコードをコンテナーに挿入し、コンテナーにソースコードの実行を準備をさせることで、実行準備が整ったイメージを生成します。S2I では、以下の手順を実行します。

  1. ビルダーイメージからコンテナーを起動します。
  2. アプリケーションソースをダウンロードします。
  3. ビルダーイメージコンテナーにスクリプトとアプリケーションソースをストリーミングします。
  4. (ビルダーイメージから) assemble スクリプトを実行します。
  5. 最終的なイメージを保存します。

ビルドプロセスの詳細のまとめについては、「S2I ビルドプロセス」を参照してください。

2.4.5. 設定

Perl イメージは多数の環境変数を複数サポートし、環境変数を設定することで Perl のラインタイムの設定や動作を制御できます。

イメージの一部としてこれらの環境変数を設定するには、ソースコードリポジトリーの中にある .s2i/environment ファイル に配置するか、ビルド設定の sourceStrategy 定義の 環境セクション に定義します。

また、新規アプリケーションの作成時に 既存のイメージを使用するか、デプロイメント設定などの 既存のオブジェクトの環境変数を更新して 環境変数を設定できます。

注記

ビルドの動作を制御する環境変数は、s2i ビルド設定または .s2i/environment ファイルの一部として設定して、ビルドの手順で利用できるようにする必要があります。

表2.3 Perl 環境変数

変数名説明

ENABLE_CPAN_TEST

true に設定している場合は、この変数は全 cpan モジュールをインストールして、そのテストを実行します。デフォルトでは、モジュールのテストはオフになっています。

CPAN_MIRROR

この変数は、cpanminus が依存関係のインストールに使用するミラーの URL を指定します。デフォルトではこの URL は指定されていません。

PERL_APACHE2_RELOAD

これを true に設定すると、変更した Perl モジュールの自動再読み込みが有効になります。デフォルトでは、自動再読み込みはオフになっています。

HTTPD_START_SERVERS

StartServers ディレクティブは、起動時に作成される子サーバープロセスの数を設定します。デフォルトは 8 です。

HTTPD_MAX_REQUEST_WORKERS

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 またはコンテナーランタイムで実行可能です。

2.5.2. バージョン

現在、OpenShift Container Platform では、PHP のバージョン 5.55.6 および 7.0 を提供しています。

2.5.3. イメージ

これらのイメージには 2 つのフレーバーがあり、ニーズに合わせて選択できます。

  • RHEL 7
  • CentOS 7

RHEL 7 ベースのイメージ

RHEL 7 イメージは、Red Hat レジストリーから入手できます。

$ docker pull registry.redhat.io/openshift3/php-55-rhel7
$ docker pull registry.redhat.io/rhscl/php-56-rhel7
$ docker pull registry.redhat.io/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 コンテナーイメージレジストリー にプッシュしてください。さらに、コンテナーイメージレジストリーまたは外部の場所に、対象イメージを参照する イメージストリーム を作成することもでき、OpenShift Container Platform リソースがこのイメージストリームを参照できるようになります。

提供される全 OpenShift Container Platform イメージに対して イメージストリームの定義例 があります。

2.5.4. ビルドプロセス

S2I は、ソースコードをコンテナーに挿入し、コンテナーにソースコードの実行を準備をさせることで、実行準備が整ったイメージを生成します。S2I では、以下の手順を実行します。

  1. ビルダーイメージからコンテナーを起動します。
  2. アプリケーションソースをダウンロードします。
  3. ビルダーイメージコンテナーにスクリプトとアプリケーションソースをストリーミングします。
  4. (ビルダーイメージから) assemble スクリプトを実行します。
  5. 最終的なイメージを保存します。

ビルドプロセスの詳細のまとめについては、「S2I ビルドプロセス」を参照してください。

2.5.5. 設定

PHP イメージは数多くの環境変数を複数サポートし、環境変数を設定することで PHP のラインタイムの設定や動作を制御できます。

イメージの一部としてこれらの環境変数を設定するには、ソースコードリポジトリーの中にある .s2i/environment ファイル に配置するか、ビルド設定の sourceStrategy 定義の 環境セクション に定義します。

また、新規アプリケーションの作成時に 既存のイメージを使用するか、デプロイメント設定などの 既存のオブジェクトの環境変数を更新して 環境変数を設定できます。

注記

ビルドの動作を制御する環境変数は、s2i ビルド設定または .s2i/environment ファイルの一部として設定して、ビルドの手順で利用できるようにする必要があります。

以下の環境変数は、php.ini ファイルに同等のプロパティー値を設定します。

表2.4 PHP 環境変数

変数名説明デフォルト

ERROR_REPORTING

PHP で対応する必要のあるエラー、警告、注意を PHP に通知します。

E_ALL & ~E_NOTICE

DISPLAY_ERRORS

PHP がエラー、注意、警告を出力するかどうか、さらに出力先を制御します。

ON

DISPLAY_STARTUP_ERRORS

PHP の起動シーケンス時に発生した表示エラーを通常の表示エラーとは別に処理するようにします。

OFF

TRACK_ERRORS

$php_errormsg (boolean) に最後のエラー/警告メッセージを保存します。

OFF

HTML_ERRORS

対象のエラーに関連するドキュメントにエラーをリンクします。

ON

INCLUDE_PATH

PHP ソースファイルへのパス

.:/opt/openshift/src:/opt/rh/php55/root/usr/share/pear

SESSION_PATH

セッションデータファイルの場所

/tmp/sessions

DOCUMENTROOT

アプリケーションのドキュメントルートを定義するパス (例: /public)

/

以下の環境変数は、opcche.ini ファイルに同等のプロパティー値を設定します。

表2.5 PHP の他の設定

変数名説明デフォルト

OPCACHE_MEMORY_CONSUMPTION

OPcache 共有メモリーのストレージサイズ

16M

OPCACHE_REVALIDATE_FREQ

更新のスクリプトタイムスタンプをどの頻度で確認するかを秒単位で指定します。0 に指定すると、OPcache はすべての要求の更新を確認します。

2

以下を設定して PHP 設定の読み込みに使用するディレクトリー全体を上書きすることも可能です。

表2.6 PHP の他の設定

変数名説明

PHPRC

php.ini ファイルにパスを設定します。

PHP_INI_SCAN_DIR

追加の .ini 設定ファイル

デフォルトの 'packagist.org' ではなく、カスタムの Composer リポジトリーのミラー URL を使用して、パッケージをダウンロードできます。

表2.7 Composer 環境変数

変数名説明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 またはコンテナーランタイムで実行可能です。

2.6.2. バージョン

現在、OpenShift Container Platform では、Python のバージョン 2.73.33.4 および 3.5 を提供しています。

2.6.3. イメージ

これらのイメージには 2 つのフレーバーがあり、ニーズに合わせて選択できます。

  • RHEL 7
  • CentOS 7

RHEL 7 ベースのイメージ

RHEL 7 イメージは、Red Hat レジストリーから入手できます。

$ docker pull registry.redhat.io/rhscl/python-27-rhel7
$ docker pull registry.redhat.io/openshift3/python-33-rhel7
$ docker pull registry.redhat.io/rhscl/python-34-rhel7
$ docker pull registry.redhat.io/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 コンテナーイメージレジストリー にプッシュしてください。さらに、コンテナーイメージレジストリーまたは外部の場所に、対象イメージを参照する イメージストリーム を作成することもでき、OpenShift Container Platform リソースがこのイメージストリームを参照できるようになります。提供されている全 OpenShift Container Platform イメージに対して イメージストリームの定義例 があります。

2.6.4. ビルドプロセス

S2I は、ソースコードをコンテナーに挿入し、コンテナーにソースコードの実行を準備をさせることで、実行準備が整ったイメージを生成します。S2I では、以下の手順を実行します。

  1. ビルダーイメージからコンテナーを起動します。
  2. アプリケーションソースをダウンロードします。
  3. ビルダーイメージコンテナーにスクリプトとアプリケーションソースをストリーミングします。
  4. (ビルダーイメージから) assemble スクリプトを実行します。
  5. 最終的なイメージを保存します。

ビルドプロセスの詳細のまとめについては、「S2I ビルドプロセス」を参照してください。

2.6.5. 設定

Python イメージは多数の環境変数を複数サポートし、環境変数を設定することで Python のラインタイムの設定や動作を制御できます。

イメージの一部としてこれらの環境変数を設定するには、ソースコードリポジトリーの中にある .s2i/environment ファイル に配置するか、ビルド設定の sourceStrategy 定義の 環境セクション に定義します。

また、新規アプリケーションの作成時に 既存のイメージを使用するか、デプロイメント設定などの 既存のオブジェクトの環境変数を更新して 環境変数を設定できます。

注記

ビルドの動作を制御する環境変数は、s2i ビルド設定または .s2i/environment ファイルの一部として設定して、ビルドの手順で利用できるようにする必要があります。

表2.8 Python 環境変数

変数名説明

APP_FILE

この変数は、アプリケーションを起動する Python インタープリターに渡すファイル名を指定します。デフォルトでは、この変数は app.py に設定されています。

APP_MODULE

この変数は WSGI 呼び出し可能なオブジェクトを指定します。この変数のパターンは $(MODULE_NAME):$(VARIABLE_NAME) で、モジュール名はドットのフルパスに指定し、変数名は指定のモジュール内の関数を参照します。アプリケーションのインストールに setup.py を使用した場合に、モジュール名はファイルから読み込むことができ、変数は application に設定されます。setup-test-app のサンプルがあります。

APP_CONFIG

この変数は、gunicorn 設定 で有効な Python ファイルへのパスを指定します。

DISABLE_COLLECTSTATIC

空でない値に設定して、ビルド時に manage.py collectstatic が実行されないようにします。これは Django プロジェクトに対してのみ影響があります。

DISABLE_MIGRATE

空でない値に設定して、生成されたイメージの実行時に manage.py migrate が実行されないようにします。これは Django プロジェクトに対してのみ影響があります。

PIP_INDEX_URL

ビルドプロセス時に必要なパッケージをダウンロードするための、カスタムのインデックス URL またはミラーを使用するように、この変数を設定します。これは、requirements.txt ファイルに記載のパッケージにのみ影響があります。

WEB_CONCURRENCY

これを設定して、ワーカー 数のデフォルト設定を変更します。デフォルトでは、これは利用可能なコアに 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 またはコンテナーランタイムで実行可能です。

2.7.2. バージョン

現時点で、OpenShift Container Platform では、Ruby のバージョン 2.02.2 および 2.3 を提供しています。

2.7.3. イメージ

これらのイメージには 2 つのフレーバーがあり、ニーズに合わせて選択できます。

  • RHEL 7
  • CentOS 7

RHEL 7 ベースのイメージ

RHEL 7 イメージは、Red Hat レジストリーから入手できます。

$ docker pull registry.redhat.io/openshift3/ruby-20-rhel7
$ docker pull registry.redhat.io/rhscl/ruby-22-rhel7
$ docker pull registry.redhat.io/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 コンテナーイメージレジストリー にプッシュしてください。さらに、コンテナーイメージレジストリーまたは外部の場所に、対象イメージを参照する イメージストリーム を作成することもでき、OpenShift Container Platform リソースがこのイメージストリームを参照できるようになります。提供されている全 OpenShift Container Platform イメージに対して イメージストリームの定義例 があります。

2.7.4. ビルドプロセス

S2I は、ソースコードをコンテナーに挿入し、コンテナーにソースコードの実行を準備をさせることで、実行準備が整ったイメージを生成します。S2I では、以下の手順を実行します。

  1. ビルダーイメージからコンテナーを起動します。
  2. アプリケーションソースをダウンロードします。
  3. ビルダーイメージコンテナーにスクリプトとアプリケーションソースをストリーミングします。
  4. (ビルダーイメージから) assemble スクリプトを実行します。
  5. 最終的なイメージを保存します。

ビルドプロセスの詳細のまとめについては、「S2I ビルドプロセス」を参照してください。

2.7.5. 設定

Ruby イメージは多数の環境変数を複数サポートし、環境変数を設定することで Ruby のラインタイムの設定や動作を制御できます。

イメージの一部としてこれらの環境変数を設定するには、ソースコードリポジトリーの中にある .s2i/environment ファイル に配置するか、ビルド設定の sourceStrategy 定義の 環境セクション に定義します。

また、新規アプリケーションの作成時に 既存のイメージを使用するか、デプロイメント設定などの 既存のオブジェクトの環境変数を更新して 環境変数を設定できます。

注記

ビルドの動作を制御する環境変数は、s2i ビルド設定または .s2i/environment ファイルの一部として設定して、ビルドの手順で利用できるようにする必要があります。

表2.9 Ruby 環境変数

変数名説明

RACK_ENV

この変数は、Ruby アプリケーションがデプロイされる環境を指定します。たとえば productiondevelopment または test などです。ロギングの詳細レベル、エラーページ、Ruby gem インストールなど、レベルごとに動作が異なります。アプリケーションのアセットは、RACK_ENVproduction に設定されている場合にのみコンパイルされます。デフォルト値は production です。

RAILS_ENV

この変数は、Ruby on Rails アプリケーションがデプロイされる環境を指定します。たとえば productiondevelopment または test などです。ロギングの詳細レベル、エラーページ、Ruby gem インストールなど、レベルごとに動作が異なります。アプリケーションのアセットは、RAILS_ENVproduction に設定されている場合にのみコンパイルされます。デフォルトではこの変数は ${RACK_ENV} に設定されています。

DISABLE_ASSET_COMPILATION

この変数は true に設定されている場合には、アセットのコンパイルプロセスを無効にします。アセットのコンパイルは、アプリケーションが実稼働環境で実行されている場合にのみ行われます。そのため、アセットがコンパイル済みの場合は、この変数を使用できます。

PUMA_MIN_THREADSPUMA_MAX_THREADS

この変数は、Puma のスレッドプールで利用可能な最小および最大スレッド数を指定します。

PUMA_WORKERS

この変数は、Puma の クラスターモード で起動されるワーカープロセスの数を示します (Puma が 3 つ以上のプロセスを実行する場合)。明示的に設定されていない場合には、デフォルトの動作で PUMA_WORKERS が、コンテナーで利用可能なメモリーや、ホスト上のコア数に適した値に設定されます。

RUBYGEM_MIRROR

ビルドプロセス時に必要な 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 ビルダーイメージには通常、assemblerun スクリプトが含まれていますが、これらのスクリプトのデフォルトの動作は全ユーザーに対して適切であるとは限りません。以下のトピックでは、デフォルトのスクリプトなど、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