Kopia maszyny wirtualnej z istniejącymi dyskami vhd (szablon grupy zasobów)

7 Cze

W Azure istnieje możliwość wykorzystania szablonów grup zasobów do powielania powtarzających się wdrożeń, a w szczególności do tworzenia obrazów maszyn wirtualnych. W skrajnych przypadkach szablon można wykorzystać by utworzyć kopię maszyny wirtualnej z danego momentu w przeszłości, jednak proces ten jest czasochłonny więc nie powinien być wykorzystywany do regularnych backupów. W tym celu lepiej wykorzystać Recovery Services Vaults.

Zakładając jednak że chcemy utworzyć kopię maszyny z dysków, które wcześniej sobie skopiowaliśmy np. przy użyciu AzCopy możemy wykorzystać szablon grupy zasobów w którym zdefiniujemy wszystkie elementy składające się na maszynę wirtualną, m.in. magazyn (w szczególności dyski), interfejs sieciowy, itd. ale też parametry, które je definiują czyli np. nazwa maszyny i hasło administratora. Poniżej znajduje się scenariusz, który opiszę krok po kroku:

  1. Mam maszynę wirtualną testVM z bazą danych MSSQL, z której mniej lub bardziej korzystam na co dzień. Ponieważ jest to maszyna do testów istnieje duże prawdopodobieństwo że prędzej czy później napsuję coś tak że nie będzie się dało tego odkręcić 🙂 Zdaję sobie przy tym sprawę, że w razie awarii utworzę jej kopię z danego dnia czyli wszystkie zmiany wprowadzone po tym dniu zostaną utracone.
  2. Idealnie byłoby gdyby kopia maszyny wirtualnej została utworzona w oddzielnej grupie zasobów tak by była zupełnie odrębna od oryginału.
  3. Wszystkie zasoby utworzone na potrzebę kopii niech mają dopisek Copy.
  4. Login i hasło administratora muszą być takie same jak na oryginale.
  5. Obie grupy zasobów (oryginalna i nowa) znajdują się w tym samym regionie.

Kopia dysków twardych

Należałoby zacząć od skopiowania dysków mojej maszyny bazowej testVM. Wykorzystam w tym celu narzędzie AzCopy. Ponieważ opisałem jak go używać w tym wpisie to nie będę się tutaj rozpisywał. Wystarczy napisać że w tym celu utworzę nową grupę zasobów rmtemplatestCopy z nowym kontem magazynu testvmcopystor, które będzie przechowywać kopie dysków testVM oraz że do kopiowania wykorzystam inną najmniejszą – a co za tym idzie najtańszą – maszynę wirtualną by przyspieszyć cały proces. Po jego zakończeniu usuwam bądź wyłączam tę tymczasową maszynę by nie generowała kosztów. Z kopiowaniem chwilę się zejdzie więc wieczorem wyłączam testVM (inaczej nie uda mi się skopiować jej dysków) i inicjuję kopiowanie by na następny dzień móc działać dalej.

 Eksport szablonu grupy zasobów

Następnym krokiem jest wyeksportowanie szablonu grupy zasobów, w której znajduje się oryginalna maszyna wirtualna. Najlepiej jeśli w tej grupie zasobów będzie znajdować się tylko i wyłącznie interesująca nas maszyna wraz z jej zasobami, w przeciwnym razie będzie trzeba później modyfikować szablon tak by nie utworzyć kopii zbędnych zasobów (np. dodatkowych aplikacji web albo baz danych MySQL).

Wchodzimy na kartę maszyny wirtualnej i z menu ustawień wybieramy Export template. Następnie klikamy Download.

export-rgtemplate

Teraz mamy łatwy dostęp do szablonu grupy zasobów i możemy go wyedytować by odpowiadał naszym wymaganiom.

Edycja szablonu grupy zasobów

Przed nami najciekawsza część – edycja szablonu. Polecam do tego celu Visual Studio, ale zwykły notatnik też od biedy się nada. Niestety w momencie pisania tego postu nic mi nie wiadomo o walidatorze, który można by wykorzystać do walidacji zmian więc o ewentualnych błędach w składni dowiemy się dopiero w momencie zapisywania szablonu do Azure. Dlatego po każdej zmianie w kodzie szablonu zalecam importować go do Azure tak by później ewentualnie oszczędzić sobie czasu na szukanie błędów – szczególnie jeśli edycji jest dużo.

Otwieram szablon (plik template.json) w Visual Studio. Na samej górze zdefiniowane są zasoby i ich nazwy, które zostaną utworzone w nowej grupie zasobów. Powinny się tu zawierać wszystkie usługi jakie znajdowały się w grupie zasobów maszyny testVM w momencie eksportu szablonu oraz definicja hasła do nowo tworzonej maszyny:

O wszystkie te parametry zostaniemy i tak zapytani w momencie tworzenia kopii maszyny testVM, ale warto podać tutaj docelowe nazwy usług co pozwoli później zaoszczędzić czas.

Dokonuję kilku zmian:

  1. Nie chcę aby pytano mnie o hasło do kopii maszyny wirtualnej, usunę więc wpis virtualMachines_testVM_adminPassword – wtedy hasło będzie takie same jak na testVM.
  2. Do wszystkich nazw, czyli w kluczu „defaultValue” dopisuję Copy. Tak będzie wygodniej ewentualnie później znaleźć usługi powiązane z kopią maszyny wirtualnej.
  3. Nazwę konta magazynu zmieniam na taką, w której przechowuję kopię dysków wirtualnych czyli testvmcopystor.

Po modyfikacji parametry w szablonie wyglądają następująco:

Jeśli chcę mogę zmienić rozmiar nowej maszyny wirtualnej

Ponieważ mam już dyski, które wykorzystam do tworzenia maszyny wirtualnej usuwam cały wpis z informacjami na temat obrazu wykorzystanego do tworzenia maszyny wirtualnej

Nieco niżej zmieniam informacje na temat dysków twardych wykorzystywanych przez maszynę. Tag „osDisk” oznacza dysk systemowy, natomiast „dataDisks” – dodatkowy dysk danych. Domyślnie dla dysku systemowego sposób jego utworzenia jest ustawiony na „FromImage”, a dla dysku danych po prostu „Empty”.

  1. Ponieważ mam kopie dysków zmieniam te opcje na „Attach”. W ten sposób Azure będzie wiedział by nie tworzyć kopii czy wręcz tworzyć nowe, puste dyski ale wykorzysta te już istniejące.
  2. Dodatkowo dla dysku danych usuwam wpis o jego rozmiarze – jest zbędny.
  3. Zmieniam „uri” dla dysków wirtualnych, ponieważ przewija się tam parametr virtualMachines_testVM_name, którego nazwę zmieniałem na samym początku edycji szablonu. Pójdę po najmniejszej linii oporu i wkleję po prostu uri w najczystszej postaci – jako url. Url mogę sobie sprawdzić z poziomu portalu Azure wyświetlając właściwości bloba w magazynie danych przechowującym kopie oryginalnych dysków (u mnie testvmcopystor).
  4. Dla dysku z systemem dodaję wpis

Lub „Linux” zamiast „Windows” dla maszyny z Linuxem.

Fragment szablonu z danymi o dyskach wygląda następująco

W tym miejscu jeśli miałbym taką potrzebę to mógłbym utworzyć dodatkowy, pusty dysk twardy, tworząc w tym celu podobny wpis jak dla lun0, ale jako „createOption” podając Empty.

Zauważ, że można zmienić linki dla dysków, które chcemy podłączyć. Jeśli twoje dyski mają jakieś niestandardowe ścieżki (np. znajdują się w kontenerze o innej nazwie niż vhds) to trzeba je zmienić.

Teraz usuwam cały wpis zawierający się w znaczniku osProfileznów powodem jest tworzenie maszyny z istniejących dysków

Resztę wpisów o interfejsie sieciowym, adresach IP, itd. zostawiam bez zmian. Jeśli oryginalna maszyna wirtualna miała skonfigurowane jakieś niestandardowe endpoint’y to jej kopia również powinna je mieć ustawione.

Jak tworzyłem kopie maszyn wirtualnych, które miały zarezerwowane publiczne adresy IP to coś szło nie tak i maszyny się nie tworzyły. W takich przypadkach po prostu odpowiednio edytowałem szablon by nie tworzył zarezerwowanego adresu i dopiero później z poziomu portalu robiłem rezerwację.

Import szablonu do Azure

Po zakończeniu edycji można spróbować wgrać szablon do Azure’a i przede wszystkim sprawdzić czy nigdzie nie popełniliśmy błędu w jego składni.

W tym cel wchodzę w Browse – Templates i klikam Add. Podaję podstawowe parametry takie jak nazwa, opis a do zakładki ARM Template wklejam cały kod szablonu. Klikam OK. Jeśli z szablonem jest wszystko w porządku to zostanie dodany do listy szablonów i będziemy mogli z niego korzystać 🙂

Tworzenie kopii maszyny wirtualnej z szablonu

Wystarczy wybrać interesujący nas szablon i kliknąć Deploy. Otworzy się zakładka na której możemy podać inne nazwy zasobów niż te, które sobie zdefiniowaliśmy podczas edycji. W każdym razie klikamy OK, zanim przejdziemy dalej.

deploy-rgtemplate

Następnie wybieramy subskrypcję i grupę zasobów – tutaj musimy wybrać grupę zasobów, w której znajdują się kopie oryginalnych dysków wirtualnych. Na końcu akceptujemy warunki usługi i klikamy Create. Już po chwili powinniśmy wiedzieć czy udało się utworzyć maszynę wirtualną czy też nie. Jeśli pojawiają się jakieś błędy to najlepiej jest sprawdzać na poziomie usługi, która błąd zgłosiła – zazwyczaj wtedy opis jest bardziej szczegółowy i może być bardziej pomocny.

deployment-details

W ramach sprawdzianu loguję się jeszcze na testVMCopy i sprawdzam czy wszystkie moje ustawienia i dane znajdują się na swoim miejscu.

Miłej zabawy z szablonami! Dzięki nim można bardzo zautomatyzować i dostosować tworzenie nowych usług w Azure na nasze potrzeby a co za tym idzie zaoszczędzić czas na klikaniu 🙂

Dodaj komentarz