第5章 S2I イメージのテスト


5.1. 概要

Source-to-Image (S2I) ビルダーイメージの作成者は、S2I イメージをローカルでテストして、自動テストや継続的な統合に OpenShift Container Platform ビルドシステムを使用できます。

注記

続行する前に、S2I アーキテクチャーの詳細については、S2I 要件 のトピックを参照してください。

S2I 要件 のトピックに説明されているように、S2I ビルドを正常に実行するには、S2I に assemblerun スクリプトが必要です。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 イメージビルダーをテストするデフォルトのワークフローを記述しています。

  1. usage スクリプトが機能していることを確認します。

  2. イメージをビルドします。

  3. オプションで、save-artifacts をサポートする場合には、再度、手順 2 を実行して、保存して復元したアーティファクトが正しく機能することを確認します。
  4. コンテナーを実行します。

  5. コンテナーが実行され、アプリケーションが応答していることを確認します。

これらの手順を実行すると、通常、ビルダーイメージが予想通りに機能しているかどうかが分かります。

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 イメージをもとにアプリケーションのリビルドをトリガーすることも可能です。詳しい情報は、「イメージ変更トリガー」を参照してください。

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.