Docker images for production deploys with Fly.io - controlling the version of NodeJS & NPM

I’m trying to work with Docker to get my production environment to match my local development environment exactly. I’m following the Fly.io instructions here: Build, Deploy and Run an Elixir Application

In addition to bolting down the versions of Erlang and Elixir that I’m using, I would also like to bolt down the versions of NodeJS and NPM.

The Dockerfile suggested at Build, Deploy and Run an Elixir Application begins as follows:

###
### Fist Stage - Building the Release
###
FROM hexpm/elixir:1.12.1-erlang-24.0.1-alpine-3.13.3 AS build

# install build dependencies
RUN apk add --no-cache build-base npm

# prepare build dir
WORKDIR /app

But I’m concerned that the command RUN apk add --no-cache build-base npm won’t always result in the exact same version of NPM (and nodejs) running in the Docker image.

I’m confused because I thought that the whole point of Docker was to carefully control the software environment, so updating to the whatever the latest version on NPM is seems like it will constantly result in a different environment.

But this seems like a common command in Dockerfiles, so I think I must not understand something. What am I missing?

You can use specific package versions in alpine with the <package>=<version> syntax

apk add --no-cache build-base npm=14.17.6-r0

See here for where I found which version is available in alpine v3.13:
https://pkgs.alpinelinux.org/packages?name=npm&branch=v3.13

I’ve worked on teams who pinned everything and anything they could because reproducible builds were important. In general I think most people are fine with building using the latest provided by their distribution because:

  • The cost of debugging the first build broken by a version bump is pretty small
  • Using latest pulls in security patches
  • The distro default is likely a stable, long term support release offering backwards compatibility
2 Likes

I believe Alpine will lock the version of the library based on the version of Alpine, so 3.13 will always pull the same nodejs… I might be mistaken though. They might allow for patch updates. In general, I’ve never had to deal with a different version of a library as long as i stayed on the same version of Alpine.

The bigger issue comes when you need a newer version of a single lib, there are plenty of ways to work around that, but it can be quite the rabbit hole.

Thanks, @entone and @sbaildon. I have a few follow-up questions, though.

First, how can I get node 16.9.1 installed? It appears that to install node on alpine I have to install npm, but I can’t find a version of npm to install that will install node 16.9.1 for me. From @entone’s remark it seems that Alpine locks the version of npm that can be installed.

But then what do I do then if I want to use node 16.9.1 – do I just have to ditch Alpine Linux altogether?

Second, what is going on with the npm versioning system? It seems that Alpine 3.13.3 says it uses npm version 14.7.6-r0, which looks to me like it is actually a node version, not an npm version, but Alpine 13.4.0 uses npm 7.17.0-r0, which is not a node version. So that is confusing as well.

I guess for the time being I will just use Alpine 13.4.0 with node+npm 14.7.6-r0 and also set that as the node version on my MacBook development machine. So this is perhaps not all that big of a deal for me for now.

Thanks for your comments.

You’ll have to bump alpine to at least 3.14 to get node 16 via the nodejs-current package

https://pkgs.alpinelinux.org/packages?name=nodejs-current&branch=v3.14

Regarding the node and npm versioning mismatch, I agree, that does seem weird. I have no comments there.

Looks like even edge is at 14.17, you can add edge and community packages to Alpine 3.14 if needed.

https://wiki.alpinelinux.org/wiki/Enable_Community_Repository