Niezależnie od tego, jak długo korzystasz z platformy Microsoft Azure, z pewnością spotkałeś się już z terminem „model wdrożenia”. Nowym użytkownikom te słowa mogą kojarzyć się z procesem tworzenia nowego zasobu, podczas którego należy wybrać jeden z dostępnych modeli. Użytkownicy Azure posiadający nieco dłuższy staż pracy z rozwiązaniem korzystali (i być może dalej korzystają) ze starszej wersji portalu Azure i klasycznego modelu zasobów. Poniższy artykuł jest skierowany dla obu grup użytkowników i powinien rozwiać wątpliwości, dotyczące wyboru jednego z dostępnych modeli wdrożenia oraz kwestii migracji zasobów z modelu klasycznego do menadżera zasobów.
Dwa modele zasobów
Zacznijmy od postawienia pewnej tezy, która dla części Czytelników CentrumXP może okazać się oczywista. Azure nie jest nową platformą - technologia ta jest rozwijana przez Microsoft od ponad 8 lat! Pierwsza oficjalna prezentacja Azure miała miejsce w 2008 roku – w świecie IT to naprawdę odległe czasy. Inżynierowie Microsoftu założyli wtedy możliwość zarządzania i komunikacji użytkownika z chmurą za pomocą dwóch podstawowych narzędzi – graficznego interfejsu użytkownika dostępnego poprzez przeglądarkę internetową oraz poprzez dedykowane API (z możliwością wykorzystania składni PowerShell). API (z ang. Application Programming Interface) to zestaw zdefiniowanych funkcji, za pomocą których można skomunikować się z danym systemem, wykonać określone akcje i przesyłać dane do i z systemu.
Warto sobie uświadomić, że portal Azure to tak naprawdę graficzna nakładka API – graficzne elementy strony służą do wywoływania tych samych funkcji, które mogą zostać wywołane przez bezpośrednie użycie programowalnego interfejsu aplikacji. W przypadku chmury publicznej Microsoftu mieliśmy do czynienia z zestawem funkcji, znanym jako Windows Azure Service Management API. Azure Service Managment oraz internetowy portal Azure pozwalały na tworzenie i zarządzanie zasobami. Narzędzia te umożliwiały wdrożenia zasobów w sposób, który dziś znany jest jako „klasyczny model wdrożenia”.
Klasyczny model wdrożenia był jedynym modelem dostępnym w ramach platformy Azure aż do roku 2014, kiedy to zaprezentowano jego nowszą wersję, znaną dziś pod nazwą "menadżera zasobów" (w wersji angielskiej "Azure Resource Manager"). Jednocześnie zaprezentowano nową wersją portalu Azure (początkowo pod nazwą „Azure Preview Portal”). Obecnie nowa wersja portalu i nowsza wersja API są domyślnymi narzędziami pracy z chmurą. Dalej jednak istnieje możliwość wykorzystania starszych wersji interfejsu. Przekonajmy się teraz, jakie są główne różnice pomiędzy „starym” i „nowym” Azure.
Klasyczny model wdrożenia
Klasyczny model wdrożenia był jedynym modelem dostępnym w przypadku korzystania ze starszej wersji portalu Azure, a współcześnie jest nadal dostępny jako alternatywna opcja do wyboru podczas procesu tworzenia zasobu w nowej wersji portalu (utworzone w ten sposób zasoby są oznaczone dopiskiem „klasyczne”). Jak już wiemy, pod nazwą klasycznego modelu kryje się starsza wersja API. Jakie były możliwości i funkcjonalności Windows Azure Service Management API? Przede wszystkim zasoby utworzone za pomocą klasycznego modelu miały swoje specyficzne ograniczenia i właściwości. Na przykład utworzenie klasycznej maszyny wirtualnej powodowało pojawienie się kilku zasobów (maszyna, dysk, karta wirtualna itd.), które nie były ze sobą w żaden sposób logicznie skojarzone. Na liście wszystkich zasobów panował więc bałagan, a administrator takiego systemu musiał na bieżąco kontrolować listę utworzonych zasobów, w szczególności w kontekście ich rozliczeń.
Azure Service Management API nie umożliwiało grupowania zasobów, co utrudniało zadania administracyjne. Sama administracja portalem była również ograniczona w zakresie przyznawania praw dostępu do kont – nie było możliwości przyznania spersonalizowanego profilu dostępu do zasobów. Omawiana wersja API nie umożliwiała zapisywania schematów zasobów i wdrażania kilku maszyn jednocześnie. Wielu użytkowników Azure skarżyło się również na konieczność tworzenia zasobu „Cloud Service” przy operacji tworzenia nowej maszyny wirtualnej. Można wypisać jeszcze kilka ograniczeń Azure Service Management API, ale to, co charakteryzuje klasyczny model wdrażania, to przede wszystkim ograniczona oferta zasobów, w szczególności po porównaniu jej z aktualnie dostępną ofertą Azure.
Z biegiem czasu (i wraz z dynamicznym rozwojem całego sektora chmury publicznej) okazało się, że za pomocą starego API nie można zaimplementować nowego typu zasobów, a przecież jednym z wyróżników platformy Azure jest ciągłe poszerzanie oferty i dostosowywanie jej do trendów panujących na rynku. Był to jeden z powodów, dla którego Microsoft zdecydował się na przedstawienie nowszej wersji interfejsu programowego i graficznego.
Menadżer zasobów
Menadżer zasobów to nowy model wdrażania dostępny w Azure. Tak naprawdę pod tą nazwą kryją się dwa pojęcia – nowy portal Azure (domyślny graficzny interfejs użytkownika dostępny pod adresem portal.azure.com i opisany już na łamach CentrumXP w ramach tego artykułu) oraz nowy zestaw funkcji znany jako Azure Resource Manager API. W kwestii graficznej zmieniono przede wszystkim funkcjonalność górnej belki i układ bocznego menu, gdzie zastosowano rozwijane poziomy interfejsu.
Pod względem funkcjonalnym zmieniło się naprawdę wiele, a większość zmian była podyktowana sugestiami użytkowników starszej wersji Azure. Menadżer zasobów wprowadza więc możliwość grupowania zasobów, oferując tworzenie logicznych kontenerów, w których umieszczać można dowolne zasoby. Możliwe staje się masowe zarządzanie zasobami poprzez operacje na grupie zasobów (pojedyncze zasoby dziedziczą swoje prawa w zależności od praw grupy). Już podczas tworzenia nowego zasobu – np. maszyny wirtualnej – można wskazać, do której grupy ma ona należeć, lub utworzyć nową grupę. Istnieje również opcja manualnego tagowania pojedynczych zasobów, tak aby znalazły się w określonej grupie. Należy przy tym pamiętać, że jeden zasób może należeć jednocześnie do więcej niż jednej grupy.
Wprowadzono również moduł znany jako Role-based Access Control, czyli zupełnie nową funkcjonalność przypisywania praw użytkowników do zasobów z bardzo szczegółową granulacją poszczególnych opcji. Dużym udogodnieniem w stosunku do poprzedniej wersji jest obsługa schematów zasobów (ang. Templates). Schematy są dostępne w formie pliku JSON, co ułatwia ich edycję i wdrażanie. Opisując możliwości nowego API, nie sposób nie wspomnieć o możliwej integracji z oprogramowaniem Microsoft Visual Studio za pomocą dedykowanego SDK. Możliwość zarządzania zasobami Azure z poziomu IDE istniała już wcześniej, ale w obecnej wersji portalu dodano nowe funkcjonalności, które są stale rozwijane. Deweloperzy zyskali np. możliwość bezpośredniego kopiowania danych aplikacji na dedykowany ku temu zasób Azure i błyskawiczne wdrożenie działającej w chmurze aplikacji. Oczywiście w ramach nowego portalu Azure pojawiła się poszerzona oferta zasobów, która jest stale rozwijana. Dla użytkowników z Polski przygotowano polską wersję interfejsu, w przeciwności do starszej wersji portalu, gdzie nie było wyboru języka polskiego.
Co wybrać?
Czym powinniśmy się kierować podczas wyboru modelu wdrażania? W tym przypadku odpowiedź wydaje się naprawdę prosta – jeżeli nie ma powodów, by używać modelu klasycznego, to powinno się wybrać menadżera zasobów. Microsoft dosyć jasno przedstawia obecną sytuację i deklaruje, że jedynie nowa wersja portalu będzie dalej rozwijana. Jednocześnie mówi się o tym, że stara wersja Azure dalej będzie funkcjonowała, więc w żaden sposób nie zmusza się użytkowników do przejścia na nowe API. Pomimo tego firma z Redmond zaleca nowym użytkownikom korzystanie z menadżera zasobów, a tych korzystającym z klasycznego modelu zachęca do przeprowadzenia procesu migracji do nowszej wersji. Microsoft zdecydował się na wdrożenie obsługi zasobów utworzonych w ramach klasycznego modelu rónież w nowej wersji portalu Azure. Dzięki temu możliwe jest zarządzanie zasobami obu modeli w ramach jednego portalu. Nie oznacza to jednak, że te dwa typy zasobów są ze sobą kompatybilne. W portalu Azure pozycje menu przeznaczone do obsługi klasycznego modelu zostały oznaczone dodatkowym dopiskiem „klasyczne”, jak na przykład widoczna na ilustracji poniżej pozycja "Maszyny wirtualne (klasyczne)".
Klasyczna maszyna wirtualna nie jest widoczna w menu przeznaczonym do obsługi maszyn wirtualnych, utworzonych za pomocą menadżera zasobów. Nie jest też możliwe skonfigurowane klasycznej maszyny wirtualnej do współpracy z siecią wirtualną, utworzoną w ramach menadżera zasobów. Nie ma możliwości konfiguracji ze sobą zasobów utworzonych w różnych modelach oraz przypisanie klasycznego zasobu do grupy zasobów. Oczywiście nic nie stoi na przeszkodzie, by skomunikować ze sobą dwie maszyny wirtualne różnego typu, ale komunikacja taka nie jest możliwa w ramach jednego zasobu sieci wirtualnej. Warto również wiedzieć, że zasoby utworzone w ramach menadżera zasobów nie są widoczne w starszej wersji portalu Azure. Podsumowując – zaleca się wykorzystywanie menadżera zasobów jako rozwiązania, które będzie dalej wspierane i rozwijane jako podstawowy model zasobów w Microsoft Azure.
Migracja z modelu klasycznego do menadżera zasobów
Jak już zostało wspomniane powyżej, są pewne argumenty za tym, by w określonych przypadkach dalej korzystać z klasycznego modelu zasobów. Przemawiać za tym może sytuacja, w której część zarządzanej przez nas infrastruktury korzysta z zasobów Azure, uruchomionych zgodnie z klasycznym modelem wdrożenia, a do tego używamy narzędzi i skryptów, dostosowanych do wymagań starszego API. W takiej sytuacji przejście na nową wersję portalu Azure i wykorzystanie zasobów, utworzonych za pomocą menadżera zasobów, wymaga opracowania nowych procedur i skryptów, zgodnych z wymaganiami nowego API. Oczywiście nic nie stoi na przeszkodzie, aby dalej wykorzystywać klasyczne zasoby, ale stwarza to opisane wcześniej problemy w zakresie współpracy z nowymi zasobami modelu wdrożenia. Dlatego, jeśli wcześniej korzystaliśmy z starszej wersji Azure, warto jest zastanowić się nad przeprowadzeniem migracji do nowego modelu.
Proces migracji może okazać się najlepszym rozwiązaniem, ale wymaga odpowiedniego przygotowania. Przede wszystkim należy posiadać aktywną subskrypcję. Następnie należy wyświetlić listę swoich zasobów utworzonych w klasycznym modelu wdrożenia i porównać ją z oficjalną listą zasobów, których migracja jest możliwa. Lista znajduje się tutaj i co jakiś czas następują na niej zmiany (najczęściej są to zmiany na plus, tj. umożliwia się migracje dla coraz większej ilości zasobów). Jeżeli któryś z naszych zasobów nie jest na liście kompatybilności, to w większości wypadków wynika to z faktu, że brak jest w modelu menadżera zasobów bezpośredniego odpowiednika tego zasobu. Zdarza się, że ta samą konfiguracja jest wspierana za pomocą innego zasobu, dostępnego w menedżerze zasobów. Można zweryfikować, czy migracja danego klasycznego zasobu w używanej przez nas konfiguracji jest wspierana, za pomocą odpowiedniego polcenia wydanego przez linię poleceń (np. dla sieci wirtualnej będzie to Move-AzureVirtualNetwork -Validate).
Kolejnym krokiem w procesie jest przygotowanie zasobu do migracji, np. poleceniem Move-AzureVirtualNetwork -Prepare. Na tym etapie możliwe jest jeszcze przerwanie procesu migracji i pozostawienie zasobów w ich obecnym stanie. Jest to szczególnie zalecane, kiedy podczas wykonywania opisanych wcześniej poleceń pojawią się komunikaty błędów. W takim przypadku najlepiej skontaktować się ze swoim Partnerem Microsoft lub bezpośrednio ze wsparciem technicznym Microsoft Azure. Zatwierdzenie procesu migracji odpowiednim poleceniem z przełącznikiem -Commit spowoduje rozpoczęcie nieodwracalnego procesu migracji do menadżera zasobów. Proces ten spowoduje chwilową niedostępność zasobów, dlatego warto go zaplanować w godzinach niskiego obciążenia naszego systemu, szczególnie w przypadku środowisk produkcyjnych.
Podsumowanie
Niniejszy artykuł przedstawia naszym Czytelnikom możliwe do wyboru modele wdrożeń zasobów Azure. CentrumXP gorąco poleca korzystanie z menadżera wdrożenia jako modelu, będącego nowszym i bardziej perspektywicznym rozwiązaniem. W przypadku użytkowników, już korzystających ze starszej wersji modelu zasobów, możliwe jest ich dalsze używanie również za pomocą nowej wersji portalu Azure. W ramach artykułu opisany został również proces migracji zasobów, który pozwala na przejście ze starszego modelu na nowszy. Nasza redakcja jest ciekawa Waszych doświadczeń i praktyk związanych z Azure, dlatego gorąco zachęcamy do dyskusji w komentarzach!
