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

[Ben Parees]

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...
> :)
>

​yeah, pretty much...  so yes, not "free" and there is some non-zero value
in offering an "s2i_sdk" type image.  Perhaps the most sensible thing to do
would be to create the lightweight s2i_core image and then layer the
"commonly needed packages" on top of that image to create the s2i_base
image​.  Then we're not really introducing a new image, we're just
splitting out the existing layers so you can start at the layer you want.




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

​basically you create your two buildconfigs using whatever mechanism you
want and edit/configure them as needed to setup the chaining.  There's no
tooling specifically around "chain these builds together" if that is what
you're asking.​



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

​It was done because extended builds
1) were limited to s2i based flows (with chained builds you can use an s2i
build to produce a war file and a docker build to add that war into a
runtime image)
2) were a special case of something you could already do in the product via
chained builds and thus were a redundant codepath/feature to maintain (with
more limitations than the existing capability, per (1)).
3) required learning another technique (creating more s2i scripts to
support the extended flow, possibly creating more s2i images (runtime and
build specific images), etc, whereas chained builds allows you to more
directly use existing content

So yeah, it's a bit more configuration work, but it's a more flexible
mechanism that more naturally builds on things people are already doing/can
do instead of introducing a whole new path/type of image/etc.
​



>
> Lance
>



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