Вопрос: Управление обновлением и распределением виртуальной машины - неправильно?


Я работаю в компании-разработчике программного обеспечения. Мой отдел отвечает за (помимо всего прочего) создание и распространение виртуальных машин VMWare для членов нашей команды продаж, которые затем запускают их с помощью VMWare Player для демонстрации своих продуктов для клиентов.

В последнее время мне пришло в голову, что способ обновления и распространения этих виртуальных машин - это все виды ошибок. Вот наш процесс для обновления «Demo VM:

  1. Загрузите новую копию виртуальной машины (~ 35 ГБ) с центрального сервера
  2. Установите его в постоянный режим, затем запустите его и внесите такие изменения, как обновление продуктов до последних версий и обновление лицензий
  3. После того, как изменения будут выполнены, закройте его и верните в режим непостоянного, затем загрузите все (~ 35 ГБ) обратно на центральный сервер с новым именем папки с добавочным номером версии
  4. Тот, кому нужна последняя версия, затем загружает ее с файлового сервера (35 ГБ * X)

Это не только требует большой пропускной способности сети, но и загрузка 35 ГБ материала из сети может занять много времени, особенно для людей в наших удаленных офисах, у которых нет роскоши скоростей внутри сети.

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

Причина, по которой я начал расспрашивать наш текущий метод, заключается в том, что при обновлении виртуальной машины изменяется только небольшая часть файлов (VMEM и изображения виртуальных дисков), правильно? Поэтому вместо копирования всей папки VM, должен быть способ загрузить / загрузить только дельта, так сказать. Подобно тому, как работают системы управления версиями, такие как Git. Я на самом деле пытался использовать Git для этого, но оказывается, что Git ужасен, когда дело доходит до управления огромными файлами, Поэтому я подумал, что спрошу здесь.


6
2018-03-09 20:06


Источник


Это действительно зависит от того, что вы используете и обновляете. Это может быть так же просто, как иметь некоторый способ запуска yum -y update внутри VM, и это может быть то, что перераспределение всего этого является лучшим решением. - faker
Какую ОС запускает гостевая виртуальная машина? Как часто происходят такие обновления? - Mxx


Ответы:


Rsync будет хорошо работать для этого. Если вы хотите распространять diff на машины, которые не имеют прямого доступа к серверу, вы также можете попробовать Xdelta,

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


5
2018-03-09 20:59





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

В этом рабочем процессе может быть интересный поворот, который может улучшить процесс, сделав его воспроизводимый, но также гибкий, Позвольте мне попытаться объяснить, как это сделать. Эта задача, как вы ее описали (и если я ее правильно понял), основана на построении золотое изображение в автономном режиме и позволяя сотрудникам отдела продаж клонировать его.

(Из информации, которую вы дали, неясно, сможет ли этот персонал изменить золотой образ или просто использовать для демонстрационных целей, поскольку он распространяется, что может породить ветвление, которое я не рассматриваю ниже).

Итак, чтобы дать хотя бы частичный ответ, это мои

допущения:

  • целевая платформа (Demo VM) - это машина GNU / Linux
  • распределенное программное обеспечение и его лицензии упакованы (или могут быть упакованы) с использованием формата целевой ОС (RPM, deb, ...). Это можно решить разными способами:
    • стандарт debian-rules или spec файлы в паре с autotools течь
    • более гибкие процессы с использованием таких инструментов, как fpm

4
2018-03-10 19:49