Konfiguracja aplikacji wydaje się być prosta, 😊 appsettings.json i jazda. Trochę tak, można trochę  więcej, bo przecież jest 🙂 azure key vault,
😅enviroment settings lokalnie, 😂enviroment settings na hoście,
😹appsettings.json.local, 😭appsettings.json.develop czy wreszcie
🤪Azure App Configuration.

Co wybrać jak żyć? To może po kolei 🚂

appsettings.json

Najprościej i najłatwiej. Wszystko ⭐, co tam jest idzie na proda czy każde inne środowisko, na które ma pójść, idzie w postaci pliku appsettings.json, czyli bez zmian. W zasadzie szkoda strzępić języka na tę część.

appsettings.json.local

Tutaj nadpisuje ⭐⭐ ja lub się i dodaje się rzeczy, które będą tylko lokalnie, np. dla azure emulatora czy coś.

appsettings.{environment}.json

Dziękuje Janek za zwrócenie uwagi :*

Tutaj w zależności od konfiguracji, która będzie uruchomiona z visual studio (lub innego lepszego IDE) można brać konfigurację dla środowiska, które mamy emulować.

I teraz gdy idziesz domyślnym wizardem aplikacji, to on naturalnie wspiera ładowanie dżejsonów z konfiguracją per środowisko.

Jeśli chcesz zrobić to sam, to musisz wyciągać to np. z IWebHostEnvironment i dodać jako przez AddJsonFile(…)

Azure Key Vault

Gdy potrzeba więcej bezpieczeństwa powinieneś skierować oczy do Azure Key Vault, gdzie bezpiecznie możesz trzymać klucze, sekrety czy certyfikaty. Ja tutaj korzystam tylko z sekretów, sam AKV pożyczony od #isthereanynews na potrzeby wpisu

Z poziomu kodu dopiąć się można w ten sposób:

Gdzie pod Uri należy wstawić adres do vaulta. Dodatkowo zwracam uwagę że w AKV hierarchie buduje się przez — (sztuk dwie), BlogSettings–AKV.

Zmienne środowiskowe

Czasem jest potrzeba, aby “ukryć” dane, np. aby nie trzymać ich w pliku (np. appsettings.json.local), bo można wrzucić do repo, czy coś. Wtedy można posłużyć się zmiennymi środowiskowymi. Takie rzeczy na maszynie lokalnej robimy o tak:

Zwróć uwagę, że tutaj poprawna hierarchia działa przez :, BlogSettings:Enviroment

App Service / Hosting Environment

Na azure robi się to przez ustawienia w serwisie / konfiguracja – i tutaj zaczyna się trochę magii, bo można także dołożyć ustawienia dedykowane dla slotów (o nich kiedyś już mówiłem, o tutaj: https://jaroslawstadnicki.pl/2017/06/09/azure-deployment)

A na azure robimy tak:

Zwróć uwagę, że tutaj hierarchię budujemy przez __, BlogSettings__Azur

Azure App Configuration

To konfiguracja dla aplikacji, wspiera sloty, jest droga (przynajmniej dla mnie teraz) – nie korzystałem, nie będę opisywać. Zostawię tylko linka:
https://azure.microsoft.com/en-us/services/app-configuration/

Azure price kalkulator:
https://azure.microsoft.com/en-us/pricing/calculator/

Dodanie zmiennych środowiskowych to takie kod:

Szczepienie 💉

Skoro napisałem gdzie można, to jak z tego skorzystać, wszystko fajnie, bo microsoft ładnie to zaciąga i umożliwia jednakowy dostęp do takich danych. Następnie można zrobić bind do klasy z ustawieniami, np o tak:

Tutaj klasa do ustawień, do której będę wszystko wpisywać:

Nazwa pliku z ich zawartością. Zwróć uwagę, że żaden plik nie zawiera pełnych danych dla ustawień, ponadto czasem się nadpisują:

Hierarchie buduje się obiektowo, jak to w jsonach.

Przypinanie do klasy settings robię tak 🕺

Korzystam z tego tak:

Hierarchia / Ważność:

Brak. Kolejność dodania configuration providera (bo tak się nazywają) w konfiguracji ustawia hierarchie.

Mając taki kod:

Mam taki wynik:

Zmieniając kolejność dodawania providerów na taką:

Wynik jest taki:

NULL ok

Zwróć uwagę, że Azur jest pusty. To dlatego, że obrazki pochodzą z localhosta, a tę wartość czytam ze zmiennej środowiskowej, którą mam ustawioną tylko na azure. Na lokalu null, ale w chmurze:

Pamiętaj, aby wcześniej nadać uprawnienia dostępu do AKV dla swojej testowej aplikacji, (którą już usunąłęm – gdyby kusiło Cię klikanie)

Podsumowanie🧮:

Jest kilka możliwości / miejsc, które umożliwiają skonfigurowanie naszej aplikacji. W zależności od wymagań, celu czy bezpieczeństwa musisz zdecydować, które z miejsc jest wystarczająco dobre dla Ciebie.
Przyjemne jest to, że cała konfiguracja może być rozbita pomiędzy różne źródła: json, akv, env a Bind pobierze to z nich wszystkich i wrzuci do jednej klasy.

Inspiracja

Przykład jest oparty o produkcyjna już aplikację ITAN (isthereanynews.com), nad którą pracuje w czasie wolnym. ITAN to raczkujący czytnik RSSów z planami i ambicjami. Możesz śledzić tagi #isthereanynews na tym blogu, Twitterze czy odwiedzić stronę.

Małym druczkiem

⭐ – No prawie wszystkie, bo jeszcze przecież mamy azure devops pipelines variable, które zaraz przed deployem mogą to nadpisać
⭐⭐ – nadpisuje, bo tak ustawiłem w kodzie, przypominam, że kolejność ma znaczenie. Zobacz punkt hierarchia