yocontra / node-gdal-next

Node.js bindings for GDAL (Geospatial Data Abstraction Library) [Fork]
https://contra.io/node-gdal-next/
Apache License 2.0
75 stars 35 forks source link

how to optimize Docker image #61

Closed stefanocudini closed 1 year ago

stefanocudini commented 1 year ago

hi I'm working to a Nodejs application with api rest that uses this fantastic fork of node-gdal! here the sources: https://github.com/opengeo-tech/geotiff-picker/

have a package.json similar to this:

"dependencies": {
    "@turf/turf": "^6.5.0",
    "gdal-next": "^2.8.0",
    "lodash": "^4.17.21"
  }

as you can see in my starting docker image I already have gdal pre-installed. then I add nodejs and npm and example install. but this operation is very very slow, I think because it is compiling the gdal sources.

is there a way to perform an install and recompile the internal g from the library?

P.S. if added this indicated in the readme there is no difference and everything is recompiled anyway npm install gdal-next --build-from-source --shared_gdal

I don't understand how these parameters work.. If the system already contains a compiled and working binaries of gdal why do I have to add the "--build-from-source" parameter?

Dockerfile:

FROM osgeo/gdal:ubuntu-small-latest

RUN curl -sL https://deb.nodesource.com/setup_18.x | bash -
RUN apt-get update -y && apt-get install -y \
    build-essential \
    libgdal-dev \
    nodejs \
    && rm -rf /var/lib/apt/lists/*

WORKDIR /home

COPY ./ ./

RUN npm install
CMD ["node", "index.js"]
yocontra commented 1 year ago

@stefanocudini --build-from-source kicks off the build of the native components of the package (tells npm not to use the prebuilds), and --shared_gdal is telling that compilation process not to use/compile the bundled version of gdal (in the src folder of this repo) but to link to the OS one instead.

If you're optimizing for build speed, I think using our prebuilt binaries (that come with a built-in gdal) is going to be much faster than linking to the OS GDAL. If you're optimizing for container size I think it's a toss up, there's nothing about our compiled binaries that are going to be any larger or smaller than the OS GDAL ones you install with apt-get.

It sounds like you're optimizing for build speed - you want to make sure you're using a node version and OS that has prebuilds available. Check our matrix here: https://github.com/yocontra/node-gdal-next/blob/master/.travis.yml

One thing you could do to reduce the container size is after building (either way, using prebuilt or from source) is delete the cpp source code like rm -rf node_modules/gdal-next/src since it isn't needed post-build.

stefanocudini commented 1 year ago

@yocontra thanks for your so much details, I was trying to optimize above all for the compilation speed, in particular to try to use little ram when compiling.

one thing I guess from your explanations and that I didn't understand before, correct me if I'm wrong is this: so i can't use gdal-next without any compilation?

I ask this because I did not understand very well the binding mechanism node/gdal, it is something that I found poorly docs about this on the official gdal website

yocontra commented 1 year ago

You can use gdal-next with no compilation if you use one of our prebuild binaries, which are available up to node 16. Try using https://deb.nodesource.com/setup_16.x instead of https://deb.nodesource.com/setup_18.x and you should notice it speed up.

Alternatively, look at node-gdal-async which is another fork which may have prebuilds available for node 18.