On Fri, Mar 17, 2017 at 12:43 PM Ben Parees <bpar...@redhat.com> wrote:
> On Fri, Mar 17, 2017 at 12:18 PM, Lance Ball <lb...@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... :) > > - 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
_______________________________________________ Container-tools mailing list Container-tools@redhat.com https://www.redhat.com/mailman/listinfo/container-tools
