Temat wydaje się banalny, chcemy stworzyć całe środowisko ASE w Azure z szablonu ARM lub też z istniejącego środowiska ASE utworzyć szablon ARM w portalu, a następnie, na jego bazie stworzyć kolejne ASE, być może pod inny typ środowiska lub tożsame środowisko w innym regionie.
Jeśli ktoś zaczyna swoją przygodę z ASE to materiałów jest już wiele. Polecam źródła oficjalne lub swój wpis na blogu.
Jeśli już macie swoje ASE i na portalu Azure generujecie skrypt ARM, to portal podpowie, że skrypt nie jest kompletny. Przykład niżej.
Co więcej, jeśli będziecie próbowali z tego skryptu wykonać wdrożenie, to ono się nie powiedzie :). Taki urok. Skrypt bowiem nie zawiera przede wszystkim kluczowej konfiguracji tzw. hostingEnvironment, który jest potrzebny by powstały AppServicePlan’y a w nich WebSite’s, na których działają Wasze aplikacje. Co więcej, generowane przez portal definicje AppServicePlan’ów nie zawierają żadnej referencji do hostingEnvironment (w sumie to logiczne, skoro go nie ma:)) i odpowiednich Worker Pool’i w ramach których mają działać… Ach ten portal Azure i jego skrypt ARM.
Po kolei… czym jest hostingEnvironment? Dokumentacja nie jest zbyt wylewna, jak sama nazwa mówi to środowisko serwerów wirtualnych na których rozpinacie Wasze AppServicePlan’y. Co więcej, to środowisko podzielone jest na cztery separowane pule serwerów. Pula pierwsza, tzw. FrontEnd Pool, to pula 2 serwerów o wielkości P2, które pełnią rolę Load Balancerów, dedykowanych tylko dla naszego ASE. Kolejne pule Microsoft oznaczył nazwami Worker Pool 0, Worker Pool 1, Worker Pool 2. W każdej możecie mieć do 20 nod’ów, muszą one być tej samej wielkości i możecie wybierać tylko z nodów Premium. Łącznie ASE nie może przekroczyć 55 nodów z których 50 będzie użytecznych. Polecam wpis napisany przez grupę, który w szczegółach to opisuje. Z tej konstrukcji wynikają konkretne konsekwencje – nie możecie przeskalować Waszego AppServicePlan’u w ramach ASE, jeśli Wasz środowisko (hostingEnvironment) nie ma wolnych nodów (maszyn wirtualnych). O wolne nody musicie zadbać wcześniej, przed powiększeniem Waszego AppServiePlan’u. Co więcej, każdy AppServicePlan musi mieć przynajmniej jeden, dedykowany dla niego nod, jeśli dodajesz więc nowy AppServicePlan do ASE upewnij się, że któraś z Worker Pool’i taki nod zawiera.
Tyle teorii, wróćmy więc do bazowego zadania.
- Z pomogą przychodzi GitHub i przykład:https://github.com/Azure/azure-quickstart-templates/tree/master/101-create-ase-with-webapp, który pokazuje jak stworzyć proste ASE z jednym AppServicePlan w ramach, którego działa jedna web aplikacja. Template działa od pierwszego „przeklejenia” dlatego potraktujemy go jak bazę. Tytuł tego template’u jest błędny:) ale opis mówi naprawdę co dzieje się w środku.
- W moim przypadku problem nie był trywialny, moje ASE miało 5 AppServicePlanów, ponad 27 WebSite’ów, przeszło 50 parametrów i dość rozbudowane NSG na sieci ale się udało więc i Tobie się uda. Korzystałem z Visual Studio, który potrafi zinterpretować template JSON i ułatwia korzystanie z parametrów, zmiennych i weryfikuje składnie. Łatwiej mi było do bazowego template’u, pobranego z GitHub, dodać te elementy, które wygenerował mi Portal Azure dla mojego ASE. Zacząłem oczywiście od dodania całej listy parametrów i zmiennych, a następnie dodałem konfigurację NSG.
- Pierwsza rzecz o którą zadbałem to właśnie wspominane już hostingEnvironment. Jego konfiguracja wygląda jak niżej. Kluczowe element to: 1) nazwa i region Azure, 2) konfiguracja sieci, 3) wielkość i ilość nodów dla FrontEnd Pool (Load Balancer) oraz 4) wielkość i ilość nod’ów w poszczególnych Worker Pool’ach
- Drugim krokiem było odpowiednie skonfigurowanie App Service Planów, które w nomenklaturze ARM nazywamy serverfarms. I tutaj potrzeba chwilę pracy, bo AppServicePlan’y, które są w wygenerowanym templacie ARM z portalu nie zawierają kluczowych elementów, które poniżej zaznaczyłem. Kilka punktów: 1) AppServiePlan może być stworzony po tym, jak już macie hostinEnvironment, 2) musicie wskazać Worker Pool, w którym Wasz AppServicePlan będzie rezydował, 3) musicie określić hostingEnvironment, z którego będzie korzystał i wreszcie 4) określić ilość i wielkość nodów, które chcecie przypisać do tego AppServicePlan’u.
Ważne: Wasz AppServicePlan może wykorzystać tylko tyle instancji, ile jest ich w Worker Pool, do której ten AppServicePlan przypisaliście i tylko o takiej wielkości. Uważajcie więc by przypisywać to z głową. - I już na koniec zostało nam kilka rzeczy, które możecie z Waszego template’u usunąć. Przy definiowaniu stron bowiem (obiekt sites) w ARM pojawiają się takie właściwości jaki: hostNames, enabledHostNames, hostNameSslStates. Jeśli tworzycie kopię swojego aktualnego środowiska to jest prawdopodobieństwo graniczące z pewnością, że przypisywane domeny się zmienią stąd parametry te można usunąć a następnie nowe nazwy domenowe skonfigurować ręcznie, na nowo powstałym środowisku.
I już, po tych w sumie drobnych zmianach macie gotowy skrypt ARM, który stworzy Wasze środowisko. W razie kłopotów, dajcie znać:)