Як ви керуєте та розгортаєте порти FreeBSD у великих умовах?

19

Мені цікаво, як люди розгортають порти FreeBSD у своєму оточенні. Я припускаю, що більшість людей, які використовують FreeBSD, справді використовують порти (і часто португраду для оновлення бінарними файлами). Однак мене цікавить, як у вас є така настройка, оскільки я не задоволений тим, як працюють в останніх версіях. Зараз я запускаю FreeBSD 9.0 і виникають проблеми.

Я налаштував так:

/ usr / ports передається через NFS з одного вузла (з нічним "оновленням portsnap fetch").
Кожен вузол монтує / usr / порти з читанням-записом
Я встановив "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" та "пакети"), але це відчуває себе як велика трата місця (і не кажучи вже про багато непотрібних оновлень).

— vpetersson

vpeterson: Це питання, яке потрібно задати (я зараз заблокований. І +5 голосів і 3 зірки говорить про те, що ми не одні). Можливо, очистіть це питання та викладіть деякі конкретні проблеми, які ви намагаєтеся вирішити. (FWIW, хтось проголосував, щоб закрити ваше запитання. Особисто я дуже хотів би, щоб це чи подібне запитання було збережено).

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

Я не впевнений, як зробити питання більш зрозумілим. Я також не думаю, що @ voretaq7 насправді відповідає на запитання, а скоріше пропонує альтернативний метод. Питання справді полягає в тому, що підказує тема - як люди розгортають порти FreeBSD у багатовузловому середовищі.

— vpetersson

13

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

Мої найкращі поради (з метою зростання переваг, "найгіршого" рішення до "найкращого" рішення):

Якщо ви будуєте кожного хоста, не робіть цього .
Якщо потрібно, не робіть цього над NFS за допомогою кріплення для читання-запису, як ви описуєте: Ви зазвичай можете довіряти портам зробити правильну річ і не тупати по дереву портів, якщо ви надаєте альтернативні робочі каталоги, але завжди краще будьте безпечніші, ніж вибачте: запустіть локальне дзеркало CVS / csup і запускайте всі свої хости з цього вікна, а потім будуйте локально, як би ви були, якби це були окремі машини.
Так, я знаю, це означає мати більше дискового простору на хостах та додатковий крок. Це майже гарантовано без проблем.
Caveat: Напевно, ви хочете синхронізувати файли конфігурації пакета (rsync або подібні) з призначеного "хоста конфігурації", щоб забезпечити послідовність роботи кожної машини (ви навіть можете rsync весь дерево портів, якщо хочете, а не використовувати csup на кожному вузлі).

Скористайте хост побудови, створіть пакети та встановіть їх.
Набагато краще рішення, ніж побудова на кожній окремій машині: використовуйте хост побудови для створення пакетів та наводьте свої інструменти на ці пакунки.
Це означає зберігати хост збірки для кожної запущеної архітектури (або перехресне компілювання), але в кінцевому підсумку приємніше для ваших цільових машин (відсутність великих завдань компіляції, гарантія послідовності)

Використовуйте інструмент для конфігурації / управління системою.
Це рішення, з яким я завершився - я будую стандартне зображення сервера і розгортаю його навколо свого середовища за допомогою radmind. Ви можете робити подібні речі з Лялькою або шеф-кухарем . Це має всі переваги використання хоста побудови (послідовність, менша навантаження на окремі сервери) та додає перевагу управління конфігурацією.

Caveat: Це працює дуже добре, лише якщо ваші машини "ідентичні" - тобто ви можете встановити один і той же набір портів на всіх. Він може працювати, якщо у вас різні набори портів, але це суттєво збільшує адміністративні витрати.

Відмова: Я підтримую порти для sysutils/radmind. Так, мені це дуже подобається, що я його прийняв.

Все це базується на моєму досвіді управління різними розмірами середовищ FreeBSD (від 1-2 машин до понад 100). Інструменти конфігурації / управління системою, які натискають і підтримують стандартизоване зображення, справді є найкращим способом вирішити це з мого досвіду.

— voretaq7
джерело

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

— vpetersson

Якщо ваші апаратні та базові конфігурації програмного забезпечення однакові, я б запропонував щось на зразок radmind, керуючи зображенням всієї системи. Лялька та шеф-кухар - чудові інструменти, однак, як ви зазначили, вони називають основні бінарні файли ОС, що відштовхується від використання хоста побудови та розповсюдження пакетів. radmind уникає цього, переймаючи управління на рівні файлової системи ("Якщо це не те, що тут повинно бути, замініть або видаліть"), а не намагаючись бути сурогатним sysadmin ("Виконайте ці команди / змініть ці файли для мене, щоб налаштувати коробка ").

— voretaq7

Ну, системи мають однакову техніку, але не однакові конфігурації. Мені доведеться заглянути в Radmind, але я не впевнений, чи це найкращий підхід. Використання вбудованих інструментів повинно працювати IMHO, саме тому я звертаюся до спільноти, щоб побачити, чи я пропустив щось очевидне. Навряд чи я єдиний, хто намагається це зробити.

— vpetersson

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

— voretaq7

Так, насправді цікава ідея. Я просто не впевнений, чи спрацювало б воно з розповсюдженням портів-пакетів без особливих модифікацій. Мені дуже цікаво, як системні адміністратори великих систем керують цим, оскільки існує велика кількість великих розгортань FreeBSD. Чи всі вони самостійно вирішують рішення? Якщо так, то це виглядає досить дивним і не дуже відкритим вихідним кодом.

— vpetersson

6

Дивно, що ніхто не згадав про порти-mgmt / tinderbox :

Tinderbox - це система побудови пакетів для портів FreeBSD, заснована на офіційних сценаріях Portbuild, що використовуються на кластері pointyhat building. Tinderbox написав Джо Маркус Кларк.

Ви можете визначити декілька в'язниць (базові версії системи) та декілька портрейдів. Поєднання в'язниці і портрета називається складанням. В'язниця Tinderbox - це не те, що розуміється як в'язниця у FreeBSD, це насправді даний світ у хроторі. Tinderbox підтримує автоматичне відстеження залежностей і лише відновлює пакети, які змінилися з останнього запуску. Tinderbox підтримує сповіщення електронною поштою про невдалі збірки. Tinderbox також добре інтегрується з кешем.

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

Також перехід на pkgng значно спрощує розгортання пакету.
Перевірте це на github: https://github.com/pkgng/pkgng

— SaveTheRbtz
джерело

1

Хоча це, безумовно, може бути зручним для побудови фактичних пакетів у різноманітних умовах (декілька версій, архітектури тощо), це насправді не вирішує проблему розгортання пакетів.

— vpetersson

Tinderbox робить пакети доступними через HTTP, так що ви можете поєднати це з коментарями до відповіді voretaq7, щоб отримати рішення щодо розгортання (наприклад, встановити PACKAGEROOT/ PACKAGESITEі використовувати radmind або Puppet / Chef).

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

Так, але створення та розповсюдження пакетів не є проблемою. Я можу використовувати portupgrade (-p) для складання пакету та розповсюдження їх через NFS (з деревом портів або без нього). Проблема полягає в тому, що ця модель все ще вимагає або а) повного дерева портів локально, або б) дерева портів, експортованих через NFS, що повертає нас до проблем.

— vpetersson

2

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

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

1

Правильно, але pkg_delete навряд чи є розумним підходом. Скажімо, ви хочете оновити Ruby, Python або будь-який інший пакет, що є необхідною умовою для великої кількості інших пакетів. Тоді pkg_delete вимагатиме від вас видалити всі залежності, що навряд чи є варіантом для виробничої системи. Portupgrade робить набагато кращу роботу з цим, але, знову ж таки, це не здається масштабом.

— vpetersson

3

Я керував 100+ серверами FreeBSD, просто обмінюючись / usr тільки для читання над добре налаштованою NFS, переміщуючи бази даних пакетів з / var в / usr і посилаючись на них (не суворо потрібно, але дозволяє pkg_info і таке інше). Можливо, був один або два інші файли, які потрібно було перемістити в одну або іншу сторону і посилати на них, але на цілі налаштування мені знадобилося близько години. Це працювало дуже, дуже добре. Якби у мене виникли проблеми зі масштабуванням, я б додав додаткові сервери NFS і розділив навантаження, але це ніколи не з'явилося. Продуктивність ніколи не була проблемою для мене (насправді вона була чудовою), але я вважаю, що ви можете поставити сервер NFS / usr (або його копію) на md.

— нечітка
джерело

Обмін вбудованими файлами пакунків через NFS (про що це звучить, як ви говорите?), Безумовно, ще один розумний підхід - ви можете використовувати щось на зразок лялькових (або навіть домашніх сценаріїв SSH-і-оболонок) для встановлення / оновлення пакетів від частки НФС.

— voretaq7

1

Схоже, ніхто, на жаль, не отримав хорошого рішення. Швидше за все, це пов'язано з обмеженнями в інструментах, що лежать в основі.

Ось що я придумав: я вирізав ідею експортувати все порт-дерево. Натомість я поступився і поставив повне дерево портів на кожен вузол. Потім я встановив "пакети" над NFS (щоб увімкнути розповсюдження пакетів).

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

Список літератури:

— vpetersson
джерело