Alpine Linux / Docker Build

[tracker1]

Would really be appreciated if some help could be rendered to getting an alpine image for iojs passing the test suite.

• Consider alpine/busybox base image docker-iojs#44
• Consider alpine/busybox base image docker-iojs#44 (comment)

If there could be two build images, one for just node, and another with everything needed for node_gyp and nan to run.

Also, would be nice to see tests for building common binary modules (sqlite3, expat and a few others).

[jbergstroem]

@tracker1 I think one challenge will be fully supporting musl as a libc replacement. I'm not against it but have very little knowledge about it. It doesn't look like its in too bad a shape. I'm keen on setting up a system based on musl, so I might give this a go down the road, but don't count on me for the moment.

[tracker1]

@jbergstroem understandable... :-) Really wish I had more time (and a more intimate working relationship with C/C++).

[springmeyer]

Also, would be nice to see tests for building common binary modules (sqlite3, expat and a few others).

As the maintainer of node-sqlite3, 👍

I'm keen on setting up a system based on musl, so I might give this a go down the road, but don't count on me for the moment.

Same here. I'm also interested in musl.

[mhart]

The failures in the tests (there are only two) are due to assumptions in the tests themselves. One being that the platform has glibc (which Alpine isn't), the other being that the ps command supports the -p flag (which Alpine doesn't).

You can read more here: nodejs/docker-iojs#44 (comment)

[Starefossen]

I am putting this on the agenda for #300

[jbergstroem]

I don't think anyone objects to get this part of the ci, but work needs to be done. Lets get an outline going for whats required - feel free to add:

• we lack a vm provider that can run alpine (unless we automate docker stuff)
• we lack ansible scripts to set a host up

[Starefossen]

Regarding version of Alpine linux it looks like the Docker Library guys are using alpine:3.3 for some of their official images on Docker Hub.

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

[jbergstroem]

@Starefossen how often is stable updated? How does that affect toolchain, etc? (thinking if they have a LTS mindset)

[Starefossen]

I had a chat with one of the Alpine Linux maintainers today. This is what they told me:

• They have Node.js in main repository
• Releases are supported for 2 years since initial release with security backports or critical bugfixes
• edge is our rolling release, where latest releases land
• official alpine image pulls latest stable release by default
• breaking changes are usually unrelated to high level stuff like Node.js
• suggests running tests for maintenance releases on latest stable, and development on edge

[mhart]

@Starefossen some important things to note about the Node.js package in the aports repository are:

• They compile with shared zlib (--shared-zlib)
• They compile with shared libuv (--shared-libuv)
• They compile with shared openssl (--shared-openssl) (this recently caused a compatibility issue)
• They compile without snapshot (--without-snapshot)
• I'm not sure how to get Node.js 5.x if you're not on edge?

These may not be an issue but they're worth being aware of. They've certainly been a lot better at keeping up to date with releases since 4.x

(latest build file is here: http://git.alpinelinux.org/cgit/aports/tree/main/nodejs/APKBUILD?id=18fd7609f0ec2df89c873e788880119a703496a1)

[jbergstroem]

@mhart the intention is to build node, so not being on edge shouldn't be a problem. Meeting the dependencies (if using shared libraries) might though.

[MylesBorins]

Having just done the ssl update I know there are 4 floating patch's on top of the release

[mhart]

@jbergstroem yeah, sorry I kinda got off track there – Node.js certainly builds on Alpine without requiring you to use shared libraries, was just pointing out that that's what you get with the package @Starefossen was referring to – but it's more relevant to users of the package (or any official endorsement of it) rather than building on Alpine from scratch.

[rvagg]

Can we get someone to pass on that --without-snapshot shouldn't be used anymore, it's no longer a (potential) security concern since v4+ and with more recent releases (where we fixed a bug that was causing it to always actually be without-snapshots ...) the startup speed improvement is non-trivial. I would think that this would be particularly beneficial to the kinds of applications where Alpine is used, i.e. presumably leaning toward the small and nimble service side of the spectrum, hopefully employing the fast-kill-and-restart paradigm on errors.

@ncopa perhaps?

[jbergstroem]

@rvagg might be an issue, see nodejs/node#4212.

[ncopa]

@mhart we fixed openssl in alpine linux (edge) and will probably backport that fix for alpine 3.3-stable.

@rvagg I am looking at removing that --without-snapshot. It seems to require gold linker? why?

[bnoordhuis]

V8 uses it to speed up the link step (ld-gold is multi-threaded, regular ld is not). I think you can disable it by setting 'linux_use_gold_flags%': 0 in common.gypi.

[ncopa]

i can install gold too.

But I have other issue now, mksnapshot is run during build. I need to pax-mark the binary to disable PaX' MPROTECT as JITs does not work with it enabled.

So I need to:

1. build mksnapshot
2. pax mark it
3. build the rest

Currently I am trying to figure out how to only build mksnapshot.

[bnoordhuis]

make -C out mksnapshot BUILDTYPE=Release - replace Release with Debug for a build with a ton of extra checks.

[ncopa]

That worked. many thanks!
--without-snapshot is removed.

[mhart]

@ncopa can you explain why you need to paxmark mksnapshot? (as in, what happens if you don't?) I've never had a problem on Alpine compiling the node binary in a single step and then just paxmark'ing it (the node binary).

[jbergstroem]

@ncopa you can check how we pax-mark in the ebuild I've done for gentoo: https://github.com/jbergstroem/gentoo/blob/verbump/net-libs/nodejs-5.4.1/net-libs/nodejs/nodejs-5.5.0.ebuild#L115

[shouze]

@ncopa yes, agree, I've updated my Dockerfile.

it build perfectly on my local boot2docker virtualbox instance or on a fresh digital ocean trusty docker-machine.... but always fails on docker hub (Linux 3.13.0-40-generic, docker 1.8.3):

LINK(target) /usr/src/node-v5.7.0/out/Release/mksnapshot
usr/lib/gcc/x86_64/alpine/linux/musl/5.3.0/x86_64/alpine/linux/musl/bin/ld.gold: fatal error: /usr/src/node/v5.7.0/out/Release/mksnapshot: Not supported
collect2: error: ld returned 1 exit status

I use binutils-gold of course, I wonder if it's not because of the docker release. In any cases something differ on docker hub.

[Vanuan]

I believe in nodejs/docker-node#156 we have Dockerfiles for building all node versions in Alpine.
The only problem is that build times out on travis. Probably there's the same problem with Docker Hub?
Docker is meant to be a way for reproducible images, the only difference being linux kernel config, mounted filesystems and resource limitations (like memory usage, etc), and docker itself of course.

I think it should be built inside an alpine image and put to https://nodejs.org/dist/ under "node-$VERSION-linux-musl-$ARCH.tar.gz".

[Vanuan]

Regarding error, ld.gold outputs it for 2 flags: http://manpages.sgvulcan.com/ld.gold.1.php
copy-dt-needed-entries and add-needed. Is there any output of which flags are provided?

[rvagg]

As per #437, we have support for Node built on Alpine running in Alpine but this doesn't yet cover the nodejs.org binaries. If that's needed for some reason then we should continue that discussion here.

[ljharb]

Since nvm doesn't yet support installing from source for node/iojs >= 1, having binaries would be very helpful (it also allows for faster installs for those users regardless).

[sylus]

What are the next steps to get this working with binaries off of nodejs.org. I think that is what is holding up nodejs/docker-node#156 which is currently building off of source but preference was to use the binaries to save build time in CI etc.

[rvagg]

I believe the question is about shipping musl binaries? I'm hesitant about adding musl binaries to nodejs.org for the following reasons:

• We're going to get calls for adding support for older versions of musl than we're building against—we need a clear understanding about what is supported out there by distros so we can answer with "that version isn't used by any distro version that is currently supported" like we do with libc (we build on CentOS5 because EL5 is the oldest thing that's still supported, so we get no complaints).
• We're going to be asked for more architectures and we have no way to deal with that as far as I know. We can use Docker to build 64-bit musl on Apline 3.4 but what about 32-bit, what about arm? what about arm64?

It's a Pandora's Box that we have to be sure we want to open before we go ahead with this. Right now it's easy and obvious: our binaries only support libc.

Let's get this on the Build WG agenda and see if anything comes out of that.

[shouze]

@rvagg for sure it need to be maintained... to me node docker alpine variants are sufficient. I'm not convinced that shipping musl compatible binaries (outside of docker containers) deserves many use cases. In general we talk about people that are used to compile node themself no?

[rvagg]

I think the proposal here is for us to ship musl binaries on nodejs.org so the docker-node folks don't need to build it on image when shipping to Docker Hub. If that's incorrect then someone please clarify what the ask here is now.

[bnoordhuis]

Security angle: statically linking in musl means we're obligated to track it for CVEs and make the proper announcements and releases when vulnerabilities are found. IOW, it's more work.

[Starefossen]

I think the proposal here is for us to ship musl binaries on nodejs.org so the docker-node folks don't need to build it on image when shipping to Docker Hub. If that's incorrect then someone please clarify what the ask here is now.

That is correct, Rod!

[shouze]

So... musl could be not statically linked then docker-node folks will need to build an image that include node compilation and on security angle it will benefit from docker hub security scanning feature.

Of course If I had nodejs binary ready to download for my docker container it would be cool, so I'm not against this proposition, just not convinced it worth it regarding the amount of energy to spend.

[LaurentGoderre]

Couldn't I make the case that docker and Alpine are a wildly adopted platform and having a binary targeting those is good for Node. Couldn't you justify this one in particular and avoid the scfope creep since Docker has a consistent architecture.

[LaurentGoderre]

I would like to bump this. Since we included an alpine variant to the docker project, we received a lot of questions about the alpine variant specifically. It's unfortunate that we don't have stats about specific docker tag downloads but it's possible that alpine will become on of the most used platforms for Node, if it isn't already.

[Trott]

Is this resolved? I haven't read all the details, but I know that we have docker and alpine in CI now and I see that this issue has not received much in the way of comments lately.

[SimenB]

I'm not sure what this issue is tracking, tbh. I'd still love alpine binaries as part the regular release, but that might not be tracked here?

[Vanuan]

This was the first issue mentioning Docker/Alpine use case specifically asking to provide help with running test suite in alpine.
Several follow up issues were created since then.
So this apparently was re-purposed as an umbrella issue for all other issues mentioning Alpine.

Now, that Alpine variant is in CI and included into official docker library: https://github.com/docker-library/official-images/blob/master/library/node
the only missing part is providing node binary linked against musl (at least for x86_64) here:
https://nodejs.org/dist/

[maclover7]

Alpine (both 36 and 37) is being used in CI, which I believe closes this issue? Please reopen if I'm mistaken.