Co to są stosy wdrażania?

Ukończone

Stos wdrażania platformy Azure to typ zasobu platformy Azure, który umożliwia zarządzanie cyklem życia kolekcji zasobów platformy Azure jako pojedynczą jednostką niepodzielna, nawet jeśli obejmują wiele grup zasobów lub subskrypcji. Umożliwia spójne i powtarzalne wdrożenia, upraszcza zarządzanie i umożliwia efektywne skalowanie i aktualizowanie zasobów.

W tej lekcji poznasz organizację zasobów na platformie Azure i dowiesz się, jak stosy wdrażania mogą pomóc w zarządzaniu zasobami w sposób, który nie był wcześniej możliwy.

Organizacja zasobów

Istnieje wiele sposobów organizowania zasobów na platformie Azure. Możesz wybrać organizowanie zasobów na podstawie środowiska (produkcyjnego, przejściowego, programistycznego), cyklu życia aplikacji lub funkcji (na przykład łączności lub zasobów obliczeniowych). Czynniki takie jak rozmiar organizacji, liczba aplikacji i miejsce przechowywania danych wpływają na te decyzje i istnieją ogólne najlepsze rozwiązania dla każdego scenariusza.

W przypadku środowisk wdrażania można je rozdzielić na różne subskrypcje, a nawet grupy zarządzania. Wszystkie składniki aplikacji mogą istnieć w jednej grupie zasobów, wielu grupach zasobów, a nawet wielu subskrypcjach. W przypadku organizacji zasobów platformy Azure najlepsze rozwiązania sugerują organizowanie zasobów w grupy zasobów na podstawie cyklu życia i zabezpieczeń.

Aplikacja pojedynczej grupy zasobów

Czasami użycie jednej grupy zasobów dla aplikacji ma sens. Jeśli dopiero zaczynasz korzystać ze środowiska deweloperskiego lub wdrażasz aplikację produkcyjną bez wielu zasobów, może działać pojedyncza grupa zasobów.

Grupa zasobów jest często używana jako granica zabezpieczeń dla uprawnień. Można zarządzać przypisaniem kontroli dostępu opartej na rolach (RBAC) w zakresie grupy zasobów, jeśli wymagania dotyczące zabezpieczeń nie są ścisłe.

Załóżmy, że aplikacja składa się z usługi app Service, usługi Application Insights i bazy danych SQL wdrożonej w jednej grupie zasobów. Twoja organizacja ma oddzielne zespoły do zarządzania obliczeniami, aplikacjami internetowymi i bazami danych. Jeśli zasady zabezpieczeń organizacji wymagają szczegółowej kontroli dostępu opartej na rolach, konieczne jest określanie zakresu uprawnień w zakresie zasobów zamiast zakresu grupy zasobów.

W miarę upływu czasu możliwe jest, że zasoby niepowiązane z aplikacją są również wdrażane w tej samej grupie zasobów. Na przykład współpracownik wdraża nową usługę Azure Key Vault i przypadkowo wybiera niewłaściwą grupę zasobów w momencie wdrożenia. Ten scenariusz może utrudnić określenie, które zasoby należą do aplikacji i potencjalnie mogą prowadzić do problemów, takich jak przypadkowe usunięcie krytycznego zasobu.

Aplikacja grupy zasobów z wieloma zasobami

Co się stanie, gdy aplikacja skaluje się do punktu, w którym jest wymagana zmiana? Może być konieczne podjęcie części aplikacji i podzielenie ich na oddzielne grupy zasobów w celu uproszczenia mechanizmów kontroli zabezpieczeń. Na przykład wszystkie zasoby obliczeniowe można umieścić w grupie zasobów obliczeniowych, zasobach aplikacji w grupie zasobów aplikacji i wszystkich bazach danych w grupie zasobów bazy danych.

Ten model umożliwia określanie zakresu uprawnień do zespołów obliczeniowych, aplikacji i baz danych do odpowiednich grup zasobów. Chociaż ta praktyka może rozwiązać problem, wprowadzono zdecentralizowane zarządzanie. Ponieważ większość wdrożeń na platformie Azure jest ograniczona do grupy zasobów, nie masz już możliwości zarządzania zasobami jako jedną jednostką.

Jeśli zasoby aplikacji są wdrażane w osobnych grupach zasobów, zidentyfikowanie zasobów będących częścią aplikacji może być trudne. Tagi platformy Azure umożliwiają identyfikowanie zasobów w aplikacji, ale istnieje możliwość, że zasób nie jest prawidłowo oznakowany.

Operacje wdrażania mogą być wykonywane więcej niż raz w modelu wielosóbowej grupy zasobów. Podczas wdrażania zasobów w zależności od metody wdrażania może być konieczne wykonanie wielu poleceń wdrażania. Większość wdrożeń na platformie Azure jest ograniczona do grupy zasobów, dlatego najpierw konieczne byłoby wdrożenie zasobów sieciowych, a następnie zasobów aplikacji. To samo dotyczy operacji usuwania. Jeśli musisz usunąć wszystkie grupy zasobów powiązane z aplikacją, może być konieczne wykonanie wielu operacji usuwania.

Wprowadzanie stosów wdrażania

Stosy wdrażania zmieniają sposób myślenia o organizacji zasobów w grupach zasobów i subskrypcjach. Stos wdrożenia umożliwia grupowanie wszystkich zasobów tworzących aplikację, niezależnie od tego, gdzie znajdują się one w hierarchii organizacyjnej zasobów platformy Azure. Można nimi zarządzać jako pojedynczą jednostką. W przypadku stosów wdrażania możesz wykonywać operacje cyklu życia w kolekcji zasobów tworzących stos.

Stosy wdrażania można traktować jako serię wskaźników, które grupuje zasoby aplikacji w jedną jednostkę. Stosy wdrażania można tworzyć w różnych zakresach, takich jak grupy zasobów, subskrypcje i grupy zarządzania.

Rozważmy przykład z wcześniejszej wersji. Wdrażając aplikację i jej zasoby za pomocą pojedynczego stosu w zakresie na poziomie subskrypcji i w grupach zasobów, możesz teraz zarządzać aplikacją jako pojedynczą jednostką. Każda grupa zasobów i jej zasoby są zarządzane przez stos.

Korzystanie ze stosów wdrażania

Jakie operacje można wykonać na stosach wdrożenia? Możesz tworzyć, wyświetlać, aktualizować i usuwać stosy wdrożenia. W przypadku zasobów możesz wyświetlać zasoby w stosie, dodawać i usuwać zasoby w stosie oraz chronić stos i jego zasoby przed usunięciem.

Tworzenie i wdrażanie stosu wdrożenia i jego zasobów jest niemal identyczne ze standardowym wdrożeniem platformy Azure i używa tych samych szablonów JSON usługi ARM, plików Bicep lub specyfikacji szablonu, do których służysz. Na przykład:

Polecenie interfejsu wiersza polecenia platformy Azure służące do wdrażania pliku Bicep w grupie zasobów to:

az deployment group create \
    --resource-group rg-depositsApplication \
    --template-file ./main.bicep

Polecenie interfejsu wiersza polecenia platformy Azure umożliwiające utworzenie stosu wdrożenia w zakresie grupy zasobów to:

az stack group create \
    --name stack-deposits \
    --resource-group rg-depositsApplication \
    --template-file ./main.bicep \
    --action-on-unmanage detachAll \
    --deny-settings-mode none

Stosy wdrożeń umożliwiają wydajne oczyszczanie środowiska. Stosy wdrażania umożliwiają usunięcie stosu i wszystkich jego zasobów za pomocą jednego wywołania interfejsu API bez konieczności zrozumienia zależności. Ta funkcja upraszcza usuwanie zasobów w niezawodny sposób, co zwiększa szybkość usuwania zasobów. Na przykład:

Polecenie interfejsu wiersza polecenia platformy Azure umożliwiające usunięcie stosu wdrożenia w zakresie grupy zasobów wraz z jej zasobami to:

az stack group delete \
    --name stack-deposits \
    --resource-group rg-depositsApplication \
    --action-on-unmanage detachAll

Uwaga

W ramach istniejącej strategii wdrażania można już używać wdrożeń w trybie pełnym. Jeśli tak, rozważ wdrożenie stosów, aby być następną ewolucją, a także bezpieczniejszą opcją.

Zasoby zarządzane

Po przesłaniu pliku Bicep, szablonu JSON usługi ARM lub specyfikacji szablonu do stosu wdrożenia stos staje się odpowiedzialny za zarządzanie zasobami opisanymi w pliku. Zasoby zarządzane przez stos są nazywane zasobami zarządzanymi, ale te zasoby są nadal modyfikowane za pomocą oryginalnych plików szablonów.

Jeśli zasób nie musi już być zarządzany przez stos wdrożenia, możesz zmodyfikować stos tak, aby nie zawierał już zasobu. Akcja dotycząca zachowania niezarządzanego stosu wdrożenia określa, co dzieje się z zasobem usuniętym z definicji stosu wdrożenia. To zachowanie, omówione w dalszej części lekcji, określa, czy zasób, grupa zasobów lub grupy zarządzania jest odłączony lub usunięty ze stosu.

Ustawienia odmowy

Ponadto możesz skonfigurować "ustawienie odmowy" dla stosu i jego zasobów, które uniemożliwiają nieautoryzowane zmiany. Te przypisania odmowy można dostosowywać. Możesz ustawić tryb na wartość bez flagi, odmowy usunięcia lub odmowy zapisu i usunięcia, co może wyglądać podobnie do blokad platformy Azure. Ponadto można wykluczyć określone akcje lub jednostki usługi z przypisań odmowy. Rozważ odmowę ustawienia dodatkowej warstwy ochrony przed przypadkowymi modyfikacjami i usunięciami.