RedHat OpenShift “S2I” Technology

24 Sep RedHat OpenShift “S2I” Technology

Recently I had the opportunity to work with OpenShift, which is RedHat’s management platform for containers. One of the selling points for OpenShift is its “s2i” feature, short for “Source 2 Image”.

Whilst it is certainly a good feature, there can be some confusion as to why and when to use it.

Traditional Container Approach

Although Docker is not very old (having been released in 2013), many people will be familiar with the process of deploying container applications:

1. Source code
   Your code should reside somewhere that your tooling can access, whether it’s Java, NodeJS, .Net, PHP or anything else.
2. Deployment artifacts
   Before deployment, the application should be packaged up (preferably together with any dependencies). NPM and Maven are popular tools for achieving this.
3. Image
   Use a Dockerfile to create an image with the application server and deployment artifacts included. Many vendors have made their products available for containerisation, making it easy to utilise their software for this purpose.
4. Container
   Once the image is created, the application can be instantiated with environment-specific configuration and then deployed to the container management platform of choice.

S2I Approach

OpenShift’s s2i approach attempts to eliminate steps 2 and 3. For some of the more popular technologies, these steps are so predictable that OpenShift can take care of them for you:

1. Source code
   Developers still need to maintain their source code and make it available for OpenShift.
2. OpenShift
   Point OpenShift at your source code and tell it which technology to use (PHP, Java, NodeJS, etc.). OpenShift will build your application and deploy a container on your behalf.

The biggest benefit here is that it automates a significant amount of the workflow for you. Additionally, developers need less knowledge about Docker (and Linux); they no longer need to maintain a Dockerfile.

Whilst this could potentially replace any automation pipelines you already have, there are a few caveats to be aware of:

• OpenShift can handle many common technologies (and aims to support new versions of these), but you will have to create your own “s2i images” if you’re using something else.
• The S2I feature is specific to OpenShift, so it could be more difficult to switch to a different platform later.
• An automation pipeline can execute much more complex procedures, when that is required.
• The deployed container will include the build tooling, which is not usually desired.

Author: Edwin Hurst