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

Ben Parees bparees at redhat.com
Fri Mar 17 16:42:40 UTC 2017 

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

> Joe,
>
> Thanks for the input here. This is useful, and the thread you link to is
> interesting. No doubt solving this is not easy since you can never really
> know everything the end user/developer will want for an application
> build/runtime.
>
> Some of the ideas in that thread, and in this document [1] that sound the
> most compelling to me are
>
>    - 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.



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



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


> I think the combination of these three capabilities give the developer a
> lot of flexibility - maybe all that is needed - in customizing the build
> and runtime environments for their application. And since s2i-base still
> has the whole kit and caboodle(??!!), you still have a simple, easily
> demonstrated experience for new users who just want to get to know
> OpenShift and don't need deep levels of customization/optimization.
>
> My 2c.
> Lance
>
> [1] https://github.com/openshift/source-to-image/blob/master/docs/runtime_
> image.md
>
> On Fri, Mar 17, 2017 at 11:27 AM Joe Orton <jorton at redhat.com> wrote:
>
>> On Fri, Mar 17, 2017 at 02:52:03PM +0000, Lance Ball wrote:
>> > Thanks for the reply Ben. Adding everyone else back in...
>> >
>> > I honestly don't mean to be obtuse here, but I'm still a little
>> confused.
>> > Please bear with me and a couple more questions.
>>
>> I think the list of packages added to s2i-base is exactly the set of
>> things which have been seen to be common across the various language
>> images.  BenP & Honza can probably expand on this.
>>
>> We're discussing the same thing over on the RHSCL list, FYI =>
>>
>> http://post-office.corp.redhat.com/archives/rh-software-collections/2017-
>> March/msg00028.html
>>
>> With the node image the gyp npm module is one we have had "fun" with -
>> it needs Python and a C++ compiler.
>>
>> Regards, Joe
>>
>> >
>> > On Thu, Mar 16, 2017 at 7:40 PM Ben Breard <bbreard at redhat.com> wrote:
>> >
>> > > I mean that fedora and centos will have versions of the rhel7-atomic
>> > > image. With this we can potentially create smaller s2i and other
>> useful
>> > > things. ...but I have no other insight on who maintains what. sorry
>> > >
>> >
>> > I don't understand how Fedora and CentOS can have "versions of the
>> > "rhel7-atomic" image. Do you mean that there will be "atomic" (and
>> > therefore hopefully, smaller) images for these OSs? So, we'd have
>> something
>> > like fedora-atomic and centos-atomic?
>> >
>> >
>> > > I'm confused why you would need to install httpd, etc in a base
>> builder
>> > > image. Shouldn't a base s2i builder image just be the minimal
>> requirements
>> > > to support runtime execution in the OpenShift environment?
>> > >
>> > > yes!!! Here's the list:
>> > >
>> > >   INSTALL_PKGS="autoconf \
>> > >   automake \
>> > >   bsdtar \
>> > >   bzip2 \
>> > >   findutils \
>> > >   gcc-c++ \
>> > >   gd-devel \
>> > >   gdb \
>> > >
>> >
>> > Why would a plain vanilla builder image need gdb, gcc, gcc-c++, gd-devel
>> > and make (below)? I suppose for projects that require compilation during
>> > the build step this makes sense. But isn't that specific to a runtime
>> > platform/language? E.g. if I'm running a Ruby application, why on earth
>> > would I want my runtime image to contain gd-devel and gdb? And to be
>> > honest, even for compiled projects, gdb seems a bit overkill for a
>> runtime
>> > build environment.
>> >
>> >
>> > >   gettext \
>> > >   git \
>> > >   libcurl-devel \
>> > >   libxml2-devel \
>> > >   libxslt-devel \
>> > >   lsof \
>> > >   make \
>> > >
>> >   mariadb-devel \
>> > >   mariadb-libs \
>> > >
>> >
>> > Why include MariaDB by default in the builder images? Most projects
>> won't
>> > use this will they? Or is it specific to OpenShift's needs?
>> >
>> >
>> > >   openssl-devel \
>> > >   patch \
>> > >   postgresql-devel \
>> > >
>> >
>> > Same question as above. Why include this unless it's needed by OpenShift
>> > itself.
>> >
>> >
>> > >   procps-ng \
>> > >   scl-utils \
>> > >   sqlite-devel \
>> > >
>> >
>> > Ditto...
>> >
>> >
>> > >   tar \
>> > >   unzip \
>> > >   wget \
>> > >   which \
>> > >   yum-utils \
>> > >   zlib-devel" && \
>> > >
>> >
>> > Devel libs seem unnecessary?
>> >
>> > I guess on the whole, I think the base builder images for any given
>> > operating system should have only enough in them to fulfill OpenShift
>> > requirements. After that, it seems that subsequent builder images that
>> > layer on top of these should be responsible for handling their own
>> > dependencies. So, it's confusing to me why we would need to include all
>> of
>> > this extraneous stuff in the builder images.
>> >
>> >  Thanks
>> > Lance
>> --
>> Joe Orton // Red Hat Core Services
>>
>


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

More information about the Container-tools mailing list