Подготовка виртуального устройства

Прежде чем преобразовывать работающую виртуальную машину в OVA (распространяемое виртуальное устройство), что нужно сделать, чтобы убедиться, что она находится в состоянии готовности, чтобы экземпляры OVA не приводили к ненужным или потенциально разрушительным потрясениям в процессе сборки? Это то, что я до сих пор. Я что-то пропустил? Если это уже был ответ или есть документ Best Common Practices, я был бы признателен за указатель в правильном направлении. Благодарю.

################################# ## ## Получить все пакеты up2date и ## вычистить любую грязь в ## локальные пакеты ## ######################################## yum -y update; ням чистить все;


#################################
##
## Избавиться от признаков, я был ## возиться с этим ##
#################################
[[ -a /etc/issue-original,v ]] && unlink /etc/issue-original,v;
[[ -a /etc/issue,v ]] && unlink /etc/issue,v;
ci -u /etc/issue;



#################################
##
## Удалите ключи хоста, чтобы они ## были регенерированы, когда ## новая виртуальная машина вращается ## ## Также убедитесь, что я удалил все ## личные ключи, которые я, возможно, ## использовал при настройке ##
#################################
find /etc/ssh/*host* |xargs unlink; найти /root/.ssh/ -type f |xargs unlink; найти /home/*/.ssh/ -type f |xargs unlink;



#################################
##
## Избавьтесь от использования UUID в ## FSTAB и любых других Конфигурация NIC##, чтобы новая виртуальная машина могла найти тогда, когда ## UUIDs восстанавливаются ## ## Поскольку мы используем LVM, только /boot
## - это прямая ссылка на срез ## остальные - логические тома ##
#################################
sed -i -e 's/UUID=[0-9a-f-]*\s/\/dev\/sda1\t/' /etc/fstab;
sed -i -e '/^UUID=[0-9a-f-]*.*/d' /etc/sysconfig/network-scripts/ifcfg-eno*;
sed -i -e '/^UUID=[0-9A-F-]*.*/d' /etc/sysconfig/network-scripts/ifcfg-eno*;
find /etc/udev/rules.d/ -iname '70*net*' |xargs unlink;


#################################
##
## Пусть NTP-демон знает, ## ожидать большого скачка в время, так что ## он не волнуется. Также дайте ## ему знать, что если стены тают, ## это кислота, говоря, и ## он будет в порядке ##
#################################
[[ -a /etc/ntp.conf ]] && \
  [[ "$(head -1 /etc/ntp.conf)" == "Паника по повозке 0" ]] || \
  sed -i -e '1itinker panic 0\n' /etc/ntp.conf;



#################################
##
## Обрезать истории команд ##, потому что процесс обучения # # может содержать некоторые неловкие ## ошибки, некоторые из которых ## тоже плохие opseC##
#################################
>/root/.bash_history;
>/home/*/.bash_history;
>/root/anaconda-ks.cfg;



#################################
##
## Наконец, дайте команду ОС повторить ## начальную настройку и верните ## этот запах новой машины ##
#################################
sys-unsfig;
Источник

1 ответ

Решение

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

Имея это в виду, это дополнительные шаги, которые вы, возможно, должны позаботиться о

  • убирать /etc/hosts, /etc/resolv.conf, /etc/sysconfig/network любых настроенных ценностей
  • в дополнение к удалению файлов ifcfg, не забудьте удалить любые файлы маршрутов (/etc/sysconfig/network-scripts/route-eno*), если они у вас есть
  • вращать и очищать каждый лог-файл, журнал аудита и файл wtmp (не удаляйте файл wtmp, просто cat /dev/null > /var/log/wtmp), поэтому они пустуют
  • убирать /var/tmp а также /tmp
  • очистите журнал инициализации vmware, если он у вас есть (iirc, /var/log/vmware-imc/*)
  • если вы зарегистрировали свой шаблон на что-то вроде RH Satellite, SpaceWalk, SuSE Manager или самого RHN, обязательно восстановите /etc/sysconfig/rhn или аналогичный обратно к значениям по умолчанию. Из опыта, rmэто плохая идея. Обычно мы просто делаем резервную копию при первом создании образа и возвращаем его обратно при закрытии. То же самое касается /etc/sysconfig/osad, если ваша среда использует его.
  • удалите лишних пользователей, которые могли быть созданы, и КАЖДЫЙ ОДИН пароль в файле теней
  • убедитесь, что сценарии инициализации, первой загрузки и настройки после развертывания действительно настроены для запуска при первой загрузке.

И наконец, что не менее важно, вы можете обнулить каждую файловую систему плюс дополнительное неиспользуемое пространство VG, чтобы вы могли лучше сжать изображение. У нас есть скрипт, который входит в каждую файловую систему, dd - это куча нулей, пока он не заполнится, а затем удаляет файл. То же самое для VG с пустым пространством, создайте LV, который заполняет 100% БЕСПЛАТНО, обнулите его и удалите. После завершения этих последних шагов (последних перед выключением) вы можете использовать прием в зависимости от типа создаваемого вами изображения:

  • Для VMWare клонируйте образ в новую виртуальную машину с целевым назначением в качестве тонкой подготовки. При этом все смежные нули будут преобразованы в ничто
  • Для изображений openstack/kvm вы можете преобразовать их с помощью qemu-img в qcow2 (если ваш провайдер поддерживает это) и включить флаг сжатия: qemu-img convert -f raw -O qcow2 -c source.raw destination.qcow2

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

РЕДАКТИРОВАТЬ: в духе "каждый раз, когда мы узнаем что-то новое", в прошлый раз были добавлены следующие шаги:

  • ням история новая
  • yum переустановить базовую систему -y
Источник
Другие вопросы по тегам