Can I put the Mongo DB connection details in `Conf...
# ask-questions
c
Can I put the Mongo DB connection details in
Config.yml
instead of using the
MONGODB_URI
environment variable.
h
No, I don't believe so.
c
sad... But thanks
h
Can I ask what the use case is?
c
Sure: I am using AWS CDK to setup DocumentDB in AWS (and everything else). The password and username is automatically created, stored, and dynamically rotated in AWS Secrets manager as a side-effect of creating DocumentDB. In the CDK where I create the ECS Cluster where GrowthBook will be running the DocumentDB hostname, username, and password are set as environment variables (incidentally the password may contain complex characters so I need a way to URL escape those too in the current URL like scheme). In Docker I do something like this
Copy code
FROM growthbook/growthbook:2.4.0

ENV GBHOME=/usr/local/src/app

WORKDIR $GBHOME

RUN apt-get update && \
  apt-get install -y curl telnet && \
  apt-get clean && \
  rm -rf /var/lib/apt/lists/*

RUN wget <https://truststore.pki.rds.amazonaws.com/global/global-bundle.pem>

EXPOSE 3000
EXPOSE 3100
That image will be put in ECR. There is no way to formulate the
MONGODB_URL
with the values that are only available in AWS secrets or in the VM. So I am stuck duplicating the other "secrets" in a
MOGODB_URL
or overriding the
ENTRYPOINT
and formulating it in that script and then calling
yarn start
manually. A downside of this is that variable would only be available in the context of that start script and not to the environment. This also has an unfortunate side effect of breaking password rotation too unless I build something that will update
MONGODB_URI
in secrets when ever the DB password rotates. If I could specify a config file with mongo settings that would compose/resolve environment variables at runtime it would be SO much easier to get this running in ECS Fargate. I think it is similar a story for
APP_ORIGIN
and
API_HOST
. I want to have the same ECR image that can run in various environments like dev, production, staging and resolve the configuration from the environment variables and not put secure stuff in ECR image or need to duplicate secrets in the secrets store.
It is unfortunate that Docker does not support resolving this sort of thing at runtime but would instead stashed the resolved values in the image:
Copy code
ENV MONGODB_URI="mongodb://${DOC_DB_USER}:${DOC_DB_PASSWORD}@${DOC_DB_HOSTNAME}:27017/growthbook?authSource=admin&directConnection=true&serverSelectionTimeoutMS=5000&tls=true&tlsAllowInvalidHostnames=true&tlsCAFile=%2Fusr%2Flocal%2Fsrc%2Fapp%2Fglobal-bundle.pem&retryWrites=False"
Plus the need to URL escape stuff is an issue.
If
if (!MONGODB_URI) {
here it would be nice if there were a way to call a bash script (or something) that could pass it or some other way to provide the needed credentials before it fall through to
throw new Error("Missing MONGODB_URI environment variable");
I am sure there are lots of ways to solve this but this is sort of what I was thinking could be helpful: (I've not thought a lot about it so this may not be great)
Copy code
export let MONGODB_URI = process.env.MONGODB_URI;

// If MONGODB_URI is not set
if (!MONGODB_URI) {
    const scriptPath = "/somepath/getMongoCredentials.sh";

    // Check if the script exists
    if (fs.existsSync(scriptPath)) {
        try {
            // Execute the shell script and capture the output
            const output = execSync(scriptPath, { encoding: 'utf8' });

            // Check the exit code (implicitly, as execSync would throw an error on non-zero exit code)
            // and if the output contains only one line
            if (output.trim().split('\n').length === 1) {
                MONGODB_URI = output.trim();
            }
        } catch (error) {
            console.error(`Error executing ${scriptPath}:`, error);
        }
    }
}

// If MONGODB_URI is still not set, throw an error
if (!MONGODB_URI) {
    throw new Error("Missing MONGODB_URI environment variable or failed to retrieve from script");
}
h
Thanks for the context. I'm not sure myself if there are technical reasons why we can't do this, but let me check with the team.