Move towards eliminating .env requirement for dev,rc,experts

[qjhart]

The plan for experts will continue to be routing all requests through a single router (router.experts.library.ucdavis.edu). I'd like to continue routing via different ports for our servers, and because of the number of installs, we will potentially be running two instances (like dev,rc) on one backend (eg. blue).

Since we have seperate docker-compose for each stage, I suggest that we update those compose files, for the default values for server names and ports. So we'd have something like:

  gateway:
    image: ucdlib/rp-ucd-gateway:dev
    environment:
      - ${SERVER_URL:-https://dev.experts.library.ucdavis.edu}
    ports:
      - ${HOST_PORT:-3006}:3000
    restart: on-failure

Also, we'd potentially limit the ports we'd promote to the OS on rc and prod.

The only downside would be developers testing different installs, but since the .env would still be read, that could be adjusted there, without modifing the docker-compose files.

[jrmerz]

What is the motivating factor for this issue?

While we might be able to do this, it won't be easy. We will need to

• handle secrets
• either update config.sh every time we merge or create config directories for each environment
• if using config directories we will need to mount and load config base on dir
• Agree upon ports not by machine but by env

[qjhart]

I guess the main motivating factor is if one would pull rc, or a tagged version, it'd be nice if it didn't depend on an untracked .env file to work, and it seems like adding per/branch defaults is so similar to per/branch images that it wasn't a heavy lift. I don't understand why the need for per merge mods would be. Just add a few more variables to the .tmpl files.

Secrets is a good question, I believe fuseki handles lack of a secret okay, but the password is somewhat hidden. Do we want to investigate secrets via Google's cloud setup?

Regarding ports, that's sort of true, but remember developers can just set HOST_PORT and FUSKEKI_HOST_POST in their .env files, and have a per-machine setup anyways.

The only reason I could see for multiple yaml files is if we wanted to prevent some setups from exposing all the ports to the OS, which could be a difference between production and dev enviroments, but would be anyways.