此内容没有您所选择的语言版本。

Chapter 5. Testing S2I Images


5.1. Overview

As an Source-to-Image (S2I) builder image author, you can test your S2I image locally and use the OpenShift Container Platform build system for automated testing and continuous integration.

Note

Check the S2I Requirements topic to learn more about the S2I architecture before proceeding.

As described in the S2I Requirements topic, S2I requires the assemble and run scripts to be present in order to successfully execute the S2I build. Providing the save-artifacts script reuses the build artifacts, and providing the usage script ensures that usage information is printed to console when someone runs the container image outside of the S2I.

The goal of testing an S2I image is to make sure that all of these described commands work properly, even if the base container image has changed or the tooling used by the commands was updated.

5.2. Testing Requirements

The standard location for the test script is test/run. This script is invoked by the OpenShift Container Platform S2I image builder and it could be a simple Bash script or a static Go binary.

The test/run script performs the S2I build, so you must have the S2I binary available in your $PATH. If required, follow the installation instructions in the S2I README.

S2I combines the application source code and builder image, so in order to test it you need a sample application source to verify that the source successfully transforms into a runnable container image. The sample application should be simple, but it should exercise the crucial steps of assemble and run scripts.

5.3. Generating Scripts and Tools

The S2I tooling comes with powerful generation tools to speed up the process of creating a new S2I image. The s2i create command produces all the necessary S2I scripts and testing tools along with the Makefile:

The generated test/run script must be adjusted to be useful, but it provides a good starting point to begin developing.

Note

The test/run script produced by the s2i create command requires that the sample application sources are inside the test/test-app directory.

5.4. Testing Locally

The easiest way to run the S2I image tests locally is to use the generated Makefile. If you did not use the s2i create command, you can copy the following Makefile template and replace the IMAGE_NAME parameter with your image name.

Example 5.1. Sample 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. Basic Testing Workflow

The test script assumes you have already built the image you want to test. If required, first build the S2I image using:

The following steps describe the default workflow to test S2I image builders:

  1. Verify the usage script is working:

  2. Build the image:

  3. Optionally, if you support save-artifacts, execute step 2 once again to verify that saving and restoring artifacts works properly.
  4. Run the container:

  5. Verify the container is running and the application is responding.

Executing these steps is generally enough to tell if the builder image is working as expected.

5.6. Using OpenShift Container Platform Build for Automated Testing

Another way you can execute the S2I image tests is to use the OpenShift Container Platform platform itself as a continuous integration system. The OpenShift Container Platform platform is capable of building container images and is highly customizable.

To set up an S2I image builder continuous integration system, define a Custom build and use the openshift/sti-image-builder image. This image executes all the steps mentioned in the Basic Testing Workflow section and creates a new S2I builder image.

Example 5.2. Sample 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/sclorg/s2i-ruby-container.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"

You can use the oc create command to create this BuildConfig. After you create the BuildConfig, you can start the build using the following command:

If your OpenShift Container Platform instance is hosted on a public IP address, the build can be triggered each time you push into your S2I builder image GitHub repository. See webhook triggers for more information.

You can also use the CustomBuild to trigger a rebuild of your application based on the S2I image you updated. See image change triggers for more information.

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.