[Openshift Commons Image Builders SIG] source2image and compiling java...where's the right place to do it?

[Jorge Morales Pou]

Hi Marc,
Our current s2i builders expect the source code to be provided, and the
build to happen in OpenShift, but this is just an actual limitation of our
builders rather than the platform. A custom s2i image can be crafted so
that instead of expecting the source code to build the application, it just
get's the generated artifact and layers that on top of a runtime image
(Tomcat in your example).
For this, we've been working, and keep doing, into making this scenario
easier, by:
- Making a source repository optional (OSE 3.3)
- Providing binaries to the build process (3.2:
https://docs.openshift.com/enterprise/3.2/dev_guide/builds.html#binary-source
)
- Providing content from another image (3.2:
https://docs.openshift.com/enterprise/3.2/dev_guide/builds.html#image-source
)
- Splitting the build process into builder + runtime images (3.3)
- Provide additional information in webhooks (3.3)
With these tools in place, it would be trivial to make an s2i that fetches
a binary artifact from an artifact repository manager (nexus, artifactory)
on the coordinates provided via webhook or start-build options, and just
layer the artifact into a runtime image. This will be an OOTB scenario for
3.3, until then, some manual crafting need to be done, but still possible,
by a custom assemble script as an example.
https://docs.openshift.com/enterprise/3.2/dev_guide/builds.html#using-external-artifacts
http://blog.andyserver.com/2016/03/getting-to-the-cloud-faster-with-binary-builds-on-openshift/

If your using one of our s2i, option 2 seems the way to go (or even if
you're crafting your own, you can follow similar approach, following our
wildfly s2i https://github.com/openshift-s2i/s2i-wildfly/tree/master/10.0).
As I mentioned before, we will be splitting builder and runtime image, so
you will no longer need to have javac + maven on the s2i image, but rather
you'll have a maven builder and a tomcat runtime, and the generated
artifact will be copied from the former to the later automagically in the
s2i process. You can see details here:
https://trello.com/c/MWUAjl6k/237-13-extended-builds-separate-mvn-vs-jboss-evg.
This is a Work in Progress, that will be in OSE 3.3. Also, this can be
currently achieved by combining 2 builds and chaining them. The image built
in the first build (which would be just java + maven) will be used as
source for the second build to get the artifact into a plain Tomcat.

The 3rd option seems like a big boilerplate to craft in an image, so I
would rather recommend either option 2 or 1.

Hope this helps,

Jorge Morales
OpenShift by Red Hat
EMEA Field Product Manager
Product Marketing Manager

On Wed, Jun 1, 2016 at 6:05 PM, Marc Boorshtein <
marc.boorshtein at tremolosecurity.com> wrote:

> Fellow builders,
>
> We're building a source2image builder for our Java application and
> we're struggling with the question of where to actually build the
> system.  The output of a maven build process is a war file that goes
> into a hardened version of Tomcat.  We see three options:
>
> 1.  Input is a war file created as the output of an external build -
> simple for us but seems to defeat the purpose of s2i
>
> 2.  Assume that maven and javac are wherever s2i is running and have
> the assemble script pull the maven project, build it and deploy the
> war file into the image - This seems the most obvious to me since it
> lets us rely on existing build processes.
>
> 3.  Pull in maven and the source code into the image, then have the
> image build the project, deploy the wars and then remove maven and the
> source code - This seems like it would be the most consistent way to
> do a build since it wouldn't matter which system s2i runs on but it
> requires the most amount of work on our end.
>
> Any thoughts/advise on the best or recommended approach?  Is there one
> that we're missing?
>
> Thanks
>
>
> Marc Boorshtein
> CTO Tremolo Security
> marc.boorshtein at tremolosecurity.com
> (703) 828-4902
> Twitter - @mlbiam / @tremolosecurity
>
> _______________________________________________
> Openshift-commons-sig-image-builders mailing list
> Openshift-commons-sig-image-builders at redhat.com
>
> https://www.redhat.com/mailman/listinfo/openshift-commons-sig-image-builders
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/openshift-commons-sig-image-builders/attachments/20160602/deedb51b/attachment.htm>