openstreetmap-tile-server
openstreetmap-tile-server copied to clipboard
Publish ARM64 image
The current image works insanely slow on QUEMU and crashes. I've just built the image locally on Apple Silicon, so, there should be no problem with that.
When I wrote the Github Action I did try to make a multiarch build using QEMU for linux/amd64
, linux/arm64
, linux/386
, linux/ppc64le
, linux/arm/v7
, linux/s390x
and linux/riscv64
. But the only arch that worked without running into errors was linux/amd64
:disappointed:
- https://github.com/Istador/openstreetmap-tile-server/commit/83f3fecccff396f72523ba7c7516eb053ebe3c35
- https://github.com/Istador/openstreetmap-tile-server/commit/b2121cd7d3ed2f5f35eb6026835f22c40f22515e
- https://github.com/Istador/openstreetmap-tile-server/commit/6b717a9d0a2d2c15d55f2d3cbfc475b2e17581b3
- https://github.com/Istador/openstreetmap-tile-server/commit/df36919866d3af5db9ec709f106d96809824f3a7
- https://github.com/Istador/openstreetmap-tile-server/commit/009bc71e0fc9c4f4a5444e552bd79e854710c80b
- https://github.com/Istador/openstreetmap-tile-server/commit/c6503c978f7fbb154e8084fc541324f13c730dc9
- https://github.com/Istador/openstreetmap-tile-server/commit/a809d3704c6ccee5724f1e9e5f84520d05164cd6
Maybe now with the changes from #234 that updated the ubuntu
base image from 20.04
to 22.04
it won't run into errors anymore? Worth a try.
Otherwise I think building it here automatically for other architectures without QEMU on real hardware isn't that easy/cheap.
I'm currently trying to build for different architectures again with the newest master
version.
linux/arm64/v8
worked so far.
I'll try out all the other archs before creating a pull request.
Please try out if the image works on your real hardware with that architecture: https://github.com/Istador/openstreetmap-tile-server/pkgs/container/openstreetmap-tile-server/27972280?tag=multiarch
@Istador, arm64/v8 works fine with the latest Luxembourg maps on M1.
How soon do you think this will be available in Docker?
I was just thinking about it today on how to proceed with my PR #292.
I tried to test the images in the pipeline with qemu but faced some issues:
-
arm64/v8
fails startingapache
within 20 seconds ("The apache2 instance did not start within 20 seconds. Please read the log files to discover problems"
). But even if I increase the timeout to 5 minutes or so, it won't start. -
arm/v7
on the other hand ran into actual errors. I had toa2dismod
anda2enmod
thempm_event
(it was enabled, but apache complained that it was not:"AH00534: apache2: Configuration error: No MPM loaded."
). But even with that, the renderer later ran into issues with the fonts. They seem to be all installed correctly, butmod_tile
can't seem to find them ("no valid fonts could be loaded in FontSet 'fontset-0'"
). Installingfonts-hanazono
package (which is recommended but not required) manually on the CLI inside adocker run
resolved that issue (the other fonts were still missing, but it starts with only the hanazono fonts). But installing that package in theDockerfile
had no influence on the issue at runtime...
I assume these are all just emulation issues, but until someone tests the arm/v7
build on real hardware or fixes the issues, I'd rather leave it out and only provide the arm64/v8
arch for now, trusting in Sitins' test on real hardware.
Automatically testing the image will only be done for the amd64
image, because of these issues and also because it is really slow emulated.
(Parallel testing of the arm
images with qemu and caching takes like 25-35 minutes or more, instead of the 6-10 minutes for amd64
only).
I can confirm that above image also works for me - tested on Air M1 for datasets:
- Pomorskie 87Mb pbf 2022-07-18 20:30:41 Reading input files done in 51s. 2022-07-18 20:30:41 Processed 9549978 nodes in 15s - 637k/s 2022-07-18 20:30:41 Processed 1218907 ways in 31s - 39k/s 2022-07-18 20:30:41 Processed 12442 relations in 5s - 2k/s
2022-07-18 20:31:01 osm2pgsql took 71s (1m 11s) overall.
- Poland - 1,6GB in pbf file. 2022-07-18 20:36:18 osm2pgsql version 1.6.0 2022-07-18 20:36:18 Database version: 14.4 (Ubuntu 14.4-0ubuntu0.22.04.1) 2022-07-18 20:36:18 PostGIS version: 3.2 2022-07-18 20:36:18 Setting up table 'planet_osm_point' 2022-07-18 20:36:18 Setting up table 'planet_osm_line' 2022-07-18 20:36:18 Setting up table 'planet_osm_polygon' 2022-07-18 20:36:18 Setting up table 'planet_osm_roads' 2022-07-18 21:23:13 Reading input files done in 2815s (46m 55s). 2022-07-18 21:23:13 Processed 188403004 nodes in 276s (4m 36s) - 683k/s 2022-07-18 21:23:13 Processed 26116304 ways in 2165s (36m 5s) - 12k/s 2022-07-18 21:23:13 Processed 194191 relations in 374s (6m 14s) - 519/s
(broken due to disk space)
Processing: Nodes ~ 1Gb mem, cpu 1-1,4; Way: ~3,2Gb, cpu 1,3; Relation ~3,4 GB cpu jumping 0,7-1.4 Total disk read: 22,5 GB/write 72GB
Running with Docker Desktop. 4CPU dedicated to Docker: VM mem usage 8-9GB( 1GB swap); CPU ~20%
I doubt the sync script will push the arm images to docker hub.
I doubt the sync script will push the arm images to docker hub.
@Overv Any chance to get this fixed? https://stackoverflow.com/questions/68567983/how-to-copy-multi-arch-docker-images-to-a-different-container-registry
@Istador I could quickly implement it thanks to your research and link :+1: The sync script now mirrors images as-is for all architectures as seen for the latest
tag on Docker Hub:
https://hub.docker.com/repository/docker/overv/openstreetmap-tile-server/tags?page=1&ordering=last_updated
I've also stopped my own build cronjob that was (erroneously) still running and pushing tags with a v
prefix.
Import process now works for me on arm64 (Raspberry Pi 4, 8GB ram, latest version of Ubuntu) pull the latest docker image.
Docker container exits after about 30secs from running server - any ideas?
Import process now works for me on arm64 (Raspberry Pi 4, 8GB ram, latest version of Ubuntu) pull the latest docker image.
Docker container exits after about 30secs from running server - any ideas?
Is there an error message in the log?
"The apache2 instance did not start within 20 seconds. Please read the log files to discover problems"
by any chance? (I had that error testing it, but regarded it as an emulation-only issue.)
@Istador there was no error message to check logs. I had to check the docker container list every couple of seconds to see that it was exiting. Haven't checked log yet.