Created Docker support with postgis instance

[Stoiker]

Adapted README.md to indicate the new Docker support

Dockerbuild uses a two-stage build to keep a low memory footprint for the final container. Actual data is stored in docker volumes, that way one can avoid trouble with SELinux and permissions. No proxy is used to keep it simple.

Works on my system with podman as well.

[olivierdalang]

Thanks for that !! Just tested, it seems to work great out of the box (after some very simple testing, I'm completely new to Timemill and was just looking for a way to easily test it, so take the following comments with a grain of salt)

Here are some ideas/comments/questions:

• [edit, forgot the most important] mount the project folder to something like ./_docker_projects, so that one can view/edit files from the filesystem directly. Make sure to gitignore and dockerignore the folder.
• don't expose port 5432 in the docker-compose (no need for it by default, and could be dangerous esp. because of hardcoded password). If you want to provide a dev/debugging setup, better to put it as overrides in a docker-compose.override.yml
• I don't think you need - ALLOW_IP_RANGE=0.0.0.0/0
• I see those 20008/20009 ports are some tilemill default, but why not expose more standard 80 (or 8000 or 8080) ports which make it more clear it's a good old http service?
• why the startdocker.sh script instead of just putting the command in the dockerfile ? (which would be more readable)
• you could improve the dockerfile by first copying just the files required by npm install package.json and package-lock.json, and only add the whole source after npm install, so that you avoid redownloading/reinstalling all dependencies for changes unless they affect dependencies
• add an image name for tilemill, so that the day you publish images to the dockerhub, the docker-compose is usable without building (and also that the docker-compose setup can easily be used in CI to automatically build/push the image)
• include a github workflow setup to build and push the images (would require for maintainers to include secrets to allow pushing to dockerhub), so that users of the docker container don't need to checkout/build manually

Cheers

[Stoiker]

Hi @olivierdalang! Thx for testing and your input. Some general remarks: Personally I am using Fedora with SELinux enabled and podman. Hence, port 80 is a no-go per default and direct mounting of folders is troublesome (but solvable via :Z) To keep things simple and make it work out of the box for non-daily docker users I decided to stick with the default tilemill ports and docker-volumes (Also I assume that users that want to use this in actual production are far more capable than me in hosting stuff and adjust it accordingly)

Regarding your questions:

• The file mgmt is the thing that troubles me the most. As stated above, the direct mounting seems to be an issue (or at least something users have to tinker with) Do you know any other way to get pure docker volumes "linked" to your FS besides an inspect and manual navigation there?
• Without exposing 5432 and the ALLOW_IP_RANGE one can not populate the db with something like osm2pgsql (?)
• Changing from stardocker.sh to CMD was a good idea, changes are pushed and squashed into the previous commit
• Also good input regarding the copying of package.json
• The whole naming/building and publishing of an image was beyond the scope of this PR (since I am not a maintainer of this project I simply lack the necessary information) One would have to discuss how the whole release cycle should be adapted