Jak zarządzasz i wdrażasz porty FreeBSD w dużym środowisku?

Jestem ciekawy, jak ludzie wdrażają porty FreeBSD w swoim środowisku. Zakładam, że większość ludzi korzystających z FreeBSD faktycznie używa portów (i często portupgrade do aktualizacji przy pomocy plików binarnych). Jestem jednak zainteresowany tym, jak masz tę konfigurację, ponieważ nie jestem zadowolony z tego, jak działają rzeczy w ostatnich wersjach. Korzystam teraz z FreeBSD 9.0 i mam problemy.

Skonfigurowałem następujące rzeczy:

• / usr / porty są udostępniane przez NFS z jednego węzła (z nocną „aktualizacją pobierania portów portów”).
• Każdy węzeł montuje / usr / porty z odczytem i zapisem
• Ustawiłem „WRKDIRPREFIX = / usr / tmp” w /etc/make.conf na wszystkich węzłach
• Skonfigurowałem Portsnap do korzystania z lokalnego indeksu, dodając następujące elementy do /usr/local/etc/pkgtools.conf:

ENV['LOCALINDICES'] ||= '/var/db'

ENV['PORTS_INDEX'] ||= ENV['LOCALINDICES'] + '/INDEX.local'

Mogę pomyślnie uruchomić, portupgrade -p packageaby zbudować pakiet, a następnie portupgrade -P packagezainstalować plik binarny na innych węzłach.

Jednak czasami pojawia się następujący problem: /var/db/INDEX.local:23265:dbm_store failed

Nie mogę wymyślić żadnych innych optymalizacji, które mogę zrobić dla systemu, ponieważ indeks znajduje się teraz lokalnie, a jedyną naprawdę wyeksportowaną rzeczą jest drzewo portów i nic nie jest tam zapisywane z węzłów.

Nigdy nie byłem w pełni usatysfakcjonowany systemem portów w dużym środowisku - zawsze wydaje się, że musisz zastosować do niego jakieś zewnętrzne zarządzanie, aby działało dobrze.

Moje najlepsze wskazówki (w kolejności rosnącej preferencji, „najgorsze” rozwiązanie dla „najlepszego” rozwiązania):

Jeśli budujesz na każdym hoście, nie rób tego .
Jeśli musisz, nie rób tego przez NFS z podłączeniami do odczytu i zapisu, tak jak to opisujesz: zazwyczaj możesz zaufać portom, że wykonają właściwą czynność i nie stąpają po drzewie portów, jeśli udostępniasz alternatywne katalogi robocze, ale zawsze lepiej jest bądź bezpieczny: przeprasz lokalny serwer lustrzany CVS / csup i csup wszystkie hosty z tego pola, a następnie buduj lokalnie tak, jak gdyby były to pojedyncze maszyny.
Tak, wiem, że oznacza to więcej miejsca na dysku na hostach i dodatkowy krok. Prawie gwarantuje też, że jest bezproblemowa.
Zastrzeżenie: Prawdopodobnie chcesz zsynchronizować pliki konfiguracji pakietu (rsync lub podobne) z wyznaczonego „hosta konfiguracji”, aby zapewnić spójność na każdym komputerze (możesz nawet zsynchronizować całe drzewo portów, jeśli chcesz, zamiast używać csup na każdym węźle).

Użyj kompilatora, utwórz pakiety i zainstaluj je.
O wiele lepsze rozwiązanie niż budowanie na każdym komputerze: użyj hosta kompilacji, aby utworzyć pakiety i skieruj swoje narzędzia na te pakiety.
Oznacza to utrzymanie hosta kompilacji dla każdej uruchomionej architektury (lub kompilacji krzyżowej), ale ostatecznie jest ładniejszy dla komputerów docelowych (brak dużych zadań kompilacji, gwarancja spójności)

Użyj narzędzia do konfiguracji / zarządzania systemem.
To rozwiązanie, na którym się skończyłem - buduję standardowy obraz serwera i wdrażam go w moim środowisku, używając radmind. Możesz robić podobne rzeczy z Puppet lub Chef . Ma to wszystkie zalety korzystania z hosta kompilacji (spójność, mniejsze obciążenie poszczególnych serwerów) i dodaje korzyści z zarządzania konfiguracją.

Uwaga: Działa to naprawdę dobrze tylko wtedy, gdy twoje maszyny są „identyczne” - to znaczy, że możesz zainstalować ten sam zestaw portów na wszystkich z nich. To może działać, jeśli mają różne zestawy portów, ale znacznie zwiększa koszty administracyjne.

Oświadczenie: Jestem opiekunem portu sysutils/radmind. Tak, podoba mi się to, że go adoptowałem.

Wszystko to opiera się na moim doświadczeniu w zarządzaniu środowiskami FreeBSD różnej wielkości (od 1-2 komputerów do ponad 100). Narzędzia konfiguracji / zarządzania systemem, które popychają i utrzymują znormalizowany obraz, są naprawdę najlepszym sposobem, aby sobie z tym poradzić.

Dziwne, że nikt nie wspomniał o portach-mgmt / tinderbox :

Tinderbox to system do budowania pakietów dla portów FreeBSD, oparty na oficjalnych skryptach Portbuild używanych w klastrze pointyhat. Tinderbox został napisany przez Joe Marcusa Clarke'a.

Możesz zdefiniować wiele więzień (podstawowe wersje systemu) i wiele portów. Połączenie więzienia i portstree nazywa się kompilacją. Więzienie Tinderbox nie jest tym, co w FreeBSD jest rozumiane jako więzienie, w rzeczywistości jest to dany świat w chroot. Tinderbox obsługuje automatyczne śledzenie zależności i odbudowuje tylko pakiety, które zmieniły się od ostatniego uruchomienia. Tinderbox obsługuje powiadomienia e-mail o nieudanych kompilacjach. Tinderbox dobrze integruje się również z ccache.

Tinderbox został zaprojektowany z myślą o łatwym dostarczaniu pakietów portów, których potrzebujesz, dla potrzebnych platform i architektur. Tinderbox jest także doskonałym narzędziem do testowania nowych portów i aktualizacji portów, szczególnie do testowania zależności i list pakowania. Przydaje się również do testowania portów w różnych wersjach FreeBSD, ponieważ można uruchomić świat FreeBSD 6.X jako więzienie na hoście FreeBSD 7.X / 8.X.

Również przejście na pkgng znacznie upraszcza wdrażanie pakietów.
Sprawdź to na github: https://github.com/pkgng/pkgng

Zarządzałem ponad 100 serwerami FreeBSD, po prostu udostępniając / usr tylko do odczytu przez dobrze dostrojony NFS, przenosząc pakiety baz danych z / var do / usr i łącząc się z nimi (nie jest to absolutnie konieczne, ale umożliwia pkg_info i tym podobne). Możliwe, że był jeden lub dwa inne pliki, które musiały zostać przeniesione w jednym lub drugim kierunku i dowiązane symbolicznie, ale cała konfiguracja zajęła mi około godziny. Działa bardzo, bardzo dobrze. Gdybym napotkał problemy ze skalowaniem, dodałbym dodatkowe serwery NFS i podzieliłbym obciążenie pracą, ale nigdy się nie pojawił. Wydajność nigdy nie była dla mnie problemem (w rzeczywistości była świetna), ale przypuszczam, że możesz umieścić / usr serwera NFS (lub jego kopię) na MD.

Wygląda na to, że nikt niestety nie ma dobrego rozwiązania tego problemu. Najprawdopodobniej wynika to z ograniczeń w narzędziach podkładowych.

Oto, co wymyśliłem: odrzuciłem pomysł, aby wyeksportować całe drzewo portów. Zamiast tego poddałem się i położyłem pełne drzewo portów na każdym węźle. Następnie zamontowałem „pakiety” na NFS (aby umożliwić dystrybucję pakietów).

Zamierzam również użyć buforującego serwera proxy (prawdopodobnie Squid), aby przyspieszyć proces portnap. Napisałem krótki post o tym, jak to skonfigurować na moim blogu.

Bibliografia:

• Pomysł na proxy
• Implementacja proxy HTTP w portach portów (a raczej globalnie)