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

19

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.

freebsd

— vpetersson
źródło

Jedną z opcji byłoby posiadanie pełnego lokalnego drzewa portów na każdym węźle (i być może po prostu montowanie „plików distfiles” i „pakietów”), ale wydaje się to ogromną stratą miejsca (i nie wspominając o wielu niepotrzebnych aktualizacjach).

— vpetersson

vpeterson: To pytanie należy zadać (jestem teraz zablokowany. +5 głosów i 3 gwiazdki sugerują, że nie jesteśmy sami). Być może posprzątaj to pytanie i podaj konkretne problemy, które próbujesz rozwiązać. (FWIW, ktoś głosował za zamknięciem twojego pytania. Osobiście bardzo chciałbym zobaczyć to lub podobne pytanie zapisane).

— Stefan Lasiewski

Nie jestem pewien, jak wyjaśnić pytanie. Nie sądzę też, że @ voretaq7 faktycznie odpowiada na pytania, ale sugeruje alternatywną metodę. Pytanie naprawdę dotyczy tego, co sugeruje temat - w jaki sposób ludzie wdrażają porty FreeBSD w środowisku z wieloma węzłami.

— vpetersson

13

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ć.

— voretaq7
źródło

Dobre wskazówki. W przeszłości grałem z Puppet i uwielbiam to na Ubuntu. Nie jestem jednak pewien, jak dobrze gra z FreeBSD. Jeszcze tego nie wypróbowałem. Niezależnie od tego, nawet w przypadku Puppet, myślę, że wymaga Portupgrade, który zabiera nas z powrotem do pierwszego poziomu. Nie widzę innego sposobu, by to działało, ponieważ musiałoby to zrobić pkg_delete / pkg_add lub 'pkg_add -f', co nie byłoby dobrym pomysłem. Jeśli chodzi o sprzęt - wszystkie są identyczne, ponieważ działają w chmurze publicznej (KVM / Qemu).

— vpetersson

Jeśli twój sprzęt i podstawowe konfiguracje oprogramowania są identyczne, sugerowałbym coś w rodzaju radmind, zarządzającego całym obrazem systemu. Puppet i Chef są świetnymi narzędziami, jednak, jak zauważyłeś, nazywają się plikami binarnymi systemu operacyjnego, co pozwala na powrót do korzystania z hosta kompilacji i dystrybucji pakietów. radmind unika tego, przejmując zarządzanie na poziomie systemu plików („Jeśli nie ma tego, co powinno tu być, zamień lub usuń”) zamiast próbować być zastępczym sysadminem („Uruchom te polecenia / zmień te pliki, aby skonfigurować pudełko").

— voretaq7

Systemy mają identyczny sprzęt, ale nie identyczne konfiguracje. Będę musiał spojrzeć na Radminda, ale nie jestem pewien, czy to najlepsze podejście. Korzystanie z wbudowanych narzędzi powinno działać IMHO, dlatego zwracam się do społeczności, aby sprawdzić, czy coś przeoczyłem. Nie mogę być jedynym, który próbuje to zrobić.

— vpetersson

Wbudowany narzędzi zdecydowanie DO pracę, po prostu wymaga dużo pomocy (serwery budować, lokalnej dystrybucji opakowań, etc.) - są one bardzo nastawione na zarządzanie jedną maszynę, a nie skala, jak mogli. Zauważ, że zrezygnowałem z opcji rozwijania własnego serwera aktualizacji freebsd - nigdy nie próbowałem tego więcej niż tylko system podstawowy, ale teoretycznie jest to możliwe. Właśnie

— trzymałem

Tak, to naprawdę ciekawy pomysł. Po prostu nie jestem pewien, czy działałoby to z dystrybucją pakietów portów bez większych modyfikacji. Jestem naprawdę ciekawy, jak zarządzają tym administratorzy dużych systemów, ponieważ istnieje wiele dużych wdrożeń FreeBSD. Czy wszystkie z nich opracowują własne rozwiązanie? Jeśli tak, wydaje się to dość dziwne i niezbyt otwarte.

— vpetersson

6

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

— SaveTheRbtz
źródło

1

Chociaż z pewnością może to być przydatne do budowania rzeczywistych pakietów w zróżnicowanym środowisku (wiele wersji, architektur itp.), To tak naprawdę nie rozwiązuje problemu wdrażania pakietów.

— vpetersson,

Tinderbox udostępnia pakiety przez HTTP, więc możesz połączyć to z komentarzami do odpowiedzi voretaq7, aby uzyskać rozwiązanie do wdrożenia (np. Ustaw PACKAGEROOT/ PACKAGESITEi użyj radmind lub Puppet / Chef).

— James O'Gorman

Tak, ale budowanie i dystrybucja pakietów nie stanowi problemu. Mogę użyć portupgrade (-p) do zbudowania pakietu i rozpowszechnienia go przez NFS (z drzewem portów lub bez). Problem polega na tym, że ten model nadal wymaga albo a) lokalnego drzewa portów lokalnie, albo b) drzewa portów wyeksportowanego przez NFS, co przywraca nas do problemu.

— vpetersson

2

Portupgrade zrobi dokładnie to, co powinieneś zrobić, jeśli budujesz ze źródła lub używasz pakietów binarnych - pkg_deletenajpierw musisz uruchomić, a następnie zainstalować nową wersję. OpenBSD poradził sobie z tym lepiej, włączając opcję aktualizacji w pkg_add. Nie jestem pewien co do Portupgrade, ale kapitan portu może działać tylko przy użyciu INDEX, a nie pełnego drzewa portów.

— James O'Gorman

1

Racja, ale pkg_delete nie jest rozsądnym podejściem. Powiedzmy, że chcesz zaktualizować Ruby, Python lub dowolny inny pakiet, który jest niezbędny dla wielu innych pakietów. pkg_delete wymaga wtedy usunięcia wszystkich zależności, co nie jest opcją dla systemu produkcyjnego. Portupgrade radzi sobie z tym znacznie lepiej, ale znowu nie wydaje się skalować.

— vpetersson,

3

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.

— kędziory
źródło

Udostępnianie wbudowanych plików pakietów przez NFS (co brzmi, jak mówisz?) Jest z pewnością innym rozsądnym podejściem - możesz użyć czegoś takiego jak marionetka (lub nawet własne skrypty SSH i powłoki) do zainstalowania / uaktualnienia pakietów z udziału NFS.

— voretaq7

1

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:

— vpetersson
źródło