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

[Ben Parees]

On Fri, Mar 17, 2017 at 2:03 PM, Stephanos Bacon <sbacon at redhat.com> wrote:

>
>
> 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/lat
>> est/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
>

​chained builds can work with any types of builds, there's no requirement
either build in the chain be a docker build (but it is something you *can*
do, which you can't do w/ extended builds).  But you're correct that you
still can't use docker builds in online.  You can chain 2 s2i builds.
​​


> 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?
>

​Sure, you can do the compilation anywhere you want and then inject the
compiled artifacts into a runtime image using either an s2i build or a
docker build (possibly via a binary build), it's all open ended.  We have
plenty of customers doing that... again demonstrating that creating a
specific feature for this (extended builds) was a mistake when there are
already other ways to accomplish the same goal.




>
> -steph
>



-- 
Ben Parees | OpenShift
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/container-tools/attachments/20170317/68168f96/attachment.htm>