source-to-image for Mac

Source-To-Image (S2I)

Overview

Source-to-Image (S2I) is a toolkit and workflow for building reproducible container images from source code. S2I produces ready-to-run images by injecting source code into a container image and letting the container prepare that source code for execution. By creating self-assembling builder images, you can version and control your build environments exactly like you use container images to version your runtime environments.

For a deep dive on S2I you can view this presentation.

Want to try it right now? Download the latest release and run:

$ s2i build https://github.com/sclorg/django-ex centos/python-35-centos7 hello-python $ docker run -p 8080:8080 hello-python

Now browse to http://localhost:8080 to see the running application.

You've just built and run a new container image from source code in a git repository, no Dockerfile necessary.

How Source-to-Image works

For a dynamic language like Ruby, the build-time and run-time environments are typically the same. Starting with a builder image that describes this environment - with Ruby, Bundler, Rake, Apache, GCC, and other packages needed to set up and run a Ruby application installed - source-to-image performs the following steps: Start a container from the builder image with the application source injected into a known directory The container process transforms that source code into the appropriate runnable setup - in this case, by installing dependencies with Bundler and moving the source code into a directory where Apache has been preconfigured to look for the Ruby config.ru file. Commit the new container and set the image entrypoint to be a script (provided by the builder image) that will start Apache to host the Ruby application.

For compiled languages like C, C++, Go, or Java, the dependencies necessary for compilation might dramatically outweigh the size of the actual runtime artifacts. To keep runtime images slim, S2I enables a multiple-step build processes, where a binary artifact such as an executable or Java WAR file is created in the first builder image, extracted, and injected into a second runtime image that simply places the executable in the correct location for execution.

For example, to create a reproducible build pipeline for Tomcat (the popular Java webserver) and Maven: Create a builder image containing OpenJDK and Tomcat that expects to have a WAR file injected Create a second image that layers on top of the first image Maven and any other standard dependencies, and expects to have a Maven project injected Invoke source-to-image using the Java application source and the Maven image to create the desired application WAR Invoke source-to-image a second time using the WAR file from the previous step and the initial Tomcat image to create the runtime image