Consider alpine/busybox base image

[tracker1]

https://registry.hub.docker.com/_/alpine/

Though I'm not sure how much will actually be saved once Python2.7, build tools and libssl dependencies are installed, it might be worth considering.

[oren]

👍

[oren]

@tracker1 https://github.com/oren/alpine-node - only 22 MB

[jbergstroem]

Perhaps run this binary against the test suite to make sure it passes?

[retrohacker]

@jbergstroem automated tests of our docker images is def on my roadmap. Just haven't had time. I'll open an issue for it though.

[jbergstroem]

Just saying that the alpine stuff is pretty much bleeding edge (that alpine-node seems to pull the latest available from alpine). If this ends up being our recommended solution, it'd be great to back that statement up. Btw, I'm also really like the suggested approach of minimising the container size as long as we're very comfortable with the toolchain that leads us there.

[tracker1]

@oren thanks, had considered doing the same... added issue suggesting the addition of pre-requisites for gyp...

@jbergstroem cool, I'd thought about just seeing which version was in apm and how well up to date the alpine image would be myself, hadn't taken the time. Agreed on minimizing the size... even though it's not too bad, ubuntu and debian images are a bit bigger and if we can start off small, it is a great thing.

[oren]

yup. tiny images are nice. Here is nginx in 6 MB - https://github.com/oren/alpine-nginx

[retrohacker]

100% agree with the direction this is going. I'll be glad to tackle this, but it might be a few weeks before I'm at a point where I can explore this area (my backlog is pretty long right now). If @oren or @tracker1 (or others?) wants to kick off exploring this in the form of a PR to a new branch (maybe alpine?) we can start iterating on the idea. Thoughts?

[retrohacker]

( //CC: @pesho @Starefossen @hmalphettes @jlmitch5)

[pesho]

I also like this, and would welcome a PR adding it as a tag in this repo (possible tags: alpine, micro, busybox, or something else?)

[tianon]

IMO "alpine" would be the most self-descriptive tag 😄

[pesho]

would welcome a PR adding it as a tag in this repo

A few points, before anyone starts working on such a PR:

• The image shouldn't rely on an external package repository (as @oren's image does). A possible exception is, if this repository is also managed by the (at this point hypothetical) Docker WG, but that would be a pretty major change requiring further discussion.
• The image should properly verify during build the GPG signatures of the downloaded binaries (assuming they are used at all), like the other variants do. I doubt the Alpine base image includes GnuPG, so it may need to be added, this increasing the image size (unless GnuPG is deleted before a layer is committed, of course).
• The image should fit the current build process, so that version updates won't be complicated. The helper scripts would have to be updated.

If it's not possible to satisfy the above, I think the Alpine image should remain separate.

[hmalphettes]

The source of the iojs package build is here: https://github.com/alpinelinux/aports/blob/master/testing/iojs/APKBUILD

The image 'alpine:edge' does not contain gnupg indeed; Note that gnupg is available as a supported package.

[hmalphettes]

If we go down this route dont we need to provide the rest of the images: "iojs:alpine-slim", "iojs:alpine", "iojs:alpine-onbuild" ?

Starting from @oren's Dockerfile I have been testing Alpine to run some modules with native dependencies. @oren's image is a fine alternative to iojs:slim.

We would need a second fatter alpine image with the build tools to support this situation:

RUN apk update && \
  apk add --update iojs make g++ git gnupg python bash && rm -rf /var/cache/apk/*

That image weighs 203 MB to be compared with the 700 MB of the debian based iojs image.

[oren]

What about having 2 images: 22 MB image for situations where native modules are not needed, and 700 MB for the other case.