Configuration of DB from docker-compose.yml

Questions
1

Version: 4.10 including silverstripe-fulltextsearch via Solr

Question: I’m using 4.10 in a docker container an set my DB-config as docker-compose environment-variables. This works well until i added the module silverstripe-fulltextsearch. This module requests the DB-config in .env. And this duplicates my config.
I suppose this relates to some old functionality, but does anybody has an idea how to reuse my variables from docker-compose.yml in .env?

Best regards,
chrclaus

2

It would be useful if you could post a bit more detail of your set up, eg. what containers you’re using, what your compose file looks like, etc.

How are you setting up your environment variables? Are you specifying them manually in compose, passing them as arguments, or loading them from a .env in the compose file?

3

Just a little follow-up, the docs here give a few pointers, depending on your setup:

On our systems, we still use a .env file which is made available to all the containers in the stack that need it using the env_file directive in docker compose. That way all the containers share the same environment

4

Hi Tim,

excuse me, you are completely right, my question was very short.

Referring to the link to docker I’m looking for the oppsite way. I want to set my environment-variables in docker-compose.yml completly. This works very well in the past by the following config:

  tgc-dck-silver4:
    image: tgc-silver4
    container_name: tgc_silver4
    build: 
       ...
    volumes: 
       ...
    environment:
       - SS_DATABASE_SERVER=tgc_database
       - SS_DATABASE_NAME=dbxxx
       - SS_DATABASE_USERNAME=...
       - SS_DATABASE_PASSWORD=...
       - ...
    networks:
      - tgc-dck-revproxy_tgc_network

Everything runs fine until I installed the module silverstripe/silverstripe-fulltextsearch/. The additional SolR-server runs in a standalone-container and works fine too. I’m able to generate the config via the module-task SolrConfigure and start the Solr-instance loading the resulting cores.

I want to run the next step - the task Solr.Reindex, to generate all index-entries for my pages and dataobjects. This task (running inside my SS4-container as it is part of the fulltextsearch-module) checks the DB::config and breaks with the message
silverstripe\fulltextsearch\solr\tasks\solr_reindex.INFO: Silverstripe Framework requires a "database" key in DB::getConfig(). Did you forget to set SS_DATABASE_NAME or SS_DATABASE_CHOOSE_NAME in your environment? [] []
But i have a DB-configuration in my docker-compose.yml and the CMS works fine by creating and updating data-objects in the last months.

I got no glue from the silverstripe-doku and tried multiple things I found. My last try was to configure the DB in mysite.yml twice, using the backtics referencing env-vars perspectivly (without success):

SilverStripe\ORM\DB:
  database:
    - type: 'MySQLDatabase'
    - server: 'tgc_database'
    - username: '...'
    - password: '...'
    - database: 'dbxxx

The only workaround i found yet is the .env file in my project-root. By doing so I have to repeat my config which i want to avoid. Switching all the config back to the environment-file leads to other effort because my environment-stages currently configured via docker-compose.yml solely.

Do i miss a simple solution or is it the module silverstripe-fulltextsearch itself which blocks other ways?

6

How are you running the solr_reindex task? If you are running it via the command line, make sure you’re running it inside your docker container. The command line on your host machine naturally has no access to the environment variables that you defined in your docker-compose configuration.

5

I found a curious situation: the module silverstripe/fulltextsearchstarts a reindexing-task via a command-line as symfony-process. If there are no env-variables explicitly set, the process should take the same env-variables as the running process. This do not work: if explicitly set $process->setEnv(getEnv());everything works fine.

But my variables are set as container-variables. Why are they not visible to new symfony/php-processes?

7

Sounds like a bug in that module. If it’s using SilverStripe’s built in Environment abstraction, it should “just work” but you’re having to explicitly set stuff in the module itself, it seems

Without opening it up and looking at the code of that module myself, that’s what it looks like to me at least.