On Fri, Mar 17, 2017 at 2:03 PM, Stephanos Bacon <[email protected]> wrote:
> > > On Fri, Mar 17, 2017 at 1:57 PM, Lance Ball <[email protected]> wrote: > >> >> >> On Fri, Mar 17, 2017 at 12:43 PM Ben Parees <[email protected]> wrote: >> >>> On Fri, Mar 17, 2017 at 12:18 PM, Lance Ball <[email protected]> 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
_______________________________________________ Container-tools mailing list [email protected] https://www.redhat.com/mailman/listinfo/container-tools
