Aby unikn\u0105\u0107 manualnych prac w zakresie devops, najlepszym podej\u015bciem jest IaC, realizowany w Azure za pomoc\u0105 ARM templates. Do niedawna standardem ARM templates by\u0142 format JSON, ale pojawi\u0142 si\u0119 nowy j\u0119zyk mocno promowany przez Mocrosoft, mianowicie Bicep<\/strong>.<\/p>\n\n\n\n Bicep ma jedn\u0105 przewag\u0119 nad poprzednikiem, kt\u00f3ra jest nieoceniona przy rozwi\u0105zaniach multi-tenant. Jest to mo\u017cliwo\u015b\u0107 definiowania p\u0119tli w kodzie<\/strong>. Dzi\u0119ki temu mo\u017cemy stworzy\u0107 generyczny kod, kt\u00f3ry bazuj\u0105c na kolekcji nazw lub konfiguracji tenant\u00f3w, tworzy instancje serwisu w kontek\u015bcie ka\u017cdego tenanta.<\/p>\n\n\n\n Z punktu widzenia wsp\u00f3\u0142czesnego podej\u015bcia do architektury oprogramowania, tendencje s\u0105 takie, aby raczej tworzy\u0107 wiele niezale\u017cnych instancji, gdy\u017c w\u00f3wczas minimalizujemy skutki awarii oprogramowania. Je\u015bli zawiedzie jedna instancja, to dalej przy dobrej architekturze pozosta\u0142e powinny dzia\u0142a\u0107.<\/p>\n\n\n\n Postaram si\u0119 na przyk\u0142adzie rozwi\u0105za\u0144 opartych o serwisy Azure, pokaza\u0107 r\u00f3\u017cne sposoby po\u0142\u0105czenia podej\u015bcia multi-tenant z modularyzacj\u0105. Powy\u017cszy diagram przedstawia, jak mog\u0142oby wygl\u0105da\u0107 takie rozwi\u0105zanie.<\/p>\n\n\n\n Je\u017celi mamy aplikacj\u0119 internetow\u0105 z zarejestrowan\u0105 domen\u0105 (domena.com), to mo\u017cemy stworzy\u0107 w us\u0142udze DNS subdomeny dla ka\u017cdego tenanta: tenant1.domena.com, tenant2.domena.com … Subdomeny rejestrujemy jako wpisy CNAME wskazuj\u0105ce na serwis Azure front door. W ten spos\u00f3b ka\u017cdy tenant wysy\u0142a \u017c\u0105danie do tego serwisu z informacj\u0105 kim jest \u2013 identyfikuje go subdomena.<\/p>\n\n\n\n Serwis Azure front door nie jest jedynym mo\u017cliwym rozwi\u0105zaniem, ale z kilku powod\u00f3w najlepszym. Jest serwisem globalnym, czyli definiuj\u0105c go w Azure, nie podajemy konkretnego regionu. Wysy\u0142aj\u0105c \u017c\u0105danie, zostajemy przekierowani do najbli\u017cszej brzegowej instancji front door, kt\u00f3ra u\u017cywaj\u0105c firewalla, silnika regu\u0142 oraz routera, zweryfikuje nas oraz ewentualnie przekieruje do odpowiedniej us\u0142ugi app service.<\/p>\n\n\n\n Front door potrafi doda\u0107 do \u017c\u0105dania HTTP(S) dodatkowe informacje, bazuj\u0105c na zdefiniowanych regu\u0142ach. Nie musimy tego robi\u0107, je\u015bli dla ka\u017cdego tenanta u\u017cywamy innej subdomeny, gdy\u017c w\u00f3wczas w app service mo\u017cemy przeczyta\u0107 adres z nag\u0142\u00f3wka HTTP \u2013 Referer i bazuj\u0105c na tej informacji, mo\u017cemy wybra\u0107 elementy konfiguracji w kontek\u015bcie tenanta.<\/p>\n\n\n\n Front door posiada tak\u017ce wbudowany globalny load balancer, kt\u00f3ry w po\u0142\u0105czeniu z mo\u017cliwo\u015bciami skalowania app service, umo\u017cliwia bardzo szybkie przesy\u0142anie \u017cada\u0144 i opowiedzi. U\u017cywaj\u0105c Azure front door, dobr\u0105 praktyk\u0105 jest zablokowanie na firewallach we wszystkich us\u0142ugach app service pakiet\u00f3w sieciowych z innym \u017ar\u00f3d\u0142em\/punktem przeznaczenia ni\u017c front door. W ten spos\u00f3b mocno podniesiemy poziom bezpiecze\u0144stwa.<\/p>\n\n\n\n Mimo \u017ce front door przekierowuje nas bezpo\u015brednio do app service, to bardzo cz\u0119sto app service wymaga, aby\u015bmy si\u0119 uwierzytelnili. W zwi\u0105zku z tym zanim zd\u0105\u017cymy zobaczy\u0107 jak\u0105kolwiek stron\u0119 aplikacji, zostajemy przekierowani do identity service \u2013 w przypadku Azure jest to przewa\u017cnie Active Directory lub Active Directory Business to Customer.<\/p>\n\n\n\n Druga opcja daje wi\u0119ksze mo\u017cliwo\u015bci. W zale\u017cno\u015bci od potrzeb poszczeg\u00f3lnych tenant\u00f3w mo\u017cemy mie\u0107 jeden identity service dla wszystkich tenant\u00f3w, osobny dla ka\u017cdego lub co\u015b pomi\u0119dzy. Aby umo\u017cliwi\u0107 uwierzytelnianie w AAD (B2C) dedykowanym dla konkretnego tenanta, mo\u017cemy uwarunkowa\u0107 warto\u015bci konfiguracji AAD (B2C) w app service od informacji wys\u0142anych w oryginalnym \u017c\u0105daniu lub dodanych przez front door.<\/p>\n\n\n\n Jak wspomnia\u0142em, mo\u017cemy posiada\u0107 wiele instancji app service w jednym lub wielu regionach. Niezale\u017cnie od lokalizacji, mamy mo\u017cliwo\u015b\u0107 optymalizacji koszt\u00f3w za pomoc\u0105 serwisu app service plan. Jeden plan w zale\u017cno\u015bci od wybranego pricing tier, mo\u017ce zawiera\u0107 od 10 do nieograniczonej liczby aplikacji oraz skalowa\u0107 si\u0119 nawet do 100 instancji w najwy\u017cszym planie.<\/p>\n\n\n\n Kiedy do app service dotrze request, przewa\u017cnie mamy w nim dodatkowe informacje identyfikuj\u0105ce tenanta. Aplikacja osadzona w app service u\u017cywa tych danych do wybrania odpowiedniej konfiguracji. Sama konfiguracja przewa\u017cnie zapisana jest w us\u0142udze key vault. App service odczytuj\u0119 j\u0105 jednorazowo przy uruchomieniu serwera WWW.<\/p>\n\n\n\n Przechowujemy tu najbardziej wra\u017cliwe dane takie jak has\u0142a, klucze i connection stringi do baz danych oraz storage. Poniewa\u017c dobr\u0105 polityk\u0105 jest posiadanie oddzielnych baz danych oraz storage dla poszczeg\u00f3lnych tenant\u00f3w, r\u00f3wnie\u017c konfiguracja zapisana w key vault powinna by\u0107 oddzielna dla ka\u017cdego tenanta. Wydawa\u0142oby si\u0119, \u017ce mo\u017cliwo\u015bci key vault, kt\u00f3ry przechowuje proste pary klucz-warto\u015b\u0107, nie daj\u0105 takich opcji. Istnieje jednak spos\u00f3b na struktury drzewaste:<\/p>\n\n\n\n App service prawie zawsze potrzebuje persystencji danych. Najcz\u0119\u015bciej u\u017cywane s\u0105 tutaj serwisy Azure storage oraz SQL Server, chocia\u017c ostatnio coraz wi\u0119ksz\u0105 popularno\u015b\u0107 zyskuj\u0105 rozwi\u0105zania typu NoSQL, na przyk\u0142ad Cosmos DB. Storage daje pewne mo\u017cliwo\u015bci multi-tenancy, nawet w ramach pojedynczego serwisu, za spraw\u0105 kontener\u00f3w. Jednak bardziej naturalne wydaje si\u0119 posiadanie wielu storage accounts. Aby zaoszcz\u0119dzi\u0107, mo\u017cna mie\u0107 jeden storage account z wieloma kontenerami zawieraj\u0105cymi pliki, czyli blobs.<\/p>\n\n\n\n SQL Server w Azure mo\u017cna zamodelowa\u0107 na kilka sposob\u00f3w. Je\u017celi chcemy mie\u0107 wiele instancji baz danych, musimy mie\u0107 na wzgl\u0119dzie koszty, gdy\u017c akurat SQL Server w Azure do tanich nie nale\u017cy. Aby zaoszcz\u0119dzi\u0107<\/strong>, warto zastanowi\u0107 si\u0119 nad serwisem SQL Server elastic pool<\/strong>. W\u00f3wczas definiujemy maksymalne rozmiary dla samego poola, a zdefiniowane w nim bazy danych musz\u0105 mie\u015bci\u0107 si\u0119 w tych ramach.<\/p>\n\n\n\n Mo\u017cemy tak\u017ce zdefiniowa\u0107 regu\u0142y skaluj\u0105ce. Koszty naliczane s\u0105 na podstawie parametr\u00f3w elastic pool, a nie poszczeg\u00f3lnych instancji baz danych.<\/p>\n\n\n\n Opisane przeze mnie rozwi\u0105zanie jest tylko jednym z wielu mo\u017cliwych. Multi-tenancy, w zale\u017cno\u015bci od skali i mo\u017cliwo\u015bci systemu, mo\u017ce u\u017cywa\u0107 innych, nieopisanych przeze mnie serwis\u00f3w Azure, takich jak:<\/p>\n\n\n\n Podobnie jak w opisanych przyk\u0142adach b\u0119dziemy mogli wybra\u0107 pomi\u0119dzy wsp\u00f3\u0142dzieleniem serwisu przez tenanty, osobnymi instancjami per tenant lub kombinacjami obu.<\/p>\n\n\n\n Finalnie, b\u0119dzie to zawsze jaka\u015b analogia do serwis\u00f3w kt\u00f3re opisa\u0142em. Najwa\u017cniejsze, aby podj\u0119te decyzje by\u0142y przemy\u015blane i oparte o rzeczywiste potrzeby i wymagania.<\/p>\n\n\n\n ***<\/p>\n\n\n\n Je\u015bli interesuje Ci\u0119 tematyka Azure, polecamy r\u00f3wnie\u017c inne artyku\u0142y naszych specjalist\u00f3w np.: Azure Arc \u2013 rozwi\u0105zanie dla infrastruktury hybrydowej i multicloud<\/a>, Skalowalny monitoring dla \u015brodowisk Azure<\/a> oraz Us\u0142ugi Azure Policy i Azure Blueprint<\/a>. <\/p>\n\n\n![\"fragment](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2022\/09\/Ryc.-1-2.png\")
<\/a><\/figure><\/div>\n\n\n\n<\/a><\/a>DNS<\/strong><\/h2>\n\n\n\n
<\/a>Front door<\/strong><\/h2>\n\n\n\n
<\/a>Azure Active Directory Business to Customer (AAD B2C)<\/strong><\/h2>\n\n\n\n
<\/a><\/a>App service<\/strong><\/h2>\n\n\n\n
<\/a>Key vault<\/strong><\/h2>\n\n\n\n
<\/a><\/figure><\/div>\n\n\n\n<\/a><\/figure><\/div>\n\n\n\nBazy danych i storage<\/strong><\/h2>\n\n\n\n
<\/a><\/a>Podsumowanie<\/strong><\/h2>\n\n\n\n