Open x900603 opened 2 years ago
same problem
same here;
FROM node:12-alpine as build
ENV NODE_VERSION 12.18.1
WORKDIR /app COPY ["package.json", "package-lock.json*", "./"] RUN npm i -g npm RUN npm install RUN npm install npm@6.14.5 COPY . .
RUN npm run build
FROM nginx:stable
ENV ESC='$'
RUN rm /etc/nginx/conf.d/default.conf COPY docker/nginx.tmpl /etc/nginx/conf.d/nginx.tmpl COPY --from=build /app/dist /webroot
ENV SSH_PASSWD "root:Docker!" RUN apt-get update \ && apt-get install -y --no-install-recommends dialog \ && apt-get update \ && apt-get install -y --no-install-recommends openssh-server \ && echo "$SSH_PASSWD" | chpasswd
COPY docker/sshd_config /etc/ssh/ COPY docker/init.sh /usr/local/bin/
RUN chmod u+x /usr/local/bin/init.sh EXPOSE 80 2222 ENTRYPOINT ["init.sh"]
error:
I can consistently reproduce this - I've found that if you only have a few deps then it seems fine, but larger lists of dependencies produce the ERR_SOCKET_TIMEOUT
error. If I use node:14-alpine
rather than node:16-alpine
then I don't receive the error and the npm install
(and container build) succeeds, consistently (I've wiped my images between each build to make sure).
:bulb: Here's a repo to allow reproducing this: https://github.com/itsravenous/docker-node-repro :bulb:
I'm sure it could be specific to the network conditions on my machine, or something to do with my Docker setup, but it seems weird that switching to 14 would consistently avoid the issue in that case.
Be interesting to see if others can reproduce using my test case repo - @bbkysf and @x900603 could you confirm?
In the meantime, I'll try removing deps from that repo's package.json to see if there's any particular packages that are causing trouble, or any rough "size" of the dependency list that makes a difference. Not very scientific, I know, but not sure how else to proceed - all a bit over my head I'm afraid :)
Node 14 and Node 16 ship with different versions of NPM, so the difference is likely there.
Node 14 and Node 16 ship with different versions of NPM, so the difference is likely there.
Good point. I should clarify that this problem doesn’t occur with node 16 outside of docker.
My project have many dependencies, and it pahhend scoket time out usually.
My dependencies is up to npm install need spend 3~5 miuntes
here is my dependencies
"dependencies": {
"@line/liff": "2.12.0",
"axios": "^0.21.1",
"bootstrap": "^4.6.0",
"bootstrap-vue": "^2.21.2",
"compression-webpack-plugin": "^6.1.1",
"core-js": "^3.8.3",
"crypto-js": "^3.3.0",
"google-libphonenumber": "^3.2.16",
"qs": "^6.9.4",
"rxjs": "^7.5.5",
"sha1": "^1.1.1",
"vconsole": "^3.4.0",
"vue": "^2.6.12",
"vue-i18n": "^8.22.4",
"vue-router": "^3.5.1",
"vue-rx": "^6.2.0",
"vue2-perfect-scrollbar": "^1.5.0",
"vuex": "^3.6.0"
},
"devDependencies": {
"@vue/cli-plugin-babel": "^4.5.11",
"@vue/cli-plugin-eslint": "^4.5.11",
"@vue/cli-plugin-unit-jest": "^4.5.11",
"@vue/cli-service": "^4.5.11",
"@vue/eslint-config-airbnb": "^4.0.0",
"@vue/test-utils": "1.0.0-beta.29",
"babel-eslint": "^10.0.3",
"eslint": "^5.16.0",
"eslint-plugin-vue": "^5.0.0",
"flush-promises": "^1.0.2",
"vue-template-compiler": "^2.6.12"
}
Thinking about it - and this is a guess - but it would make sense to me that it is one, larger dependency that would be the cause, if anything. I don't think npm install
has a timeout for the total install time, just per request for each dep.
I have got same error on mcr.microsoft.com/windows:20H2
image and npm installed by choco install nodejs --version=16.14.2
I also met this issue, and ... if I switch to a stable network and disconnect all VPN, I will success to build
Same thing. Works well with node:alpine
but fails with node:16-alpine
EDIT: I am not 100% confident that this is related to :16-alpine specifically, maybe it is more sensitive to bad network, but the network I am currently on is not as reliable as the one I am usually using.
node alpine sha256:0677e437543d10f6cb050d92c792a14e5eb84340e3d5b4c25a88baa723d8a4ae 9f58095cfeb6 2 weeks ago 172MB
node 16-alpine sha256:1a9a71ea86aad332aa7740316d4111ee1bd4e890df47d3b5eff3e5bded3b3d10 e5065cc78074 5 weeks ago 112MB
Step 13/19 : RUN npm ci
---> Running in a8aad4c114bd
npm notice
npm notice New minor version of npm available! 8.5.5 -> 8.12.1
npm notice Changelog: <https://github.com/npm/cli/releases/tag/v8.12.1>
npm notice Run `npm install -g npm@8.12.1` to update!
npm notice
npm ERR! code ERR_SOCKET_TIMEOUT
npm ERR! network Socket timeout
npm ERR! network This is a problem related to network connectivity.
npm ERR! network In most cases you are behind a proxy or have bad network settings.
npm ERR! network
npm ERR! network If you are behind a proxy, please make sure that the
npm ERR! network 'proxy' config is set properly. See: 'npm help config'
npm ERR! A complete log of this run can be found in:
npm ERR! /root/.npm/_logs/2022-06-04T15_32_55_742Z-debug-0.log
The command '/bin/sh -c npm ci' returned a non-zero code: 1
...
914 verbose stack Error: Socket timeout
914 verbose stack at TLSSocket.onTimeout (/usr/local/lib/node_modules/npm/node_modules/agentkeepalive/lib/agent.js:346:23)
914 verbose stack at TLSSocket.emit (node:events:539:35)
914 verbose stack at TLSSocket.Socket._onTimeout (node:net:516:8)
914 verbose stack at listOnTimeout (node:internal/timers:559:17)
914 verbose stack at processTimers (node:internal/timers:502:7)
915 verbose cwd /app
916 verbose Linux 5.4.0-113-generic
917 verbose argv "/usr/local/bin/node" "/usr/local/bin/npm" "ci"
918 verbose node v16.15.0
919 verbose npm v8.5.5
920 error code ERR_SOCKET_TIMEOUT
921 error network Socket timeout
922 error network This is a problem related to network connectivity.
922 error network In most cases you are behind a proxy or have bad network settings.
922 error network
922 error network If you are behind a proxy, please make sure that the
922 error network 'proxy' config is set properly. See: 'npm help config'
923 verbose exit 1
924 timing npm Completed in 63573ms
...
I have changed the node image version to node:16.15.0-alpine3.15@sha256:bb776153f81d6e931211e3cadd7eef92c811e7086993b685d1f40242d486b9bb
, it works well. ✅
Previous is node:16.14.2-alpine@sha256:28bed508446db2ee028d08e76fb47b935defa26a84986ca050d2596ea67fd506
❌, got timeout issue in my laptop.
For me, using --maxsockets 1
(as @nlf suggested) worked the issue around. It is too slow though, but it works.
It always worked on my local computer, however it always failed on remote server (I used a VPN to connect to it).
I wanted to build an image from Dockerfile based on alpine:3.16.2
on which I install nodejs-current@18.6.0-r0
and npm@8.10.0-r0
. I even tried to update it using npm -g i npm@8.17.0
), however it didn’t work.
For now, I use (npm ci --no-audit || npm ci --no-audit --maxsockets 1)
as a workaround, albeit when the first command fails, it takes much longer to start the second command, as the first command hangs for about a minute before it fails.
I encountered the same problem today! And I have found a work around! Hoping to make some hint! We just need a little bit more time to find out the truth problem!
Dockerfile
:FROM node:16-alpine3.15
# Copy the current directory into the Docker image
COPY . /submission-quality-processor
# Set working directory for future use
WORKDIR /submission-quality-processor
# Install the dependencies from package.json
RUN npm install
ENTRYPOINT npm start
Dockerfile
:FROM node:16-alpine3.15
RUN set -eux; \
apk add --no-cache --virtual build-dependencies wget unzip gnupg; \
apk add --no-cache git python3 py-pip bash shellcheck openjdk11-jre curl musl-locales musl-locales-lang;
# Copy the current directory into the Docker image
COPY . /submission-quality-processor
# Set working directory for future use
WORKDIR /submission-quality-processor
# Install the dependencies from package.json
RUN npm install
ENTRYPOINT npm start
Let's find out the ghost by reducing this part:
RUN set -eux; \
apk add --no-cache --virtual build-dependencies wget unzip gnupg; \
apk add --no-cache git python3 py-pip bash shellcheck openjdk11-jre curl musl-locales musl-locales-lang;
Let's find out the ghost by reducing this part:
RUN set -eux; \ apk add --no-cache --virtual build-dependencies wget unzip gnupg; \ apk add --no-cache git python3 py-pip bash shellcheck openjdk11-jre curl musl-locales musl-locales-lang;
With node:16.15.0-alpine
simply installing curl seems to work for me.
RUN set -eux; apk add --no-cache curl;
N.B. I have not tested this. It might be a fluke!
Maybe! I just solved the network problem in my local environment setting when using axios. I will try to solve my docker container related problem with the same way.
Neville @.***> 于2022年8月29日周一 03:28写道:
Let's find out the ghost by reducing this part:
RUN set -eux; apk add --no-cache --virtual build-dependencies wget unzip gnupg; apk add --no-cache git python3 py-pip bash shellcheck openjdk11-jre curl musl-locales musl-locales-lang;
With node:16.15.0-alpine simply installing curl seems to work for me.
RUN set -eux; apk add --no-cache curl;
N.B. I have not tested this. It might be a fluke!
— Reply to this email directly, view it on GitHub https://github.com/nodejs/docker-node/issues/1668#issuecomment-1229536249, or unsubscribe https://github.com/notifications/unsubscribe-auth/AW6Q2LLVLXVDCQIGRFYUMB3V3O4VRANCNFSM5QYXHD6A . You are receiving this because you commented.Message ID: @.***>
Before solving this problem, I have another problem to solve to get better understand of the docker network.
The default network mode of docker compose is bridge
, Which cannot access my local proxy 127.0.0.1, how to solve this problem?
Before solving this problem, I have another problem to solve to get better understand of the docker network.
The default network mode of docker compose is
bridge
, Which cannot access my local proxy 127.0.0.1, how to solve this problem?
The bridge connection docker0 – with IP address 172.17.0.1 – is created by Docker at installation time. Because the host and all containers are connected to that network, our application only needs to listen to it.
All right! The answer is 172.17.0.1
.
@aphilas @all If you are under a local proxy environment like me, then the ghost should be the value of HTTPS_PRXOY in the ~/.docker/config.json
You should change it from 127.0.0.1:xxxx to 172.17.0.1:xxxx
Please give a thumb if my solution helps you.
Using this solved it for me
RUN npm cache clean --force && \
npm install -g npm@latest && \
npm install
I fixed this issue by removing ipv6 from /etc/docker/daemon.json
.
So if you don't have ipv6 you should remove it or if you have ipv6 check if you see the correct ipv6 address
If you make changes to this file you need to restart the service:
sudo service docker restart
To me, it was solved by npm upgrade and sockets limit:
RUN npm update -g npm
RUN npm ci --no-audit --maxsockets 1
To me, it was solved by npm upgrade and sockets limit:
RUN npm update -g npm RUN npm ci --no-audit --maxsockets 1
This solution helped me as well. Nothing else worked. It seems that npm update message returning code 1 in docker brakes build process.
Below is my error output when using node:lts-alpine
=> ERROR [build 5/5] RUN npm install 142.4s
------
> [build 5/5] RUN npm install:
142.3 npm notice
142.3 npm notice New minor version of npm available! 10.2.4 -> 10.4.0
142.3 npm notice Changelog: <https://github.com/npm/cli/releases/tag/v10.4.0>
142.3 npm notice Run `npm install -g npm@10.4.0` to update!
142.3 npm notice
142.3 npm ERR! code ECONNRESET
142.3 npm ERR! errno ECONNRESET
142.3 npm ERR! network request to https://registry.npmjs.org/yargs-parser/-/yargs-parser-21.1.1.tgz failed, reason: Client network socket disconnected before secure TLS connection was established
142.3 npm ERR! network This is a problem related to network connectivity.
142.3 npm ERR! network In most cases you are behind a proxy or have bad network settings.
142.3 npm ERR! network
142.3 npm ERR! network If you are behind a proxy, please make sure that the
142.3 npm ERR! network 'proxy' config is set properly. See: 'npm help config'
So maybe this bugfix PR fixed the behaviour
I had the same issue with the node v16.
To me, it was solved by npm upgrade and socket
--maxsockets 1
helped me as well, but it is too slow.
I updated the node up to v20 and everything is ok without --maxsockets 1
Add into the npm install stage the flag --verbose at your Dockerfile
RUN npm install --verbose
This will allow you to see the entire log of the docker build .
command when he face the npm install.
Then i checked out that was a error between the packages fetchs. The Node logs from my docker build was: attempt 1 failed with EAI_AGAIN
So i checked my DNS confs in the WSL2
At my WSL2 terminal:
cat /etc/wsl.conf
I saw a nameserver of my windowsOS and a search field. I delete all of them and added after the bellow command:
sudo nano /etc/wsl.conf
PASTE:
systemd=true
generateResolvConf = false
nameserver 8.8.8.8
This fixed my problem. The resume is, DNS was failing to ping the registry.npmjs.org because was returning the IP:PORT and suppost to return just the DNS.
https://github.com/laradock/laradock/issues/2843#issuecomment-972524249 should i report this problem at here? it happend when I use node:lts-alpine
here is my dockerfile
and it will cause
here is my dependencies