Konfiguracja i ustawienia aplikacji webowych

Wszelkie ustawienia aplikacji, zmienne globalne czy dane potrzebne do połączenia z bazami danych (connection strings) przechowywane są w plikach konfiguracyjnych, np. web.config. Tego typu plik nigdy nie powinien być udostępniany publicznie – nie commit’ujemy go na GitHuba, ani nie wrzucamy na żaden współdzielony publiczny dysk internetowy – chyba, że z jakimiś fałszywymi wartościami, symbolizującymi tylko jak coś w projekcie powinno wyglądać. Z pomocą portalu Azure’owego można skonfigurować wszystkie niezbędne ustawienia, które następnie zostają wstrzyknie do działającej już aplikacji, dzięki czemu możliwe staje się całkowite pozbycie się wszystkich dodatkowych plików konfiguracyjnych.

Na początku zobaczmy jak wygląda to od strony portalu. Wybierz dowolną aplikację webową, a następnie kliknij w Ustawienia Aplikacji (application settings):

Ustawienia ogólne aplikacji wewnątrz portalu ARM
Ustawienia ogólne aplikacji wewnątrz portalu ARM

Po każdej zmianie w ustawieniach powinieneś zrestartować swoją aplikację – powinno się to dziać automatycznie z każdym zapisem w ustawieniach. Dzięki funkcjonalności wykorzystania mechanizmu kontroli dostępu RBAC (role based access control) możliwe stało się ograniczenie dostępu do tych ustawień dla wybranych użytkowników. W przypadku ASM był tylko jeden administrator subskrypcji, który miał dostęp do wszystkiego. Przejdźmy do przeglądu dostępnych ustawień.

Ustawienia ogólne (general settings)

Zaczynamy od ustawień ogólnych. Można tutaj skonfigurować wersję dla każdego środowiska programistycznego:

  • .NET (3.5, 4.6),
  • PHP (5.5, 5.6, 7.0),
  • Java (1.7, 1.8) – domyślnie wyłączona,
  • Python (2.7, 3.4) – domyślnie wyłączony,
  • NodeJS – w tym jednym przypadku wersja ustalana jest przez ustawienia aplikacji (app settings).

Znajdziesz tutaj opcje dotyczące samej platformy: 32-bitowa czy 64-bitowa – ta druga zużywa więcej pamięci. Domyślnie na każdej maszynie WebSocket’y są wyłączone – pamiętaj żeby je włączyć, jeśli twoja aplikacja będzie musiała z nich korzystać. Wersja protokołu zarządzanego (managed pipeline version) – wykorzystywane przez ASP.NET, może funkcjonować w trybie zintegrowanym albo klasycznym (o tym trochę niżej).

Aplikacja może również działać w trybie „Always On” – o ile się nie mylę, wymagana jest 64-bitowa maszyna. Znajduje to zastosowanie w sytuacji, gdy korzystamy z WebJob’ów pracujących cały czas w trybie ciągłym (continuous). Jeżeli aplikacja zbyt długo znajduje się w trybie bezczynności to zostanie ona automatycznie usunięta. „Always on” dostępne jest tylko i wyłącznie od planu Basic oraz wyższych (podobnie jak 64-bitowa architektura).

Koligacja ARR (Automatic Request Routing) wykorzystywana jest w przypadku gdy mamy do czynienia z kilkoma instancjami tej samej aplikacji (wykorzystywane jest przy skalowaniu aplikacji). Opcja ta zapewnia, aby sami odbiorcy zawsze zostaną przekierowani do tej samej instancji aplikacji z każdym nowym żądaniem. Automatyczna wymiana (auto swap) wykorzystywana jest przez wspomniane ostatnio deployment sloty. Na samym końcu znajduje się jeszcze kilka ustawień dotyczących zdalnego debuggowania aplikacji. Włączenie tej funkcjonalności pozwala na debugowanie apki hostowanej na Azure za pomocą Visual Studio.

Tryb zintegrowany czy klasyczny?

Tryb zintegrowany (IIS 7) oznacza, że cała pula aplikacji korzysta z tzw. zintegrowanej architektury przetwarzania żądań. Każde zapytanie przechodzi przez pewien ujednolicony model, który eliminuje operacje powtarzalne takie jak np. uwierzytelnianie. Tryb klasyczny (IIS 6) wymaga aby każde żądanie przechodziło przez wszystkie etapy przetwarzania, przez co dochodzi do powielania niektórych operacji – było to wykorzystywane w przypadku klasycznego ASP. W większości przypadków wybierany jest już dzisiaj tylko tryb zintegrowany, tryb klasyczny mógłby znaleźć zastosowanie w przypadku jakichś starszych aplikacji webowych, pracujących pod kontrolą IIS 6.

Ustawienia aplikacji (app settings)

Do przechowywania ustawień związanych już z samą instancją Azure wykorzystuje specjalną tablicę słownikową typu klucz/wartość. Wszystkie wprowadzone zmienne wstrzykiwane są podczas działania aplikacji. Są one dostępne jako zmienne środowiskowe, dzięki czemu nie trzeba ich przechowywać w żadnych dodatkowych plikach. Jeśli mimo wszystko zdecydowałeś się na wgranie swojego własnego configa, wiedz że wszystkie ustawione przez niego zmienne zostaną automatycznie nadpisane przez ustawienia skonfigurowane na portalu – niezależnie od używanej technologii. Zaznaczenie opcji Slot setting deklaruje, że wybrana opcja zostanie przyklejona do tego slotu.

Ustawienia aplikacji oraz connection stringi wewnątrz portalu ARM
Ustawienia aplikacji oraz connection stringi wewnątrz portalu ARM

Dane połączeń do bazy danych (connection strings)

Ustawienia połączeń do danych przechowywane są w ten sam sposób co ustawienia aplikacji. Obsługiwane są następujące typy połączeń:

  • Azure SQL Database – prefiks SQLAZURECONNSTR_ – połączenie do bazy SQL działającej wewnątrz Microsoft Azure,
  • SQL Server – prefkis SQLCONNSTR_ – połączenie do instancji SQL Server znajdującej się na jakiejś fizycznej maszynie, ewentualnie maszynie wirtualnej,
  • Baza danych MySQL – prefiks MYSQLCONNSTR_ – baza MySQL,
  • Custom – prefiks CUSTOMCONNSTR_ – dowolna inna relacyjna (np. Oracle) lub noSQL’owa (MongoDB, DocumentDB) baza danych.

Do wszystkich ustawień aplikacji czy connection string’ów można dostać się w C# za pomocą:

W przypadku NodeJS dostaniesz się do nich poprzez process.env.

Domyślne dokumenty (default documents)

Znajduje się tutaj lista plików, których Azure będzie poszukiwał jako „punkt startu” web aplikacji. Najczęściej nie trzeba dodawać nowego, index.html lub index.php, powinny być one poprawnymi plikami, obecnymi w każdym projekcie webowym (oczywiście w zależności od technologii). Gdybyśmy chcieli żeby jakiś inny plik pełnił rolę pliku startowego, możemy go tutaj dodać.

Mapowanie procedur obsługi (handler mappings)

Mapowanie procedur wykorzystywane jest w sytuacji kiedy przychodzi potrzeba wgrania jakiegoś własnego preprocesora dla określonego typu plików. Wyobraźmy sobie, że pracujemy nad kilkuletnim projektem, realizowanym w PHP 4.5. Nie jesteśmy w stanie przeprowadzić aktualizacji PHP, z różnych, na chwilę obecną nieokreślonych powodów. Potrzebujemy, żeby na Azure była starsza wersja „pehapa”. Niestety, najstarszą dostępną wersją jest 5.5. W tej sytuacji możemy wgrać własny preporecesor, który zajmie się obsługą wszystkich plików *.php.

Wirtualne katalogi (virtual directories)

Wirtualne katalogi wykorzystywane są jako wskaźniki na foldery. Można stworzyć własne, czytelniejsze URL, które będą odnosić się do wybranego zasobu znajdującego się gdzieś w strukturze katalogów web aplikacji. Zamiast wskazywać na taki zagnieżdżony folder tworzy się specjalny katalog składający się z nowej ścieżki (pod jaką będzie dostępny zasób) oraz prawdziwego adresu fizycznego wskazującego na plik (physical path). Przykładem może być katalog „/” wskazujący na „site\wwwroot”:

Mapowanie procedur obsługi i wirtualne katalogi w portalu ARM
Mapowanie procedur obsługi i wirtualne katalogi w portalu ARM

Konfiguracja zmiennych z wykorzystaniem PowerShell’a

W przypadku PowerShell’a tworzy się tzw. hashtable’s:

Teraz pełny skrypt do wgrania wielu ustawień:

Azure CLI