I recently got my hands on a Windows Azure and SQL Azure token to try out a little cloud goodness.
The challenge I set myself was to host an ASP.NET MVC application (including data) in the cloud. Hopefully just an hour or so of fiddling about, but as I hadn't really used Azure before, it would also be a bit of a learning experience.
3 steps seemed to be in order:
1) Create an MVC Application
2) Move the application data from SQL Server -> SQL Azure
3) Move the application hosting to Azure
It turns out that everything I needed to do this is already published but I wanted to pull the threads together. As a result, I haven’t gone into particular detail below – you can find everything you need in the Azure Training Kit.
Step 1 - Create an MVC Application
OK, I couldn't be bothered with that to be honest, so instead I downloaded the reference NerdDinner application from CodePlex - relatively trivial and already working.
Got that, unzipped and then a quick F5 in VS2008 proved that all was well with the app.
Step 2 - Move the application data from SQL Server -> SQL Azure
This is where a little bit of work starts. In principle this is a straightforward migration - script the database and run the script elsewhere - in practice we need to configure SQL Azure, connect to it and also check that the script will run (there are differences between SQL Server and SQL Azure in terms of supported capability).
So, assuming you've got a SQL Azure token, then you should activate the account and set-up a new database. I called mine NerdDinner. You also need to add firewall exceptions so that you can access the database from your dev machine.
I then generated the schemas and data from the original DB via VS.
In principle, you can then run this script into SQL Azure, but in practice, there are differences in the support for various bits of SQL Server functionality. Fortunately, there's a handy migration tool on CodePlex which can provide some validation.
Running the script into that tool confirmed it should be valid. So, then I used the SQL command line to run the script into the SQL Azure database.
(At this point I should also set up specific user roles for that DB of course).
You can then grab the connection string to the database from the SQL Azure dashboard and change the connection string config file (Connectionstrings.config) in the NerdDinner project. An F5 later, and the original NerdDinner app is now using the SQL Azure database instead.
This step was surprisingly painless, though depending on the complexity of your database YMMV. Oh, NerdDinner uses Linq-to-SQL, but I also did the same thing with Entity Framework and it worked fine for a trivial example.
Step 3 - Move the application hosting to Azure
Now, it would be wonderful if we could just move the Membership provider databases (et al) to SQL Azure too but we can't as there are certain functions not supported. Fortunately - again - the Azure Training Kit provides some code to enable a Membership provider using Azure Table storage.
At this point then, we need to create the Azure solution (so you need to have installed the VS Tools). This involves:
- Creating a new 'Cloud Service' project - just use the ASP.NET Web Role. (There’s no default MVC option).
- Deleting the default ASP.NET Web Role.
- Adding the existing NerdDinner project to the solution.
- Associating the NerdDinner project with the cloud service. (Right click Roles –> Associate With… and choose the NerdDinner MVC Project).
This is well documented in the Azure Training Kit.
Also covered in the kit is how to get the Membership provider working. Essentially, that involves:
Adding two projects that came with the Azure Toolkit to the solution.
Adding a reference to the membership provider from the....
Ensuring the storage service is running in the development fabric.
Amending the web.config file to take advantage of this provider.
Following this, hitting F5 will fire up the project inside the development fabric - using the new membership provider and still using SQL Azure for application data. There’ll be some messages about creating the storage tables as the solution builds and runs. (We could also remove the redundant membership connection string from ConnectionStrings.config in the MVC project).
So we’re done for tweaking config. At this point, we can move the application to Azure.
Again, presuming you have an account and it is activated, you're going to need a couple of things:
Hosting for the application – I’ve set-up a host called NerdDinnerService.
Storage for the application – mine is called NerdDinnerStorage.
An affinity group for these 2 services so they can interact.
Now, you can publish the NerdDinnerService project, and then upload the package and config file to Azure. We're not done yet though, as we need to tweak the config on the production cloud. If you've followed the instructions on setting up the membership provider, you'll have a config file with the following entries (for use in the development fabric):
So these entries need to be changed for production. Instructions are a bit vague on this, but here's what you need to do:
- First of all, the “AccountName” is whatever you said when you set-up the storage service. If you can't remember, it's the first part of the service URLs you can see in the Azure dashboard for the storage service that read http://<AccountName>.table.core.windows.net
- Then you need the shared key - you can see that on the storage service page too.
- Then you need the URL for the TableStorageEndpoint. You should use https://table.core.windows.net (note the HTTPS which is required if you're NOT allowing Insecure Remote Endpoints as above).
Finish updating the config, save, wait for the package to sort itself out, then run it up and away you go.
You can see my effort at http://mmw.cloudapp.net. DON'T ENTER ANY REAL DATA INTO THE DATABASE (LIKE USERNAMES AND PASSWORDS). I'll take it down in a few days.
I’d like to say “It works on my machine” but then it’s not supposed to. So “It works on my cloud” instead.
