Configuration for QA/staging environment?

[sbrichards]

Hi folks,

I’m working to upgrade our Ghost application from 0.11 to 1.22 via Docker & Docker Compose. We’d like to support 3 separate environments: development, QA and production.

I’ve read through the information on Ghost’s config and saw your forum response on Config.js vs config.production.json, where you mention that config can be set up by “supplying both environment variables & command line arguments instead of values in the file”.

What is the recommended approach is for configuring a QA/staging environment? We have a different “url” and a different “database” option, however, since we want our QA environment to mimic our production environment as closely as possible, I’m thinking we’d still like to set NODE_ENV to production.

How do you recommend we override the database config in config.production.json? Can we create some sort of config.qa.json? Should we pass in environment variables via our docker-compose.yml files (we already do that for S3 configuration)?. Or do you propose adding conditionals to our Dockerfile that supply the configuration via command line arguments?

Thank you in advance!

[Hannah]

I would strongly recommend having the NODE_ENV set to production here. It has some special rules that wouldn’t be the same in any other env, and so would create unnecessary differences.

This means that the config file should be called config.production.json in both staging and production.

How we work internally is that config values are part of our configuration management system. The config.production.json file is templated, and the values differ ever-so-slightly between staging vs production.

Alternatively, you could have a single static config.production.json and use environment variables to override the couple of values that are different for staging.

How to handle this really comes down to the systems you’re using and preference. We make heavy use of configuration management so that makes sense to us. I don’t know enough about Docker to know how that impacts what is possible.

[sbrichards]

Thanks @Hannah – appreciate the info & advice! For those who are curious to see a solution, that’s pretty much the approach we took:

• Passed in environment variables for the DB connection (distinct for development, QA & production)
• Set NODE_ENV to production and used config.production.json for both QA & production environments
• Used docker-entrypoint.sh to generate the json config on boot (based on those environment variables)

Here’s essentially what that docker-entrypoint.sh looks like:

if [[ "${SYSTEM_ENV}" == "development" ]]
then
    export NODE_ENV="development"
    GHOST_CONFIG_FILE="config.development.json"
else
    export NODE_ENV="production"
    GHOST_CONFIG_FILE="config.production.json"
fi

cat >${GHOST_INSTALL}/${GHOST_CONFIG_FILE} <<EOF
{
  "url": "${GHOST_URL}",
  "database": {
    "client": "mysql",
    "connection": {
      "host": "${GHOST_DB_HOST}",
      "user": "${GHOST_DB_USER}",
      "password": "${GHOST_DB_PASSWORD}",
      "database": "${GHOST_DB_DATABASE}",
      "charset": "utf8"
    }
  }
}