概念介绍
OpenShift的s2i过程是把基础镜像和源代码结合，生成可以运行的application镜像的过程，s2i中的四个脚本详细介绍请参考：https://github.com/openshift/source-to-image/blob/master/docs/builder_image.md。
如果我们有特殊的要求，比如自定义build过程，一般通过重写s2i脚本实现。
编译和部署自己的应用程序
docker生成镜像的过程，当我们创建自己的应用程序镜像的时候，一般来说有两种途径：
- 通过Dockerfile来创建：
传统做法是自己编写Dockerfile，使用基础镜像，copy源代码、RUN命令来安装依赖包、shell命令来编译程序、CMD名字指定可运行程序，最后使用
docker build 生成镜像。
- 通过docker run和docker commit来创建
还有一种比较小众的做法。是docker run
运行基础镜像，然后使用交互式shell下载源代码、安装依赖包最后使用docker
commit提交容器生成镜像。
理解s2i 历程中的三个镜像
要了解 s2i的过程我们先来理解三个阶段的三个镜像：
- 基础镜像 base image：
是我们在docker hub下载的某个语言的官方镜像，比如python
2.7、PHP3.5，这些镜像只包含语言的编译环境，没有做任何加工。
- 编译镜像 builder image：
这个镜像是我们在基础镜像的基础上，经过加工以后，可以自动编译代码，并自动完成部署运行的镜像，这个镜像是通过dockerfile生成，继承自上面的base
image。制作过程参考：https://github.com/openshift/source-to-image/
- 运行时镜像 runtime image：
这个镜像是通过s2i构建出来的镜像，已经完成了编译工作，直接运行容器就可以启动,这个镜像的生成包括三个要素：1：builder
image; 2：source code; 3：s2i script;这个镜像的生成过程是，运行builder
image，在容器中注入代码，并使用s2i脚本安装依赖包以及编译工作，最后把生成的镜像comit
出一个新的image ，称为 runtime image
OpenShift由builder image到runtime image的过程如下图：
自定义s2i脚本
openshift官方已经提供了各种语言的 builder image，(当然这些builder
image中已经注入了写好的s2i脚本，一般保存在/usr/libexec/s2i目录下)，这些脚本通常适用于一些简单的程序部署，如该应用程序的编译和部署过程比较复杂，这些脚本就不能满足要求，这时候我们可以通过自定义s2i脚本来控制build和deploy过程，自定义s2i脚本的编写过程不再赘述，可以参考s2i官方文档，这里说明一下怎么应用自己编写的s2i脚本：
有以下三种方式可以使用自定义s2i脚本来替换默认脚本：
在代码中包含s2i脚本：在代码仓库的跟目录创建文件夹
.s2i/bin，把脚本放到这个目录中，当编译时会自动调用这个脚本，值得注意的是，早期版本使用的是
.sti/bin文件夹，后期版本使用的是.s2i/bin。指定网络上的s2i脚本地址：通过设置bc的bc.spec.strategy.sourceStrategy.scripts项目来指定s2i脚本地址，系统会自动去该地址下载脚本。
如果使用s2i工具创建，可以通过三种方式设置脚本位置
s2i配置文件信息
主要包含四个文件，分别为：
assemble 用于对源码编译以及安装配置的脚本
run 启动应用镜像时执行的脚本
save-artifacts
用于保存一些编译中复用的内容，这样下次编译可以直接使用这些文件，从而加快编译安装等速度usage 打印生成镜像的帮助信息
这四个文件都需要用户自行定义，s2i会通过三种方式寻找这些文件，分别为：
源码中.s2i/bin下
-scripts-url 参数指定的位置
镜像中label：io.openshift.s2i.scripts-url指定的位置
推荐使用第一种方式，这样方便管理和持续集成，其他两种url都支持以下三种形式：
image://path_to_scripts_dir 在镜像内的绝对路径
file://path_to_scripts_dir 在主机上的绝对或者相对路径
http(s)://path_to_scripts_dir 网络上的文件