Provide a slim version of onbuild

[docker-library]

Provide a slim version of onbuild

[paultag]

+1, super agree. @yosifkit @tianon thoughts?

[tianon]

So, I'm actually very -1 on this idea unless there's a really strong case for it, and I think this section of the Hub readme helps explain a little bit what my position is:

While the onbuild variant is really useful for "getting off the ground running" (zero to Dockerized in a short period of time), it's not recommended for long-term usage within a project due to the lack of control over when the ONBUILD triggers fire (see also moby/moby#5714, moby/moby#8240, moby/moby#11917).

Once you've got a handle on how your project functions within Docker, you'll probably want to adjust your Dockerfile to inherit from a non-onbuild variant and copy the commands from the onbuild variant Dockerfile (moving the ONBUILD lines to the end and removing the ONBUILD keywords) into your own file so that you have tighter control over them and more transparency for yourself and others looking at your Dockerfile as to what it does. This also makes it easier to add additional requirements as time goes on (such as installing more packages before performing the previously-ONBUILD steps).

The onbuild variant is really great for getting zero-to-Docker really, really fast, but it breaks down very quickly because inevitably you want more customized behavior. For example, if we add a slim-onbuild variant, the minute your requirements.txt references a module that needs to compile any C code, it'll fail and you'll be back to writing your own Dockerfile again (because you cannot tell Docker that you want to apt-get install something before it runs the ONBUILD instructions, so you can't install extra packages before the pip install occurs).

In Python's specific case, onbuild/Dockerfile is really, really trivial: (https://github.com/docker-library/python/blob/0fa3202789648132971160f686f5a37595108f44/3.5/onbuild/Dockerfile)

FROM python:3.5

RUN mkdir -p /usr/src/app
WORKDIR /usr/src/app

ONBUILD COPY requirements.txt /usr/src/app/
ONBUILD RUN pip install --no-cache-dir -r requirements.txt

ONBUILD COPY . /usr/src/app

Writing those lines in your own Dockerfile instead gives you the flexibility and control you either need now, or will inevitably need later (especially if you want to go with the slim variant, which doesn't have any headers or even a C compiler IIRC).

So what I'd recommend instead is something like this:

FROM python:3.5-slim

RUN apt-get update && apt-get install -y some-packages-you-need && rm -rf /var/lib/apt/lists/*

# mkdir isn't necessary anymore -- there used to be bugs in WORKDIR that necessitated it
WORKDIR /usr/src/app

COPY requirements.txt /usr/src/app/
RUN pip install --no-cache-dir -r requirements.txt

COPY . /usr/src/app

CMD ["python3", "your-main.py"]

[paultag]

So, I think there's something to be said for an image that just kinda does a thing. For one-off scripts which run off somewhere, I don't think I'd need much, and it'd be good to have a trimmed down version I could use too.

How about this; is there another home we could put the slim variant?

[tianon]

For your one-off script, would you still have a requirements.txt? My problem here is that the slim variant is intentionally super limited, so it's hard for me to justify the maintenance burden of another variant just for something that ultimately isn't going to get used much since it's really not sufficient for most people's needs. :/ As for hosting it elsewhere, it should actually be really, really easy to make a simple automated build that includes a slim-onbuild variant -- just take that existing "onbuild/Dockerfile" and change the base to be 3.5-slim instead and you're pretty much good to go; hook that puppy up to an automated build (and set up a repository link to "python" so it rebuilds whenever this image pushes) and the Hub's infra will make sure it stays up to date for you without much fuss. 👍

[alex]

I guess my takeway here is that it's too bad that ONBUILD isn't good enough that you can use it as the basis for building real abstractions.

[tianon]

Yeahhh -- I really wish ONBUILD were more flexible so we could get more aggressive about codifying best practices with it and letting everyone reap the rewards automatically. 😢

[alex]

On account of this, I guess I'm going to close this.