Partie 6 : Code de démarrage de l’application principale

Partie précédente : Dépendances et variables d’environnement

Immédiatement après les import instructions, le code de démarrage de l’application initialise les variables clés utilisées dans les fonctions de gestion des requêtes.

Tout d’abord, l’application crée l’objet d’application Flask, qui sert de base pour définir des itinéraires et gérer les requêtes HTTP entrantes. Ensuite, il récupère l’URL du point de terminaison de l’API tierce à partir d’une variable d’environnement. Cela permet au point de terminaison d’être facilement configuré sans modifier la base de code :

app = Flask(__name__)
app.config["DEBUG"] = True

number_url = os.environ["THIRD_PARTY_API_ENDPOINT"]

Ensuite, il obtient l’objet DefaultAzureCredential , qui est les informations d’identification recommandées à utiliser lors de l’authentification auprès des services Azure. Consultez Authentifier les applications hébergées Azure avec DefaultAzureCredential.

credential = DefaultAzureCredential()

Lors de l’exécution locale, DefaultAzureCredential recherche les variables d’environnement AZURE_TENANT_ID, AZURE_CLIENT_ID, et AZURE_CLIENT_SECRET qui contiennent des informations pour le principal de service que vous utilisez pour le développement local. Lors de l’exécution dans Azure, DefaultAzureCredential utilise par défaut l’identité managée affectée par le système, activée sur l’application. Il est possible de remplacer le comportement par défaut par les paramètres d’application, mais dans cet exemple de scénario, nous utilisons le comportement par défaut.

Le code récupère ensuite la clé d’accès de l’API tierce à partir d’Azure Key Vault. Dans le script d’approvisionnement, le coffre de clés est créé à l’aide az keyvault create, et le secret est stocké avec az keyvault secret set.

La ressource Key Vault elle-même est accessible via une URL, qui est chargée à partir de la variable d’environnement KEY_VAULT_URL .

key_vault_url = os.environ["KEY_VAULT_URL"]

Pour récupérer un secret à partir d’Azure Key Vault, l’application doit créer un objet client qui communique avec le service Key Vault. Étant donné que l’objectif est de lire un secret, l’application utilise la SecretClient classe de la azure.keyvault.secrets bibliothèque. Ce client nécessite deux entrées :

• URL Key Vault : généralement récupérée à partir d’une variable d’environnement
• Objet d’informations d’identification, tel que l’instance DefaultAzureCredential créée précédemment, qui représente l’identité sous laquelle l’application est en cours d’exécution.

keyvault_client = SecretClient(vault_url=key_vault_url, credential=credential)

La création d’un SecretClient objet n’authentifie pas immédiatement l’application. Le client est simplement une construction locale qui stocke l’URL du coffre de clés et l’objet d’informations d’identification. L’authentification et l’autorisation se produisent uniquement lorsque vous appelez une opération via le client, par get_secretexemple, qui génère un appel d’API REST à la ressource Azure.

api_secret_name = os.environ["THIRD_PARTY_API_SECRET_NAME"]
vault_secret = keyvault_client.get_secret(api_secret_name)

# The "secret" from Key Vault is an object with multiple properties. The key we
# want for the third-party API is in the value property. 
access_key = vault_secret.value

Même si l’identité d’une application est autorisée à accéder à Azure Key Vault, elle doit également être explicitement autorisée à effectuer des opérations spécifiques, telles que la lecture des secrets. Sans cette autorisation, un appel à get_secret() échoue, même si l’identité est autrement valide. Pour résoudre ce problème, le script d’approvisionnement définit une stratégie d’accès « get secrets » pour l’application à l’aide de la commande Azure CLI. az keyvault set-policy Pour plus d’informations, consultez l’authentification Key Vault et accorder à votre application l’accès à Key Vault. Ce dernier article montre comment définir une stratégie d’accès à l’aide du portail Azure. (L’article est également écrit pour l’identité managée, mais s’applique également à un principe de service utilisé dans le développement local.)

Enfin, le code de l’application configure l’objet client par le biais duquel il peut écrire des messages dans une file d’attente stockage Azure. L’URL de la file d’attente se trouve dans la variable STORAGE_QUEUE_URLd’environnement.

queue_url = os.environ["STORAGE_QUEUE_URL"]
queue_client = QueueClient.from_queue_url(queue_url=queue_url, credential=credential)

Comme avec Azure Key Vault, l'application utilise un objet client spécifique du kit de développement logiciel Azure (SDK) pour interagir avec Azure Queue Storage. Dans ce cas, il utilise la classe QueueClient de la bibliothèque azure-storage-queue.

Pour initialiser le client, l'application utilise la méthode from_queue_url, en fournissant l'URL entièrement qualifiée de la file d'attente et un objet d'identifiants. Cet objet d’informations d’identification est à nouveau l’instance DefaultAzureCredential créée précédemment, qui représente l’identité sous laquelle l’application s’exécute.

Comme indiqué précédemment dans ce guide, cette autorisation est accordée en affectant le rôle « Contributeur aux données de file d’attente de stockage » à l’identité de l’application , soit une identité managée dans Azure, soit un principal de service pendant le développement local. Cette attribution de rôle est effectuée dans le script d’approvisionnement à l’aide de la commande az role assignment createAzure CLI.

En supposant que tout ce code de démarrage réussit, l’application a toutes ses variables internes en place pour prendre en charge son point de terminaison d’API /api/v1/getcode .

Partie 7 - Point de terminaison d’application principal >>>