pkiraly/qa-catalogue

Create default frontend configuration with docker compose

nichtich opened this issue · 6 comments

nichtich commented

Starting a Docker container with docker compose should use given configuration to create a matching configuration file for the frontend with matching values such as dir and mainSolrEndpoint. To not overwrite existing configuration.cnf, the file could be named auto-configuration.cnf and included from configuration.cnf, so additional and persistent configuration could still be used.

See https://docs.docker.com/compose/compose-file/08-configs/ for technical details how to implement.

pkiraly commented

@nichtich Maybe I am wrong, but don't get the point.

The configuration already has an include property. The Dockerfile creates the configuration (/var/www/html/qa-catalogue/configuration.cnf), that has the following content:

dir=/opt/qa-catalogue/marc/_output
include=config/configuration.cnf

docker-compose.yml defines the mapping of config dir as

volumes:
  - ./${WEBBCONFIG:-web-config}:/var/www/html/qa-catalogue/config

So the configuration.cnf inside the $WEBCONFIG directory does not replace any existing configuration.
At the end the web UI works with two config files:

  • /var/www/html/qa-catalogue/configuration.cnf - the default one in the image
  • /var/www/html/qa-catalogue/config/configuration.cnf - the custom one attached to the container

You suggestion would be to rename the second config? Or something else, e.g. this config should not overwrite existing values or we should have third one for special purposes?

nichtich commented

You are right. What's missing is schema and mainSolrEndpoint.

pkiraly commented

mainSolrEndpoint has a default version in the Configuration class: 'http://localhost:8983/solr/. schema once also had a default value: MARC21, but now it is null, because I am not sure which should be the default value.

nichtich commented

Maybe schema could be taken from analysis output, so no need to explicitly configure in it qa-catalogue-web.

Overall this issue may become obsolete with evolution of Docker usage.

pkiraly commented

"Maybe schema could be taken from analysis output"
Yes, that is doable, good idea.