Как вы управляете и разворачиваете порты FreeBSD в большой среде?

19

Мне любопытно, как люди разворачивают порты FreeBSD в своей среде. Я предполагаю, что большинство людей, использующих FreeBSD, действительно используют порты (и часто portupgrade для обновления с помощью бинарных файлов). Мне, однако, интересно, как у вас есть эта настройка, так как я не удовлетворен тем, как все работает в последних версиях. Сейчас я использую FreeBSD 9.0 и у меня возникают проблемы.

Я настроил вещи следующим образом:

/ usr / ports используется совместно через NFS с одного узла (с еженедельным 'обновлением выборки portsnap').
Каждый узел монтирует / usr / ports с возможностью чтения-записи
Я установил «WRKDIRPREFIX = / usr / tmp» в /etc/make.conf на всех узлах
Я настроил Portsnap для использования локального индекса, добавив следующее в /usr/local/etc/pkgtools.conf:

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

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

freebsd

— vpetersson
источник

Одним из вариантов было бы иметь полное локальное дерево портов на каждом узле (и, возможно, просто смонтировать 'distfiles' и 'packages'), но это похоже на огромную трату пространства (и не говоря уже о большом количестве ненужных обновлений).

— vpetersson

vpeterson: Это вопрос, который нужно задать (я заблокирован по этому вопросу прямо сейчас. И +5 голосов и 3 звезды говорят о том, что мы не одни). Возможно, очистите этот вопрос и укажите некоторые конкретные проблемы, которые вы пытаетесь решить. (FWIW, кто-то проголосовал за закрытие вашего вопроса. Лично я очень хотел бы, чтобы этот или аналогичный вопрос был сохранен).

— Стефан Ласевски

Я не уверен, как сделать вопрос более ясным. Я также не думаю, что @ voretaq7 на самом деле отвечает на вопросы, а скорее предлагает альтернативный метод. Вопрос действительно в том, что предлагает тема - как люди разворачивают порты FreeBSD в многоузловой среде.

— Впетерссон

13

Я никогда не был полностью удовлетворен системой портов в большой среде - всегда кажется, что вам нужно применить какое-то внешнее управление для того, чтобы она работала хорошо.

Мои лучшие советы (в порядке возрастания предпочтений, «худшее» решение «лучшее» решение):

Если вы строите на каждом хосте, не надо .
Если вам нужно, не делайте этого по NFS с монтируемыми на чтение и запись монтируемыми устройствами, как вы описали: обычно вы можете доверять портам «Делать правильные вещи» и не топать по дереву портов, если вы предоставляете альтернативные рабочие каталоги, но всегда лучше Будьте осторожны, чем потом сожалейте: запустите локальное зеркало CVS / csup и скопируйте все ваши хосты из этого ящика, затем соберите их локально, как если бы это были отдельные машины.
Да, я знаю, это означает, что на хостах должно быть больше дискового пространства и дополнительный шаг. Это также почти гарантированно будет без проблем.
Предостережение: Возможно, вы захотите синхронизировать файлы конфигурации пакета (rsync или аналогичные) с назначенного «хоста конфигурации», чтобы обеспечить согласованность на каждой машине (вы можете даже rsync по всему дереву портов, если хотите, вместо использования csup на каждом узле).

Используйте Build Host, создавайте пакеты и устанавливайте их.
Гораздо лучшее решение, чем сборка на каждом отдельном компьютере: используйте хост сборки для создания пакетов и направляйте свои инструменты на эти пакеты.
Это означает сохранение хоста сборки для каждой архитектуры, которую вы запускаете (или кросс-компиляции), но в конечном итоге это лучше для ваших целевых машин (нет больших заданий компиляции, гарантия согласованности)

Используйте инструмент конфигурации / управления системой.
Это решение, с которым я столкнулся - я создаю стандартный образ сервера и использую его в своей среде radmind. Вы можете делать подобные вещи с Puppet или Chef . Это дает все преимущества использования хоста сборки (согласованность, меньшая нагрузка на отдельные серверы) и добавляет преимущества управления конфигурацией.

Предостережение: это работает очень хорошо, только если ваши машины "идентичны" - то есть вы можете установить одинаковый набор портов на всех них. Он может работать, если у вас разные наборы портов, но это существенно увеличивает административные издержки.

Отказ от ответственности: я обслуживаю порт для sysutils/radmind. Да, мне так нравится, что я принял это.

Все это основано на моем опыте управления средами FreeBSD различных размеров (от 1-2 машин до более 100). Инструменты конфигурирования / управления системой, которые поддерживают и поддерживают стандартизированный образ, - действительно лучший способ справиться с этим по моему опыту.

— voretaq7
источник

Хорошие указатели. Я немного поиграл с Puppet в прошлом, и мне это нравится в Ubuntu. Тем не менее, я не уверен, насколько хорошо он играет с FreeBSD. Я еще не попробовал это. Несмотря на это, даже с Puppet, я думаю, что это вызывает Portupgrade, который возвращает нас к исходной точке. Я не вижу другого способа, как это могло бы работать, так как тогда нужно было бы сделать pkg_delete / pkg_add или 'pkg_add -f', что было бы не очень хорошей идеей. Что касается аппаратного обеспечения - все они идентичны, поскольку работают в общедоступном облаке (KVM / Qemu).

— vpetersson

Если ваши аппаратные и базовые программные конфигурации идентичны, я бы предложил что-то вроде Radmind, управляющего всем образом системы. Puppet и Chef являются отличными инструментами, однако, как вы указали, они вызывают базовые двоичные файлы ОС, что оставляет вас в прошлом при использовании хоста сборки и распространения пакетов. Radmind избегает этого, принимая управление на уровне файловой системы («Если это не то, что должно быть здесь, замените или удалите его») вместо того, чтобы пытаться быть суррогатным сисадмином («Запустите эти команды / измените эти файлы, чтобы я мог настроить коробка ").

— voretaq7

Ну, системы имеют идентичное оборудование, но не идентичные конфигурации. Мне придется заглянуть в Radmind, но я не уверен, что это лучший подход. Использование встроенных инструментов должно работать IMHO, поэтому я обращаюсь к сообществу, чтобы узнать, пропустил ли я что-нибудь очевидное. Я едва ли могу быть единственным, кто пытается это сделать.

— vpetersson

Встроенные инструменты определенно DO работу, они просто требуют много помощи (сборки серверов, локальное распределение пакетов и т.д.) - они действительно ориентированы на управление одной машиной, и не масштабируются так, как они могли. Обратите внимание, что я упустил возможность развернуть свой собственный сервер freebsd-update - я никогда не пробовал это больше, чем просто для базовой системы, но это теоретически возможно. Я просто придерживался того, что, как я знаю, работает :)

— voretaq7

Да, это интересная идея на самом деле. Я просто не уверен, что он будет работать с распространением портов-пакетов без особых изменений. Мне действительно любопытно, как сисадмины больших систем управляют этим, поскольку существует множество крупных развертываний FreeBSD. Все ли они катят свое собственное решение? Если так, то это кажется довольно странным и не очень открытым исходным кодом.

— vpetersson

6

Странно, что никто не упомянул ports-mgmt / tinderbox :

Tinderbox - это система сборки пакетов для портов FreeBSD, основанная на официальных скриптах Portbuild, используемых в pointyhat build cluster. Tinderbox был написан Джо Маркус Кларк.

Вы можете определить несколько джейлов (базовых версий системы) и несколько портов. Комбинация jail и porttree называется сборкой. Тюрьма Tinderbox - это не то, что понимается как тюрьма во FreeBSD, это фактически заданный мир в chroot. Tinderbox поддерживает автоматическое отслеживание зависимостей и перестраивает только те пакеты, которые были изменены с момента последнего запуска. Tinderbox поддерживает уведомления по электронной почте о неудачных сборках. Tinderbox также хорошо интегрируется с ccache.

Tinderbox предназначен для простого предоставления пакетов пакетов портов, которые вам нужны, для платформ и архитектур, которые вам нужны. Tinderbox также является отличным инструментом для тестирования новых портов и обновления портов, особенно для тестирования зависимостей и упаковочных листов. Это также полезно для тестирования портов в различных выпусках FreeBSD, поскольку вы можете запускать мир FreeBSD 6.X в качестве тюрьмы на хосте FreeBSD 7.X / 8.X.

Кроме того, переход на pkgng значительно упрощает развертывание пакетов.
Проверьте это на github: https://github.com/pkgng/pkgng

— SaveTheRbtz
источник

1

Хотя это, безусловно, может быть полезно для создания реальных пакетов в разнообразной среде (несколько версий, архитектуры и т. Д.), На самом деле это не решает проблему развертывания пакетов.

— Впетерссон

Tinderbox делает пакеты доступными по HTTP, так что вы можете объединить это с комментариями к ответу voretaq7, чтобы получить решение по развертыванию (например, установить PACKAGEROOT/ PACKAGESITEи использовать radmind или Puppet / Chef).

— Джеймс О'Горман

Да, но сборка и распространение пакетов не проблема. Я могу использовать portupgrade (-p) для сборки пакета и распространения его через NFS (с или без дерева портов). Проблема в том, что эта модель все еще требует либо a) полного дерева портов локально, либо b) дерева портов, экспортированного через NFS, что возвращает нас к проблеме.

— vpetersson

2

Portupgrade будет делать то же, что и вы, если вы собирали из исходного кода или использовали бинарные пакеты - pkg_deleteсначала нужно запустить, а затем установить новую версию. OpenBSD справился с этим лучше, включив опцию обновления в pkg_add. Не уверен насчет Portupgrade, но portmaster может работать только с использованием INDEX, а не полного дерева портов.

— Джеймс О'Горман

1

Правильно, но pkg_delete вряд ли разумный подход. Допустим, вы хотите обновить Ruby, Python или любой другой пакет, который является обязательным условием для большого количества других пакетов. Затем pkg_delete потребует от вас удалить все зависимости, что вряд ли подходит для производственной системы. Portupgrade намного лучше справляется с этим, но, опять же, он не масштабируется.

— Впетерссон

3

Я управлял более чем 100 серверами FreeBSD, просто разделяя / usr только для чтения по хорошо настроенной NFS, перемещая базы данных пакетов из / var в / usr и вставляя ссылки на них (не обязательно, но включает pkg_info и тому подобное). Возможно, были один или два других файла, которые нужно было переместить в одном или другом направлении и создать символическую ссылку, но вся установка заняла у меня около часа, чтобы выяснить это. Это сработало очень и очень хорошо. Если бы я столкнулся с проблемами масштабирования, я бы добавил дополнительные NFS-серверы и разделил бы рабочую нагрузку, но она так и не появилась. Производительность никогда не была проблемой для меня (на самом деле это было здорово), но я полагаю, что вы можете поместить / usr NFS-сервера (или его копию) на md.

— пушинка
источник

Совместное использование файлов встроенных пакетов через NFS (о чем вы говорите?), Безусловно, является еще одним разумным подходом - затем вы можете использовать что-то вроде puppet (или даже собственные скрипты SSH-и-shell) для установки / обновления пакетов. из общего ресурса NFS.

— voretaq7

1

Похоже, что никто, к сожалению, не нашел хорошего решения. Скорее всего, это связано с ограничениями лежащих в основе инструментов.

Вот что я придумал: я отказался от идеи экспорта всего дерева портов. Вместо этого я сдался и поместил полное дерево портов на каждый узел. Затем я смонтировал «пакеты» поверх NFS (чтобы разрешить распространение пакетов).

Я также собираюсь использовать кеширующий прокси (возможно, Squid) для ускорения процесса portnap. Я написал небольшой пост о том, как настроить это в моем блоге.

Ссылки:

— vpetersson
источник