第5章 S2I イメージのテスト
5.1. 概要
Source-to-Image (S2I) ビルダーイメージの作成者は、S2I イメージをローカルでテストして、自動テストや継続的な統合に OpenShift Container Platform ビルドシステムを使用できます。
続行する前に、S2I アーキテクチャーの詳細については、S2I 要件 のトピックを参照してください。
S2I 要件 のトピックに説明されているように、S2I ビルドを正常に実行するには、S2I に assemble と run スクリプトが必要です。S2I 以外のコンテナーイメージを実行した場合に、save-artifacts スクリプトがあると、ビルドのアーティファクトが再利用され、usage スクリプトがあると、用途の情報がコンソールに出力されるようになります。
S2I イメージのテストは、ベースのコンテナーイメージを変更したり、コマンドが使用するツールが更新されたりした場合でも、上記のコマンドが正しく機能することを確認するのが目的です。
5.2. テストの要件
test スクリプトは、基本的に test/run に配置されます。このスクリプトは、OpenShift Container Platform S2I イメージビルダーが呼び出し、単純な Bash スクリプトか静的な Go バイナリーのいずれかの形式を取ることができます。
test/run スクリプトは、S2I ビルドを実行するので、S2I バイナリーを $PATH
に配置しておく必要があります。必要に応じて、S2I README のインストールの手順に従うようにしてください。
S2I は、アプリケーションのソースコードおよびビルダーイメージを統合します。これをテストするには、ソースが実行可能なコンテナーイメージに変換されたことを検証するためのサンプルアプリケーションのソースが必要です。サンプルアプリケーションはシンプルであるはずですが、assemble
および run
スクリプトの極めて重要な手順を実行する必要があります。
5.3. スクリプトおよびツールの生成
S2I ツールには、強力な生成ツールが含まれており、新しい S2I イメージの作成プロセスを加速化します。s2i create
コマンドでは、Makefile 以外に、必要とされる S2I スクリプトとテストツールすべてが生成されます。
生成された test/run スクリプトは、使用性を高めるために調整する必要がありますが、このスクリプトは開発のスタート地点としては、最適です。
s2i create
コマンドで生成した test/run スクリプトでは、サンプルアプリケーションのソースを、test/test-app ディレクトリーに配置しておく必要があります。
5.4. ローカルでのテスト
S2I イメージのテストをローカルでテストする方法として、生成した Makefile を使用するのが最も簡単です。
s2i create
コマンドを使用しない場合には、以下の Makefile テンプレートをコピーして、IMAGE_NAME
パラメーターをお使いのイメージ名に置き換えます。
例5.1 Makefile の例
IMAGE_NAME = openshift/ruby-20-centos7 build: docker build -t $(IMAGE_NAME) . .PHONY: test test: docker build -t $(IMAGE_NAME)-candidate . IMAGE_NAME=$(IMAGE_NAME)-candidate test/run
5.5. テストの基本的なワークフロー
test スクリプトは、テストするイメージをすでにビルドしていることが前提です。必要に応じて、以下のコマンドで S2I イメージを先にビルドしてください。
以下の手順では、S2I イメージビルダーをテストするデフォルトのワークフローを記述しています。
usage スクリプトが機能していることを確認します。
イメージをビルドします。
- オプションで、save-artifacts をサポートする場合には、再度、手順 2 を実行して、保存して復元したアーティファクトが正しく機能することを確認します。
コンテナーを実行します。
- コンテナーが実行され、アプリケーションが応答していることを確認します。
これらの手順を実行すると、通常、ビルダーイメージが予想通りに機能しているかどうかが分かります。
5.6. 自動テストでの OpenShift Container Platform ビルドの使用
S2I イメージをテストする別の方法として、継続的な統合システムとして、OpenShift Container Platform 自体を使用します。OpenShift Container Platform は、コンテナーイメージをビルドでき、非常に多くのカスタマイズが可能です。
S2I イメージビルダーの継続的な統合システムを設定するには、カスタムビルド を定義して、openshift/sti-image-builder イメージを使用します。このイメージは、「テストの基本的なワークフロー」 のセクションに記載の手順をすべて実行して、新規の S2I ビルダーイメージを作成します。
例5.2 CustomBuild
の例
kind: "BuildConfig" apiVersion: "v1" metadata: name: "ruby-20-centos7-build" spec: triggers: - type: "GitHub" github: secret: "secret101" source: type: "Git" git: uri: "git://github.com/openshift/sti-ruby.git" strategy: type: "Custom" customStrategy: from: kind: "DockerImage" name: "openshift/sti-image-builder" env: - name: "IMAGE_NAME" value: "openshift/ruby-20-centos7" - name: "CONTEXT_DIR" value: "/2.0/" exposeDockerSocket: true output: to: kind: "ImageStreamTag" name: "ruby-20-centos7:latest"
oc create
コマンドを使用して、この BuildConfig
を作成できます。BuildConfig
の作成後に、以下のコマンドを使用して、ビルドを開始してください。
OpenShift Container Platform インスタンスが公開 IP アドレスでホストされている場合には、ビルドは、S2I ビルダーイメージの GitHub リポジトリーにプッシュするたびに、トリガーされます。詳細は、「webhook トリガー」を参照してください。
CustomBuild
を使用して、更新した S2I イメージをもとにアプリケーションのリビルドをトリガーすることも可能です。詳しい情報は、「イメージ変更トリガー」を参照してください。