Fix docker: dynamic app.config and dockerhub integration

[nilsnolde]

Pull Request Checklist

• 1. I have rebased the latest version of the master branch into my feature branch and all conflicts have been resolved.
• 2. I have added information about the change/addition to functionality to the CHANGELOG.md file under the [Unreleased] heading.
• 3. I have documented my code using JDocs tags.
• 4. I have removed unnecessary commented out code, imports and System.out.println statements.
• 5. I have written JUnit tests for any new methods/classes and ensured that they pass.
• 6. I have created API tests for any new functionality exposed to the API.
• 7. If changes/additions are made to the app.config file, I have added these to the app.config wiki page on github along with a short description of what it is for, and documented this in the Pull Request (below).
• 8. I have built graphs with my code of the Heidelberg.osm.gz file and run the api-tests with all test passing
• 9. I have referenced the Issue Number in the Pull Request (if the changes were from an issue).
• 10. For new features or changes involving building of graphs, I have tested on a larger dataset (at least Germany) and the graphs build without problems (i.e. no out-of-memory errors).
• 11. For new features or changes involving the graphbuilding process (i.e. changing encoders, updating the importer etc.), I have generated longer distance routes for the affected profiles with different options (avoid features, max weight etc.) and compared these with the routes of the same parameters and start/end points generated from the current live ORS. If there are differences then the reasoning for these MUST be documented in the pull request.
• 12. I have written in the Pull Request information about the changes made including their intended usage and why the change was needed.

Fixes #696 , EDIT: fixes #718 as well.

Information about the changes

• Key functionality added:
  • changes to host's app.config are reflected now inside the container
  • CATALINA/JAVA_OPTS are set correctly
  • app.config doesn't have to be present when starting a container, which finally makes it independent of this repository and fully available for Dockerhub images

Things to test

1. Custom app.config:

• build image locally and run a container in a directory other than this repository (e.g. /tmp)
• change app.config.sample which is now supposed to be mapped to ./conf/app.config.sample
• restart container and confirm changes took effect

2. use other PBF as a volume and BUILD_GRAPHS=True, which should delete ./graphs/* and regenerate

[nilsnolde]

@MichaelsJP let me know if you have some suggestions. I guess it'd make sense to do a multi-stage build here too, the image size (even with "slim" Dockerfile) is 1.1 GB. Even though the JDK base image is already 500 MB. As a comparison: OSRM is 100 MB.

But really, we only have to keep the war file around in the tomcat folder and a directory for the app.config, the rest can go, right? Stuff for another PR though.

[nilsnolde]

Argh, that's not right.. Sorry @MichaelsJP, still a glitch. This won't work if ./conf/app.config.sample is not on the host. It'll try to create a directory then, which docker tries to map on the file in the container..

I already did it the right way before, then I changed to this and apparently forgot to test it. I'll revert quickly and update.

[nilsnolde]

It's fixed now @MichaelsJP. Tested more extensively, seems it's working fine now, no matter from which directory docker-compose up -d is done.

[MichaelsJP]

@nilsnolde For me the build fails. I guess something with the configs but I couldn't figure it out in a short session.
@takb Could you try to build it on your setup?
I would like to avoid setup related errors.

Error log:

2020-05-18 17:15:14,228 INFO [ors.Application] - Starting Application v6.1.0 on c1dbab66f174 with PID 7 (/usr/local/tomcat/webapps/ors/WEB-INF/classes started by root in /ors-core)
2020-05-18 17:15:14,230 DEBUG [ors.Application] - Running with Spring Boot v2.0.4.RELEASE, Spring v5.0.8.RELEASE
2020-05-18 17:15:14,232 INFO [ors.Application] - No active profile set, falling back to default profiles: default
2020-05-18 17:15:17,850 INFO [ors.Application] - Started Application in 4.667 seconds (JVM running for 9.429)
2020-05-18 17:15:17,874 INFO [routing.RoutingProfileManager] -  Total - 1019 MB, Free - 733.26 MB, Max: 2.00 GB, Used - 285.74 MB
2020-05-18 17:15:17,875 INFO [routing.RoutingProfileManager] -       
2020-05-18 17:15:17,899 INFO [routing.RoutingProfileManager] - ====> Initializing profiles from 'data/osm_file.pbf' (2 threads) ...
2020-05-18 17:15:17,899 INFO [routing.RoutingProfileManager] -                               
2020-05-18 17:15:17,902 INFO [routing.RoutingProfileManager] -                
2020-05-18 17:15:17,912 INFO [routing.RoutingProfile] - [1] Profiles: 'cycling-regular', location: 'data/graphs/bike-regular'.
2020-05-18 17:15:17,912 INFO [routing.RoutingProfile] - [2] Profiles: 'driving-car', location: 'data/graphs/car'.
2020-05-18 17:15:18,031 ERROR [routing.RoutingProfileManager] - java.util.concurrent.ExecutionException: java.lang.NoSuchMethodError: com.graphhopper.routing.util.EncodingManager.getKey(Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;
2020-05-18 17:15:18,032 ERROR [routing.RoutingProfileManager] - Failed to initialize RoutingProfileManager instance.
java.util.concurrent.ExecutionException: java.lang.NoSuchMethodError: com.graphhopper.routing.util.EncodingManager.getKey(Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;
	at java.util.concurrent.FutureTask.report(FutureTask.java:122) ~[?:1.8.0_252]
	at java.util.concurrent.FutureTask.get(FutureTask.java:192) ~[?:1.8.0_252]
	at org.heigit.ors.routing.RoutingProfileManager.initialize(RoutingProfileManager.java:162) ~[classes/:6.1.0]
	at org.heigit.ors.routing.RoutingProfileManager.getInstance(RoutingProfileManager.java:57) ~[classes/:6.1.0]
	at org.heigit.ors.servlet.listeners.ORSInitContextListener.lambda$contextInitialized$0(ORSInitContextListener.java:40) ~[classes/:6.1.0]
	at java.lang.Thread.run(Thread.java:748) [?:1.8.0_252]
Caused by: java.lang.NoSuchMethodError: com.graphhopper.routing.util.EncodingManager.getKey(Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;
	at org.heigit.ors.routing.graphhopper.extensions.flagencoders.bike.CommonBikeFlagEncoder.createEncodedValues(CommonBikeFlagEncoder.java:257) ~[classes/:6.1.0]
	at com.graphhopper.routing.util.EncodingManager.addEncoder(EncodingManager.java:327) ~[graphhopper-core-v0.12.2.jar:?]
	at com.graphhopper.routing.util.EncodingManager.access$300(EncodingManager.java:45) ~[graphhopper-core-v0.12.2.jar:?]
	at com.graphhopper.routing.util.EncodingManager$Builder.add(EncodingManager.java:213) ~[graphhopper-core-v0.12.2.jar:?]
	at com.graphhopper.routing.util.EncodingManager.createBuilder(EncodingManager.java:108) ~[graphhopper-core-v0.12.2.jar:?]
	at com.graphhopper.routing.util.EncodingManager.createBuilder(EncodingManager.java:80) ~[graphhopper-core-v0.12.2.jar:?]
	at com.graphhopper.GraphHopper.init(GraphHopper.java:574) ~[graphhopper-core-v0.12.2.jar:?]
	at org.heigit.ors.routing.graphhopper.extensions.ORSGraphHopper.init(ORSGraphHopper.java:97) ~[classes/:6.1.0]
	at org.heigit.ors.routing.RoutingProfile.initGraphHopper(RoutingProfile.java:168) ~[classes/:6.1.0]
	at org.heigit.ors.routing.RoutingProfile.<init>(RoutingProfile.java:127) ~[classes/:6.1.0]
	at org.heigit.ors.routing.RoutingProfileLoader.call(RoutingProfileLoader.java:35) ~[classes/:6.1.0]
	at org.heigit.ors.routing.RoutingProfileLoader.call(RoutingProfileLoader.java:21) ~[classes/:6.1.0]
	at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:1.8.0_252]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:1.8.0_252]
	at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:1.8.0_252]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) ~[?:1.8.0_252]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) ~[?:1.8.0_252]
	... 1 more
2020-05-18 17:15:18,037 INFO [routing.RoutingProfileManager] - ====> Recycling garbage...
2020-05-18 17:15:18,037 INFO [routing.RoutingProfileManager] - Before:  Total - 1019 MB, Free - 694.86 MB, Max: 2.00 GB, Used - 324.14 MB
2020-05-18 17:15:18,257 INFO [routing.RoutingProfileManager] - After:  Total - 1019 MB, Free - 926.80 MB, Max: 2.00 GB, Used - 92.20 MB
2020-05-18 17:15:18,257 INFO [routing.RoutingProfileManager] - ========================================================================
2020-05-18 17:15:18,257 INFO [routing.RoutingProfileManager] - ====> Memory usage by profiles:
2020-05-18 17:15:18,258 INFO [routing.RoutingProfileManager] - Total: 0 B (0.0%)
2020-05-18 17:15:18,259 INFO [routing.RoutingProfileManager] - ========================================================================```

[nilsnolde]

Weird.. You're sure you build an entirely new image and updated the base image @MichaelsJP ?

I just tried again (my whole system is pretty new) on Arch with the more recent PRs included and it still works:

docker build --build-arg APP_CONFIG=./docker/conf/app.config.sample --build-arg OSM_FILE=./docker/data/heidelberg.osm.gz -t openrouteservice/openrouteservice:test .

and then run the container:

docker run -dt --name ors-app \
  -p 8081:8080 \
  -v $PWD/graphs:/ors-core/data/graphs \
  -v $PWD/elevation_cache:/ors-core/data/elevation_cache \
  -v $PWD/conf:/ors-conf \
  -v $PWD/data/heidelberg.osm.gz:/ors-core/data/osm_file.pbf \
  -e "JAVA_OPTS=-Djava.awt.headless=true -server -XX:TargetSurvivorRatio=75 -XX:SurvivorRatio=64 -XX:MaxTenuringThreshold=3 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:ParallelGCThreads=4 -Xms1g -Xmx2g" \
  -e "CATALINA_OPTS=-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9001 -Dcom.sun.management.jmxremote.rmi.port=9001 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Djava.rmi.server.hostname=localhost" \
  openrouteservice/openrouteservice:test

[takb]

I confirmed, all builds and tests fine here too.

[MichaelsJP]

Seems to have been a local issue in my machine. @takb Thx for helping. I think the pr is fine.