Docker image with zero baked in

[HugoDF]

Would you guys be interested in supporting a Docker image that comes pre-built with node/zero installed?

Should be straightforward to pull in a Node image and run zero

[asadm]

It's almost straightforward, this works:

FROM node:alpine

# Install zero globally
RUN apk update && apk upgrade && apk add --no-cache python
RUN npm install --quiet --no-progress --unsafe-perm -g zero

# Add current folder to /app
ADD . /app

# Run zero in production mode
ENV NODE_ENV production

# Expose port
ENV PORT 80
EXPOSE 80

WORKDIR /app

CMD ["zero"]

I (or someone else) can help with pushing this to docker registry. For now, I have added the above sample dockerfile to README.md

[Waxyen]

I would combine the two RUN statements, to reduce the size of the docker image.

[mkoertgen]

I just tested the Dockerfile sample from above and it does not seem to work as the installation of zero seems to need make, g++, ...

I am not exactly sure but i suspect that parcel or probably node-gyp needs some more dependencies that are not present in the current node:alpine image

NOTE: btw. on Windows zero won't resolve yarn properly, so effectively npm install -g zero is broken on Windows. Maybe we should open an extra issue for this. Works without glitches on Windows-Subsystem-for-Linux (WSL)

I would also prefer a pre-baked docker image but i understand that development is probably moving fast and this would spoil a lot of image layers.

[asadm]

Yikes! I have fixed the yarn bug and pushed to npm. About Dockerfile, it looks like a recent update that may have broken this. I have updated the Dockerfile instructions to include make and g++ which fixes this.

[mkoertgen]

@asadm Woah, awesome! I see how the yarn commit would fix the issue. Just updated to 1.0.15 and i can confirm that zero now works flawlessly on windows. Thx a lot! 👍

I also tested the Dockerfile with your updated example. Works great. I did some editorial changes and pinned down the package versions to silence hadolint.

When running zero i noticed some warning on missing lscpu (as also reported by parcel/issues/2031). This can be worked around by setting PARCEL_WORKERS=1.

For your interest you can find my example repo at https://github.com/mkoertgen/hello.zero. It contains an example for a pre-baked image org/zero:1.0.15-onbuild (quite large though ~513MB), cf.:

• https://github.com/mkoertgen/hello.zero/blob/master/zero/Dockerfile

Sidenote: You may want to update your github organization link at https://github.com/remoteinterview from https://www.https://codeinterview.io/ to just https://codeinterview.io/ (or add a www-redirect, ;-))

[asadm]

Thanks for looking into this! 500MB+ is not good at all. The alpine:node image should be 50MBish and zero should take around 60MB with all it's dependencies. I will take a look at all the image layers sometime. I also like the example dockerfile, I will merge these to our instructions.

Also changed the link on our org!

Thank you very much!

[mkoertgen]

@asadm i think g++ takes the lion share here

[asadm]

I was able to bring it down to 320mb using following Dockerfile.

FROM node:alpine

# Install dependencies via apk, install zero globally, delete unnecessary deps
RUN apk add --no-cache --virtual .build-deps make gcc g++ python \
 && npm install --quiet --no-progress --unsafe-perm -g zero \
 && apk del .build-deps

# Add current folder to /app
ADD . /app

# Run zero in production mode
ENV NODE_ENV production

# Expose port
ENV PORT 80
EXPOSE 80

WORKDIR /app

CMD ["zero"]

I will dig further.

[mkoertgen]

Great work! I guess, since node-gyp relies on an effective build chain (gcc), it won't probably get much better than this. The best reference i could find is https://github.com/nodejs/docker-node/issues/282

However, i think 320MB is fine. From my experience a standard g++ image (not alpine) is at least 1.5GB.

[Amndeep7]

I'm just looking at the project for the first time today, so correct me if I have any misunderstandings, but wouldn't it be possible to use a multistage docker build for I guess just production usage? Specifically, the first stage would be the full size with g++ and so on and uses zero to build the production application. Then the second stage would install the bare minimum number of dependencies, move over the already built files, and then run zero in production mode? This would allow the final image size to be small.

@asadm