Exemples de code Stockage Blob Azure utilisant des bibliothèques de client Python version 2.1

Article
04/17/2023

Cet article présente des exemples de code utilisant la version 2.1 de la bibliothèque de client Stockage Blob Azure pour Python.

Le 31 mars 2023, nous avons mis fin à la prise en charge des bibliothèques de Kit de développement logiciel (SDK) Azure qui ne respectent pas les instructions actuelles concernant le SDK Azure. Les nouvelles bibliothèques du Kit de développement logiciel (SDK) Azure sont régulièrement mises à jour pour offrir des expériences cohérentes et renforcer votre posture de sécurité. Nous vous recommandons une transition vers les nouvelles bibliothèques du Kit de développement logiciel Azure pour profiter des nouvelles fonctionnalités et des correctifs de sécurité.

Bien que les anciennes bibliothèques puissent toujours être utilisées au-delà du 31 mars 2023, elles ne seront plus prises en charge officiellement et mises à jour par Microsoft. Pour plus d’informations, consultez l’annonce concernant l’arrêt de la prise en charge.

Générer une application hautement disponible avec le Stockage Blob

Article lié : Tutoriel : générer une application hautement disponible avec le Stockage Blob

Télécharger l’exemple

Téléchargez l’exemple de projet et extrayez (décompressez) le fichier storage-python-circuit-breaker-pattern-ha-apps-using-ra-grs.zip. Vous pouvez aussi utiliser git pour télécharger une copie de l’application dans votre environnement de développement. L’exemple de projet contient une application Python de base.

git clone https://github.com/Azure-Samples/storage-python-circuit-breaker-pattern-ha-apps-using-ra-grs.git

Configurer l'exemple

Dans l’application, vous devez fournir les informations d’identification de votre compte de stockage. Vous pouvez stocker ces informations dans des variables d’environnement sur la machine locale exécutant l’application. Suivez l’un des exemples ci-dessous, en fonction de votre système d’exploitation, pour créer les variables d’environnement.

Dans le portail Azure, accédez à votre compte de stockage. Sélectionnez Clés d’accès sous Paramètres dans votre compte de stockage. Collez les valeurs Nom du compte de stockage et Clé dans les commandes suivantes, en remplaçant les espaces réservés <youraccountname> et <youraccountkey>. Cette commande enregistre les variables d’environnement sur la machine locale. Dans Windows, la variable d’environnement n’est pas disponible tant que vous n’avez pas rechargé l’invite de commandes ou l’interpréteur de commandes que vous utilisez.

Linux

export accountname=<youraccountname>
export accountkey=<youraccountkey>

Windows

setx accountname "<youraccountname>"
setx accountkey "<youraccountkey>"

Exécuter l’application console

Pour exécuter l’application sur un terminal ou une invite de commandes, accédez au répertoire circuitbreaker.py, puis entrez python circuitbreaker.py. L’application charge l’image HelloWorld.png de la solution dans le compte de stockage. L’application vérifie que l’image s’est répliquée sur le point de terminaison RA-GZRS secondaire. Elle commence ensuite à télécharger l’image jusqu’à 999 fois. Chaque lecture est représentée par un P ou un S. P représente le point de terminaison principal et S le point de terminaison secondaire.

Capture d’écran de l’application console en cours d’exécution.

Dans l’exemple de code, la méthode run_circuit_breaker dans le fichier circuitbreaker.py est utilisée pour télécharger une image à partir du compte de stockage à l’aide de la méthode get_blob_to_path.

La fonction Nouvelle tentative de l’objet de stockage est définie sur une stratégie linéaire de nouvelles tentatives. La fonction Nouvelle tentative indique s’il faut renouveler une requête et spécifie le nombre de secondes à attendre avant de renouveler la requête. Définissez la valeur true pour retry_to_secondary si la requête doit être renvoyée à la base de données secondaire en cas d’échec de la requête à la base de données principale. Dans l’exemple d’application, une stratégie personnalisée de nouvelles tentatives est définie dans la fonction retry_callback de l’objet de stockage.

Avant le téléchargement, l’objet du service retry_callback et la fonction response_callback sont définis. Ces fonctions définissent les gestionnaires d’événements qui se déclenchent quand un téléchargement se termine correctement ou si un téléchargement échoue et effectue une nouvelle tentative.

Comprendre l’exemple de code

Gestionnaire d’événements de nouvelle tentative

Le Gestionnaire d’événements retry_callback est appelé quand le téléchargement de l’image échoue et qu’une nouvelle tentative est définie. Si le nombre maximal de tentatives définies dans l’application est atteint, le paramètre LocationMode de la requête passe à SECONDARY. Ce paramètre oblige l’application à essayer de télécharger l’image à partir du point de terminaison secondaire. Cette configuration réduit le temps nécessaire pour demander l’image puisque les nouvelles tentatives ne sont pas indéfiniment effectuées sur le point de terminaison principal.

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.")

Gestionnaire d’événements de demande terminée

Le Gestionnaire d’événements response_callback est appelé quand le téléchargement de l’image est réussi. Si l’application utilise le point de terminaison secondaire, elle continue à utiliser ce point de terminaison jusqu’à 20 fois. Au bout de 20 fois, l’application redéfinit le paramètre LocationMode sur PRIMARY et réessaie le point de terminaison principal. Si une requête réussit, l’application poursuit la lecture à partir du point de terminaison principal.

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