{"id":321,"date":"2018-10-16T09:43:34","date_gmt":"2018-10-16T09:43:34","guid":{"rendered":"https:\/\/www.appservgrid.com\/paw93\/?p=321"},"modified":"2018-10-17T07:36:08","modified_gmt":"2018-10-17T07:36:08","slug":"flexible-images-or-using-s2i-for-image-configuration","status":"publish","type":"post","link":"https:\/\/www.appservgrid.com\/paw93\/index.php\/2018\/10\/16\/flexible-images-or-using-s2i-for-image-configuration\/","title":{"rendered":"Flexible Images or Using S2I for Image Configuration"},"content":{"rendered":"

\"\"<\/p>\n

Container images usually come with pre-defined tools or services with minimal or limited possibilities of further configuration. This brought us into a way of thinking of how to provide images that contain reasonable default settings but are, at the same time, easy to extend. And to make it more fun, this would be possible to achieve both on a single Linux host and in an orchestrated OpenShift environment.<\/p>\n

Source-to-image (S2I) has been introduced three years ago to allow developers to build containerized applications by simply providing source code as an input. So why couldn\u2019t we use it to make configuration files as an input instead? We can, of course!<\/p>\n

Creating an Extensible Image<\/h2>\n

Creating S2I builder images was already described in an article<\/a> by Maciej Szulik and creating images that are extensible and flexible enough to be adjusted with custom configuration is not much different. So let\u2019s focus on the bits that are essential for making an image configurable.<\/p>\n

Required Scripts<\/h3>\n

The two scripts that every builder image must provide are; assemble and run, <\/b>both are included in the s2i\/bin\/ directory.<\/p>\n

assemble<\/h4>\n

The assemble script defines how the application image is assembled.<\/p>\n

Let\u2019s look at the official Software Collections nginx<\/a> S2I builder image to see its default behavior. When you open the assemble script (snippet below), you see that by default the nginx<\/i> builder image looks in the nginx-cfg\/<\/i> and nginx-default-cfg\/<\/i> directories within the provided source code where it expects to find your configuration files used for creating a customized application image.<\/p>\n

if [ -d .\/nginx-cfg ]; then
\necho “—> Copying nginx configuration files…”
\nif [ “$(ls -A .\/nginx-cfg\/*.conf)” ]; then
\ncp -v .\/nginx-cfg\/*.conf “$”
\nrm -rf .\/nginx-cfg
\nfi
\nfi<\/p>\n

if [ -d .\/nginx-default-cfg ]; then
\necho “—> Copying nginx default server configuration files…”
\nif [ “$(ls -A .\/nginx-default-cfg\/*.conf)” ]; then
\ncp -v .\/nginx-default-cfg\/*.conf “$”
\nrm -rf .\/nginx-default-cfg
\nfi
\nfi<\/p>\n

run<\/h4>\n

The run script is responsible for running the application container. In the nginx<\/a> case, once the application container is run, the nginx server is started on the foreground.<\/p>\n

exec \/usr\/sbin\/nginx -g “daemon off;”<\/p>\n

Labels<\/h4>\n

To tell s2i where it should expect the scripts, you need to define a label in the Dockerfile:<\/p>\n

LABEL io.openshift.s2i.scripts-url=”image:\/\/\/usr\/libexec\/s2i”<\/p>\n

Alternatively, you can also specify custom assemble<\/i> and run<\/i> scripts by collocating them with your source\/config files; the scripts baked in the builder image would then be overridden.<\/p>\n

Optional Scripts<\/h3>\n

Since S2I provides quite a complex set of capabilities, you should always provide documentation on how users are expected to use your image. Test configuration (or application) might come in handy as well.<\/p>\n

usage<\/h4>\n

This script outputs instructions on how to use the image when the container is run.<\/p>\n

test\/run and test\/test-app<\/h4>\n

These scripts will test the application source code and run of the builder image.<\/p>\n

To make the creation of these images easier, you can take advantage of the S2I container image template<\/a>.<\/p>\n

Extending an Image with Custom Configuration<\/h2>\n

Now let\u2019s have a look at how you can use such an image in the real world.<\/p>\n

Again, we\u2019re going to take the above nginx image to demonstrate how to adjust it to build a containerized application with custom configuration.<\/p>\n

One of the advantages of using source-to-image for configuration is that it can be used on any standalone Linux platform as well as in an orchestrated OpenShift environment.<\/p>\n

On Red Hat Enterprise Linux, it is as easy as running the following command:<\/p>\n

$ s2i build https:\/\/github.com\/sclorg\/nginx-container.git –context-dir=1.12\/test\/test-app\/ registry.access.redhat.com\/rhscl\/nginx-112-rhel7 nginx-sample-app<\/p>\n

The s2i build command takes the configuration files in the test\/test-app<\/i>\/ directory and injects them in the output nginx-sample-app<\/i> image.<\/p>\n

Note that by default, s2i takes a repository as an input and looks for files in its root directory. In this case, the configuration files are in a subdirectory, hence specifying the \u2013context-dir.<\/p>\n

$ docker run –rm -p 8080:8080 nginx-sample-app<\/p>\n

Running the container will then show you a website informing you that your Nginx server is working.<\/p>\n

And similarly in OpenShift:<\/p>\n

$ oc new-app registry.access.redhat.com\/rhscl\/nginx-112-rhel7~https:\/\/github.com\/sclorg\/nginx-container.git –context-dir=1.12\/test\/test-app\/ –name nginx-test-app<\/p>\n

The oc new-app<\/i> command creates and deploys a new image nginx-test-app<\/i> modified with the configuration provided in the test\/test-app\/<\/i> directory.<\/p>\n

After creating a route, you should see the same message as above.<\/p>\n

Advantages of Using an S2I Builder Image for Extension<\/h2>\n

To sum it up, there are a number of reasons to leverage S2I for your project.<\/p>\n