Npm install Dockerfile build has different result than in running container

Product support
1

I am building a Resin app which has an npm install in the Dockerfile. The build succeeds and deploys to my RaspberryPi, however the npm install did not correctly install and build dependancies and so my node app crashes. If I ssh into the container, delete the node_modules folder and run an npm install again the dependancies will install and build correctly for the Pi.

My questions is, what is the difference between the Resin Docker build server and the RaspberryPi to cause npm install to build differently?

The package which is not building correctly is leveldown which builds binaries as part on the install.

My Dockerfile with successful, but not working, npm install

FROM orbitbox/orbit-os-node:latest

# Install Backend
RUN mkdir -p /srv/api
COPY app/package.json /srv/api
RUN cd /srv/api && JOBS=MAX npm install --unsafe-perm && npm cache clean
COPY app /srv/api

# Install Frontend
COPY build /srv/static

CMD mkdir -p /data/db \
 && /init \
 && NODE_ENV=production BACKEND_PORT=$BACKEND_PORT DB_PATH=/data/db/ forever /srv/api

Commands I run in container for working npm install

cd /srv/api
rm -r node_modules
npm install

Thanks for any advice.

2

Hey, the build servers are x86 boxes on AWS at this point, and they are cross-compiling packages for the different platforms (such as ARM in case of Raspberry Pi).

I see that your base image is orbitbox/orbit-os-node, have you tried using one of the resin base images, such as resin/raspberrypi3-node (if you are on RPi3, or the other similar ones if you are using another Pi version)? I think we do internally some setup that makes the cross compilation work starting from that base image, while other base images would need to set that up (I think including a qemu-arm-static binary (looks like that’s what happens in the source), similar to this blogpost: Building ARM containers on any x86 machine, even DockerHub)

:bulb: So I would recommend either trying the resin base image for your deployment, or setting your base image up with qemu similarly as ours do.

Here’s a node.js example based on the base images we prepare: simple-server-node.

Btw :pencil2: , our base image sources are here: resin-io-library/base-images. There are Debian-, Alpine-, and Fedora-based node.js base images available.

3

Thanks for the reply @imrehg!

Our orbitbox/orbit-os-node is built on top of resin/raspberrypi3-alpine-node. This image is built on a RaspberryPi and pushed to Docker Hub.

Would this Dockerfile inheritance cause issues with qemu?

4

I was checking things out a bit along the lines you mentioned, to see e.g. whether leveldown works. Using it by itself I managed to segfault it every time, but also on my dev laptop, but looking at their docs it says “It is strongly recommended that you use LevelUP in preference to LevelDOWN”, so went with that one in testing, and it seems to work, can put and get to a database just fine. Here’s the example code for reference, both the orbitbox/orbit-os-node and the resin/raspberrypi3-alpine-node base image works: imrehg/resin-leveldb

It should also compile things fine, as the logs say it is compiling leveldown for ARM as it should be:

prebuild WARN install No prebuilt binaries found (target=v7.1.0 arch=arm platform=linux)

So thus far I can’t really reproduce what you mentioned, maybe we are missing something.

Is it possible to share the whole code what you are pushing so I can try to deploy it here? Or would it work trying it with one of the resin base images, just in case (Alpine or Debian for cross checking)? If those work, would probably be helpful seeing the Dockerfile for the orbit-os-node base image, to see what difference it is there.

5

I have managed to resolve the issue

I am installing leveldown as a dependancy of PouchDB – upgrading PouchDB from 6.0.7 to 6.1.0 fixed the build issue. I have checked the PouchDB change log but cannot identify what change might have caused this.

Here is an example Resin PouchDB app – https://github.com/jvgreenaway/resin-pouchdb

Thanks for your help!

6

Hey, glad to hear it works for you! :sparkles:

I’ve tried out the example resin PuchDB app you linked to. I’ve tried to reproduce the error, but couldn’t. Been installing pouchdb from Github using "pouchdb": "pouchdb/pouchdb#6.1.0" syntax in package.json (which is a Github URL format), and all the 6.x.y tags seem to work fine… My guess is you couldn’t identify what caused the issues because the real issue wasn’t in the PouchDB version.

Will keep an eye out for this, and I’ll try to trigger it again, maybe missed something. Don’t hesitate to let us know if you find any more info on this (or hopefully it won’t come up again :four_leaf_clover: )