(0) exportieren Drucken
Alle erweitern

Einsatz des Azure-Speicheremulators für Entwicklung und Tests

Letzte Aktualisierung: Mai 2014

Der Microsoft Azure-Speicheremulator stellt eine lokale Umgebung bereit, die zu Entwicklungszwecken den Blob-Dienst, Warteschlangendienst und Tabellendienst von Azure emuliert. Sie können mit dem Speicheremulator die Anwendung lokal für die Speicherdienste testen, ohne dass Kosten anfallen.

noteHinweis
Der Speicheremulator ist als Teil des Microsoft Azure SDK verfügbar. Sie können den Speicheremulator auch als eigenständiges Paket herunterladen.

Zum Konfigurieren des Speicheremulator benötigen Sie Administratorrechte auf dem Computer.

ImportantWichtig
Beachten Sie, dass der Zugriff auf die Daten, die in einer bestimmten Version des Speicheremulator erstellt wurden, bei Verwendung einer anderen Version nicht gewährleistet ist. Wenn Sie die Daten langfristig beibehalten müssen, wird empfohlen, diese Daten in einem Azure-Speicherkonto und nicht im Speicheremulator zu speichern.

Es bestehen einige Unterschiede zwischen dem Speicheremulator und den Azure-Speicherdiensten. Weitere Informationen zu diesen Unterschieden finden Sie unter Unterschiede zwischen dem Speicheremulator und den Azure-Speicherdiensten.

Der Speicheremulator verwendet zum Emulieren der Azure-Speicherdienste eine Microsoft® SQL Server™-Instanz und das lokale Dateisystem. Standardmäßig ist der Speicheremulator für eine Datenbank in Microsoft® SQL Server™ 2012 Express LocalDB konfiguriert. Sie können für die Verwaltung der LocalDB-Installation SQL Server Management Studio Express installieren. Der Speicheremulator stellt mithilfe von Windows-Authentifizierung eine Verbindung mit SQL Server oder LocalDB her. Sie können den Speicheremulator mit dem Referenz Befehlszeilentool Speicheremulator für den Zugriff auf eine lokale Instanz von SQL Server statt für den Zugriff auf LocalDB konfigurieren.

Der Speicheremulator unterstützt nur ein einziges festgelegtes Konto und einen bekannten Authentifizierungsschlüssel. Dieses Konto und dieser Schlüssel sind die einzigen Anmeldeinformationen, die für den Speicheremulator verwendet werden dürfen. Sie lauten wie folgt:


Account name: devstoreaccount1
Account key: Eby8vdM02xNOcqFlqUwJPLlmEtlCDXJ1OUzFT50uSRZ6IFsuFq2UVErCz4I6tq/K1SZFPTOtr/KBHBeksoGMGw==
ImportantWichtig
Der vom Speicheremulator unterstützte Authentifizierungsschlüssel ist lediglich für das Testen der Funktionalität des Clientauthentifizierungscodes vorgesehen. Er erfüllt keinerlei Sicherheitszwecke. Sie können Speicherkonto und Schlüssel für die Produktion mit dem Speicheremulator verwenden. Beachten Sie außerdem, dass Sie das Entwicklungskonto nicht mit Produktionsdaten verwenden sollten.

Wählen Sie zum Starten des Azure-Speicheremulators die Schaltfläche Start aus oder drücken Sie die Windows-Taste. Beginnen Sie mit der Eingabe von Azure-Speicheremulator und wählen Sie Azure-Speicheremulator in der Liste der Anwendungen aus.

Falls der Azure-Serveremulator bereits läuft, können Sie den Speicheremulator stattdessen auch starten, indem Sie mit der rechten Maustaste auf das Taskleistensymbol klicken und auf Speicheremulator starten klicken. Weitere Informationen zur Ausführung des Serveremulators finden Sie unter Ausführen einer Windows Azure-Anwendung im Serveremulator.

Beim Start des Speicheremulators wird eine Befehlszeile angezeigt. Mit dieser Eingabeaufforderung können Sie den Speicheremulator starten und beenden, Daten löschen, den aktuellen Status abfragen und den Emulator initialisieren. Weitere Informationen finden Sie unter Referenz Befehlszeilentool Speicheremulator.

Wenn Sie die Befehlszeile schließen, wird der Speicheremulator weiterhin ausgeführt. Wiederholen Sie die obigen Schritte zum Start des Speicheremulators, um die Befehlszeile erneut anzuzeigen.

Wenn Sie Speicheremulator zum ersten Mal ausführen, wird die Speicherumgebung automatisch für Sie initialisiert. Sie können mit dem Speicheremulator-Befehlszeilentool eine andere Datenbankinstanz verweisen oder die vorhandene Datenbank neu initialisieren. Durch die Initialisierung wird in LocalDB eine Datenbank erstellt, und es werden für jeden lokalen Speicherdienst HTTP-Ports reserviert. Für diesen Schritt sind Administratorrechte erforderlich. Ausführliche Informationen finden Sie unter Referenz Befehlszeilentool Speicheremulator.

Die Adressierung einer Ressource in den Azure-Speicherdiensten hängt davon ab, ob sich die Ressource in Azure oder in den Speicheremulator-Diensten befindet. Zum Adressieren einer Speicherressource in Azure und zum Adressieren einer Speicherressource im Speicheremulator wird jeweils ein anderes URI-Schema verwendet. Der Grund für die unterschiedlichen Schemas ist, dass der lokale Computer keine Domänennamen auflöst. Beide URI-Schemas enthalten immer den Kontonamen und die Adresse der angeforderten Ressource.

Im URI-Schema für die Adressierung von Speicherressourcen in Azure ist der Kontoname Teil des URI-Hostnamens, und die adressierte Ressource ist Teil des URI-Pfads. Für den Zugriff auf Speicherressourcen wird das folgende einfache Adressierungsschema verwendet:

<http|https>://<account-name>.<service-name>.core.windows.net/<resource-path>

<account-name> ist der Name des Speicherkontos. <service-name> ist der Name des Diensts, auf den Zugriff erfolgt, und <resource-path> ist der Pfad zu der angeforderten Ressource. Die folgende Liste enthält das URI-Schema für jeden der Speicherdienste:

  • BLOB-Dienst: <http|https>://<Kontoname>.blob.core.windows.net/<Ressourcenpfad>

  • Warteschlangendienst: <http|https>://<Kontoname>.queue.core.windows.net/<Ressourcenpfad>

  • Tabellendienst: <http|https>://<Kontoname>.table.core.windows.net/<Ressourcenpfad>

Beispielsweise kann für den Zugriff auf ein BLOB in der Cloud die folgende Adresse verwendet werden:

http://myaccount.blob.core.windows.net/mycontainer/myblob.txt
noteHinweis
Sie können auch einem Speicherkonto in der Cloud einen benutzerdefinierten Domänennamen zuordnen und diesen benutzerdefinierten Domänennamen zum Adressieren von Speicherressourcen verwenden. Weitere Informationen finden Sie unter Registering Custom Domain Names for Blob Resources.

Im Speicheremulator ist der Kontoname Teil des URI-Pfads, da der lokale Computer Domänennamen nicht auflöst. Das URI-Schema für eine im Speicheremulator ausgeführte Ressource weist das folgende Format auf:

http://<local-machine-address>:<port>/<account-name>/<resource-path>

Das folgende Format wird zum Adressieren von Ressourcen verwendet, die im Speicheremulator ausgeführt werden:

  • BLOB-Dienst: http://127.0.0.1:10000/<Kontoname>/<Ressourcenpfad>

  • Warteschlangendienst: http://127.0.0.1:10001/<Kontoname>/<Ressourcenpfad>

  • Tabellendienst: http://127.0.0.1:10002/<Kontoname>/<Ressourcenpfad>

Beispielsweise kann für den Zugriff auf ein BLOB im Speicheremulator die folgende Adresse verwendet werden:

http://127.0.0.1:10000/myaccount/mycontainer/myblob.txt
noteHinweis
HTTPS ist kein zulässiges Protokoll für Adressen von lokalen Speicherressourcen.

Ab Version 3.1 unterstützt das Speicheremulator-Konto georedundante Replikation mit Lesezugriff (RA-GRS). Für Speicherressourcen in der Cloud und im lokalen Emulator können Sie auf den sekundären Speicherort zugreifen, indem Sie -secondary an den Kontonamen anfügen. Beispielsweise kann die folgende Adresse für den Zugriff auf ein BLOB mithilfe des sekundären Speicherorts mit Lesezugriff verwendet werden:

http://127.0.0.1:10000/myaccount-secondary/mycontainer/myblob.txt

noteHinweis
Für programmgesteuerten Zugriff auf den sekundären Speicherort mit dem Speicheremulator verwenden Sie die Storage Client Library für .NET, Version 3.2 oder höher. Ausführliche Informationen finden Sie unter Referenz zur Speicherclientbibliothek.

Siehe auch

Anzeigen:
© 2014 Microsoft