Deploying Web+Database Apps to Iron Foundry Without Changing Configuration Settings

One of the tricky things you’ll experience when working with PaaS platforms is that the local development environment won’t exactly mirror the targeted PaaS environment. While some cloud providers do a good job of having a local simulated fabric that closely mimics the cloud environment, it’s inevitable that SOME differences will exist.

In this post, I want to specifically focus on database connection strings. A connection string with “server=localhost” may be perfectly fine when running on a developer’s machine, but this won’t fly when we deploy an application elsewhere. In this example, I’ll show you how we can easily keep a local database connection string while leveraging the built-in connection string rewrite that’s baked into Iron Foundry.

I’ve got a ridiculously simple ASP.NET web form, and within it, a GridView that used a SqlDataSource to grab records from a database on my machine.

Configuration File Markup

This application’s web.config file had a connection string (named “Default”) that included the details necessary to talk to the database.

Default Connection String

With this robust website ready to go, I first published the site to the file system, and then spun up the Cloud Foundry Explorer tool.

Cloud Foundry Explorer

I then chose which Iron Foundry environment to target with my “push.” In this case, I chose a Web Fabric instance hosted by Tier 3. During the push, I was asked to select the name of the application, code source location, resource needs, and which application services to bind to. I chose a Microsoft SQL Server application service.

Push Application

In a few seconds, the application was deployed, and I could see it was up and running. All that remained was to get my local database provisioned into the cloud. Recall that Microsoft SQL Server is just one of many services available in Iron Foundry.

Checking Services via the Iron Foundry VMC

While I’ve previously demonstrated some funky ways to instantiate the underlying database in an Iron Foundry environment, we’ve since made it MUCH easier to tunnel into these databases. We now use the Cloud Foundry Caldecott process to connect to the Iron Foundry / Web Fabric SQL Server database service. With a simple command (“vmc tunnel SeroterSqlDb”) I connected my machine to the hosted environment and when the tunnel was set up, vmc returned my database credentials.

Tunneling

I could now fire up SQL Management Studio and log into the database with these credentials.

SQL Server Management Studio (2008 R2)

After generating a T-SQL script out of the local database, I ran that script against the cloud database and produced the necessary tables.

Databases

You may recall that the application’s original connection string targeted my local database. How did I update it with these new cloud database settings? The answer is: I didn’t have to! When we push a web application to Iron Foundry, and it is associated with an application service like SQL Server, the provisioning process injects the new database connection details into the web.config file of the web application. We can prove this by first finding our application in the Cloud Foundry Explorer.

Databases Listed in Cloud Foundry Explorer

When I double-clicked the web.config file, I could see that a series of “app settings” were added, and, the “Default” connection string was overwritten with the details of the cloud database. Note that the connection strong had to be named “Default” for this to work!

Configuration

Sure enough, when we visit the application deployed to Tier 3’s Web Fabric, we can see that it correctly connects to the database and retrieves a set of records.

Viewing the Site

This is just one way that we’ve tried to make it easier to build your applications locally and confidently deploy them to an Iron Foundry cloud without requiring error-prone connection string synchronization tasks!