[kontinuity-dev-public] S2I vs. docker build

[Andrew Block]

The two phase build is a very intriguing feature. I have had many customers question why we are packaging build tools as part of our production image. This would certainly give them the flexibility to take advantage of the source to image feature of OpenShift, but to utilize a lean image for their production deployment. I look forward to seeing how this approach matures and to build collateral around it.

- Andy

 
Andrew Block
Red Hat Consulting
101 N. Wacker, Suite 150
Chicago, IL 60606
andrew.block at redhat.com | m. (716) 870-2408

On May 2, 2016 at 11:00:11 PM, Ricardo Martinelli de Oliveira (rmartine at redhat.com) wrote:

I've never heard about this approach, and thinking about the docker image size it could be a good approach when build pipeline is promoting a build from QA to Production. From Jenkins perspective, can this be done(promote binary from QA to Production using this strategy)?

On Mon, May 2, 2016 at 10:00 PM, Ben Parees <bparees at redhat.com> wrote:


On Mon, May 2, 2016 at 2:39 PM, Tomas Nozicka <tnozicka at redhat.com> wrote:
As I have written in a previous post I started to write Jenkinsfiles
for the helloworld application and I am not sure how will we build
docker images. The are 2 ways:

1) [Classic] Build it in your Jenkins job/build and call 'docker build'
 - 'docker build' needs to be root/privileged and will not be allowed
to run on OpenShift Online (AFAIK)
 - can be setup to do a 2-phase build for compiled languages

2) S2I (OpenShift concept [1])
 - runs S2I image as non root and commits and tags the resulting image
at the end
 - works on OpenShift Online
 - harder to setup and work with
 - does not do a 2-phase build /yet/ for compiled languages as some
people think (including myself until today)

I ​agree ​with what others have said in this thread, but just wanted to note that while there is no first class support for a 2-phase build, there are two other approaches available:

1) use an image that has both the build tools and runtime tools in the same image.  For example, our EAP, JWS, and Wildfly images all do this, so you can use them with s2i just fine, as long as you don't mind that your final application image will include maven/jdk(not just a jre).

2) define two builds, first build uses a maven image to build war, results in an image containing a war file.  second build takes the output image from the first build as its input, extracts the war and lays it on top of a runtime-only image.  More details on how the "input from an image" is defined here:
https://docs.openshift.org/latest/dev_guide/builds.html#image-source

We are also this sprint starting work on the first class implementation of two phase builds (what we call extended builds..where you have 2 images, one that's the builder image and one that's the runtime image).  It won't be done this sprint, but it is a target for 3.3.


 

What type of build are we going to use?

Are we targeting OpenShift Online?

Thanks,
Tomas

[1] - https://docs.openshift.org/latest/architecture/core_concepts/buil
ds_and_image_streams.html#source-build
S2I for Java - https://docs.openshift.org/latest/using_images/s2i_image
s/java.html

_______________________________________________
kontinuity-dev-public mailing list
kontinuity-dev-public at redhat.com
https://www.redhat.com/mailman/listinfo/kontinuity-dev-public



--
Ben Parees | OpenShift


_______________________________________________
kontinuity-dev-public mailing list
kontinuity-dev-public at redhat.com
https://www.redhat.com/mailman/listinfo/kontinuity-dev-public


_______________________________________________  
kontinuity-dev-public mailing list  
kontinuity-dev-public at redhat.com  
https://www.redhat.com/mailman/listinfo/kontinuity-dev-public  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/kontinuity-dev-public/attachments/20160502/153ce1dc/attachment.htm>