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

[Jorge Morales Pou]

Sure, and once we split the builder and the runtime you'll be able to
easily achieve.
The question here, I guess, is whether you want to have javac + maven in
your runtime, since those are not required to running the app. Once we do
the split, you'll be able to use a builder image for getting from source
code to artifact, and then the runtime would be used for both use cases,
streaming from the builder or providing the artifact from a remote location.

In your usa case, and with your tools at hand, I would recommend creating a
minimal asemble script that fits both purposes, and then reevaluate once
there's more options at hand.

In any case, how you build your images, should always be the same, as the
image, once created is the thing that promotes between environments, and
there's no need to rebuild the image again with a different strategy.

In any case, we're still learning how people uses our platform, and how
they will to use it, so any comment/discussion will be very much
appreciated. Our goal is to make a flexible platform, so if it is not
already, working into it.

Cheers,

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

On Thu, Jun 2, 2016 at 12:48 PM, Marc Boorshtein <
marc.boorshtein at tremolosecurity.com> wrote:

> Thanks Jorge.  I'd think it'd be good to have both option 1 (source)
> and option 2 (binaries) since option 1 is good for just testing
> locally but if you have a full ci/cd pipeline it would be better for
> the ci/cd pipeline to do the build to get the benefits of managing of
> having consistent artifacts?
>
> Thanks
> Marc Boorshtein
> CTO Tremolo Security
> marc.boorshtein at tremolosecurity.com
> (703) 828-4902
> Twitter - @mlbiam / @tremolosecurity
>
>
> On Thu, Jun 2, 2016 at 3:57 AM, Jorge Morales Pou <jmorales at redhat.com>
> wrote:
> > 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/5dcf1b92/attachment.htm>