Written by Harini Krish
Lead Technical Content Writer
For many enterprises, a big part of DevOps’ appeal is software automation using infrastructure-as-code techniques. This article gives developers, architects, and infra-ops engineers a further practical option. You will learn how a container-centric approach from OpenShift can help your team deliver quality software through a self-service view of IT infrastructure.
When using OpenShift, there are several different ways that you can add an application. Below are commonly used methods for deploying applications in OpenShift.
Source to Image (S2I)
However, Source to Image (S2I) is the most popular way to achieve seamless deployments in OpenShift.
Source-to-Image (S2I) is a tool for creating reproducible, Docker-formatted container images. It produces ready-to-run images by injecting an application source into a container image and assembling a new image. The new image integrates the base image (the builder) and built source and is ready to use with the buildah run command. S2I supports incremental builds, which uses previously downloaded dependencies, once built artifacts, etc.
Source-to-Image (S2I) is a framework that makes it simple to write images that uses the application source code as an input and create a new image that runs the assembled application as output.
The major advantage of using S2I for building reproducible container images is the simplicity of use for developers. As a builder image author, the two basic concepts for the images is to provide the best possible S2I performance with the build process and S2I scripts.
The build process contains the three basic elements, which are combined into a final container image:
Throughout the build process, S2I should place sources and scripts within the builder image. To do so, S2I builds a tar file that has the sources and scripts, then streams that file into the builder image. Prior to executing the assemble script, S2I un-tars that file and places its elements into the location specified by the io.opemlabel from the builder image, with the default spot being the /tmp directory.
For this process to happen, the image must provide the command line interpreter (the /bin/sh command) and tar archiving utility (the tar command available in $PATH); this lets the image to use the fastest possible build path. Suppose if the tar or /bin/sh command is not available, the s2i build process is forced to automatically perform an additional container built to put both the sources and the scripts inside the image and then run the usual build.
Run build’s task is to un-tar the sources, scripts, and artifacts and use the assemble script. Whether this is the second run (after catching tar or /bin/sh not found error), it is accountable only for invoking assemble script as both scripts and sources are already available.
There are couple of ways to make environment variables accessible to the source build process and resulting image: BuildConfig environment values and environment files. Variables given will be readily available during the build process and in the output image.
In this article, our Royal Cyber experts have explained the knowledge you need to make the best use of the OpenShift platform. Developers and administrators will learn how to run, access, and manage containers in OpenShift, including how to orchestrate them at scale. A common deployment method for applications running in OpenShift has been launched. This list is certainly not complete; but it is the hope that these methods will help OpenShift practitioners get the deployments seamless and smooth in the right direction. It can be very useful when working on an application requiring specific configuration or dependencies that could not easily reproduce outside of an OpenShift platform. For more information, you can email us at [email protected] or visit www.royalcyber.com.