Як перевірити скрипт забезпечення VM без забезпечення


10

Наразі я переживаю, що тестування коштує мені грошей і багато часу ...

Передумови: я розгортаю VM на програмному забезпеченні та використовую сценарій після розгортання (bash), який встановлюватиме все необхідне для мене програмне забезпечення після готовності VM. Проблема полягає в тому, що я можу протестувати цей скрипт лише за допомогою розгортання одного віртуального комп'ютера, і для закінчення сценарію потрібно близько 4 годин ... Тому кожна зміна, яку я ввожу, мені потрібно створити новий VM (коштує гроші) і чекати навколо 4 години, щоб побачити, чи зламаний сценарій чи ні ... Це стає хаотичним, і я не зможу рухатись вперед, якщо я залишаюсь таким.

Мені потрібен новий спосіб підійти до подібної ситуації і мати можливість тестувати сценарій забезпечення швидше і без необхідності щоразу розгортати нову машину управління.

Ви знаєте, якийсь інструмент, який допоможе мені у цьому сценарії?


4
Чи не можливо протестувати свій скрипт надання (bash) на локальній програмі VM, запустивши його локально?
Rekovni

3
Це місце, де б сяяла приватна хмара. Придбання і налаштування може коштувати вам дешевше, ніж ви зараз робите. Запустіть числа. Подивіться, що має сенс для вас.
пташенята

Відповіді:


10

Я бачу кілька варіантів:

  • Використовуйте Vagrant для створення своїх віртуальних машин; він розділяє процес створення ВМ (включаючи базову ОС) та власне забезпечення. Він також має деякі варіанти запускати певні етапи забезпечення лише за певних обставин.
  • Використовуйте Ansible, Puppet або щось подібне, щоб перейти в режим резервування, де ви не робите однакові речі кожен раз, а лише те, що потрібно. Це означає, що ви можете розпочати роботу, а на першій невдалій частині зупинитись. Виправити цю частину, а потім продовжити.
  • Використовуйте Docker. Це дещо відрізняється від підходу Vagrant / Ansible тим, що він створює контейнери (наскільки я вам насправді не потрібний). Крім корисного підходу, ви маєте перевагу в тому, що він дає вам дуже тонкий покроковий процес розробки. Тобто, якщо один крок не вдається, у вас залишаються всі образи, що ведуть до цього, тож під час розвитку, з невеликою дисципліною, ви стаєте дуже, дуже швидкими.

Усі ці інструменти роблять набагато більше, ніж потрібно, але всі вони дають вам змогу поступово виконувати свою роботу. Vagrant, Ansible та Docker досить легко вивчити, наскільки я переживаю (поки ви перебуваєте в режимі Dev / Test, "цікаві" частини починаються, коли ви переходите до виробництва). Ansible дуже мінімалістичний і не потребує нічого, крім ssh-з'єднання. Вагрант і Докер можуть бути нездійсненними у вашій інфраструктурі, ви швидко побачите.


6

http://www.vagrantup.com

Ви можете використовувати бродяжних для розгортання VM на локальному ноутбуці.

Ви також можете перевірити, чи можна розділити сценарій на менші частини, щоб його тестувати не потрібно чотирьох годин.


5

Якщо локальне тестування не є варіантом, то найбільш прямим підходом було б використовувати знімки / резервні копії обсягу диска на вашу користь. Вони все одно коштуватимуть $$$, але заощадять ваш час у довгостроковій перспективі. Потім слід розділити ваш скрипт bash на різні робочі сегменти / сценарії, які можна перевірити окремо. Після забезпечення вашого сервера, запустіть сценарій, а потім зробіть знімок. Якщо це було успішно, запустіть наступний сценарій, зробіть знімок, потім промийте та повторіть. Якщо ваш сценарій не працює, змініть його, поверніться до останнього успішного знімка, а потім спробуйте ще раз.

ПРИМІТКА. Я не впевнений, чи можете ви робити знімки віртуальних машинних дисків у IBM Cloud / Softlayer, але схоже, що ви можете легко створити образ VM.

Резервне копіювання зображень віртуальної машини

Ви можете створити резервну копію зображення віртуальної машини у своєму екземплярі. Ця функція створює копію образу віртуальної машини та конфігурації хмари, які можна відновити пізніше. Крім того, ви можете керувати цими резервними зображеннями. Деталі щодо резервного зображення є такими:

Резервне зображення - це точна копія образу віртуальної машини та конфігурації хмари. Чистка зображень не проводиться.

  • Резервне зображення не може бути розгорнуте як новий екземпляр. Його можна використовувати лише для відновлення пов'язаного зображення віртуальної машини та налаштування хмари.

  • Тільки власник проекту (або адміністратор) має доступ до відновлення резервних зображень віртуальної машини та резервної копії віртуальної машини.

  • Якщо ви використовуєте хмару OpenStack, одночасно дозволена лише одна операція резервного копіювання. Якщо інший користувач виконує резервну копію, а ви запускаєте його в тому самому екземплярі, ви отримуєте помилку, яка стверджує, що існує конфліктний запит. Щоб виконати резервну копію, потрібно почекати, поки інша резервна копія не буде закінчена.

  • Примірники OpenStack PowerVM® та z / VM® не підтримують цю дію.

  • Якщо екземпляр видалено за допомогою IBM® Cloud Manager з OpenStack, пов'язані резервні копії також видаляються.

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.