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

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

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

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

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

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

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

Источник

2 ответа

Решение

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

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

Источник

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

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

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

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

допущения:

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

  • имеется точка распространения, которая может обрабатывать как управление пакетами, так и управление / распространение (не обязательно должен быть один сервис / машина, это просто пытается отразить необходимость централизации и доступности этих сервисов). Опять же, много разных способов справиться с этим:
    • cobbler сервер. Может управлять различными сервисами, но интересными будут TFTP, PXE, кикстарт, предпосевной, т. Е. Шаг подготовки. С другой стороны, pulpтакже может распространять репозитории (не только по запросу клиента, но и активно с сервера).
    • система управления конфигурацией, такая как puppet, ansible, salt..., т. е. этап настройки.
    • вся конкретная конфигурация, которая не может быть упакована как есть в пакете, управляется системой управления конфигурацией и сохраняется в системе контроля версий.

  • Программное обеспечение, отличное от VMPlayer VMWare, может использоваться для управления виртуализированной системой.

и некоторые варианты использования:

- полномасштабные виртуальные машины GNU/Linux

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

Машины торгового персонала могут быть оснащены любой ОС, так как единственным требованием является их установка. vagrant на хост-машине. Создание Демо ВМ займет всего лишь vagrant up,

Есть интересные альтернативы vagrant, также. Проверьте, например, packer,

- предложение на основе контейнеров, а не полноценных виртуальных машин

Если машины торгового персонала могут использовать любую операционную систему GNU/Linux, вы также можете воспользоваться контейнерами - способом запуска виртуализированных операционных систем с минимальными издержками. Более интересные (на мой взгляд) способы использования этой технологии включают, но не ограничиваются: libvirt, docker а также LXC, Докер имеет эту концепцию dockerfile, аналогичные по функциональности vagrantfile и что еще интереснее, есть реестр, в котором могут размещаться ваши распространяемые образы.

Контейнеры могут работать как простые сервисы в операционной системе хостинга, поэтому их использование довольно просто.

- обойтись без операционной системы

Чтобы помочь улучшить процесс распространения, нужно, конечно, убедиться, что установлено только минимально необходимое программное обеспечение. Но есть способы, которые вы вообще можете обойтись без операционной системы. Если ваш вариант использования может выиграть от использования программного обеспечения, такого как supermin Размер устройства может составлять от нескольких мегабайт до гигабайта.

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

Источник
Другие вопросы по тегам