Build libosrm in separate image

[nilsnolde]

wrt VROOM-Project/vroom#400

Looking briefly at the runtime requirements for libosrm from vroom's makefile I guess this wouldn't bloat an image too much?
https://github.com/VROOM-Project/vroom/blob/24a6dd54175f40f2fb58be1c2ff76dd951a957f8/src/makefile#L30

I also do think it would be quite handy to have the lib rather than the full-fledged HTTP docker container for OSRM, should be more lightweight in total. Of course we'd need to incorporate the lib into the vroom image.

My suggestion would be: two images for each vroom release, one with libosrm, one without. On Dockerhub (I think) it's quite tedious to set up build arguments and such. Anyways, dockerhub (as so many other "free" services) restricts anonymous pulls quite a lot these days. Maybe it's also time to move to github actions? (until they also restrict of course :D, but pretty sure they'll wait until they got a really good market share for CI & packaging, the classic drug dealer move..)

What do you think @jcoupey? I'd target that for the next vroom release. Any idea when that'll be approx?

[jcoupey]

Yes, having another image including libosrm would be a nice addition.

Maybe we can keep release/hosting/deployment questions as a next step and start with the technical part: would setting up this new image be straightforward? From a practical point of view, can we easily manage a dual-image setup from this repo?

[xamado]

Jumping in since I might have started the discussion :)

I think that this would be a nice move, it would definetly make "starting with vroom" much easier, and unless you actually have a case where you also use osrm for something else rather than just for vroom, I don't think there's much point to running different services and scaling them independently.

The added benefit is that it would also make the "default/easy" install of vroom perform even better shaving off all that json encode/decode happening with separate http services.

[nilsnolde]

would setting up this new image be straightforward? From a practical point of view, can we easily manage a dual-image setup from this repo?

@jcoupey yes and yes :) any idea about time frame for the next release?

[jcoupey]

No deadline or guarantee on the next release, but I'd say it'll probably happen by the end of 2020, or early 21. In any case, we'll go through the usual release candidate process so it should leave a fair amount of time to sync this.

[nilsnolde]

So 2.5 years later I'm looking into this:) It's almost done, but I have no idea how to test this 😅

Can you give a quick example of how to use libosrm instead of HTTP @jcoupey ? If I read the code right, it seems it's encoded in the vehicle.profile? So if it's car, it'll expect a ./car.osrm dataset?

[jcoupey]

In order to use libosrm, you'll have to first load the dataset in RAM using osrm-datastore. It is not really about the osrm file names, but rather the shared memory dataset name that has to match the vehicle profile:

osrm-datastore --dataset-name car my_file.osrm

[nilsnolde]

ah ok, got ya. was "fearing" that ;) that might mean a bit more magic in the docker image/container to be usable in a friendly way.