Как протестировать скрипт инициализации виртуальной машины без инициализации


10

В настоящее время я нахожусь в состоянии, что тестирование стоит мне денег и много времени ...

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

Мне нужен новый подход к такой ситуации и возможность быстрее тестировать сценарий инициализации, не требуя каждый раз развертывать новую виртуальную машину.

Ребята, вы знаете какой-нибудь инструмент, который поможет мне в этом сценарии?


4
Разве невозможно протестировать ваш сценарий инициализации (bash) на локальной виртуальной машине разработчика, запустив его локально?
Rekovni

3
Это место, где будет светить частное облако. Покупка и настройка одного может стоить вам меньше, чем вы делаете в настоящее время. Запустите номера. Посмотрите, что имеет смысл для вас.
цыплята

Ответы:


10

Я вижу несколько вариантов:

  • Используйте Vagrant для создания своих виртуальных машин; он разделяет процесс создания виртуальной машины (включая базовую ОС) и фактическую подготовку. У него также есть несколько вариантов выполнения определенных шагов подготовки только при определенных обстоятельствах.
  • Используйте Ansible, Puppet или что-то в этом роде, чтобы переключиться в режим обеспечения, в котором вы не делаете то же самое каждый раз, но только то, что вам нужно. Это означает, что вы можете начать работу, а при первой неудачной части остановить. Исправьте эту часть, затем продолжите.
  • Используйте Docker. Это немного отличается от подхода Vagrant / Ansible тем, что он создает контейнеры (которые, насколько я могу судить, вам на самом деле не нужны). Преимущество, помимо подхода Ansible, состоит в том, что он дает вам очень подробный пошаговый процесс разработки. То есть, если один шаг не удался, у вас все еще есть все образы, ведущие к этому, поэтому во время разработки, с небольшой дисциплиной, вы действительно становитесь очень, очень быстрыми.

Все эти инструменты делают гораздо больше, чем вам нужно, но все они дают вам возможность постепенно выполнять свою работу. Насколько мне известно, Vagrant, Ansible и Docker довольно просты в изучении (пока вы находитесь в режиме Dev / Test, «интересные» части начинаются, когда вы начинаете работать). Ansible очень минималистичен и не требует ничего, кроме ssh-соединения. Вы скоро увидите, что Vagrant и Docker могут оказаться неосуществимыми в вашей инфраструктуре.


6

http://www.vagrantup.com

Вы можете использовать vagrant для развертывания виртуальных машин на локальном ноутбуке.

Вы также можете проверить, можно ли разбить скрипт на более мелкие части, чтобы его тестирование не заняло четырех часов.


5

Если локальное тестирование не вариант, то самым простым подходом было бы использовать моментальные снимки / резервные копии тома диска в ваших интересах. Они все равно будут стоить $$$, но сэкономят ваше время в долгосрочной перспективе. Затем вы должны разделить ваш bash-скрипт на разные рабочие сегменты / скрипты, которые можно протестировать индивидуально. Как только ваш сервер подготовлен, запустите скрипт, а затем сделайте снимок. Если все прошло успешно, запустите следующий скрипт, сделайте снимок, затем промойте и повторите. В случае сбоя сценария измените сценарий, вернитесь к последнему удачному снимку и повторите попытку.

ПРИМЕЧАНИЕ: я не уверен, что вы можете делать снимки дисков виртуальных машин в IBM Cloud / Softlayer, но похоже, что вы можете создать образ виртуальной машины довольно легко.

Резервное копирование образов виртуальных машин

Вы можете создать резервную копию образа виртуальной машины в вашем экземпляре. Эта функция создает копию образа виртуальной машины и конфигурации облака, которую можно восстановить позже. Кроме того, вы можете управлять этими резервными копиями. Подробности о резервном образе следующие:

Образ резервной копии является точной копией образа виртуальной машины и конфигурации облака. Очистка изображения не производится.

  • Резервный образ не может быть развернут как новый экземпляр. Его можно использовать только для восстановления образа виртуальной машины и конфигурации облака.

  • Только владелец проекта (или администратор) имеет доступ к восстановлению резервных образов виртуальной машины и резервной виртуальной машины.

  • Если вы используете облако 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.