Правильно. Давайте посмотрим на огромные технические последствия идеи Fix Puppet.
Как я уже упоминал в моем предыдущем посте , для разумного исправления кукол мы должны рассмотреть все и пересмотреть некоторую базовую инфраструктуру, которая позволяет всем этим работать.
Связи и зависимости между всеми частями немного сложно визуализировать. Итак, вот картинка.
Все в красном нуждается во внимании, а зеленое * просто работает *. Вещи, выделенные синим цветом, являются этапами установки, и именно над этим мы работаем над совершенствованием.
Итак, у нас в основном есть ориентированный граф, представляющий этапы и этапы, которые должны произойти с новым компьютером, прежде чем пользователи смогут войти в систему.
Шаги, предпринятые для сборки машины, выглядят примерно так:
- Unbox.
- Подключите
- Настройте Netboot.
- Передайте MAC-адрес DHCP-серверу и назначьте имя хоста.
- Клиент PXEBoots.
- Клиент загружает файл preseed.
- Клиент устанавливает себя.
- Клиент перезагружается.
- Кукольный бежит на Первой Загрузке.
- Кукольный завершает.
- Клиент снова перезагружается.
- Вход для пользователей
Вот и все, правда. Первые 4 шага намного проще при поддержке и сотрудничестве с поставщиком. Хорошо иметь системы, предварительно сконфигурированные для загрузки PXE по умолчанию в BIOS, и даже круче, если они могут отправлять MAC-адреса в виде меток на каждой физической машине.
Если мы собираемся создать новую инфраструктуру, нам потребуется проверить и переустановить серверы, которые предоставляют эту инфраструктуру, прежде чем мы сможем построить какие-либо рабочие станции.
Я большой поклонник puppet и считаю, что его следует использовать для настройки всех серверов и рабочих станций. Поэтому я не хотел ничего перестраивать без использования марионетки, поэтому первый шаг должен был заставить марионетку работать снова.
Итак, без дальнейших церемоний, давайте посмотрим на кукольную часть этого, ну, один из них.
Мой предшественник счел целесообразным, чтобы все узлы были определены с помощью puppet-dashboard, который сам по себе является прекрасной частью программного обеспечения, но я думаю, что больше для отчетности, чем для спецификации.
Сначала, по крайней мере, я перестроил манифест марионетки из заведомо исправной конфигурации . А именно базовые конфиги, которые я написал для поста около года назад; базовые конфиги, которые я скоро обновлю.
Я немного старомодный кукольный пользователь. Мне нравятся мои узлы, определенные в node.pp, а не какой-либо внешний классификатор узлов.
Причина в том, что мне нравится иметь возможность искать в одном месте и находить именно то, что я хочу. Это не массивный баллах, чтобы клонировать марионеточное репозиторий, внести изменения и подтолкнуть его обратно.
На самом деле это лучше, чем иметь веб-интерфейс для классификации узлов, потому что git предоставляет вам встроенный журнал того, что было изменено, и его легко вернуться к старой версии, потому что все хранится в системе контроля версий.
Вы также можете проверить, что вы собираетесь делать, потому что, опять же, это просто репозиторий с контролем версий. Я фанат того, чтобы Дженкинс провел несколько проверок работоспособности вашего марионеточного репо, но это отступление для другого поста в блоге.
Я не буду вдаваться в подробности о том, как установить DHCP и DNS, и как заставить его работать с Puppet, по крайней мере, здесь.
Однако я скажу, что Puppet Module Tool — самый фантастически простой способ создания шаблонных модулей для кукол.
Все, что вам нужно сделать, это бежать
puppet-module generate tomoconnor-dhcp
и вы получите полную папку модуля puppet с именем tomoconnor-dhcp, которая содержит всю структуру в соответствии с рекомендациями передового опыта.
Превосходно.
Как часть процесса обзора, стало совершенно очевидно, что Bind9 не имеет разумного интерфейса администратора / управления, или, по крайней мере, не было установлено ни одного, и, честно говоря, все, что имеет такие ужасные файлы конфигурации, должно быть снято.
Имея хороший опыт и результаты использования PowerDNS в прошлом, мы решили, что это будет действительное обновление от BIND.
PowerDNS опирается на SQL-сервер для хранения данных записи в.
Вы можете использовать MySQL или PostgreSQL , или, возможно, некоторые другие. Поскольку MySQL может быть сукой, и для всех серьезных целей — игрушечной базой данных, Postgres кажется лучшим выбором. 9.1 стабильна, и для нее есть пакет deb. 9.1 также выполняет горячую репликацию , что является чудом, потому что репликация Postgres раньше вызывала сильную боль в яичках.
Первоначально были некоторые загадочные проблемы, связанные с тем, что сервер TFTPd, как правило, был дерьмовым, в основном из-за тайм-аутов, потому что хранилище данных TFTP находилось на мучительно медленном диске. Перемещение его оттуда к монтированию NFS значительно повысило производительность и остановило TFTP.
В конфигурации TFTP есть блок для настройки параметров загрузки предварительной установки. Вот как PXE передает детали сервера preseed и классы файла preseed для запуска (в основном, какие модули)
label lucid_ws
menu label ^2) Auto Install Ubuntu Lucid WorkStation
text help
Start hands off install of a workstation.
endtext
menu default
kernel ubuntu-1004-installer/amd64/linux
append tasks=standard pkgsel/language-pack-patterns= pkgsel/install-language-support=false vga=normal initrd=ubuntu-1004-installer/amd64/initrd.gz -- quiet auto debian-installer/country=GB debian-installer/language=en debian-installer/keymap=us debian-installer/locale=en_GB.UTF8 netcfg/choose_interface=eth0 netcfg/get_hostname=ubuntu netcfg/get_domain=installdomain.wibblesplat.com url=http://autoserver/d-i/lucid/preseed.cfg classes=wibblesplat;workstation DEBCONF_DEBUG=1
Первоначально, файлы Preseed содержали все виды сумасшедшего хакерского дерьма в настройке di late-command.
Поздняя команда это круто. Это в основном последнее, что нужно запустить перед первой перезагрузкой, когда вы создаете новую систему Debian / Ubuntu. Вы можете сказать это, чтобы делать все виды вещей там. Вы, вероятно, не должны, хотя. Особенно, когда то, что ты делаешь там, лучше сделать в другом месте.
Предыдущий файл Preseed содержал целую кучу «внедрить эти исходные файлы в /etc/apt/sources.list », что является полной ерундой, потому что вы можете делать то же самое с ди локальными репозиториями, которые делают то же самое, только намного намного чище.
Это не значит, что мои переработанные preseed-файлы вообще не используют поздние команды.
Я решил вставить несколько строк в /etc/rc.local на только что построенной системе, которая обеспечивает запуск кукол при первой загрузке.
На сервере preseed есть файл « firstboot.sh », который добавляется в / usr / local / bin с помощью команды wget в конце команды.
Следующее, что происходит в поздней команде, — это строка для удаления «выхода 0» из /etc/rc.local и замены его на то, что вызывает « /usr/local/bin/firstboot.sh ».
Когда запускается firstboot, он запускает puppet, проверяет работоспособность, а затем удаляет себя из /etc/rc.local.
Код на самом деле выглядит так:
d-i preseed/late_command string \ wget -q -O /target/root/firstboot.sh http://autoserver/d-i/bin/firstboot.sh && \ chmod +x /target/root/firstboot.sh && \ sed -i 's_exit 0_sh /root/firstboot.sh_' /target/etc/rc.local
Это зависит от наличия на http: // autoserver чего-то, что в основном представляет собой apache, на котором размещены некоторые файлы, которые получатель может получить во время установки.
Круто, да?
Это гарантирует, что первое, что произойдет после сборки и перезагрузки новой машины, — это запуск кукол.
Некоторые вещи, которые мы здесь делаем, основаны на наших ручных пакетах deb, которые хранятся в нашем собственном внутреннем репозитории APT. У нас также есть кэш APT, созданный и поддерживаемый apt-cacher-ng , что по крайней мере означает, что когда вы часто перестраиваете системы, все пакеты, которые вы в противном случае загружали бы с archive.ubuntu.com, попадают прямо через LAN.
Первоначально основной проблемой при этом была скорость или отсутствие. Конечно, он не работал на скоростях, близких к ожидаемым от локальной сети 1GE, и причина снова в медленных дисках. Перемещение файлов apt-cache в высокоскоростное хранилище NFS снова повысило производительность. Если мы будем бороться в будущем, я собираюсь посмотреть на SSD-кеш для этого, но я думаю, что производительность дисков SAS / SATA в массивно параллельном хранилище, предоставляемом нашими NFS-серверами, будет достаточной для обозримого будущего.
Далее, Хозяин Марионеток. Опять же, я был очень заинтересован в создании этого с нуля, но использовал сам марионетку для настройки своего собственного мастера. Звучит довольно нелогично, правда? Но марионеточный клиент может легко загрузить мастер, используя файлы в качестве источника.
Первым шагом является клонирование последних манифестов марионеток из git, поэтому вам нужно либо выполнить git export в другом месте, либо установить git-core. Твой выбор.
После того, как вы их получили, все, что вам нужно сделать, это установить puppet-client и запустить:
puppet apply /path/to/your/manifests/site.pp
Если вы правильно написали манифесты и ваш мастер определен как узел, вы должны обнаружить, что puppet установит puppetmaster и т. Д., А затем вы получите готовый и работающий puppetmaster, который только что настроил себя.
Я использовал инструмент puppet-module для генерации модулей для следующих сервисов / элементов: «приложения» — которые на самом деле содержат набор пользовательских / проприетарных правил установки приложений, рассекреченный пример — файл googlechrome.pp, который устанавливает Chrome из PPA.
Другие модули: dhcp, kernel, ldap, network, nfs, nscd, ntp, nvidia, postgres, powerdns и ssmtp.
Как и в случае с Puppet и современными DevOps, подавляющее большинство кода во всем репозитории манифеста было собрано и исследовано из других модулей Puppet на GitHub. Подтверждение на месте, где оно должно быть, и рабочие копии, которые мы используем, часто разветвляются на github из оригинала.
Это здорово, на самом деле. Если вы ищете на PuppetForge http://forge.puppetlabs.com/, то массив доступных модулей просто поражает. Это делает загрузку нового набора манифестов удивительно быстрой и легкой.
Модуль NFS содержит набор требований для монтирования общих ресурсов NFS и определения для монтирования общего ресурса NFS. Все довольно простые вещи, но модульные для простоты использования.
Я особенно горжусь модулем postgres, у которого есть мастер-класс и подчиненный класс, который устанавливает и настраивает необходимые файлы и пакеты для обеспечения потоковой репликации с горячим резервированием на Postgres9.1.
Я скоро выпущу рассекреченный форк этого.
Я собираюсь завернуть этот пост здесь. Это очень длинный и еще много чего еще написать.
Источник: tomoconnor.eu/blogish/low-level-infrastructure-puppet-dns-and-dhcp/