4.3. S2I イメージのテスト
Source-to-Image (S2I) ビルダーイメージの作成者は、S2I イメージをローカルでテストして、自動テストや継続的な統合に OpenShift Container Platform ビルドシステムを使用できます。
S2I ビルドを正常に実行するには、S2I に assemble と run スクリプトが必要です。S2I 外のコンテナーイメージを実行した場合に、save-artifacts スクリプトがあると、ビルドのアーティファクトが再利用され、usage スクリプトがあると、使用についての情報がコンソールに出力されるようになります。
S2I イメージのテストは、ベースのコンテナーイメージを変更したり、コマンドが使用するツールが更新されたりした場合でも、上記のコマンドが正しく機能することを確認するのが目的です。
4.3.1. テスト要件について
test スクリプトは、基本的に test/run に配置されます。このスクリプトは、OpenShift Container Platform S2I イメージビルダーが呼び出し、単純な Bash スクリプトか静的な Go バイナリーのいずれかの形式を取ることができます。
test/run スクリプトは S2I ビルドを実行するので、S2I バイナリーを $PATH
で利用可能にしておく必要があります。必要に応じて、S2I README のインストール手順に従います。
S2I は、アプリケーションのソースコードおよびビルダーイメージを統合します。これをテストするには、ソースが実行可能なコンテナーイメージに変換されることを検証するためのサンプルアプリケーションのソースが必要です。サンプルアプリケーションは単純なものである必要がありますが、assemble
および run
スクリプトの重要な手順を実行できる必要があります。
4.3.2. スクリプトおよびツールの生成
S2I ツールは、新しい S2I イメージの作成プロセスを加速化する強力な生成ツールと共に提供されます。s2i create
コマンドでは、Makefile 以外に、必要とされる S2I スクリプトとテストツールすべてが生成されます。
$ s2i create _<image name>_ _<destination directory>_
生成された test/run スクリプトは、より使いやすくするために調整する必要がありますが、このスクリプトを開発の開始段階で使用することが推奨されます。
s2i create
コマンドで生成した test/run スクリプトでは、サンプルアプリケーションのソースを test/test-app ディレクトリーに配置しておく必要があります。
4.3.3. ローカルでのテスト
S2I イメージテストをローカルに実行する最も簡単な方法として、生成した Makefile を使用することができます。
s2i create
コマンドを使用しない場合には、以下の Makefile テンプレートをコピーして、IMAGE_NAME
パラメーターをお使いのイメージ名に置き換えることができます。
Makefile の例
IMAGE_NAME = openshift/ruby-20-centos7 CONTAINER_ENGINE := $(shell command -v podman 2> /dev/null | echo docker) build: ${CONTAINER_ENGINE} build -t $(IMAGE_NAME) . .PHONY: test test: ${CONTAINER_ENGINE} build -t $(IMAGE_NAME)-candidate . IMAGE_NAME=$(IMAGE_NAME)-candidate test/run
4.3.4. テストの基本的なワークフロー
test スクリプトは、テストするイメージをすでにビルドしていることが前提です。必要に応じて、以下のコマンドで S2I イメージを先にビルドしてください。以下のいずれかのコマンドを実行してください。
Podman を使用する場合は、以下のコマンドを実行します。
$ podman build -t _<BUILDER_IMAGE_NAME>_
Docker を使用する場合は、以下のコマンドを実行します。
$ docker build -t _<BUILDER_IMAGE_NAME>_
以下の手順では、S2I イメージビルダーをテストするデフォルトのワークフローを説明しています。
usage スクリプトが機能していることを確認します。
Podman を使用する場合は、以下のコマンドを実行します。
$ podman run _<BUILDER_IMAGE_NAME>_ .
Docker を使用する場合は、以下のコマンドを実行します。
$ docker run _<BUILDER_IMAGE_NAME>_ .
イメージをビルドします。
$ s2i build file:///path-to-sample-app _<BUILDER_IMAGE_NAME>_ _<OUTPUT_APPLICATION_IMAGE_NAME>_
- オプション: save-artifacts をサポートする場合には、再度手順 2 を実行して、保存して復元するアーティファクトが正しく機能することを確認します。
コンテナーを実行します。
Podman を使用する場合は、以下のコマンドを実行します。
$ podman run _<OUTPUT_APPLICATION_IMAGE_NAME>_
Docker を使用する場合は、以下のコマンドを実行します。
$ docker run _<OUTPUT_APPLICATION_IMAGE_NAME>_
- コンテナーが実行され、アプリケーションが応答していることを確認します。
これらの手順を実行すると、通常はビルダーイメージが予想通りに機能しているかどうかが分かります。
4.3.5. イメージのビルドでの OpenShift Container Platform の使用
新しい S2I ビルダーイメージを構成する Dockerfile
と他のアーティファクトが準備できたら、それらを git リポジトリーに配置して、OpenShift Container Platform を使用し、イメージをビルドしてプッシュします。その後は、お使いのリポジトリーを参照する Docker ビルドを定義することのみが必要になります。
OpenShift Container Platform インスタンスが公開 IP アドレスでホストされる場合、ビルドは、S2I ビルダーイメージ GitHub リポジトリーにプッシュするたびにトリガーされます。
ImageChangeTrigger
を使用して、更新した S2I ビルダーイメージに基づくアプリケーションの再ビルドをトリガーすることもできます。