Zugriff auf App-Einstellungen in Azure Functions

Warum App-Einstellungen für Azure Functions wichtig sind

Tim beginnt damit, dass er erklärt, wie wichtig die Anwendungseinstellungen sind, wenn man etwas anderes als die einfachsten .NET-Anwendungen erstellt. Die Notwendigkeit des Zugriffs auf Anwendungseinstellungen in Azure Function-Umgebungen ist sogar noch ausgeprägter, da die Azure Functions-Laufzeit Konfigurationswerte aus verwalteten Speichern wie Umgebungsvariablen, JSON-basierten local.settings.json oder Azure App Configuration erwartet.

Eine häufige Funktion, die sich Entwickler wünschen, ist der Zugriff auf eine Einstellungsdatei", erklärt Tim bei 0:17.

Ob für einen API-Schlüssel, einen Verbindungsstring oder ein Feature-Flag, Konfigurationsflexibilität und Sicherheit sind von größter Bedeutung - insbesondere bei der Bereitstellung auf Cloud-Plattformen wie Microsoft Azure.

Mit Visual Studio die Grundlage schaffen

Bei 1:24 richtet Tim ein Konsolenprojekt mit Visual Studio ein und gibt ihm den Namen SettingsDemoApp. Während Azure-Entwickler normalerweise ein Functions-Projekt mit den Azure Functions Core Tools initialisieren, lässt sich Tims Methode, den Code einzurüsten und zu organisieren, nahtlos übersetzen. Der Aufbau der Projektdatei und die Codestruktur sind wichtige Grundlagen - egal, ob Sie in einer Konsolenumgebung arbeiten oder eine isolierte Azure Functions-App mit dem isolierten Worker-Modell erstellen.

Installieren Sie die erforderlichen NuGet-Pakete

Ab 2:33 führt Tim durch die Installation von vier wichtigen NuGet-Paketen:

• Microsoft.Erweiterungen.Konfiguration

• Microsoft.Erweiterungen.Konfiguration.Json

• Microsoft.Erweiterungen.Konfiguration.Binder

• Microsoft.Erweiterungen.Konfiguration.UserSecrets

Dies spiegelt das von Azure Functions verwendete App-Konfigurationssystem wider, das im Hintergrund auf denselben Paketen basiert. Tim unterstreicht den Wert der Modularität:

Dies ist eigentlich das Gegenteil von aufgeblasen", merkt er an, da .NET Core unnötige Nutzlasten vermeidet, indem es Entwicklern die Möglichkeit gibt, sich über NuGet zu entscheiden.

Für eine typische Funktionsanwendung sind diese Pakete entweder bereits referenziert oder können leicht hinzugefügt werden, um benutzerdefinierte Logik für Konfigurationseinstellungen, Dependency Injection oder erweiterte Anwendungsfälle wie die Unterstützung von Key Vault und Azure App Configuration zu unterstützen.

Hinzufügen und Konfigurieren einer JSON-Einstellungsdatei

Bei 6:12 erstellt Tim eine neue Datei namens appsettings.json, die die Struktur von local.settings.json für die Entwicklung von Azure Functions nachahmt. Er füllt sie mit Schlüssel-Werte-Paaren wie:

{
  "Benutzer": {
    "Vorname": "Tim",
    "Nachname": "Corey"
  },
  "StarterCountValue": 5
}

In den lokalen Funktionen verwenden die Entwickler local.settings.json in nahezu demselben Format, um Werte über injizierte IConfiguration in ihre Anwendungslogik einzulesen. Tim hebt auch einen wichtigen Schritt hervor: die Einstellung der Datei Copy to Output Directory auf "Copy if newer" - wichtig, um sicherzustellen, dass Ihre Konfiguration zur Laufzeit verfügbar ist.

Manuelles Erstellen der Konfigurationspipeline

Tim schreibt nun den Code, mit dem eine Konfigurationspipeline manuell eingerichtet wird:

var builder = new ConfigurationBuilder()
    .SetBasePath(Verzeichnis.GetCurrentDirectory())
    .AddJsonFile("appsettings.json", optional: true, reloadOnChange: true);

Obwohl die Azure Functions-Laufzeitumgebung diese Pipeline automatisch handhabt, verdeutlicht Tims Aufschlüsselung, wie Funktionsprojekte Werte aus verschiedenen Quellen einholen. Seine Verwendung von .AddJsonFile() spiegelt wider, wie Entwickler local.settings.json in ihrer Azure-App konfigurieren, wobei reloadOnChange das Konzept der dynamischen Aktualisierung von Konfigurationseinstellungen während der Entwicklung einführt.

Werte mit Typsicherheit lesen

Tim zeigt, wie man Einstellungen mithilfe der GetValue()-Methode um 11:00 Uhr liest:

int count = config.GetValue<int> ("StarterCountValue");

Und für verschachtelte Einstellungen verwendet er:

string firstName = config.GetValue<string> ("User:FirstName");

Bei der Arbeit mit Azure Functions gelten dieselben Syntaxmuster. Tims Verwendung von durch Doppelpunkte getrennten Schlüsseln ("User:FirstName") hat eine direkte Abbildung in Umgebungsvariablen mit doppelter Unterstrichsyntax (__):

Benutzer__Vorname=Tim

Dies ist besonders nützlich bei der Bereitstellung von Azure App Service oder bei der Konfiguration über das Azure-Portal, wo Sie Einstellungen zur Laufzeit mithilfe von Anwendungseinstellungen oder umgebungsbasierten Überschreibungen außer Kraft setzen können.

Sicherer Umgang mit Geheimnissen mit UserSecrets

Um 15:00 Uhr stellt Tim das secrets.json-Muster über User Secrets vor, das für die Speicherung sensibler Daten wie API-Schlüssel oder Verbindungsstrings verwendet wird, ohne sie in der Quellcodekontrolle offenzulegen. Er zeigt, wie man mit dieser Zeile einen User Secrets Store an sein Projekt anhängen kann:

builder.AddUserSecrets<Program> ();

Er betont, dass es auf die Reihenfolge ankommt - User Secrets setzen frühere Konfigurationsquellen außer Kraft, wodurch das Prinzip "Wer zuletzt kommt, mahlt zuerst" gestärkt wird. Azure Functions verwendet secrets.json zwar nicht direkt, aber in einer Produktions-Cloud-Umgebung würden Sie Azure Key Vault verwenden, optional mit verwalteter Identitätsauthentifizierung, um die gleichen sicheren Überschreibungen zu erreichen.

Tim merkt an, dass Geheimnisse in der lokalen Entwicklung stellvertretend für das sichere System stehen, das Sie in der Produktion verwenden:

Diese secrets.json ist ein Stellvertreter für das sichere System, das Sie zum Speichern Ihrer echten Werte verwenden - sei es Key Vault oder Umgebungseinstellungen."

Konfigurationen ausführen und validieren

Nachdem er sowohl appsettings.json als auch secrets.json eingerichtet hat, führt Tim das Beispiel aus und überprüft, ob secrets die Basiswerte überschreiben. Dies spiegelt direkt wider, wie Azure Functions Überschreibungen aus mehreren Quellen handhabt: local.settings.json, Azure App Configuration, Umgebungsvariablen oder Key Vault.

Unabhängig davon, ob die Azure Functions Core Tools über die Befehlszeile verwendet oder über Visual Studio bereitgestellt werden, verhalten sich die Ladereihenfolge und die Schichtung der App-Konfiguration genau so, wie Tim es beschreibt.

Best Practices für das Konfigurationsmanagement

Abschließend empfiehlt Tim, Konfigurationswerte, die sich nicht oft ändern - wie Feature-Flags, Häufigkeitseinstellungen oder CORS-Konfigurationen - in Ihrer JSON-Datei zu speichern und sensible Daten wie Verbindungszeichenfolgen und Geheimnisse in einem sicheren Speicher abzulegen.

Dies steht im Einklang mit modernen Best Practices für Azure Functions:

• Entwickler verwenden local.settings.json für lokale Funktionen

• Teams nutzen das Azure-Portal für Anwendungseinstellungen

• Geheimnisse gehen an Key Vault

• Werte aus dem Azure App Configuration Store helfen, Einstellungen vom Code zu trennen

Diese Quellen werden mittels Dependency Injection in die Laufzeitumgebung integriert, ohne dass die Binärdateien der Anwendung berührt werden.

Abschließende Gedanken

Obwohl es in Tims Video um Konsolenanwendungen geht, lässt sich jede von ihm vermittelte Technik nahtlos auf Azure Functions-Anwendungen übertragen - von der Erstellung von Konfigurationsdateien über das Lesen von Schlüsseln und die Verwendung von verwalteten Identitäten bis hin zum Laden von Konfigurationen über Dependency Injection. Ob es um die Bereitstellung mit Visual Studio, die Verwaltung Ihres Azure-Kontos oder die Suche nach vollständigen Code-Beispielen geht, seine Erkenntnisse lassen sich direkt auf die realen Cloud-Praktiken übertragen.