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/ > 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 > Also, will chained builds work on OpenShift Online and OpenShift Dedicated? (I thought that docker builds didn't 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? -steph
_______________________________________________ Container-tools mailing list [email protected] https://www.redhat.com/mailman/listinfo/container-tools
