Skip to content
This repository has been archived by the owner on Jan 15, 2023. It is now read-only.

node-gyp needs build tools #27

Closed
tino opened this issue Mar 25, 2016 · 12 comments
Closed

node-gyp needs build tools #27

tino opened this issue Mar 25, 2016 · 12 comments

Comments

@tino
Copy link

tino commented Mar 25, 2016

node-gyp, which is often used by packages installed through npm (at least that is my experience), needs python, make, and gcc. Would it make sense not to clean those up? (Currently happening in line 36 of the Dockerfile)

@mhart
Copy link
Owner

mhart commented Mar 25, 2016

The idea of this docker image is to be as small as possible with a full node installation – for ppl who don't have native dependencies, it would add a lot of weight to include these.

There's an example on the README for how to add them in your own Dockerfile if you need them for your project though: https://github.com/mhart/alpine-node#example-dockerfile-for-your-own-nodejs-project

@mhart mhart closed this as completed Mar 25, 2016
@cusxio
Copy link

cusxio commented May 17, 2016

@mhart I'm fairly new to this, so I was wondering what is the purpose of installing make gcc g++ python linux-headers paxctl gnupg and removing them later?

In the official dockerfile it does not seem like Node requires it for installation.

@mhart
Copy link
Owner

mhart commented May 17, 2016

That Dockerfile doesn't need any build tools because it's not actually building node – it's just unpacking a prebuilt binary on debian. There's no prebuilt binary for Alpine, so we have to build it ourselves – hence all the build tools that need installing. They're then removed to keep the image size down – most ppl won't need them again – but if you do you can always reinstall them

@Nepoxx
Copy link

Nepoxx commented May 1, 2017

Sorry about posting on an old thread, but since Google lands here for this question, I'dd suggest doing the following if you have native dependencies:

RUN apk add --no-cache make gcc g++ python && \
  npm install --production --silent && \
  apk del make gcc g++ python

This way the build dependencies don't end up in your Docker layers and thus keep the image size almost as small as if you didn't install those dependencies.

@JorritPosthuma
Copy link

Old thread, but because of google, still relevant :).
To make it even simpler you can do:

RUN apk add --no-cache --virtual .build-deps make gcc g++ python \
 && npm install --production --silent \
 && apk del .build-deps

Or simpler, by using alpine-sdk, similar to Ubuntu's build-essential:

RUN apk add --no-cache --virtual .build-deps alpine-sdk python \
 && npm install --production --silent \
 && apk del .build-deps

@AkashBabu
Copy link

AkashBabu commented Sep 9, 2018

Perhaps you could use docker multi-stage build and copy node_modules from ubuntu image and then run npm rebuild in alpine image.

Sample Dockerfile:

# Stage-1 dependencies
FROM node:latest as dep

RUN mkdir /sample
WORKDIR /sample

ADD package.json .
RUN ["npm", "i", "--only=production"]


# Stage-2 final image
FROM node:alpine

RUN mkdir /sample
WORKDIR /sample

COPY --from=dep /sample/node_modules ./node_modules
RUN ["npm", "rebuild", "-q"]

ADD . .

ENTRYPOINT [ "npm", "start" ]

Hope this helps

@thebetterjort
Copy link

@AkashBabu Is the prefered way of handling deps moving forward.

@AkashBabu
Copy link

@thebetterjort Can you please elaborate your statement?

@thebetterjort
Copy link

thebetterjort commented Sep 27, 2018

@AkashBabu
If you need to add build-essential / alpine-sdk then you shouldn't be using node alpine. But, luckily Docker gives us multistage builds.
" With a statically compiled language like Golang people tended to derive their Dockerfiles from the Golang "SDK" image, add source, do a build then push it to the Docker Hub. Unfortunately the size of the resulting image was quite large - at least 670mb.

A workaround which is informally called the builder pattern involves using two Docker images - one to perform a build and another to ship the results of the first build without the penalty of the build-chain and tooling in the first image.

Multi-stage builds give the benefits of the builder pattern without the hassle of maintaining three separate files:

The prefered way of handling deps for the future of containers is multistage as it miitigates multiple Dockerfiles for different architectures."

moby/moby#32063

@mhart
Copy link
Owner

mhart commented Sep 28, 2018

@thebetterjort @AkashBabu there's already an example of doing multistage builds in the README: https://github.com/mhart/alpine-node#example-dockerfile-for-your-own-nodejs-project (the second example)

@AkashBabu
Copy link

AkashBabu commented Sep 28, 2018

+1 for @mhart's answer

adrienjoly added a commit to openwhyd/openwhyd that referenced this issue Nov 8, 2020
@Startouf
Copy link

Just a note for people still referring to this thread :

RUN apk add --no-cache --virtual .build-deps alpine-sdk python

May throw some error

[ 5/17] RUN apk add --no-cache alpine-sdk python:
#9 0.234 fetch https://dl-cdn.alpinelinux.org/alpine/v3.14/main/x86_64/APKINDEX.tar.gz
#9 0.337 fetch https://dl-cdn.alpinelinux.org/alpine/v3.14/community/x86_64/APKINDEX.tar.gz
#9 0.592 ERROR: unable to select packages:
#9 0.640 python (no such package):

You have to specify the python version in some cases to avoid apk errors

RUN apk add --no-cache --virtual .build-deps alpine-sdk python2

or

RUN apk add --no-cache --virtual .build-deps alpine-sdk python3

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants