Wdrażanie infrastruktury chmurowej nie musi wiązać się z mozolnym przechodzeniem przez kreatory tworzenia poszczególnych zasobów. Cały proces może zostać znacznie usprawniony przy wykorzystaniu odpowiednich szablonów i mechanizmów ich implementowania.
Platforma Microsoft Azure pozwala na elastyczne wdrażanie szeregu usług chmurowych w celu budowania pełnoskalowych środowisk informatycznych. Wprowadzane rozwiązania – w zależności od potrzeb organizacji – mogą być budowane w modelach:
- oprogramowanie jako usługa (SaaS);
- platforma jako usługa (PaaS);
- infrastruktura jako usługa (IaaS).
Wszystkie powyższe mogą być tworzone w różnoraki sposób. Najprostszym z nich jest wykorzystywanie portalu Microsoft Azure. Witryna jest przydatna szczególnie dla początkujących administratorów. Dla osób bardziej wymagających dostępne są również mechanizmy wdrażania skryptowego, na przykład za pomocą wiersza poleceń Azure CLI lub gotowych modułów języka Windows PowerShell.
Niemniej, gdy zajmujemy się wdrażaniem infrastruktury na masową skalę (w szczególności gdy poszczególne elementy są często wykorzystywane), konieczne jest posłużenie się mechanizmami pozwalającymi na automatyzację. Jednym z nich są stosy wdrażania (ang. deployment stack).
Stosy wdrażania
Są one specyficznym elementem platformy Azure, dzięki któremu możemy zarządzać cyklem życia całych kolekcji zasobów chmurowych. Ich podstawowym zadaniem jest kreowanie innych zasobów w subskrypcjach Azure na bazie wcześniej przygotowanych szablonów. Jak łatwo się domyślić, wykorzystywanie template’ów pozwala na standaryzację wdrażanych rozwiązań. Dzięki nim możemy ponadto znacznie usprawnić ten proces – nie musimy bowiem wprowadzać poszczególnych zasobów pojedynczo. Możemy np. zbudować szablon bazujący na wielu różnych elementach infrastruktury tak, by docelowo wdrożyć całe rozwiązanie za jednym podejściem.
Wszystkie zasoby wdrażane za pomocą mechanizmu deployment stack określane są mianem zasobów zarządzanych. Oznacza to, iż nawet po wprowadzeniu możemy zarządzać ich cyklem życia. Oznacza to, że gdy wdrażana kolekcja zasobów nie będzie nam już potrzebna, wszystkie elementy wprowadzone za pomocą konkretnego stosu mogą zostać automatycznie posprzątane z taką samą łatwością, z jaką zostały utworzone. Wszystko zależy od zdefiniowania odpowiedniej akcji podczas usuwania instancji deploment stacku. Należy jednak pamiętać, iż zasoby utworzone niejawnie, czyli takie, które zostały wdrożone poza stosem, nawet jeżeli będą znajdować się w grupie zasobów przez niego utworzonej, nie staną się automatycznie zasobami zarządzanymi.
Podstawowym zakresem stosu wdrażania jest grupa zasobów. Oznacza to, iż dla wskazanej grupy możemy wdrożyć zdefiniowane w szablonie elementy. Nie są to jednak wszystkie możliwości, jakie oferuje nam deployment stack. Zakres łatwo rozszerzyć np. na całą subskrypcję, dzięki czemu możemy wdrażać zasoby w ramach różnych grup. Mało tego – przy wyższych zakresach możemy zarządzać również ustawieniami całych subskrypcji, np. przypisaniem odpowiednich polityk platformy Azure czy nawet nadawaniem uprawnień dla poszczególnych jej elementów. Zakres stosu wdrażania możemy rozszerzać nawet do poziomu konkretnych grup zarządzania.
Szablony wdrażania
Jak już wspomniano, usługa deployment stack musi bazować na szablonach wdrażania. W tym celu możemy wykorzystać jeden z ich dwóch rodzajów. Pierwszym są template’y zapisane w formacie JSON usługi ARM (Azure Resource Manager), czyli klasyczne szablony, które możemy w łatwy sposób wydobyć z platformy Azure. Jednym ze sposobów ich pozyskania jest wyeksportowanie wcześniej wdrożonego zasobu za pomocą funkcji Export template.
Jednakże, jeżeli nie posiadamy jeszcze wdrożonych zasobów, które moglibyśmy wyeksportować, możemy je pozyskać również w ramach kreatora tworzenia danego zasobu. Po wypełnieniu wszystkich ustawień danego elementu wystarczy przejść do ostatniego kroku, czyli walidacji ustawień, i skorzystać z linku Download a template for automation.
Drugim rodzajem template’ów, jakie mogą być wykorzystywane przez usługę stosów wdrażania, są te napisane w języku Bicep, który pozwala na opisywanie praktycznie dowolnego typu zasobów platformy Azure. W porównaniu do szablonów ARM ma mocno uproszczoną składnię, dzięki czemu nie trzeba znać żadnych języków programowania, by móc za jego pomocą opanować tworzenie zasobów.
Przydatnym narzędziem w tworzeniu szablonów Bicep może się okazać bezpłatne rozwiązanie Visual Studio Code. W szczególności gdy wyposażymy go w rozszerzenie o nazwie Bicep (rys. 3). Za jego sprawą zyskujemy mechanizmy intuicyjnego podpowiadania składni poszczególnych zasobów, natychmiastowej walidacji definiowanych parametrów czy nawet łatwego wdrażania utworzonych template’ów bezpośrednio w platformie Azure.
Szablony wdrożeń mogą być przechowywane jak zwykłe pliki na dysku, co dla prostych rozwiązań lub testów może być akceptowalnym rozwiązaniem. Jednakże w przypadku profesjonalnych zastosowań zalecane jest zaimportowanie ich do usługi specyfikacji szablonów (ang. template specs). Dzięki niej możemy trzymać wszystkie nasze template’y na platformie Azure, skąd będą później pobierane bezpośrednio do poszczególnych wdrożeń.
Aby załadować szablon do usługi w chmurze, wystarczy posłużyć się dedykowanym poleceniem Windows PowerShell:
$TemplateSpec = @{
Name = „VNetHub”
Version = „1.0”
ResourceGroupName = $ResourceGroup
Location = $Location
TemplateFile = „/Users/mga/Library/VNetHub.bicep”
}
New-AzTemplateSpec @TemplateSpec
Jako podstawowe parametry wskazujemy nazwę importowanego szablonu wraz z jego numerem wersji. Dodatkowo wybieramy lokalizację w grupie zasobów oraz link do docelowego pliku z template’em na dysku, który ma zostać zaimportowany do chmury.
Wdrażanie infrastruktury
Niezależnie od tego, jaki typ szablonu wybierzemy – ARM JSON czy też Bicep – jeżeli jest on poprawnie zbudowany, może zostać użyty do wdrożenia zasobów mechanizmem deployment Stack. Obecnie stosy wdrażania pozwalają jedynie na wdrażanie template’ów z poziomu wiersza poleceń Azure CLI lub poleceń konsoli Windows PowerShell.
W zależności do tego, w ramach jakiego zakresu zamierzamy wdrażać szablony, do dyspozycji mamy trzy osobne komendy. Podczas wprowadzania zasobów w zakresie grupy zasobów będziemy musieli posłużyć się poleceniem New-AzResourceGroupDeploymentStack. W zakresie subskrypcji wykorzystamy New-AzSubscriptionDeploymentStack oraz analogicznie New-AzManagementGroupDeploymentStack w przypadku grupy zarządzania.
Aby utworzyć odpowiedni stos wdrażania w ramach jednego z powyższych poleceń, musimy wskazać odpowiednie parametry. Podstawowym jest nazwa stosu – musi być ona unikalna w danym zakresie. W przeciwnym wypadku podczas wdrażania dostaniemy informację, że dany stos już istnieje i zostaniemy zapytani, czy zamierzamy zastąpić wszystkie jego zasoby nowym szablonem.
Drugim kluczowym parametrem jest wskazanie pliku z template’em. Można tego dokonać na kilka sposobów. Najprostszym rozwiązaniem jest wskazanie odpowiedniego pliku na dysku za pomocą parametru -TemplateFile. Możemy również zrobić to poprzez użycie identyfikatora szablonu zaimportowanego do usługi Template specs. W tym celu musimy posłużyć się parametrem -TemplateSpecId.
- DetachAll – odłącza i pozostawia niezarządzane wszystkie zasoby i grupy zasobów;
- DeleteResources – usuwa wszystkie zasoby, jednakże pozostawia odłączoną grupę zasobów lub grupę zarządzania;
- DeleteAll – usuwa wszystkie zasoby wraz z grupą zasobów oraz grupą zarządzania.
Ostatnim prezentowanym zestawem parametrów są ustawienia ochrony zasobów. Podstawowym parametrem z niniejszej grupy jest -DenySettingsMode. Pozwala on zablokować wdrażane zasoby platformy Azure poprzez narzucenie uprawnień typu odmowy dostępu. Obecnie usługa stosów wdrażania pozwala na zastosowanie jednej z trzech metod ochrony:
- None – brak ochrony;
- DenyDelete – zakaz usuwania zasobu;
- DenyWriteAndDelete – zakaz zarówno modyfikowania, jak i usuwania zasobu.
Należy pamiętać, że ochrona zasobów domyślnie działa na płaszczyźnie sterowania, tzn. blokada nie pozwala na usunięcie lub zmodyfikowanie ustawień samego zasobu, np. obiektu storageAccount. Niemniej zasoby podrzędne obiektu takie jak na przykład kontenery blob, nie będą już zarządzane przez stos wdrażania, przez co będą mogły być modyfikowane. Aby ochroną objąć również podrzędne obiekty, konieczne jest zastosowanie dodatkowego parametru w postaci -DenySettingsApplyToChildScopes. Dzięki niemu rozszerzamy ochronę również na wszystkie podrzędne obiekty.
Zazwyczaj od każdej reguły są wyjątki – dotyczy to także omawianej ochrony zasobów. Za pomocą parametru -DenySettingsExcludedPrincipal możemy definiować listę obiektów wykluczonych z ochrony, np. identyfikator obiektu (ObjectID), użytkownika lub grupy, które nie będą uwzględnione w blokadzie dostępu Deny assigment. W analogiczny sposób możemy tworzyć wyjątki w wykonywaniu poszczególnych akcji. W tym celu wystarczy wykorzystać parametr -DenySettingsExcludedAction, dla którego definiujemy listę wykluczonych z blokady akcji.
Poniżej zaprezentowano przykładowe wdrożenie stosu tworzącego wirtualną sieć w platformie Azure:
DeploymentStack = @{
Name = „VNetCore”
ResourceGroupName = „RG-VNet”
TemplateSpecId = $TemplateSpecId_VNetCore
TemplateParameterObject = @{
AddressSpace = „192.168.0.0/24”
}
ActionOnUnmanage = „detachAll”
DenySettingsMode = „DenyWriteAndDelete”
DenySettingsExcludedPrincipal = @(„4c12c300-e455-4978-b616-1cb23eae33d9
„)
DenySettingsExcludedAction = „Microsoft.Network/virtualNetworks/\
subnets/join/action”
Verbose = $true
}
New-AzResourceGroupDeploymentStack @DeploymentStack
Stosy wdrożeniowe w zależności od zakresu możemy wylistować za pomocą analogicznych poleceń:
Get-AzResourceGroupDeploymentStack
Get-AzSubscriptionDeploymentStack
Get-AzManagementGroupDeploymentStack
Ich szczegóły mogą być również przeglądane za pomocą portalu Azure. Wystarczy przejść do odpowiedniego zakresu, czyli grupy zasobów, subskrypcji lub grupy zarządzania, i następnie z menu Settings wybrać pozycję Deployment stacks. W nowym widoku zostanie załadowana lista zaimplementowanych stosów wdrażania. Po wejściu w szczegóły jednego z nich możemy zobaczyć, jakie zasoby są zarządzane przez stos (rys. 4). W zakładce Deployment możemy dodatkowo podejrzeć szczegółowy proces wprowadzania poszczególnych zasobów oraz sprawdzić, jakiego rodzaju ochrona – wraz z opcjonalnymi wyjątkami – została zastosowana.
Usuwanie stosu wdrażania wymaga wybrania jednej z trzech wcześniej wspomnianych akcji. Dzięki niej będziemy mogli zdecydować, co stanie się z zasobami po usunięciu deployment stacka, tzn. czy wdrożone zasoby mają pozostać na platformie Azure, czy może przeciwnie – należy usunąć je wraz z całym stosem.
Szablony usprawniają wdrażanie
Mechanizm deployment stack może być bardzo przydatnym narzędziem dla administratorów środowiska chmurowego Azure. Zwłaszcza w momencie, gdy nasza infrastruktura zaczyna dynamicznie się rozrastać i musimy powielać poszczególne rozwiązania w różnych segmentach organizacji.
Odpowiednio przygotowane szablony zasobów pozwalają na usprawnienie wdrażania, a co za tym idzie – znacznie skrócić czas ich przygotowywania. Mało tego, dodatkowym atutem mechanizmu jest zapewnienie odpowiedniej ochrony zasobów poprzez możliwość zastosowania blokad dostępu. Dzięki nim, nawet delegując uprawnienia właściciela subskrypcji innym osobom, możemy mieć pewność, iż pewne operacje pozostaną nadal pod naszym nadzorem.
Autor
Michał Gajda
Autor ma wieloletnie doświadczenie w administracji oraz implementowaniu nowych technologii w infrastrukturze chmurowej. Pasjonat technologii Microsoft. Posiada tytuł MVP Cloud and Datacenter Management oraz Microsoft Azure. Autor webcastów, książek oraz publikacji w czasopismach i serwisach branżowych.
