Refactor for GitHub Action

[lucernae]

Add GitHub action to build the following images:

Only from the develop branch:

• kartoza/docker-osm:imposm-latest
• kartoza/docker-osm:osmupdate-latest
• kartoza/docker-osm:osmenrich-latest

The PR also reorganized the docker-compose file and the Makefile commands. Explanation included in the README.md

[lucernae]

The changelist for the reorganization:

• move docker-imposm3 folder to docker-imposm so that the GH Action build matrix is simpler to publish the docker tag
• delete .env file and move it to .example.env to let user put his .env file without being committed into the repo
• separate docker-compose.yml file so that we have ready to use recipe for production usage (docker-compose.yml), local usage (docker-compose.develop.yml), custom build usage (docker-compose.build.yml), and service helper usage (docker-compose.pgadmin.yml and docker-compose.web.yml). Instructions to use is described in the README.md
• Refactor Makefile to use parameter from .env file.

[Gustry]

Side note, why not using a single docker-compose file with the use of docker service ?

[lucernae]

Some future TODO, not implemented now, depending on how we wanted to make this stack production ready:

• Break the docker tag into separate docker repo. Currently we can't easily uses public GitHub Action recipes due to our unconventional tag: kartoza/docker-osm:imposm-latest. Either we make our own tools to generate the tag name, or we make it simpler like: kartoza/docker-osm-imposm:latest.
• Because of the above reason, we can't build and push a PR docker image tag (image tag for Pull Request to test).
• Make the code dependency clear. At the moment, the Dockerfile recipe doesn't explain clearly why or how the code/binaries are needed.
• Make the stack kubernetes-ready. At the moment, the image is based on ad-hoc deployment (imposm) and long polling process (osmupdate, and osmenrich). To make it kubernetes-ready, all the images needs to have a clear process state. For example imposm should be once-off job. osmupdate and osmenrich should a kubernetes cron-job. They all need to have an exit status.

[lucernae]

Hi @Gustry , sorry I haven't see your comment above when I'm writing the next comment after you.

Side note, why not using a single docker-compose file with the use of docker service ?

Which one are you referring to? Is it for commenting on why I break it apart into several files?
At the moment, the reason I do that is to make it easier to convert it into production deployment, and/or other orchestrator such as podman/kubernetes. The minimum files needed for production is the default one: docker-compose.yml. The rests are easily composeable/merged together if needed (via .env file in COMPOSE_FILE variables). The ordering matters. If you don't have existing docker-compose file from previous project, then just use the current order described in .example.env. If you do have existing customized compose file, let's say docker-compose.custom.yml, then put this one first and override as needed, for example: docker-compose.custom.yml:docker-compose.develop.yml:docker-compose.build.yml

The other reason is that for cloud deployment the volume declaration needs to be abstracted away. In the original recipe, the settings folder directly mounted from local directory in the main recipe docker-compose.yml. We can't convert the recipe using kompose to Kubernetes with that, so we separate the declaration (default to use volume, but you can use local bind mount in separate recipe).

[Gustry]

Thanks for your explanations @lucernae
As I said, it was just a "side note". I'm also discovering docker-compose config ;-)

[NyakudyaA]

LGTM, we still need to also add tests these should cover

• docker-osm - check if the importer runs successfully
• docker-osm-enrich - check if the imported table extra details are added
• docker-osm / docker-enrich check SSL connection parameters where we connect to PostgreSQL using FORCE_SSL settings

[lucernae]

I will merge the PR first, so we can check GH action.