S2I Workflow and Logic

    For more information about how to use S2I in KubeSphere, refer to Source to Image: Publish an App without a Dockerfile. Besides, you can refer to the code repositories and S2IRun for more details.

    For interpreted languages like Python and Ruby, the build-time and runtime environments for an application are typically the same. For example, a Ruby-based Image Builder usually contains Bundler, Rake, Apache, GCC, and other packages needed to set up a runtime environment. The following diagram describes the build workflow.

    S2I performs the following steps:

    1. Start a container from the Image Builder with the application source code injected into a specified directory.
    2. Set the run script provided by the Image Builder as the image entrypoint for starting the container, and then commit a new image as the application image to meet user needs.

    See the S2I workflow chart as below.

    For compiled languages like Go, C, C++, or Java, the dependencies necessary for compiling will increase the size of resulting images. To build slimmer images, S2I uses a phased build workflow with unnecessary files removed from images. An artifact, which is an executable like a Jar file or binary file, will be extracted when building finishes in the Image Builder, and then injected into a Runtime Image for execution.

    See the building workflow as below.