Windows Azure: Einführung in die Laufzeitumgebung

Bei der Entwicklung von Anwendungen für eine neue Plattform wie Windows Azure sind einige Dinge zu beachten. Hier berichtet ein Entwickler von seinen Erfahrungen.

Jose Barreto

Neulich habe ich gelernt, wie ich eine Windows Azure-Anwendung entwickeln, testen und bereitstellen kann. Ich hatte schon viel über Windows Azure gehört und einige Erfahrungsberichte gelesen, wollte dann aber meine eigenen Erfahrungen machen und das Gelesene selbst überprüfen. Die Veröffentlichung von Visual Studio 2010 war der Anstoß, den ich noch brauchte.

In diesem Artikel beschreibe ich die Erstellung und Bereitstellung einer Beispielanwendung. Das ist immer eine gute Möglichkeit, sich mit neuer Technologie vertraut zu machen, und außerdem war ich so gezwungen, den gesamten Lebenszyklus einer Anwendung in Windows Azure nachzuvollziehen.

Hilfreich für mich war, dass ich bereits früher ASP.NET-Anwendungen entwickelt habe. Eine Windows Azure-Anwendung baut auf derselben Architektur auf, also Webrollen (Frontend für Web) und Workerrollen (Backend für Dienste). Auch das wichtigste Tool bei der Entwicklung von Windows Azure-Anwendungen und herkömmlichen ASP.NET-Anwendungen ist dasselbe: Visual Studio. Ich hatte bereits die letzte Version von Visual Studio 2010 auf meinem Windows 7-Computer installiert und IIS als optionale Windows 7-Komponente hinzugefügt.

Außer Visual Studio 2010 und IIS hatte ich die Windows Azure-Tools heruntergeladen, sodass mir zusätzliche Vorlagen für die Windows Azure-Entwicklung zur Verfügung standen. Ich wollte mehr über die Umgebung wissen, in der Windows Azure-Anwendungen ausgeführt werden. Mir war zwar schon bekannt, dass es virtuelle Computer sind, die unabhängig von bestimmten Konfigurationsdetails für andere Anwendungen funktionieren, aber ich war neugierig, wie sie bei Windows Azure implementiert sind. Aufgrund meiner Erfahrung mit IT-Infrastrukturen interessiere ich mich für den Hintergrund dieser Art der Bereitstellung.

Ich entschloss mich also dazu, eine Anwendung zu schreiben, die mir Informationen über das Dateisystem des Computers liefern würde, auf dem sie ausgeführt wird. Ganz einfache Daten, beispielsweise vorhandene Treiber und deren Merkmale, wie Typ, Dateisystem, Gesamtgröße und verfügbarer Speicher. Außerdem sollten Ordner und Dateien abgefragt werden, um zu verstehen, was sich an welchen Orten befindet. Abbildung 1 zeigt das Ergebnis.

Figure 1 A sample file system report application created in Windows Azure.

Abbildung 1 Eine in Windows Azure erstellte Beispielanwendung für Berichte über das Dateisystem

Keine komplizierte Angelegenheit, wie Sie sehen, aber die Anwendung ermöglicht es, die Entwicklung zu verstehen, die Bereitstellung nachzuvollziehen und die Tools für die Windows Azure-Laufzeitumgebung zu nutzen.

C# für die Cloud

Das Erstellen der Anwendung war sehr einfach. Ich habe auf Basis von C# ein neues Projekt erstellt und das Cloud-Projekt ausgewählt. Aus Gründen der Einfachheit habe ich für mein Cloud-Dienst-Projekt eine einzelne ASP.NET-Webrolle verwendet.

Dann habe ich einige Steuerelemente gezogen, Code hinzugefügt und mit dem Testen begonnen. Da der Entwicklungsprozess lokal ausgeführt wird, ist zu diesem Zeitpunkt nicht einmal ein Windows Azure-Konto erforderlich. Es wurde kein Windows Azure-Speicher verwendet, d. h. es gab nur eine Webrolle ohne externe Abhängigkeiten. Nicht unbedingt eine sehr nützliche Anwendung, aber mein Ziel war es, für den Anfang eine Art glorreiches „Hallo Welt“ zu erstellen.

Da ich auf das komplette Microsoft .NET-Framework zugreifen konnte, was das Schreiben des Codes kein Problem. Zum Abrufen der Treiberinformationen habe ich z. B. das System.IO-Namespace verwendet.

protected void btnDrives_Click(object sender, EventArgs e)
 {
   DriveInfo[] diAll = DriveInfo.GetDrives();
   string strDrive = "";
   foreach (DriveInfo diOne in diAll)
    {
       strDrive = "Drive " + diOne.Name + " Type:" + diOne.DriveType.ToString();
      if (diOne.IsReady)
       {
          strDrive = strDrive + " Volume:" + diOne.VolumeLabel + " FS:" + diOne.DriveFormat.ToString() + " Total:" + diOne.TotalSize.ToString() + " Free:" + diOne.AvailableFreeSpace.ToString();
       }
       txtAdd(strDrive);
    }
 }

Abgesehen davon, dass ich Visual Studio als Administrator ausführen musste, verlief die Entwicklung und das lokale Debuggen der Anwendung sehr unspektakulär. Beim Ausführen meiner Anwendung (siehe Abbildung 2) wurde die lokale Simulationsumgebung von Windows Azure automatisch von Visual Studio gestartet. Ich konnte Haltepunkte festlegen, den Code Schritt für Schritt überwachen usw. Keine Überraschungen also.

Figure 2 Here’s how my application looked when it ran through the Windows Azure Simulation Environment.

Abbildung 2 So sah die Anwendung in der Simulationsumgebung von Windows Azure aus.

Bereitstellen von Azure-Anwendungen

Für mich als Anfänger in Windows Azure stellte es die größte Schwierigkeit dar, zu wissen, was genau ich für die Bereitstellung meiner Anwendung benötigte. Wenn Sie Ihren Dienst in der Webbenutzeroberfläche von Windows Azure erstellt haben, kommen Sie an einen Punkt, an dem Sie die Anwendung bereitstellen können.

Wenn Sie auf die Schaltfläche „Deploy“ klicken, werden Sie aufgefordert, zwei Dateien (eine für das Anwendungspaket und eine für die Konfigurationseinstellungen) sowie einen Namen für die Dienstbereitstellung anzugeben. Das war es eigentlich schon, was Tipps zur Erstellung angeht.

Nach einiger Zeit in der Visual Studio-Umgebung war mir nicht mehr klar, wie ich diese Dateien erstelle bzw. welche Dateierweiterungen sie haben müssten. Jetzt musste ich zum ersten Mal in die Dokumentation von Windows Azure schauen. Bis dahin hatte ich einfach improvisiert. Wie sich herausstellte, musste ich mit der rechten Maustaste auf das Cloud-Projekt klicken, um die Option „Publish...“ zu finden und ein Paket für Windows Azure zu erstellen.

Dabei werden die zwei erforderlichen Dateien erstellt, ein Cloud-Dienstpaket (.cspkg) und eine Cloud-Dienstkonfiguration (.cscfg). Nach dem Klicken auf die Option „Publish...“ wird ein Windows Explorer-Fenster mit dem richtigen Ordner geöffnet (siehe Abbildung 3) sowie ein Internet Explorer-Fenster mit der richten Windows Azure-URL.

Figure 3 The Windows Explorer window opened from the “Publish-…” option.

Abbildung 3 Das über die Option „Publish...“ geöffnete Windows Explorer-Fenster

Nach den erforderlichen Eingaben wurde der Dienst innerhalb von Sekunden veröffentlicht. Anschließend wurde die Anwendung durch Klicken auf „Run“ bereitgestellt. Das ist der Moment, in dem die virtuelle Maschine (VM) mit der ausgeführten Anwendung bereitgestellt und gestartet wird. Dieser Schritt dauert einige Minuten.

Ausführen des Diensts

Der Status des Diensts änderte sich von „Initializing“ in „Busy“ und dann „Ready“. Die Bereitstellung war damit abgeschlossen, und der Dienst konnte ganz einfach durch Klicken auf die Website-URL „http://servicename.cloudapp.net“ ausgeführt werden.

Nun war ich bereit, einige Merkmale der Windows Azure-VM, auf der mein Dienst ausgeführt wurde, genauer zu betrachten. Zuerst habe ich die Laufwerke des Systems aufgelistet. Es stellte sich heraus, dass die VM über drei Laufwerke (C:, D: und E:) verfügte, wie in Abbildung 1 gezeigt. Dann öffnete ich mithilfe der Anwendung auf jedem Laufwerk bestimmte Ordner und Dateien. Nach einer Weile kam ich zu einem Ergebnis, was die drei Laufwerke betrifft, das in Abbildung 4 zu sehen ist.

Abbildung 4 Verteilung des Speichers auf die drei Laufwerke

Zur Größe des Speichers, der pro VM festgelegt werden kann, fand ich entsprechende Dokumentation. Die Standardgröße (klein) bietet einen lokalen Speicher von 250 GB. Das war die Größe meiner VM. Sie können aber auch größere lokale Speicher von 500 GB, 1000 GB und 2000 GB wählen.

Was ich allerdings nicht gefunden habe, war Dokumentation zur Aufteilung zwischen den drei Laufwerken bzw. zu den drei Laufwerken an sich. Ich kann nur sagen, dass die Zahlen in Abbildung 4 für meine Anwendungsbereitstellung zu dieser Zeit galten.

Wenn Sie planen, in Ihrer Anwendung lokalen temporären Speicher zu verwenden, sollten Sie sich die Dokumentation für lokale Speicherressourcen ansehen. Es sieht so aus, als würden sich die lokalen Speicherressourcen auf Laufwerk C: befinden, aber Sie sollten den genauen lokalen Pfad mithilfe der API suchen.

Wenn Sie dauerhaften Speicher benötigen, sollten Sie die vielen Optionen von Windows Azure genauer betrachten, z. B. Blobs, Tabellen, Warteschlangen, Drivesand SQL Azure-Datenbanken. Der Zugriff darauf erfolgt über APIs, und die Speicherung erfolgt unabhängig vom lokalen Speicher der Windows Azure-VM.

Grundlagen zum Staging

Eine letzte Sache, auf die ich eingehen möchte, ist die Bereitstellung zusätzlicher Versionen der Anwendung. Windows Azure ermöglicht das Speichern der neuen Version in einem eigenen „Stagingbereich“. Auf diese Weise können Sie die neu bereitgestellte Version mit einer temporären URL ausführen und testen, während die ältere Version noch mit der Haupt-URL ausgeführt wird.

Wenn Sie mit der Version zufrieden sind, können Sie einfach beide Umgebungen tauschen. Das geht ganz schnell, da zu diesem Zeitpunkt beide Umgebungen vollständig bereitgestellt sind und Sie einfach die URLs vertauschen. Falls es Probleme mit der neuen Version gibt, können Sie jederzeit wieder zur ursprünglichen Version wechseln.

Verpackung für die Cloud

Wenn Sie sich mit ASP.NET auskennen, ist das Erstellen von Windows Azure-Anwendungen keine große Sache, sofern Sie einige Besonderheiten verstanden haben. Ich habe viel über das Verpacken von Anwendungen in Windows Azure gelernt und auch die Bereitstellungsschritte besser verstanden.

Die Bereitstellung meiner ersten Windows Azure-Anwendung ist mir gelungen, und bei diesem Prozess habe ich mehr über die Windows Azure-Laufzeit erfahren. Das Konzept der verschiedenen Laufwerke für die Windows Azure-VMs sowie die Einzelheiten der VM-Bereitstellung sind mir klar geworden. Zwar ist es zum Bereitstellen von Anwendungen nicht unbedingt erforderlich, die Details zu verstehen, aber als Entwickler fühlt man sich dann auf jeden Fall sicherer.

Jose Barreto Photo

Jose Barretogehört als leitender Programmmanager dem File Server Team an, das Teil der Microsoft Server and Cloud Division ist. 1989 schloss er sein Informatikstudium an der Universidade Federal do Ceara in Brasilien ab und zog 2000 in die USA um. Barreto arbeitet seit 2002 bei Microsoft in Kalifornien und wechselte 2007 zum Campus in Redmond.

Verwandter Inhalt