Die Windows Azure Plattform gibt es schon eine ganze Weile, allerdings bin ich bislang noch nicht wirklich dazu gekommen eine bestehende Webanwendung nach Azure zu migrieren. Ich versuche dies mal Schritt für Schritt zu dokumentieren. Die ersten Schritte sind jedenfalls recht einfach: WebApp Package bauen und auf SQLAzure gehen (die einfachste Möglichkeit).
"Abgrenzung” - mein Szenario
Die Web Anwendung die bei diesem Blogpost als Grundlage diente, war eine ASP.NET MVC 2 Applikation, welche einen SQL Server als Datenbank benutzte. Irgendwelche Windows Dienste, Services Bus-Geschichten oder anderer Konstrukte waren nicht teil davon. Ich wollte einfach, dass im simpelsten Fall meine WebApp mit einer Instanz auf Azure läuft. Das ist noch nicht der große Wurf, aber ein erster Schritt ;)
Was braucht man?
Man braucht das aktuelle Windows Azure SDK (ich hab die June 2010 Version genommen - ist das die aktuelle? ;) ) Dann benötigt man noch ein SQL Management Studio Express und falls man ein großen SQL Server auf seinem Rechner installiert hat, der sollte sich noch das hier durchlesen.
DemoSolution
Wir haben eine Standard MVC App, welche auch keine Referenzen zu irgendwelchen Azure Assemblies hat. Dazu haben wir noch im SQL Server irgendwo unsere Datenbank. Zum SQL Server komm ich aber noch später.
Cloud Projekt hinzufügen
Nach der Installation des Windows Azure SDKs findet man einen neuen Projekttyp:
Im nachfolgenden Fenster könnte man gleich ein Projekt neu erzeugen, allerdings gehen wir von unserem Szenario aus: Wir haben schon eine WebApp.
Also einfach auf "OK” klicken.
Nun das bestehende Projekt hinzufügen
Über das Kontextmenü können wir z.B. eine bestehende Web Anwendung als Web Role hinzufügen
Debugging
Man kann nun ganz normal das MVC Projekt starten, aber auch das Cloud Projekt. Beim Cloud Projekt gehen wird die Anwendung auf der lokalen Cloud-Dev-Plattform gehostet:
Config Anpassen - DiagnosticsConnectionString
Für die Logausschriften in der lokalen Umgebung wird ein Config Eintrag in den Cloud configs gemacht. Dieser muss unbedingt vor dem Deployment entfernt werden.
Meine ServiceConfiguration.cscfg
<?xml version="1.0"?>
<ServiceConfiguration serviceName="MoveToAzure.WebHost" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration">
<Role name="MoveToAzure.WebApp">
<Instances count="1" />
<ConfigurationSettings />
</Role>
</ServiceConfiguration>Meine ServiceDefinition.csdef
<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="MoveToAzure.WebHost" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
<WebRole name="MoveToAzure.WebApp">
<InputEndpoints>
<InputEndpoint name="HttpIn" protocol="http" port="80" />
</InputEndpoints>
<ConfigurationSettings />
</WebRole>
</ServiceDefinition>Beide "ConfigurationSettings” sind gelerrt. Ansonsten würde unser Projekt nicht in der Cloud starten.
MVC Anpassungen
Die Cloud kennt momentan noch nicht die MVC2 DLL, daher müssen wir dort noch "Copy Local” einstellen:
Ansonsten lässt sich auch in diesem Fall die WebApp nicht starten!
Cloud - publish...
Wer eine SQL Datenbank einsetzt und auf SQL Azure umschwenken will, sollte den Teil weiter unten zuerst lesen, da man nach dem Deployment nicht mehr auf die web.config zugreifen kann. Hierbei müsste man noch die WebApp etwas anpassen, damit man solche Sachen auch komfortabler erreichen kann. Aber wir machen mal mit dem ganz simplen Fall "ohne DB” weiter:
Über das Kontextmenü des Cloud-Projekts können wir uns ein Package bauen lassen:
Wichtig zu erwähnen: Die Configuration für den Buildvorgang sollte möglichst auf Release sein.
Ab in die richtige Cloud
Über http://windows.azure.com legt man sich ein neuen Service an.
Dann wählt man sich einen "Hosted Service”. Der andere ist nur "Speicherplatz” für Tabellen, Queues und Blobs. Erst einmal nicht interessant für uns.
In diesem Screen gibt man dem Service einen Namen und evtl. eine Beschreibung.
Hier muss man nun etwas aufpassen. Wenn man im kleinen Maßstab anfängt, sollte man darauf achten, dass z.B. die SQLAzure Instanz in derselben Region wie die WebApp ist. Ansonsten vergibt man hier noch eine Domain für den Dienst.
Danach kommt man auf eine Seite, wo man den momentan Status der Produktionsumgebung bzw. Stagingumgebung sieht:
Ein klick auf "Deploy” bringt uns da hin. Dort die vorher gebauten Package Dateien auswählen und hochladen:
Nach dem erfolgreichen hochladen muss noch "Run” gedrückt werden. Dann kann es noch ein paar Minuten dauern, bis die WebApp in den Rechenzentren von Microsoft hochgefahren ist.
Nach dem Klick auf "Run”:
Jetzt starten die Instanzen. Dieser Vorgang kann aber gut 5 bis 10 Minuten in Anspruch nehmen. Als erstes ist die Init Phase, danach folgt eine kurze Busy Phase und erst dann wird das Icon auf Grün mit "Ready”. Nun funktioniert es. Falls man die Änderungen von oben (DiagnosticsConnectionString & MVC DLL) nicht angepasst hat, wird die WebApp nicht starten und ewig auf "Busy” bleiben und dann irgendwann stoppen. Es gibt da keine schönen Fehlermeldungen :(
Daher hab ich auch das HowTo geschrieben ;)
SQL Azure
Wer eine MS SQL Datenbank benutzt, kann auf dem Azure Service Portal sich auch eine SQLAzure Datenbank anlegen. Dort wird auch ein ConnectionString angezeigt, dieser kann dann z.B. ganz normal im SQL Management Studio verwendet werden um sich zur Datenbank zu connecten. Als Schutz muss man auch seine IP mit angeben, dies ist aber soweit alles selbsterklärend.
Wahrscheinlich gibt es viele Wege, wie man die Daten von A nach B bekommt. Ich habe mir aber ein SQL Script generieren lassen, hilfreich waren da auch diese beiden Parameter:
Zu dem Dialog kommt man, wenn man auf eine SQL DB geht und dort "Rechtsklick” "Tasks” "Generate Scripts...” aufruft.
Danach das SQL per Copy & Paste über das Management Studio nach SQL Azure und fertig :)
Dann noch den ConnectionString in der WebApp anpassen und nun kann man mal schauen, ob es noch funktioniert ;)
Fazit
Die WebApp samt DB sollte erst einmal auf Azure nun stabil laufen. Allerdings gibt es noch diverse Probleme zu lösen, darunter z.B. wie man die Session oder den Cache unter Azure nutzen könnte um so eine richtig skalierbare Anwendung zu bauen. Für den Anfang passt das aber erst mal ;)
