Azure Blob Storage-Codebeispiele mit Python-Clientbibliotheken der Version 2.1
Dieser Artikel zeigt Codebeispiele, welche die Version 2.1 der Azure Blob Storage-Clientbibliothek für Python verwenden.
Am 31. März 2023 haben wir die Unterstützung für Azure SDK-Bibliotheken eingestellt, die nicht den aktuellen Azure SDK-Richtlinien entsprachen. Die neuen Azure SDK-Bibliotheken werden regelmäßig aktualisiert, um konsistente Erfahrungen zu ermöglichen und Ihren Sicherheitsstatus zu stärken. Es wird empfohlen, auf die neuen Azure SDK-Bibliotheken umzusteigen, um die neuen Funktionen und wichtigen Sicherheitsupdates zu nutzen.
Obwohl die älteren Bibliotheken noch über den 31. März 2023 hinaus verwendet werden können, erhalten sie keinen offiziellen Support und keine Updates mehr von Microsoft. Weitere Informationen finden Sie in der Ankündigung der Supporteinstellung.
Erstellen einer hochverfügbaren App mit Blob Storage
Laden Sie das Beispielprojekt herunter, und extrahieren (entzippen) Sie die Datei „storage-python-circuit-breaker-pattern-ha-apps-using-ra-grs.zip“. Sie können auch Git verwenden, um eine Kopie der Anwendung in Ihre Entwicklungsumgebung herunterzuladen. Das Beispielprojekt enthält eine einfache Python-Anwendung.
git clone https://github.com/Azure-Samples/storage-python-circuit-breaker-pattern-ha-apps-using-ra-grs.git
Das Beispiel konfigurieren
Sie müssen in der Anwendung Ihre Anmeldeinformationen für das Speicherkonto angeben. Sie können diese Informationen in einer Umgebungsvariablen auf dem lokalen Computer speichern, auf dem die Anwendung ausgeführt wird. Befolgen Sie je nach Betriebssystem die Schritte für eines der unten angegebenen Beispiele, um die Umgebungsvariablen zu erstellen.
Navigieren Sie im Azure-Portal zu Ihrem Speicherkonto. Wählen Sie in Ihrem Speicherkonto unter Einstellungen die Option Zugriffsschlüssel aus. Fügen Sie die Werte Speicherkontoname und Schlüssel in die folgenden Befehle ein, und ersetzen Sie dabei die Platzhalter <youraccountname> und <youraccountkey>. Mit diesem Befehl werden die Umgebungsvariablen auf dem lokalen Computer gespeichert. Unter Windows ist die Umgebungsvariable erst verfügbar, wenn Sie die Eingabeaufforderung oder die verwendete Shell neu laden.
Linux
export accountname=<youraccountname>
export accountkey=<youraccountkey>
Windows
setx accountname "<youraccountname>"
setx accountkey "<youraccountkey>"
Ausführen der Konsolenanwendung
Navigieren Sie zum Ausführen der Anwendung in einem Terminal oder über eine Eingabeaufforderung zum Verzeichnis circuitbreaker.py, und geben Sie python circuitbreaker.py
ein. Die Anwendung lädt das Bild HelloWorld.png Bild aus der Projektmappe in das Speicherkonto hoch. Anschließend wird von der Anwendung überprüft, ob das Bild im sekundären RA-GZRS-Endpunkt repliziert wurde. Das Bild wird dann von der Anwendung maximal 999 Mal heruntergeladen. Jeder Lesevorgang wird dabei durch ein P oder ein S dargestellt. Während P für den primären Endpunkt steht, repräsentiert S den sekundären Endpunkt.
Im Beispielcode wird die run_circuit_breaker
-Methode in der Datei circuitbreaker.py
verwendet, um mit der get_blob_to_path-Methode ein Bild aus dem Speicherkonto herunterzuladen.
Die retry-Funktion des Storage-Objekts wird auf eine lineare Wiederholungsrichtlinie festgelegt. Mit der retry-Funktion wird ermittelt, ob für eine Anforderung ein Wiederholungsversuch durchgeführt werden soll. Außerdem wird angegeben, wie viele Sekunden lang gewartet werden soll, bevor der Versuch gestartet wird. Legen Sie den Wert retry_to_secondary auf „true“ fest, wenn für die Anforderung ein Wiederholungsversuch für den sekundären Endpunkt durchgeführt werden soll, falls die erste Anforderung an den primären Endpunkt fehlschlägt. In der Beispielanwendung wird in der retry_callback
-Funktion des Storage-Objekts eine benutzerdefinierte Wiederholungsrichtlinie definiert.
Vor dem Herunterladen werden die Funktionen retry_callback und response_callback für das Dienstobjekt definiert. Mit diesen Funktionen werden die Ereignishandler definiert, die aufgerufen werden, wenn ein Download erfolgreich abgeschlossen wurde oder wenn ein Download fehlschlägt und erneut versucht wird, den Download durchzuführen.
Verstehen des Beispielcodes
Ereignishandler für erneuten Downloadversuch
Der Ereignishandler retry_callback
wird aufgerufen und für einen Neuversuch festgelegt, wenn es beim Herunterladen des Bilds zu einem Fehler kommt. Wenn die maximale Anzahl von Wiederholungen erreicht ist, die in der Anwendung definiert ist, wird die LocationMode-Eigenschaft der Anforderung in SECONDARY
geändert. Durch diese Einstellung versucht die Anwendung, das Bild vom sekundären Endpunkt herunterzuladen. Diese Konfiguration reduziert die Anforderungszeit für das Bild, da die Anzahl der wiederholten Anforderungen an den primären Endpunkt begrenzt ist.
def retry_callback(retry_context):
global retry_count
retry_count = retry_context.count
sys.stdout.write(
"\nRetrying event because of failure reading the primary. RetryCount= {0}".format(retry_count))
sys.stdout.flush()
# Check if we have more than n-retries in which case switch to secondary
if retry_count >= retry_threshold:
# Check to see if we can fail over to secondary.
if blob_client.location_mode != LocationMode.SECONDARY:
blob_client.location_mode = LocationMode.SECONDARY
retry_count = 0
else:
raise Exception("Both primary and secondary are unreachable. "
"Check your application's network connection.")
Ereignishandler für abgeschlossene Anforderung
Der Ereignishandler response_callback
wird aufgerufen, wenn der Download des Bilds erfolgreich ist. Wenn die Anwendung den sekundären Endpunkt verwendet, stellt die Anwendung weiterhin bis zu 20 Anforderungen an diesen Endpunkt. Nach 20 Anforderungen legt die Anwendung für die LocationMode-Eigenschaft auf den Wert PRIMARY
zurück und versucht erneut, Anforderungen an den primären Endpunkt zu senden. Wenn eine Anforderung erfolgreich ist, liest die Anwendung weiterhin aus dem primären Endpunkt.
def response_callback(response):
global secondary_read_count
if blob_client.location_mode == LocationMode.SECONDARY:
# You're reading the secondary. Let it read the secondary [secondaryThreshold] times,
# then switch back to the primary and see if it is available now.
secondary_read_count += 1
if secondary_read_count >= secondary_threshold:
blob_client.location_mode = LocationMode.PRIMARY
secondary_read_count = 0