Alpine Linux / Docker Build about build

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

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

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

[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!

[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/

[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

[ncopa]

@mhart the PaX patched kernel we use in Alpine will not permit JIT compiled code to execute. mksnapshot will crash if you don't disable those memory protections. This only affects when you use Grsecurity/PaX kernel.

As mentioned, it now builds just fine.

I have also submitted a couple of pull requests to fix the test suite:
nodejs/node#5099
nodejs/node#5056

AFAIK all issues should now be resolved. What is now needed to move forward?

[mhart]

@ncopa – ah, ok, I failed to mention I was compiling on Docker, so yeah, haven't seen this.

[shouze]

Ok guys... I didn't mentioned this discussion when I've opened this PR earlier today nodejs/docker-node#107.

👍 @ncopa BTW for nodejs/node#5099 & nodejs/node#5056.

@ncopa:

• Do this patch still relevant (even if we don't compile with --shared-openssl)?
• Why compiling also with --shared-zlib & --shared-libuv?

[shouze]

@ncopa --with-intl=small-icu && --download=all configure options are not in the APKBUILD but @Starefossen and/or @rvagg can probably confirm that every official node binary is distributed with small-icu.

[jbergstroem]

@shouze if icu is already apk'ed you could build against a system version of it.

[shouze]

@jbergstroem yup, but I'm not sure, it's not the usual way node is distributed (small icu, can be completed with a npm install full-icu, openssl not shared).

[jbergstroem]

@shouze if you already have a full icu from system there's no need to do anything else.

[shouze]

@jbergstroem you make a point, in fact I'm thinking about official bin you can download from node homepage so yes - of course - all static is the rule.

[rvagg]

Yes, small-icu should be default. @chrislea has some experience making it work with system icu packages and might be able to share his experience.

[jbergstroem]

Fwiw, we're running --system-icu in gentoo successfully: https://github.com/gentoo/gentoo/blob/master/net-libs/nodejs/nodejs-5.6.0-r1.ebuild#L92

[ncopa]

@shouze No, the patch for checking return values from openssl is not relevant if you don't build with --shared-openssl. The patch is correct though and applied upstream.

As distro we try build and link everything shared/dynamically whenever possible. Using shared libs simplifies maintenance when you have 1000+ packages to maintain and it saves memory as only one copy of zlib and libuv will be in memory.

For an official binary that you can download from node, yes static makes sense - just remember to ship new build with updated openssl on March 1 if you link openssl statically.

[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).

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

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

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

[maclover7]

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