Jak przetestować skrypt udostępniania VM bez aprowizacji

Obecnie jestem w stanie, że testowanie kosztuje mnie dużo pieniędzy i dużo czasu ...

Tło: wdrażam maszyny wirtualne w programie softlayer i używam skryptu poinstalacyjnego (bash), który zainstaluje każde oprogramowanie, którego potrzebuję, gdy maszyna wirtualna będzie gotowa. Problem polega na tym, że mogę przetestować ten skrypt tylko po wdrożeniu jednej maszyny wirtualnej, a zakończenie skryptu zajmuje teraz około 4 godzin ... Tak więc każda wprowadzana przeze mnie zmiana muszę tworzyć nową maszynę wirtualną (kosztuje) i czekać na około 4 godziny, aby zobaczyć, czy skrypt jest zepsuty, czy nie ... To staje się chaotyczne i nie będę mógł iść naprzód, jeśli pozostanę w ten sposób.

Potrzebuję nowego sposobu, aby podejść do tego rodzaju sytuacji i móc przetestować skrypt obsługi administracyjnej szybciej i bez potrzeby wdrażania nowej maszyny wirtualnej za każdym razem.

Czy znacie jakieś narzędzie, które pomoże mi w tym scenariuszu?

Widzę kilka opcji:

• Użyj Vagrant do tworzenia maszyn wirtualnych; oddziela proces tworzenia maszyny wirtualnej (w tym podstawowego systemu operacyjnego) od faktycznego udostępniania. Ma również pewne opcje, aby uruchomić pewne etapy udostępniania tylko w określonych okolicznościach.
• Użyj Ansible, Puppet lub czegoś podobnego, aby przejść do trybu udostępniania, w którym nie robisz za każdym razem tego samego, ale tylko to, co jest potrzebne. Oznacza to, że możesz rozpocząć zadanie, a przy pierwszej nieudanej części zatrzymać. Napraw tę część, a następnie kontynuuj.
• Użyj Dockera. Różni się to nieco od podejścia Vagrant / Ansible, ponieważ tworzy kontenery (które, o ile wiem, nie są tak naprawdę potrzebne). Ma tę zaletę, że poza podejściem Ansible, zapewnia bardzo drobnoziarnisty proces rozwoju krok po kroku. To znaczy, jeśli jeden krok zawiedzie, nadal masz wszystkie obrazy prowadzące do tego, więc podczas rozwoju, z odrobiną dyscypliny, naprawdę stajesz się bardzo, bardzo szybki.

Wszystkie te narzędzia robią znacznie więcej, niż potrzebujesz, ale wszystkie dają ci możliwość stopniowego wykonywania pracy. Moim zdaniem, Vagrant, Ansible i Docker są dość łatwe do nauczenia się (o ile jesteś w trybie deweloperskim / testowym, „ciekawe” części zaczynają się, gdy przejdziesz do produkcji). Ansible jest bardzo minimalistyczny i nie wymaga niczego oprócz połączenia ssh. Vagrant i Docker mogą być niewykonalne w twojej infrastrukturze, szybko to zauważysz.

http://www.vagrantup.com

Za pomocą narzędzia Vagrant można wdrożyć maszyny wirtualne na lokalnym laptopie.

Możesz również sprawdzić, czy można podzielić skrypt na mniejsze części, aby przetestowanie go nie zajęło czterech godzin.

Jeśli lokalne testowanie nie jest opcją, najprostszym podejściem byłoby wykorzystanie migawek / kopii zapasowych woluminów dysku na swoją korzyść. Te nadal będą kosztować $$$, ale na dłuższą metę zaoszczędzisz czas. Następnie należy podzielić skrypt bash na różne działające segmenty / skrypty, które można testować indywidualnie. Po przygotowaniu serwera uruchom skrypt, a następnie zrób migawkę. Jeśli się udało, uruchom następny skrypt, zrób migawkę, a następnie spłucz i powtórz. Jeśli skrypt zawiedzie, zmodyfikuj skrypt, przywróć ostatnią pomyślną migawkę, a następnie spróbuj ponownie.

UWAGA: Nie jestem pewien, czy możesz robić migawki dysków maszyn wirtualnych w IBM Cloud / Softlayer, ale wygląda na to, że możesz łatwo utworzyć obraz maszyny wirtualnej.

Tworzenie kopii zapasowych obrazów maszyn wirtualnych

Możesz utworzyć kopię zapasową obrazu maszyny wirtualnej w swoim wystąpieniu. Ta funkcja tworzy kopię obrazu maszyny wirtualnej i konfiguracji chmury, którą można później przywrócić. Dodatkowo możesz zarządzać tymi obrazami kopii zapasowych. Szczegóły dotyczące obrazu kopii zapasowej są następujące:

Obraz kopii zapasowej jest dokładną kopią obrazu maszyny wirtualnej i konfiguracji chmury. Nie wykonuje się czyszczenia obrazu.

• Obraz kopii zapasowej nie może zostać wdrożony jako nowa instancja. Można go użyć tylko do przywrócenia skojarzonego obrazu maszyny wirtualnej i konfiguracji chmury.

• Tylko właściciel projektu (lub administrator) ma dostęp do przywracania kopii zapasowych obrazów maszyny wirtualnej i kopii zapasowej maszyny wirtualnej.

• Jeśli korzystasz z chmury OpenStack, tylko jedna operacja tworzenia kopii zapasowej jest dozwolona w tym samym czasie. Jeśli inny użytkownik uruchamia kopię zapasową i uruchomisz ją w tej samej instancji, pojawi się błąd informujący o żądaniu będącym w konflikcie. Aby wykonać kopię zapasową, musisz poczekać, aż druga kopia zostanie zakończona.

• Instancje OpenStack PowerVM® i z / VM® nie obsługują tej akcji.

• Jeśli instancja zostanie usunięta przy użyciu programu IBM® Cloud Manager z OpenStack, powiązane kopie zapasowe również zostaną usunięte.

https://www.ibm.com/support/knowledgecenter/en/SST55W_4.1.0/liacb/liacbsaverestorevsvmw.html