What IS S2I in OCP3.9?

[MJ]

In OpenShift, the Source-to-Image (S2I) process pulls code from an SCM repository. The source code requirements for runtime are automatically detected and a pod is launched that is created from a base image specific to the required runtime. The application is built inside the pod by OpenShift with the same procedure a developer would use. When the build is successful, another image is created, layering the application binaries over its runtime. The resulting image is then pushed to an OpenShift internal repository.

[flozano]

Just to add a little more detail: the OpenShift S2I process supports two different workflows, and two different strategies out of the box:

- Source workflow: just as describe in the fist message of this discussion, it pulls source code from an SCM repository

- Binary workflow: employed by tools such as the Fabric8 Maven Plug-in abd used by Red Hat Fuse and Red Hat OpenShift Application Runtimes, it pulls an application binary, build locally by the developer, and builds a new container image that embedds this binary.

- Source strategy: runs either the source or binary worlflows, deppending on the inputs configured in the OpenShift build configuration

- Docker strategy: it is similar to the source workflow, except that the SCM repository is expected to contain a Dockerfile, and the build pod runs a docker build operation to produce a new container image. This is a regular docker build, but you do not need to install Docker in your workstation.

[kubeadm]

S2I is also a tool that can be used 'standalone' - outside of OCP - one can install it from the 'source-to-image' package or download it from the official github repo.

The beauty of this tool is that it allows one to create an application image from your source-code repository, for example: 

s2i build https://github.com/openshift/django-ex centos/python-35-centos7 hello-python

where:

- https://github.com/openshift/django-ex  <- your applicaiton source-code

- centos/python-35-centos7  <- the "Builder Image" (that contains the Python runtime)

- hello-python  <- the name of your application image.

No need to mess around with Dockerfiles :-)

You can then test the application image (hello-python) locally with Docker before pushing to the OCP internal registry for deployment.

More details can be found here: https://github.com/openshift/source-to-image

[kubeadm]

To clarify further, when one runs the command:

oc new-app --name=myapp http://url-to-mysource-code-repo/app-src-code/

Openshift will automatically detect the source code in the repository url (e.g. whether PHP, Java, Python, etc) and then picks the appropriate builder image and uses the S2I process to build your application image ("myapp").

The "s2i" tool can be invoked independently outside of OpenShift.

[flozano]

One advantage of using s2i outside of OpenShift, as an alternative to Dockerfiles, is that S2I adds a single layer to the parent image, while Dockerfiles add roughtly one layer for each instruction.

I wonder wether S2I is able to work without a docker daemon, like podman and buildlah, and thus allow a developer to use it without getting root privileges. When using S2I inside of OpenShift neither the OpenShift user nor the builder pod require elevated privileges to work.

[kubeadm]

I don't think so - it complains if docker is not running.

Once I've restarted docker, it goes about building the image.