docker-node
docker-node copied to clipboard
NPM install stucks with node:20
Environment
- Platform: MacOS Ventura (13.4.1) on M1
- Docker Version: 24.0.5
- Node.js Version: 20
- Image Tag: 20
Expected Behavior
NPM install should be started. I've tested this with node:18 image instead and it works. node:20-slim stucks too.
Current Behavior
NPM install does not start and stucks.
[test] docker build --progress=plain --platform linux/amd64 -t test-image . 9:52:01
#0 building with "desktop-linux" instance using docker driver
#1 [internal] load .dockerignore
#1 transferring context: 66B done
#1 DONE 0.0s
#2 [internal] load build definition from Dockerfile
#2 transferring dockerfile: 414B done
#2 DONE 0.0s
#3 [internal] load metadata for docker.io/library/node:20
#3 DONE 1.3s
#4 [1/5] FROM docker.io/library/node:20@sha256:64b71834718b859ea389790ae56e5f2f8fa9456bf3821ff75fa28a87a09cbc09
#4 CACHED
#5 [2/5] WORKDIR /usr/src/app
#5 DONE 0.0s
#6 [internal] load build context
#6 transferring context: 1.12kB 0.0s done
#6 DONE 0.0s
#7 [3/5] COPY package*.json ./
#7 DONE 0.0s
#8 [4/5] RUN npm install
I've tried other npm commands like npm cache clean --force
but those stuck too.
Possible Solution
Steps to Reproduce
I'm using the docker file from official nodejs example :
FROM node:20
# Create app directory
WORKDIR /usr/src/app
# Install app dependencies
# A wildcard is used to ensure both package.json AND package-lock.json are copied
# where available (npm@5+)
COPY package*.json ./
RUN npm install
# If you are building your code for production
# RUN npm ci --omit=dev
# Bundle app source
COPY . .
EXPOSE 8080
CMD [ "node", "server.js" ]
Additional Information
I have the same issue with yarn
Same here. My image works with Node 16, 18 and 19. With 20 even corepack enable
command gets stuck
Update: on my pipeline based on Ubuntu-22.04 linux/amd64 works
I just tried on Ventura with an M2 chip and it didn't hang
I am ablwe to reproduce the behavior when disabling my network. I am wondering if some firewall rule might be blocking traffic.
Hi, I'm also facing the same issue. I'm using M1 Mac. I'm observing this issue since last week. I have tried Node 20,18 alpine, slim and latest. The issue persist.
I was able to run yarn and npm commands now after disabling Use Rosetta for x86/amd64 emulation on Apple Silicon option in docker settings. Not sure this is a fix.
I'm encountering the same issue - docker build hangs on RUN npm install
. The problem occurs when trying to build an image using --platform=linux/amd64
on Docker Desktop Mac.
(Why do this? I want to test an image on my mac laptop that will eventually run in an amd64 environment, and one apt dependency does not have an arm64 version)
Workarounds I found:
- Downgrade to the previous base node image (node:18.17.0, should be the case for node:20 as well)
- Turn off Rosetta, as @callmemaxi suggested (slow)
- Build for arm64 (causes issues if you need amd64)
Dockerfile
FROM --platform=linux/amd64 node:18
RUN npm install --loglevel verbose
CMD index.js
package.json
{
"name": "docker-bug",
"version": "1.0.0",
"description": "",
"main": "index.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1"
},
"author": "",
"type": "module",
"license": "ISC",
"dependencies": {
"chalk": "^5.3.0"
}
}
index.js
import chalk from 'chalk';
console.log(chalk.green('Hello world'));
Console output
$ docker build . -t node-docker-bug
[+] Building 11.7s (4/5) docker:desktop-linux
=> [internal] load .dockerignore 0.0s
=> => transferring context: 2B 0.0s
=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 120B 0.0s
=> [internal] load metadata for docker.io/library/node:18 0.3s
=> CACHED [1/2] FROM docker.io/library/node:18@sha256:ee0a21d64211d92d4340b225c556e9ef1a8bce1d5b03b49f5f07bf1dbbaa5626 0.0s
=> [2/2] RUN npm install --loglevel verbose 11.5s
=> => # npm info using [email protected]
=> => # npm info using [email protected]
=> => # npm verb title npm install
=> => # npm verb argv "install" "--loglevel" "verbose"
=> => # npm verb logfile logs-max:10 dir:/root/.npm/_logs/2023-09-25T19_40_55_092Z-
=> => # npm verb logfile /root/.npm/_logs/2023-09-25T19_40_55_092Z-debug-0.log
Same issue affecting npm and yarn when using docker buildx
and building for linux/arm/v7
got same issues , you can easily duplicate this issue with below commands
$ cat Dockerfile
FROM node:lts-alpine
RUN export PATH=/usr/local/bin:$PATH && npm install -g semver
CMD ["semver", "--help"]
$ export platform="linux/arm/v7"
$ docker buildx build --progress=plain --platform "${platform}" --tag demo .
...
#6 [2/2] RUN export PATH=/usr/local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin && npm install -g semver
Then it stucks at installation forever.
run tests on below platforms
linux/amd64,linux/arm/v6,linux/arm/v7,linux/arm64/v8,linux/ppc64le,linux/s390x
- platforms without problem:
linux/amd64
,linux/arm64/v8
,linux/ppc64le
- platforms with
buildx
hangs on problem:linux/s390x
,inux/arm/v6
,linux/arm/v7
My workaround at the moment is to stay on Node 18.x.
I hope there will be a fix for the armv6
and armv7
architectures. Otherwise I will have to drop them.
Maybe Node 22.x
Also have the same issue, and reverted back to Node 18.x for my docker builds.
It seems that this is a duplicate of #1798? I see the same seqence of mremap
as reported in https://github.com/nodejs/docker-node/issues/1798#issuecomment-1666243017 when using strace
with the reproducer from https://github.com/nodejs/docker-node/issues/1946#issuecomment-1811716910.
Upgrading from Docker Desktop 4.21 to 4.26.1 (Latest at the time of this writing) seems to have fixed this problem for me on an M2 Mac.
Trigger
What triggered this problem for me was updating my package-lock.json
from version 1 to version 3.
Solution
The key solution for me was using npm install --no-audit
, which also just makes it run much faster, and auditing can probably just be done independently of the normal build/CI process.
Details
Here are some additional details I gathered before finding the final solution, in case it's helpful for others, or for debugging the root problem.
Sorta Solutions
These attempts somewhat worked but not in a satisfactory way...
-
Reverting back to my version 1
package-lock.json
file worked, but I didn't want to stick with this because it felt fragile and it was slow because npm had to recreate it each time I ran my docker-based build (unless in the docker cache). -
For 1 code repository, it worked to remove the
package-lock.json
file and recreate it, but this didn't work for my other repo.
Non-Solutions
These attempts didn't work...
- Flushing docker state with ...
docker container prune -a
docker rm -f $(docker ps -qa)
docker image prune -a
docker volume prune
docker volume rm $(docker volume ls -q)
docker buildx prune
- Reinstall docker at older versions (on linux mint) with instructions here https://docs.docker.com/engine/install/ubuntu/#install-using-the-repository using the "specific version" instructions, something like ...
apt-cache madison docker-ce
va=... # pick an older version from above
apt-cache madison containerd.io
vb=... # pick an older version from above
apt-get install docker-ce=$va containerd.io=$vb
# restarted
-
Installing the latest LTS
node
currently 20.11.1 which containsnpm
version 10.2.4 -
Deleting and recreating my
package-lock.json
(although it worked for the 1 repo mentioned above) -
Using
docker build --network=host
Using docker build --network=host
did actually help me. I'm on Ubuntu 22.04 through WSL2 on Windows 11, Node v20.10.0
My finding is that it eventually goes through the installation process, but hangs for 2 - 5 minutes. In my build process there are two node applications installed in node:20, the other one goes through fine, the second one hangs.
Both have lockfileVersion 3. Only difference I can find is that the non-functioning one is defined as a "type": "module" in package.json.
It's still a thing on node 22 :/
any news? :/
I suddenly faced this issue since last week, building on a Cloud platform local is working fine
Same problem, i upgrade to puppeteer 22.4.1 but problem still occurs :-(
Using a Dockerfile to specify the image seems to fix it.