As I’ve previously blogged, Azure App Service offers a Web App as a service and you can continuously deploy your NodeJS applications there. Unfortunately, we’ve seen first-hand recently that when GitHub, Visual Studio and cloud services get together, sometimes bad things happen. Even with quick recognition, significant damage and costs can apply. It’s usually because someone was dumb enough to check in credentials or keys to the service (I was guilty of checking in admin passwords at one point – it’s easy to do. It’s still dumb).
We can secure the publishing process, but how do we give the application the keys they need without checking them in. The answer is in the app settings within Azure. To show this off, I’ve created a new NodeJS webapp. You can get the code from my GitHub repository and run it locally. It allows you to browse to http://localhost:3000/home/env to get the page we are interested in. The page cycles through process.env, displaying the environment as we go. If you run it, you will get something akin to the following in the browser:
On my own machine, I expect the list to be very expansive. Actually, I was surprised to see a lot of stuff about the actual environment in there, including node version, npm version, and the various versions of the npm packages I depend on. Now that I have this working on my home site, I set up an Azure web app with Git deployment to see what I could see there, deployed the app and ran it.
Take a look at the environment variables starting with WEBSITE and APPSETTING – those contain interesting information about your NodeJS environment on Azure. In addition, there is a PORT environment variable – I use this to connect the Express instance to the outside world. There is also a NODE_ENV and it’s set to production. This allows me to decide what to do with logging based on the environment.
This isn’t enough for me yet. Let’s say I want to connect to a SQL Azure service. I don’t want the credentials of this to be included in the GitHub repository. Perhaps I can utilize the app settings to provide the app the setting automatically. Here is how I did it.
1. Create a SQL Azure Instance
Go to your web app and select Settings, then Data.
It will automatically set you up for adding a new data source. Select SQL Database:
Create a new database, give it a name, then click on the Server and fill in the Server Name, admin and password information. Ensure the Allow azure services to access server checkbox is actually checked. Make a note of the Server admin login and password – you will need it shortly. Once you are done this, click on the OK buttons at the bottom of the blades, starting with the right hand one and ending when you get back to the Add data connection.
Create A Connection String Setting
Now click on the Connection string link:
Leave the Name box alone. Fill in the username and password based on the Server admin and password you provided when you were creating the database. Then click on OK on that blade and OK on the Add data connection blade. Once that is done, wait… perhaps several minutes… while your database is being created. The Notifications area will tell you when the database is created.
Check the Results
Once that is done, give your server a restart and reload that /home/env page:
Note that the Name from the connection string was MS_TableConnectionString and that became SQLCONNSTR_MS_TableConnectionString. it contains the appropriate SQL Server connection string. You could feed this into the Tedious driver to access the SQL database.
Other App Settings
You can set other app settings and they may or may not have specific meaning within your environment. To set an app setting, click on Settings then Application Settings:
Note that my MS_TableConnectionString is already listed. There is generally a list that the Azure SDKs rely on. For example, MS_DebugMode, when set to true, will enable additional debugging logic within the app environment. You could also add your own environment variables in – especially if you have passwords or keys to use within the environment. Don’t be that guy who has to clean up a mess because you checked in a password.