Docker-node: Add an Alpine variant?

Created on 18 Sep 2015  Â·  27Comments  Â·  Source: nodejs/docker-node

Having an Alpine variant would be useful.

This primarily depends on https://github.com/nodejs/build/issues/75 though

enhancement

Most helpful comment

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 :smile:

All 27 comments

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

Ok, it looks like the Docker guys have given Alpine an official :+1: 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

Nice!

For https://github.com/nodejs/build/issues/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.

:+1: 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

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

This seems relevant to the convo

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.

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.

https://github.com/nodejs/docker-iojs/issues/44

@retrohacker make check works once those 2 pull requests are merged:
https://github.com/nodejs/node/pull/5099
https://github.com/nodejs/node/pull/5056

I think all the issues should be resolved now.

@ncopa you rock! Those PRs are :fire:

@retrohacker anything else preventing this to move forward?

@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

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

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?

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.

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

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.

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.

Hey @ncopa :smile:

We have a dangling pull request here that I have meant to follow back up on: https://github.com/nodejs/docker-node/pull/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 https://github.com/nodejs/docker-node/pull/156 , I would be confident on :+1:ing that PR.

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 :smile:

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.

@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.

@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?

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: https://github.com/nodejs/node/issues/8265#issuecomment-242307839

(for more background: https://github.com/nodejs/docker-node/issues/46#issuecomment-220451497)

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

ah cool, that makes sense :)

On Thu, Sep 8, 2016 at 5:14 PM, William Blankenship <
[email protected]> 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)
https://github.com/nodejs/node/issues/8265#issuecomment-242307839

(for more background: #46 (comment)
https://github.com/nodejs/docker-node/issues/46#issuecomment-220451497)

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
https://github.com/nodejs/docker-node/issues/46#issuecomment-245781857,
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

Closed via #156

Was this page helpful?
0 / 5 - 0 ratings

Related issues

hjanuschka picture hjanuschka  Â·  30Comments

nodkz picture nodkz  Â·  46Comments

Hypnosphi picture Hypnosphi  Â·  19Comments

rwillians picture rwillians  Â·  33Comments

mikemaccana picture mikemaccana  Â·  24Comments