O konfiguracji App Service Environment (ILB) i Application Gateway słów kilka…

O konfiguracji App Service Environment (ILB) i Application Gateway słów kilka…

Cześć! Mając duży problem ze znalezieniem instrukcji w jaki sposób skonfigurować App Service Environment (ILB) z Appplication Gateway postanowiłem opisać jak możemy skonfigurować taki “twór” z użyciem portalu.

Czym jest App Service Environment?

App Service Environment z dużym przymróżeniem oka można nazwać prywatnym App Service z obsługą VNET. Nie należy ono do najtańszych usług, lecz w zamian gwarantuje nam znacznie większe możliwości skalowania (50 instancji, czyli o 30 więcej niż w App Service Premium) oraz bezpieczeństwo i izolację od internetu. App Service Environment podczas tworzenia musi korzystać albo z wewnętrznego VIP (ang. Virtual IP), albo zewnętrznego VIP. Decyducjąc się na pierwszą opcję ASE będzie dostępne tylko w ramach VNET’u, podczas gdy korzystając z zewnętrznego VIP będzie dostępne z zewnątrz (internetu). Częstym przypadkiem App Service Environment z ILB jest budowa rozbudowanych i wysoce-skalowalnych intranetrów dla firm.

Czym to jest Application Gateway?

Application Gateway nie ma jednoznacznej definicji.  Może między innymi funkcjonować zarówno jako load-balancer, jak i jako proxy. Kolejną funckjonalnością jest możliwość ucinania” SSL (Gateway Offloading pattern), dzięki czemu nie musimy się martwić zarządzaniem certyfikatami wykorzystywanymi wewnętrznie w ramach VNET’u.

Virtual Network

Każde App Service Environment musi zostać stworzone w ramach sieci wirtualnej, dlatego pierwszym krokiem będzie stworzenie nowej sieci, w nowej grupie zasobów z następującymi przestrzeniami adresów:

  • 10.0.0.0/24 – dla maszyn wirtualnych i serwera DNS,
  • 10.0.1.0/24 – dla App Service Environment,
  • 10.0.2.0/24 – dla Application Gateway,

Będąc na etapie konfiguracji sieci tworzymy nową podsieć, w której będzie działać Application Gateway. Tworzymy więc ją dla adresów 10.0.2.0/24.

App Service Environment

Teraz nadszedł czas na stworzenie długowyczekiwanego ASE. Konfigurujemy jego nową nazwę, w moim przypadku cloudcookingase.p.azurewebsites.net. Wybieramy stworzoną wcześniej sieć i grupę zasobów oraz tworzymy nową podsieć w bloku adresowym 10.0.1.0/24. Dzisiaj konfigurujemy ASE z wewnętrznym VIP, dlatego wybieramy odpowiadającą nam wewnętrzną subdomenę, na przykład internal.cloudcooking.pl.

Proces tworzenia ASE powinien zająć od jednej do dwóch godzin, dlatego radzę się uzbroić w cierpliwość 🙂

Po stworzeniu ASE dodajemy nową aplikację wraz z App Service Planem.

Wybieramy z katalogu Web App oraz ją konfigurujemy. Nadałem jej nazwę “aplikacja“, dlatego będzie dostępna pod hostem aplikacja.internal.cloudcooking.pl. Tworzymy również App Service Plan w wybranej Worker Pool’i.

Chcąc korzystać z niestandardowej nazwy domeny wchodzimy w stworzoną aplikację i dodajemy dodatkową domenę, pod którym chcemy otwierać aplikację z zewnątrz. W moim przypadku będzie to aplikacja-ase-waf.cloudcooking.pl.

DNS (wewnętrzny)

Aby DNS wewnątrz sieci działał, potrzebujemy dodać maszynę wirtualną (np. z Windows Server 2016) ze skonfigurowaną rolą DNS i odblokowanym portem 53 UDP. Proces konfiguracji VM’ki pominę. Musi ona również znaleźć się w tej samej sieci, która towarzyszy nam przez cały post.

W maszynie dodajemy zonę internal.cloudcooking.pl, a w niej rekord A, który ma przekierowywać Application Gateway na wewnętrzny adres ASE – 10.0.1.8.

W konfiguracji sieci później ustawiamy adres DNS na 10.0.0.4, który odpowiada wewnętrznemu adresowi stworzonej maszyny wirtualnej z serwerem DNS, a następnie restartujemy maszynę.

Application Gateway

Po stworzeniu ASE wraz z aplikacją nadszedł czas na stworzenie bramy z WAF’em, która będzie stać na straży naszej aplikacji. Wyszukujemy ją w portalu oraz wybieramy wersję z WAF’em.

Dodajemy ją do stworzonej na początku podsieci 10.0.2.0/24. Dobieramy publiczny adres IP i konfigurujemy firewall według naszego własnego uznania 😉

Po stworzeniu zasobu w pierwszej kolejności dodajemy nowy Listener, który będzie nasłuchiwał po HTTPS. Wybieramy port 443, odchaczamy wajchę HTTPS i zapinamy certyfikat SSL, który chcemy, by był przedstawiany przez “zaporę ogniową“.

Dodajemy w BackendPools -> appGatewayBackendPool adres 10.0.1.8, który odpowiada za wewnętrzny balancer (ILB) ASE. W przypadku otrzymania błędu “…Error: Data must be specified for Certificate...” musimy poczekać, aż konfiguracja bramy się zaktualizuje.

Kolejnym krokiem jest dodanie nowej reguły w zakładce Rules, która opisuje, skąd, jak i dokąd Application Gateway ma przekazywać przychodzące zapytania.

Aby brama wiedziała, że nasz serwis działa prawidłowo, powinniśmy skorzystać z healthcheck’a (Health Endpoint Monitoring pattern). W zakładce Health probes dodajemy nowy element sprawdzający działanie aplikacji. Jako host podajemy wewnętrzny adres aplikacji Web, czyli aplikacja.internal.cloudcooking.pl.

W zakładce HTTP settings w elemencie appGatewayBackendHttpSettings zaznaczamy checkbox’a, i wybieramy z listy stworzonego healthcheck’a. Dzięki temu zapytania będą przekazywane do puli backendu tylko podczas jej prawidłowego działania.

DNS (zewnętrzny)

Jako wisienka na torcie, musimy do zewnętrznego DNS dodać rekord CNAME, kierujący na DNS przypisany do Application Gateway. W moim prypadku dodajemy przekierowanie aplikacja-ase-waf.cloudcooking.pl -> 60cd6a4b-5090-44fa-9b7b-6b341c60d438.cloudapp.net .

Efekt

Od teraz aplikacja uruchomiona wewnątrz ASE z ILB jest dostępna publicznie, a dodatkowo chroniona przez WAF‘a w formie Application Gateway. Mamy nim zapięty SSL, który jest ‘rozszyfrowywany’ podczas przerzucania zapytań na aplikację, która dostępna jest tylko stworzonym VNET.


Jestem ciekaw waszych opinii, także zapraszam wszystkich do aktywnego komentowania 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *