Возможно ли создать единого «главного» гостя OpenVZ, который будет использоваться только для управления пакетами, и использовать что-то вроде mount --bind на некоторых других гостях OpenVZ как бы обманом заставляют их использовать среду, установленную главным гостем?
Смысл этого в том, чтобы пользователи могли поддерживать свои собственные контейнеры и при этом оставаться в синхронизации с основной средой разработки, чтобы у них всегда были самые последние и самые высокие требования, не беспокоясь о системном администрировании. Если им нужно установить свои собственные пакеты, можно ли поместить их в / opt или / usr / local (или указать путь к их домашнему каталогу)?
Перефразируя, я хотел бы, чтобы несколько (например, разработчиков) гостей OpenVZ, чьи / bin, / usr (и так далее ...) фактически ссылались на то же место на диске, что и главный гостевой OpenVZ, который может быть запущен для установки и обновить общие пакеты для среды, которые будут использоваться всей этой группой гостей OpenVZ.
Как бы то ни было, мы используем Debian 6.
Редактировать:
Я попытался смонтировать (привязать и только для чтения) / bin, / lib, / sbin, / usr таким образом, и он отказывается запускать контейнеры, заявляя, что файлы уже смонтированы или используются иным образом:
Starting container ...
vzquota : (error) Quota on syscall for id 1102: Device or resource busy
vzquota : (error) Possible reasons:
vzquota : (error) - Container's root is already mounted
vzquota : (error) - there are opened files inside Container's private area
vzquota : (error) - your current working directory is inside Container's
vzquota : (error) private area
vzquota : (error) Currently used file(s):
/var/lib/vz/private/1102/sbin
/var/lib/vz/private/1102/usr
/var/lib/vz/private/1102/lib
/var/lib/vz/private/1102/bin
vzquota on failed [3]
Если я размонтирую эти четыре тома и запустил гостевую систему, а затем смонтирую их после запуска гостевой системы, гость никогда не увидит их смонтированными.
Судя по комментариям, вопрос немного отличается от того, что я (и, возможно, другие) ожидал: использование слова «поддержка» относится не к пакетам в контейнерах, а к их индивидуальной конфигурации.
Это делает процесс более трудным, но все же возможным. Например:
Как вы сказали, вам нужно будет предоставить общий доступ к монтированию для двоичных файлов (например, /usr/bin), что станет первым шагом к обеспечению того, чтобы они могли совместно использовать все пакеты - это позволит установленным двоичным файлам быть легко доступными для всех других контейнеров.
Вы должны убедиться, что когда вы mount --bind - вы делаете это на ROOT каталог в вашем соответствующем /etc/vz/<veid>.conf файл.
Например, mount --bind /some/mount/point/bin /vz/root/1/bin
Также важно, чтобы эти крепления были чистыми (как сделать так, чтобы они были на месте после первой загрузки машины?). Для этого OpenVZ предлагает хуки запуска и остановки в виде скриптов. Предполагая, что вы работаете в /etc/vz/conf, вы можете иметь:
/etc/vz/conf/<veid>.mount - это начальный хук: вызывается после запуска контейнера/etc/vz/conf/<veid>.umount - это стоп-крючок: вызывается, когда контейнер закрываетсяИх названия происходят от их технических определений: крепления OpenVZ /vz/private/<veid> на /vz/root/<veid> так что это то, что он зацепляет (при условии, что каталоги по умолчанию).
В комментариях вы спросили, что одним из преимуществ будет то, что они могут настроить свой сервер так, как им нравится (например, mysql.cnf или httpd.conf/apache2.conf). Единственная проблема, которую я мог видеть в этом, заключается в том, что вам необходимо убедиться, что при установке пакетов эти файлы конфигурации устанавливаются внутри каждого из контейнеров. Вы можете попробовать поделиться маунтом копирование при записи Поделиться.
Проблема именно в этом который каталоги для совместного использования. Apache это в /etc/httpd и MySQL в /etc/mysql - поэтому вам нужно быть уверенным, что вы скопируете эти стандартные файлы, иначе эта идея не сработает. Лично я бы осмотрел на .deb файлы, которые установлены вашим «глобальным» администратором пакета, и извлекать любые каталоги, которые не используются совместно, в отдельные контейнеры. Но это всего лишь один способ сделать это - я уверен, что есть еще несколько.
Одна вещь, которую я придумал, заключается в том, что вы можете просто заменить двоичные файлы и библиотеки, которые поставляются с пакетом, но вам нужно наблюдать, перезапускает ли менеджер пакетов службы после его установки.
Вы поднимаетесь на private, вам нужно установить на /var/lib/vz/root/1102/bin каталог (при условии, что на это указывает корень в вашем vz .conf файл).
У Джея есть правильный ответ для его реализации, как вы просите, но я не уверен, хотите ли вы обновлять контейнеры людей во время работы.
Я думаю, вы по-прежнему хотите монтировать системные каталоги как доступные только для чтения в своих контейнерах, но вы хотите обновить эти системные каталоги и хотите, чтобы они устанавливали свое собственное программное обеспечение в свой домашний каталог или где-то, что связано с монтированием извне их контейнера.
Когда пользователю нужна последняя версия, вы должны воссоздать его CT, используя обновленный шаблон. Каждый раз при обновлении вы можете сохранять его как шаблон CT. Это обеспечивает стабильность их систем, но они могут запросить обновление в любое время.