Git Deployment To An Azure WebSite: Keeping Configuration Secrets
Windows Azure recently introduced their “Websites” concept which allows quick and easy deployment of ASPNET, Node.js and PHP web-sites to the Azure cloud. One of the most exciting developments was the ability to deploy to web-sites rapidly using “Git Publishing,” meaning if you are using Git you just need to add a new remote and do “git push azure” to deploy your code on demand.
As I began to utilize this feature I stumbled quickly upon a problem – how do we configure web.config “secrets,” like app settings and connection string passwords? Since git publishing just pushes your current repository directly to Azure, I was worried that I would have to check my secrets into source control, which is an obviously undesirable solution, especially on collaborative teams.
It turns out there are a few aspects of Azure which allow you to keep configuration secrets and still deploy your web-site using the awesome git publishing method. In this blog post I’m going to show you how easy it is to configure appSettings, and I’ll show you a workaround for keeping your connectionStrings and other information secret as well.
AppSettings are easy!
Configuring AppSettings are very simple thanks to the Windows Azure “Portal” (http://windows.azure.com). All you have to do is go into the Dashboard for your web-site and click "Configure.”
Now scroll down and you will see a section for app settings and connection strings.
Any app setting key-value pair you set here will either overwrite an existing value in your web.config or add a new value if there is no match. This is the expected behavior, and it makes it very easy to setup your configuration from the web portal.
The app settings here will persist across deployments, so you can keep your local web.config checked into source control and free of secret configuration info.
ConnectionStrings Cannot Be Modified
Unfortunately, as you can see in the above picture, connection strings cannot be set through the admin interface. Every time we deploy, the values in your web.config (possibly merged with your transformation file) will be used. At this point it doesn’t seem like we can store connection string information outside of source control, however, with a little knowledge of the deployment process, you will see this is not an insurmountable issue.
The Git Publishing Process
The engine behind the git deployment process in Windows Azure is a project called “Kudu,” which is an open source project hosted on GitHub. The relevant details we need to know about Kudu are:
- Currently Kudu will run the build configuration “Release” for any deployment
- Kudu will NOT remove a file if there is no matching file in your deployment
Point #2 here is the key—if you have a file sitting on the server, let’s say “robots.txt,” and then you remove that file from your git repository and deploy using your latest change, that robots.txt file will still exist on the remote.
With this in mind, and knowing that Kudu uses the “Release” build configuration, let’s try to keep our secret information outside of source control and attempt a deployment.
ConnectionStrings and Other Web.Config Transformations
First we have to make sure web.release.config is not part of our repository. Add web.release.config to your .gitignore file and, if necessary, use “git rm” to remove the file from your repository. Now that web.release.config will not be sent up as part of our deployment, we just have to figure out how to get our secret web.release.config file onto the server, knowing that Kudu will not replace the file.
Here our old friend FTP comes to the rescue. Under your website in the Azure portal, go to “Dashboard” and down the right side you will see some basic information about your setup, including “FTP HOSTNAME.”
We are going to use that FTP site to drop in our desired web.release.config file, and when we do future deployments it will be used to transform our base web.config with whatever magical values we chose.
I’m just going to use windows explorer for FTP to keep things simple. On connecting you get the following prompt:
Make sure to enter your username with the dashboard’s “DEPLOYMENT USER” text, which is ‘{sitename}\{username}.’
Once you are in, you’ll see two folders, “Log Files” and “site.” You’ll want to choose “site” and then “repository” so the full path is “ftp://[yourftp].ftp.azurewebsites.windows.net/site/repository/"
Within this folder, navigate to your web.config location and drop in your web.release.config file. This file will persist across deployments and automatically transform your web.config.
As you can see above, towards the middle of this deployment Kudu reported to us “Transformed Web.config using Web.Release.confg.” This is exactly what we were trying to accomplish, and now we have the ability to put anything we want into our Web.Release.config, keep that information outside of source control, and have the transformations persist across deployments.
Conclusion
It is very simple to configure “AppSettings” using the Azure Portal, but setting other web.config values require a bit more effort, especially when you don’t want your configuration values to be stored and versioned in source control. Using FTP, we’ve shown that we can directly place our configuration transform file and have it automatically merge on deployment, allowing us to set virtual any option we desire.
Enjoy!