Configuring Node.js cloud application database settings

Tags: javascript, node-js, nodester, cloud, paas

After the last post describing the specifics of cloud deployment, I'm going to cover the technique of setting up the database configuration parameters, without the risk of pushing them to the public repository.

As already covered in the last post, cloud deployment is done by git-pushing the code to the cloud hosting environment, pretty much the same as pushing it to your code repository. This raises the security question for configuration parameters which need to be kept secure.

Again, I'm going to use a Backbone/Node demo application as the example. As you can see in the Readme, there is a step to set up MongoDB access, which includes creating a file containing the database access parameters. This file is meant to be private (therefore it's being .gitignored), and you wouldn't want it to end up on GitHub publicly.

On the other hand, when deploying to Nodester (or any other cloud hosting), the same git-push of the master branch needs to be done, just to a different remote repository. If you add DB config file once to be pushed to the production repository, it will end up being pushed to GitHub too. If you remove it from being versioned after pushed to production, it will also be removed from the production repository on the next deployment.

Using environment variables technique

So, managing a database config file isn't the solution here. But, if you remember using environment variables within the application to detect which port the application is running on in the cloud environment, the same technique can be used for database settings.

This time, it's just that we need to set our own environment variables on the server, containing the database connection information. This can be done easily using the Nodester CLI (or the REST API / API explorer, if you prefer). The similar APIs will be found at the other cloud hosting services.

Setting remote environment variables

We need to set 5 database parameters - host, port, DB name, username and password - the same parameters being set up through the configuration file. Instead of typing those commands by hand, we'll make a short shell script to run it all at once, using the Nodester CLI (don't forget to install the CLI before running the script).

The script will be called and put in /nodester directory of our application code (already .gitignored):

nodester env set ${APPNAME} "dbname" "<db-name>"
nodester env set ${APPNAME} "dbhost" "<db-host>"
nodester env set ${APPNAME} "dbport" <db-port>
nodester env set ${APPNAME} "dbusername" "<db-username>"
nodester env set ${APPNAME} "dbpassword" "<db-password>"

Replace the placeholder values with your own database parameters, and save the script. Give it executable permissions (chmod 755 and run the script. The script will call the Nodester API and the response will be nodester info environment variable set. for each line if everything went OK.

Preparing the source code to pick up those settings

As for the application port detection, we need to change our Node.js application code a little bit to make it aware of these settings, with a fallback to the local file settings if environment variables are missing (for local development).

We'll check for the existence of one of the five environment variables, and if found we'll set dbConfig object attributes with those parameters, otherwise we'll fall back to picking up settings from the local file. After settings have been read, we construct the database connection URL from it, and connect to the database using MongoJS driver:

var dbConfig = process.env['dbname']
  ? {
        name : process.env['dbname']
      , host : process.env['dbhost']
      , port : process.env['dbport']
      , user : process.env['dbusername']
      , pass : process.env['dbpassword']
  : require("./_db.config").dbConfig;

var databaseUrl =       dbConfig.user + ':' + dbConfig.pass 
                + '@' + + ':' + dbConfig.port
                + '/' +
  , db = require("mongojs").connect(databaseUrl, collections)

This time, changes are being made in the /node/data/_dbConfig.js file, where you can see the complete structure.

Publishing the application

The application code prepared this way is now ready to be git-pushed to your cloud hosting service. As in the last post, the demo application is still the same:

The raise of public and social coding tools like GitHub has resulted in more transparency than ever. Keeping your private data secure is now even more important.

Story comments:

blog comments powered by Disqus