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

[Lance Ball]

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

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/container-tools/attachments/20170317/550e68e5/attachment.htm>