This post is about S2I which is source to image process to build application container images for OpenShift.
s2i is available here:
About S2I :
Source-to-Image (S2I) is a framework that makes it "easy to write images" that take application source code as an input and produce a new image that runs the assembled application as output.
so, input is application source code
output is image
Two basic concepts:
1. the build process
2. S2I scripts.
During the build process, S2I must place sources and scripts inside the builder image.
So, what is a Builder image here?
- is one which is going to build the application source. So, it should contains the bits necessary to build the application.
For example, for building python based application all necessary python libs.
S2I creates a tar file that contains the sources and scripts, then "streams" that file into the builder image.
source + scripts ================> tar =========> builder image ===========> container image.
(compiled into) (fed to) ( produces)
untar of tar file into default directory /tmp. ( can be modified with --destination flag)
tar + sh is necessary to carry out above operation.
If tar +sh is NOT available, additional container build is required to put both source and script inside the image and then usual s2i build procedure.
After untar, assemble script is executed.
- builds the application artifacts from a source and places them into appropriate directories inside the image.
- executes your application
- gathers all dependencies that can speed up build processes that follow.
// for ruby, gems installed, for java m2 contents.
- inform how to properly use your image
create a simple process to check if image is running properly.
Creating S2I builder image:
s2i tool -> creating builder images.
builder image contains specific intelligence required to produce that executable image(aka build artifacts).
simple work flow:
1. download s2i scripts( or use one from inside builder image)
2. download application source.
3. s2i streams the scripts and application sources into the builder image container.
4. it runs the assembler script, which is defined in the builder image.
5. save the final image.
Builder image -> responsible for actually building the application. (so it has to contain necessary libraries and tools need to build and run the application).
it needs script log to actually perform build and run operations.
- assemble for build of application
- run for running of application
// for bootstrapping a new s2i enabled image repo.
// generates skeleton .s2i directory and populate it with sample s2i scripts (which you can start hacking on).
// Here lighttpd-centos7 *future builder image name*
// s2i-lighttpd is directory created
s2i create lighttpd-centos7 s2i-lighttpd
// build test-app using lighttpd-centos7 as builder image , output image is lighttpd-centos7-app
s2i build test/test-app lighttpd-centos7 lighttpd-centos7-app
Building application image using builder image:
// build a application image using builder image
$ s2i build https://github.com/openshift/django-ex centos/python-35-centos7 hello-python
source - https://github.com/openshift/django-ex
build image - centos/python-35-centos7 // this should be present either locally / at docker hub.
output tagged image - hello-python
// You can run the built image as below :
$ docker run -p 8080:8080 hello-python
Next, We will see about how to save the built images into a persistent store and to retrieve artifacts while building application.