Add an Alpine variant?

[chorrell]

Having an Alpine variant would be useful.

This primarily depends on nodejs/build#75 though

[Starefossen]

Related: nodejs/docker-iojs#44 and nodejs/docker-iojs#80

[notslang]

Related: https://github.com/mhart/alpine-node

[Starefossen]

Ok, it looks like the Docker guys have given Alpine an official 👍 by adding :alpine variants to many of their managed official images:

https://github.com/docker-library/python/blob/master/3.5/alpine/Dockerfile
https://github.com/docker-library/redis/blob/master/3.0/alpine/Dockerfile

[chorrell]

Nice!

For nodejs/build#75, testing builds against a Docker container I think would be good enough for our use case, but obviously they'd want a VM to build against too.

[gabeio]

👍 the alpine image is amazingly small

golang also has an alpine image! (hope this helps)
https://github.com/docker-library/golang/blob/master/1.6/alpine/Dockerfile

[retrohacker]

https://news.ycombinator.com/item?id=11000827

This seems relevant to the convo

[tianon]

Using the word "switching" there is a fair bit misleading -- we're not outright replacing the base in any image so far, since the potential for breakage by doing so is far too great. In the cases where this is happening, we're simply offering an Alpine-based alternative for space-conscious consumers.

[retrohacker]

Thank you for clarifying @tianon.

I'm going to work on some sort of automated testing for our PR process. If memory serves that was the blocker to trying to ship an alpine or scratch image.

nodejs/docker-iojs#44

[ncopa]

@retrohacker make check works once those 2 pull requests are merged:
nodejs/node#5099
nodejs/node#5056

I think all the issues should be resolved now.

[retrohacker]

@ncopa you rock! Those PRs are 🔥

[ncopa]

@retrohacker anything else preventing this to move forward?

[retrohacker]

@ncopa testing is all that is left.

If we can simply get something that runs dante to smoke test 4 or 5 popular node modules on each PR, I would be happy to go to bat for this.

This is what I do at NodeSource to reassure myself I'm not shipping a broken runtime: https://github.com/nodesource/docker-nsolid/blob/master/tests/npm/smoke_test.sh

[retrohacker]

Adding in make check would be awesome if there is a way to do that without doing the whole build in the container.

[LaurentGoderre]

I am in the process of creating a alpine variant for another service I use and I would like to help out with this.

https://github.com/docker-solr/docker-solr/pull/16/files

I like how that service has templates that are generated. Is this something you guys would consider to simplify adding and maintaining variants?

[chorrell]

I really like the templates approach. it would make updating minor versions (v4.5, v5.11, etc.) easier.

Generally speaking, we're at a point now where we want to be pretty conservative with what variants we add. I think an Alpine variant will be the last one we add for a while unless a very compelling use case comes up.

[LaurentGoderre]

PR #144 is a start on this but I am wondering why there such a diff between versions

[chorrell]

There are some differences between the 0.10, 0.12 images and the 4.x and 5.x. This is mostly due to the fact that 0.10 and 0.12 came from the Joyent org and 4.x etc came from iojs -- this was before the merge.

[ncopa]

People are moving away from the official node image. What can I do to help adding official alpine support?

There was some performance issues with node 4, so it might be an idea to only support node 5.x and newer for alpine.

[retrohacker]

Hey @ncopa 😄

We have a dangling pull request here that I have meant to follow back up on: #141

This allows us to have a thorough test suite of the Docker images and smoke test against a collection of popular node modules.

Having this define a test that runs the make check script would be amazing, and would allow us to assert that the node binary is behaving as expected.

If we get smoke testing and make check to pass on #156 , I would be confident on 👍ing that PR.

[retrohacker]

To reiterate why Alpine is a special case, the images we ship use releases of distributions that Node.js is tested against by the upstream project. Alpine isn't tested upstream, so by supporting it in this repo we are taking on the responsibility of testing that image and asserting it is stable.

As an awesome side effect of these requirements, we are getting thorough testing on all of our images 😄

[retrohacker]

An update on this:

I've been experimenting with ways of shipping a minimal docker image without needing to use Alpine etc. It is looking like it is possible using debian:jessie to supply shared libraries for the nodejs binary (I have an image running locally that is down to 26MB for v4.X).

This would have the advantage of not requiring upstream to support libmusl (which is what busybox and alpine are using) while still having tiny Docker images.

It also has the advantage of using linked libraries from an officially supported distribution.

[ncopa]

@retrohacker I've been experimenting with ways of shipping a minimal docker image without needing to use Alpine

FWIW, an official Alpine image is important for Docker inc. as we use Alpine for a lot other stuff.

[retrohacker]

@ncopa the ones I've been experimenting with have been built from scratch. Will that do or do you need something specific from the Alpine base image?

[jessfraz]

why not adopt https://github.com/mhart/alpine-node?

[retrohacker]

Hey @jfrazelle! I would def prefer to have Alpine tested in our CI/CD upstream before we release an official Docker image. It sounds like the build working group is making progress here: nodejs/node#8265 (comment)

(for more background: #46 (comment))

That being said @mhart is doing something amazing and is using libgcc as opposed to libmusl which should make this a lot safer.

[jessfraz]

ah cool, that makes sense :)

On Thu, Sep 8, 2016 at 5:14 PM, William Blankenship <
notifications@github.com> wrote:

Hey @jfrazelle https://github.com/jfrazelle! I would def prefer to have
Alpine tested in our CI/CD upstream before we release an official Docker
image. It sounds like the build working group is making progress here: nodejs/node#8265
(comment)
nodejs/node#8265 (comment)

(for more background: #46 (comment)
#46 (comment))

That being said @mhart https://github.com/mhart is doing something
amazing and is using libgcc as opposed to libmusl which should make this
a lot safer.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#46 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABYNbLQZsCncTOa7KoG_azGDztYZW2PYks5qoKTagaJpZM4F_65j
.

Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC 511E 18F3 685C 0022 BFF3
pgp.mit.edu http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3

[chorrell]

Closed via #156