Назад | Перейти на главную страницу

Создание новых виртуальных машин для развертывания программного обеспечения

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

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

Одно из основных преимуществ, которые мы ожидаем, заключается в том, что это поможет контролировать дрейф между конфигурациями тестовой и производственной среды. Если мы сдуваем виртуальные машины с каждым развертыванием, то даже если кто-то внесет изменения в отдельный сервер, это не продлится долго. (В конечном итоге мы движемся к централизованному управлению конфигурацией, хотя считаем, что подход виртуальной машины все еще помогает.)

Есть ли у кого-нибудь опыт или даже мысли по этому поводу? Одна из проблем, поднятых одним из моих коллег, заключалась в том, что нам может потребоваться перейти на конфигурацию «одно приложение на каждую виртуальную машину», чтобы нам не приходилось отключать несколько приложений на одной виртуальной машине при развертывании одного из приложений. Другая потенциальная проблема - наличие нескольких виртуальных машин с одним и тем же именем хоста во время развертывания.

Было бы интересно услышать ваш опыт и мысли. Это довольно новая территория для моей организации.

Я считаю, что каждый раз развертывать новую виртуальную машину - отличная идея. Наличие нескольких приложений на одной виртуальной машине не должно быть проблемой, если у вас есть процесс тестирования каждого из них, прежде чем вы переключитесь на производство. У вас должна быть возможность создать собственный сценарий запуска, который дает каждой виртуальной машине уникальное имя хоста, чтобы избежать конфликтов с производственными виртуальными машинами.

Вот пара вещей (я уверен, что их гораздо больше), которые вам нужно учитывать:

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