Teil 6: Hauptstartcode der App

Vorheriger Teil: Abhängigkeiten und Umgebungsvariablen

Unmittelbar nach den import Anweisungen initialisiert der Startcode der App schlüsselvariablen, die in den Anforderungsverarbeitungsfunktionen verwendet werden.

Zunächst erstellt die Anwendung das Flask-App-Objekt, das als Grundlage für die Definition von Routen und die Behandlung eingehender HTTP-Anforderungen dient. Als Nächstes ruft sie die API-Endpunkt-URL eines Drittanbieters aus einer Umgebungsvariable ab. Mit diesem Ansatz können Sie den Endpunkt ganz einfach konfigurieren, ohne die Codebasis zu ändern:

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

number_url = os.environ["THIRD_PARTY_API_ENDPOINT"]

Als Nächstes ruft es das DefaultAzureCredential-Objekt ab, das das für die Authentifizierung mit Azure-Diensten empfohlene Anmeldeinformationsobjekt ist. Siehe Authentifizieren von von Azure gehosteten Anwendungen mit DefaultAzureCredential.

credential = DefaultAzureCredential()

Wenn DefaultAzureCredential lokal ausgeführt wird, sucht es nach den Umgebungsvariablen AZURE_TENANT_ID, AZURE_CLIENT_ID und AZURE_CLIENT_SECRET, die Informationen für das Dienstprinzipal enthalten, das Sie für die lokale Entwicklung verwenden. Wenn sie in Azure ausgeführt wird, DefaultAzureCredential wird standardmäßig die auf der App aktivierte vom System zugewiesene verwaltete Identität verwendet. Sie können das Standardverhalten mit Anwendungseinstellungen außer Kraft setzen, aber in diesem Beispielszenario wird das Standardverhalten verwendet.

Der Code ruft als Nächstes den Zugriffsschlüssel der Drittanbieter-API aus Azure Key Vault ab. Im Bereitstellungsskript wird der Schlüsseltresor mithilfe von az keyvault create erstellt, und das Geheimnis wird mithilfe von az keyvault secret set gespeichert.

Auf die Key Vault-Ressource selbst wird über eine URL zugegriffen, die aus der KEY_VAULT_URL Umgebungsvariable geladen wird.

key_vault_url = os.environ["KEY_VAULT_URL"]

Um einen geheimen Schlüssel aus Azure Key Vault abzurufen, muss die Anwendung ein Clientobjekt erstellen, das mit dem Key Vault-Dienst kommuniziert. Da das Ziel darin besteht, einen geheimen Schlüssel zu lesen, verwendet die App die SecretClient Klasse aus der azure.keyvault.secrets Bibliothek. Für diesen Client sind zwei Eingaben erforderlich:

• Die Schlüsseltresor-URL – in der Regel aus einer Umgebungsvariablen abgerufen
• Ein Anmeldeinformationsobjekt, wie die zuvor erstellte Instanz DefaultAzureCredential, die die Identität repräsentiert, unter der die App betrieben wird.

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

Durch das Erstellen eines SecretClient Objekts wird die Anwendung nicht sofort authentifiziert. Der Client ist einfach ein lokales Konstrukt, das die Key Vault-URL und das Anmeldeinformationsobjekt speichert. Die Authentifizierung und Autorisierung erfolgen nur, wenn Sie über den Client einen Vorgang aufrufen, wie z.B. get_secret, der einen REST-API-Aufruf an die Azure-Ressource generiert.

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

Auch wenn die Identität einer Anwendung für den Zugriff auf Azure Key Vault autorisiert ist, muss sie auch explizit zum Ausführen bestimmter Vorgänge autorisiert sein , z. B. zum Lesen von geheimen Schlüsseln. Ohne diese Berechtigung schlägt ein Aufruf get_secret() fehl, auch wenn die Identität andernfalls gültig ist. Um diese Berechtigung zu beheben, legt das Bereitstellungsskript mithilfe des Befehls az keyvault set-policyAzure CLI eine Zugriffsrichtlinie für geheime Schlüssel für die App fest. Weitere Informationen finden Sie unter Key Vault-Authentifizierung und Gewähren des Zugriffs ihrer App auf Key Vault. In diesem Artikel wird gezeigt, wie Sie mithilfe des Azure Portals eine Zugriffsrichtlinie festlegen. (Der Artikel wird auch für verwaltete Identitäten geschrieben, gilt aber auch für einen Dienstprinzipal, der in der lokalen Entwicklung verwendet wird.)

Schließlich richtet der App-Code das Clientobjekt ein, über das Nachrichten in eine Azure Storage-Warteschlange geschrieben werden können. Die URL der Warteschlange befindet sich in der Umgebungsvariable STORAGE_QUEUE_URL.

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

Wie bei Azure Key Vault verwendet die Anwendung ein bestimmtes Clientobjekt aus dem Azure SDK, um mit Azure Queue Storage zu interagieren. In diesem Fall wird die Klasse QueueClient aus der Warteschlangenbibliothek von Azure-Storage verwendet.

Zum Initialisieren des Clients verwendet die App die from_queue_url Methode, wobei die vollqualifizierte URL der Warteschlange und ein Anmeldeinformationsobjekt bereitgestellt werden. Dieses Anmeldeinformationsobjekt ist erneut die DefaultAzureCredential zuvor erstellte Instanz, die die Identität darstellt, unter der die App ausgeführt wird.

Wie weiter oben in diesem Leitfaden erwähnt, wird diese Autorisierung durch das Zuweisen der Rolle „Storage Queue Data Contributor“ (Mitwirkender für Speicherwarteschlangendaten) an die Identität der Anwendung gewährt – entweder eine verwaltete Identität in Azure oder ein "Service Principal" während der lokalen Entwicklung. Diese Rollenzuweisung erfolgt im Bereitstellungsskript mithilfe des Befehls az role assignment createAzure CLI.

Wenn dieser Startcode erfolgreich ist, verfügt die App über alle internen Variablen, um den /api/v1/getcode-API-Endpunkt zu unterstützen.

Teil 7 – Haupt-App-Endpunkt >>>