[Container-tools] [node-devel] Community Node.js Builder Images

[Stephanos Bacon]

On Fri, Mar 17, 2017 at 1:57 PM, Lance Ball <lball at redhat.com> wrote:

>
>
> On Fri, Mar 17, 2017 at 12:43 PM Ben Parees <bparees at redhat.com> wrote:
>
>> On Fri, Mar 17, 2017 at 12:18 PM, Lance Ball <lball at redhat.com> wrote:
>>
>>
>>    - Allowing for composability so that the developer can add what they
>>    need at image build time. I think that .s2i/assemble and friends make
>>    this possible, but maybe I am missing something larger. Am I?
>>
>> ​I think you're missing two things:
>>
>> 1) assemble can't install packages, it doesn't have root permissions
>> 2) doing things at assemble time means doing them every time you build
>> the application image, instead of just one time when you create the builder
>> image, so it dramatically increases build times.
>>
>
> Ahh, good points. Thanks.
>
>
>>
>>    - Providing two different s2i base images for each runtime
>>    environment: s2i-core and s2i-base, for example. I think the core
>>    image should be similar to rhel7-atomic. Just a bare bones,
>>    optimized-for-the-container image. Developers concerned about image size
>>    can use this image and .s2i/assemble to have a fully customizable
>>    build/runtime environment. Developers less concerned about minimal size
>>    could depend on s2i-base which has all of the tools and development
>>    libraries that are generally required for the vast majority of
>>    OS/platform/language environments.
>>
>>
>> ​s2i-base really started out as an internal thing for us to use as a
>> common base for the s2i images we were providing.  We actually fought, for
>> a long time, making it "public" and having other people start creating
>> their own images on top of it because we didn't want to treat it as an api.
>>
>> If we were going to create a "slimmed down" version of s2i-base, i'd be
>> curious what would actually be in it, as opposed to just telling people who
>> want to build smaller s2i images, to use some other generic base image.
>> The things s2i-base provides are:
>> 1) common set of packages that are useful for things built on top (the
>> stuff you are suggesting getting rid of)
>> 2) a few helper scripts and env variables that provide useful context for
>> an s2i image.
>>
>
>> I don't know that there's enough value in (2) to justify created a second
>> "s2i-base-lite" image once you get rid of (1).
>>
>
> I think that means that for users who want to build smaller images,
> they'll need to use the base image of their choice, and then be aware
> of/provide the bits described here: https://docs.openshift.org/
> latest/creating_images/guidelines.html#openshift-
> origin-specific-guidelines and here: https://docs.openshift.org/
> latest/creating_images/s2i.html#creating-images-s2i, if I understand
> correctly. In my opinion, a slim image that provides these things would be
> useful. There is a lot of content in those docs to sift through and
> implement for a potentially common case. But I'm a sample size of 1, so...
> :)
>
>
>>
>>    - Allow users to specify the runtime image and runtime artifact(s) on
>>    the command line, as described in the document linked below. In a
>>    contrived/simple case, this would mean that a developer could use
>>    s2i-base for building the application image and s2i-core for the
>>    runtime. No customization required, just a simple command line option that
>>    builds in a full featured environment and deploys to a slimmed down
>>    runtime.
>>
>>
>> ​fyi we are really encouraging people not to use extended builds(the
>> build/runtime image mechanism) and instead accomplish that goal via
>> chained-builds:
>>
>> https://docs.openshift.org/latest/dev_guide/builds/
>> advanced_build_operations.html#dev-guide-chaining-builds
>>
>
> Interesting. If I want to use chained builds, how do I accomplish that? Do
> I need to create a build in the UI, then manually edit the BuildConfig? Or
> somehow POST a BuildConfig to OpenShift? Is there any easier and more
> intuitive way?
>
> I'm curious why this is the suggested approach. From my perspective,
> extended builds seem much more intuitive, and certainly easier for the end
> user.
>
> Lance
>

Also, will chained builds work on OpenShift Online and OpenShift Dedicated?
 (I thought that docker builds didn't work on OCO and OCD).  Also, also -
if docker builds work anyway, could one dispense with the s2i build and do
both the compilation and the docker build in a jenkins build pod?

-steph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/container-tools/attachments/20170317/5747c8d4/attachment.htm>