Контроль версий образов виртуальных дисков
Существует ли какая-либо существующая система для эффективного отслеживания истории версий образа виртуального диска?
По сути, у меня есть образ диска, который используется в качестве корневой шаблонной файловой системы для тестирования программ. Иногда мне нужно внести в него изменения (например, установить пакеты), но в большинстве случаев он доступен только для чтения. Мне нужно иметь возможность вести полную историю изменений (в основном, чтобы я мог откатиться, если что-то пойдет не так, но мне также может понадобиться найти более старую ревизию по дате и времени, чтобы воспроизвести более ранний тест).
Я бы хотел, чтобы история сохранялась в каком-то инкрементном формате, так как большую часть времени изменения, которые я делаю, очень малы (и полный образ диска огромен).
Мне бы хотелось, чтобы каждая ревизия хранилась в отдельном файле, для удобства резервного копирования с помощью rsync.
Я хотел бы иметь возможность легко удалять старые ревизии, которые больше не нужны.
Мне бы хотелось, чтобы самые последние ревизии хранились как нечто близкое к плоскому файлу, то есть производительность чтения должна быть O(1), независимо от того, сколько существует более старых ревизий.
О, и виртуальная машина должна иметь возможность безопасно использовать образ диска (только для чтения), пока я делаю изменения; "совершение" должно быть атомарной операцией.
(Очевидно, я ожидаю, что между этими критериями будут некоторые компромиссы; я просто пытаюсь дать представление о том, что я ищу.)
Производительность для фактических операций "контроля версий" сравнительно не важна; правильность и стабильность, с другой стороны, имеют решающее значение.
В настоящее время я использую kvm / qemu с образами дисков qcow2, но мне было бы интересно услышать о других вариантах.
Я вижу, как могу написать такую систему контроля версий самостоятельно, используя qemu-img с поддержкой файлов и перебазированием, но существует ли какой-либо существующий набор инструментов, который бы работал для этой цели?
4 ответа
Похоже, что VAGRANT ( https://www.vagrantup.com/) может подойти для ваших нужд. Vagrant работает с несколькими виртуальными машинами (например, virtualbox, vmware, проверьте ссылку выше).
Некоторые преимущества включают в себя:
- Это совместимо с системами VCS (единый текстовый файл)
- Кроссплатформенность - windows, linux, mac
- Очень легко поделиться с кем угодно и где угодно
- Обеспечивает согласованную среду тестирования
Начало работы
Сначала установите vagrant и, скажем, virtualbox.
Затем вы описываете свою виртуальную машину в одном VagrantFile, который вы можете сгенерировать с помощью:
vagrant init ubuntu/trusty64 [1]
Тогда у вас будет файл дескриптора для вашей предпочитаемой ОС. Если хотите, отредактируйте несколько IP-адресов, портов, пакетов и общих папок в VagrantFile.
Когда вы закончите, запустите:
vagrant up
и у вас есть виртуальная машина, в которую вы можете войти используя:
vagrant ssh
настройка
Если этого недостаточно, и у вас есть очень специфические требования, выходящие за рамки возможностей vagrant, существует множество виртуальных машин, предварительно настроенных для работы с системами управления конфигурациями, такими как cfengine, или chef, или puppet, и так далее.
[1] Существует множество предварительно настроенных vagrant vms, посмотрите ( https://vagrantcloud.com/discover/featured).
Если вы используете только образы amd64 linux и были бы довольны контейнерами вместо полной виртуализации, возможно, Docker ( http://docker.io/) будет возможным вариантом.
Проверь это:
Virtualbox: Multi-Attach диск
http://virtbjorn.blogspot.co.uk/2012/12/virtualbox-multi-attach-disk.html
Когда вы назначаете мастер-диск виртуальной машине, происходит то, что виртуальная машина создает разностный диск, куда идут все записи. Мастер-диск будет использоваться для чтения, если он не перезаписан на разностном диске. Со временем разностный диск, который является локальным для каждой виртуальной машины, будет расти, и большое количество исходных файлов будет перезаписано обновлениями. Это не существенно, концепция не о сохранении дискового пространства.
Смотрите ссылку для получения дополнительной информации.
Это может зависеть от того, как хранятся образы ваших виртуальных машин, но при использовании qcow2 кажется, что они хранятся в виде файлов в файловой системе. При использовании файловой системы кластера OCFS2 вы можете использовать снимки для «копирования» любого состояния изображения.
Основное преимущество заключается в том, что такие снимки будут выполнять COW (копирование при записи), поэтому исходный снимок занимает «нулевое» (т. е. всего несколько блоков) пространство; только при изменении блока выделяется новый блок, который «отменяется» от исходного изображения.
Однако недостатками являются:
Необходимое пространство в базовой файловой системе увеличивается по мере записи образа моментального снимка. В крайнем случае, будет ноль общих блоков, а для изображения потребуется вдвое больше места.
Если исходное изображение полностью нефрагментировано, оно будет фрагментировано после создания моментального снимка и записи образа. Это связано с COW, и необходимо было выделить новый блок «вне» изображения, и невозможно предсказать, каким будет следующий блок, в который будет записываться. При использовании дисковых систем на основе твердотельных накопителей это может не быть проблемой, но для вращающихся магнитных дисков это может отрицательно сказаться на производительности.
Ввод-вывод изображения будет задержан во время создания моментального снимка (возможно, даже после его удаления).
Таким образом, при «возврате» к снимку вы можете удалить плохое изображение и
Поскольку на самом деле я использую это для создания автоматических периодических снимков (например, ежечасно, ежедневно, еженедельно, ежегодно), я знаю, что (для хранилища SAN на базе SSD, подключенного через Fibre Channel) обычно создание моментального снимка занимает менее трех секунд. , но иногда это может занять около 30 секунд. Во время создания моментального снимка ввод-вывод виртуальной машины задерживается до завершения создания моментального снимка.