Funkcje, czyli z grubsza rzecz biorąc, główni reprezentanci linii serverless w Azure (FunctionApp i LogicApp) mogą łączyć się z siecią w trzech płaszczyznach:
- przez adres publiczny – jeśli aplikacja jest udostępniona publicznie
- przez private endpoint – co jest wykorzystywane do połączenia się do funkcji (klient chce skorzystać z funkcjonalności funkcji, więc łączy się do jej endpointa
- przez integration subnet – ten rodzaj połączenia jest wykorzystywany przez funkcję, kiedy chce ona „wyjść na zewnątrz”, np. w celu skorzystania z innych zasobów, które są potrzebne do działania tej funkcji.
Integration subnet nigdy nie jest wykorzystywane do połączenia się do funkcji. Nawet jeśli do integration subnet podłączysz NSG z regułami inbound, to zostaną one zignorowane, bo ruch przychodzący po prostu nie działa. Jedynym wyjątkiem są pakiety transferowane w ramach odpowiedzi na komunikację wychodzącą z funkcji, ale to zrozumiałe, bo bez tego komunikacja nie miałaby sensu.
Dzięki sprytnemu połączeniu ręcznie konfigurowanego routingu, NSG, integracji z Firewallem i innych mechanizmów konfiguracji sieci, administrator ma szeroki zakres możliwości definiowania jakie połączenia mogą być nawiązywane przez funkcje, np.: korzystanie z zasobów lokalnych sieci, połączenie do on-prem, połączenia z express route, innymi endpointami, wyjście do Internetu itd.
Do wykonania konfiguracji NSG może się przydać znajomość prywatnego adresu IP funkcji w integration subnet. Jest on zapisany w zmiennej środowiskowej WEBSITE_PRIVATE_IP.
Ruch sieciowy generowany przez funkcję podlega normalnym regułom. Jeśli np. chcesz przesłać pakiety do gateway’a, wystarczy odpowiednio zmodyfikować trasy routingu przypisane do podsieci.
Co ciekawe, application plan bazujący na windows, może się integrować z dwiema podsieciami, a na linux, tylko z jedną.
Sam routing to również ciekawa sprawa, bo można go konfigurować w trzech zakresach:
- Routing aplikacyjny – określa, co ma sie stać z ruchem generowanym przez działającą aplikację. Może sięgać tylko do zasobów lokalnych, albo wychodzić na zewnątrz
- Routing konfiguracyjny – określa, jak należy wykonywać routing przed uruchomieniem aplikacji, co jest wymagane np. do wykonania operacji pull image for container. Domyślnie komunikacja jest wykonywana przez połączenie publiczne, jeśli ma być inaczej, to wymagana jest zmiana. Jeśli funkcja ma sięgać do Key Vault po zapisane tam sekrety, które mają być np. używane w konfiguracji funkcji, to jeśli taka publiczna komunikacja jest zablokowana, to funkcja podejmuje próbę połączenia przez integration subnet
- Routing sieciowy – pozwala na zdefiniowanie konkretnych tras. Generalnie, ruch wychodzący z funkcji podlega wszystkim normalnym zasadom routingu, które przynajmniej częściowo można tutaj zdefiniować.
Z drugiej strony private endpoint, pozwala na połączenie się do usługi. Endpoint jest podłączony do wybranej podsieci, otrzymuje swój adres IP, a ten adres powinien być zarejestrowany w DNS. Dzięki temu wybrane usługi będą mogły połączyć się do funkcji i skorzystać z jej funkcjonalności.
Integrate your app with an Azure virtual network – Azure App Service | Microsoft Learn
