Мне любопытно, как люди развертывают порты FreeBSD в своей среде. Я предполагаю, что большинство людей, использующих FreeBSD, действительно используют порты (и часто портируют для обновления с помощью двоичных файлов). Однако мне интересно, как у вас эта настройка, поскольку я не удовлетворен тем, как все работает в последних версиях. Сейчас я использую FreeBSD 9.0, и у меня возникли проблемы.
Я установил следующее:
ENV['LOCALINDICES'] ||= '/var/db'
ENV['PORTS_INDEX'] ||= ENV['LOCALINDICES'] + '/INDEX.local'
Я могу успешно бежать portupgrade -p package создать пакет, а затем portupgrade -P package для установки двоичного файла на другие узлы.
Тем не менее, иногда я получаю следующую проблему: /var/db/INDEX.local:23265:dbm_store failed
Я не могу думать о каких-либо других оптимизациях, которые я могу сделать для системы, поскольку индекс теперь находится локально, и единственное, что действительно экспортируется, - это дерево портов, и в него никогда ничего не записывается с узлов.
Я никогда не был полностью удовлетворен системой портов в большой среде - всегда кажется, что вам нужно применить к ней какое-то внешнее управление, чтобы она работала хорошо.
Мои лучшие советы (в порядке возрастания предпочтений, от «худшего» решения к «лучшему»):
Если вы строите на каждом хосте, не.
Если необходимо, не делайте этого через NFS с монтированием для чтения и записи, как вы описываете: обычно вы можете доверять портам делать то, что нужно, и не топтать дерево портов, если вы предоставляете альтернативные рабочие каталоги, но всегда лучше будьте осторожны, чем сожалеете: запустите локальное зеркало CVS / csup и csup для всех ваших хостов из этого окна, а затем выполните сборку локально, как если бы они были отдельными машинами.
Да, я знаю, что это означает наличие большего дискового пространства на хостах и дополнительный шаг. Кроме того, это почти гарантированно без проблем.
Предостережение: Вероятно, вы захотите синхронизировать файлы конфигурации пакета (rsync или аналогичные) с назначенного «узла конфигурации», чтобы обеспечить согласованность на каждой машине (вы даже можете rsync всего дерева портов, если хотите, вместо использования csup на каждом узле).
Используйте Build Host, создайте пакеты и установите их.
Гораздо лучшее решение, чем сборка на каждой отдельной машине: используйте узел сборки для создания пакетов и направьте свои инструменты на эти пакеты.
Это означает наличие узла сборки для каждой используемой архитектуры (или кросс-компиляции), но в конечном итоге это лучше для ваших целевых машин (нет больших заданий компиляции, гарантия согласованности)
Используйте инструмент настройки / управления системой.
Это решение, к которому я пришел - я создаю стандартный образ сервера и развертываю его в своей среде, используя radmind. Вы можете делать то же самое с Кукольный или Повар. Это имеет все преимущества использования хоста сборки (согласованность, меньшая нагрузка на отдельные серверы) и добавляет преимущество управления конфигурацией.
Предостережение: Это работает хорошо, только если ваши машины «идентичны» - то есть вы можете установить на всех один и тот же набор портов. Это жестяная банка работают, если у вас разные наборы портов, но это существенно увеличивает административные издержки.
Отказ от ответственности: Я сопровождаю порт для sysutils/radmind. Да, мне так нравится, что я принял это.
Все это основано на моем опыте управления средами FreeBSD различного размера (от 1-2 машин до более 100). По моему опыту, инструменты настройки / управления системой, которые продвигают и поддерживают стандартизированный образ, действительно являются лучшим способом справиться с этим.
Странно, что никто не упомянул порты-MGMT / tinderbox:
Tinderbox - это система сборки пакетов для портов FreeBSD, основанная на официальных сценариях Portbuild, используемых в кластере сборки point. Tinderbox написал Джо Маркус Кларк.
Вы можете определить несколько тюрем (базовые версии системы) и несколько деревьев портов. Комбинация jail и portstree называется сборкой. Тюрьма Tinderbox - это не то, что во FreeBSD понимается под тюрьмой, это фактически определенный мир в chroot. Tinderbox поддерживает автоматическое отслеживание зависимостей и перестраивает только те пакеты, которые изменились с момента последнего запуска. Tinderbox поддерживает уведомление по электронной почте о неудачных сборках. Tinderbox также хорошо интегрируется с ccache.
Tinderbox разработан, чтобы легко предоставлять наборы пакетов необходимых вам портов для платформ и архитектур, которые вам нужны. Tinderbox также является отличным инструментом для тестирования новых портов и обновлений портов, особенно для тестирования зависимостей и списков упаковки. Это также полезно для тестирования портов на различных выпусках FreeBSD, поскольку вы можете запустить FreeBSD 6.X world в качестве тюрьмы на хосте FreeBSD 7.X / 8.X.
Также переход на pkgng значительно упрощает развертывание пакетов.
Проверьте это на github: https://github.com/pkgng/pkgng
Я управлял более чем 100 серверами FreeBSD, просто предоставляя доступ к / usr только для чтения через хорошо настроенную NFS, перемещая базы данных пакетов из / var в / usr и создавая на них символические ссылки (не обязательно, но разрешает pkg_info и тому подобное). Возможно, был один или два других файла, которые нужно было переместить в том или ином направлении и связать символическими ссылками, но на всю установку у меня ушло около часа. Это сработало очень и очень хорошо. Если бы у меня возникли проблемы с масштабированием, я бы добавил дополнительные серверы NFS и разделил бы рабочую нагрузку, но этого не произошло. Для меня производительность никогда не была проблемой (на самом деле она была отличной), но я полагаю, вы могли бы поместить / usr сервера NFS (или его копию) на md.
Похоже, к сожалению, ни у кого не было хорошего решения этой проблемы. Скорее всего, это связано с ограничениями инструментов для укладки.
Вот что я придумал: я отказался от идеи экспорта всего дерева портов. Вместо этого я сдался и поместил полное дерево портов на каждый узел. Затем я смонтировал «пакеты» через NFS (чтобы разрешить распространение пакетов).
Я также собираюсь использовать кеширующий прокси (возможно, Squid) для ускорения процесса portnap. Я написал короткую Почта о том, как настроить это в моем блоге.
Ссылки: