Wie managen und implementieren Sie die FreeBSD-Ports in einer großen Umgebung?

19

Ich bin gespannt, wie Leute die Ports von FreeBSD in ihrer Umgebung bereitstellen. Ich gehe davon aus, dass die meisten Leute, die FreeBSD verwenden, tatsächlich Ports verwenden (und Portupgrade häufig für Upgrades mit Binärdateien). Ich bin jedoch daran interessiert, wie Sie dieses Setup haben, da ich mit der Funktionsweise in neueren Versionen nicht zufrieden bin. Ich lasse jetzt FreeBSD 9.0 laufen und habe Probleme.

Ich habe die Dinge wie folgt eingerichtet:

/ usr / ports wird über NFS von einem Knoten aus gemeinsam genutzt (mit nächtlichem 'portsnap fetch update').
Jeder Knoten stellt / usr / ports mit Lese- / Schreibzugriff bereit
Ich habe "WRKDIRPREFIX = / usr / tmp" in /etc/make.conf auf allen Knoten gesetzt
Ich habe den Portsnap so konfiguriert, dass er einen lokalen Index verwendet, indem ich Folgendes zu /usr/local/etc/pkgtools.conf hinzufüge:

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

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

Ich kann erfolgreich ausführen portupgrade -p package, um ein Paket zu erstellen und dann portupgrade -P packagedie Binärdatei auf den anderen Knoten zu installieren.

Manchmal erhalte ich jedoch das folgende Problem: /var/db/INDEX.local:23265:dbm_store failed

Ich kann mir keine anderen Optimierungen für das System vorstellen, da sich der Index jetzt lokal befindet und das einzige, was wirklich exportiert wird, der Ports-Tree ist und von den Knoten nie etwas darauf geschrieben wird.

freebsd

— vpetersson
quelle

Eine Möglichkeit wäre, auf jedem Knoten einen vollständigen lokalen Port-Tree zu haben (und möglicherweise nur "distfiles" und "packages" zu mounten), aber dies fühlt sich wie eine massive Verschwendung von Speicherplatz an (und ganz zu schweigen von vielen unnötigen Updates).

— vpetersson

vpeterson: Dies ist eine Frage, die gestellt werden muss (ich bin momentan blockiert. Und +5 Stimmen und 3 Sterne deuten darauf hin, dass wir nicht alleine sind). Räumen Sie diese Frage möglicherweise auf und geben Sie einige spezifische Probleme an, die Sie lösen möchten. (FWIW, jemand hat gestimmt, um Ihre Frage zu schließen. Persönlich würde ich sehr gerne sehen, dass diese oder eine ähnliche Frage gespeichert wird.)

— Stefan Lasiewski

Ich bin mir nicht sicher, wie ich die Frage klarer stellen soll. Ich denke auch nicht, dass @ voretaq7 tatsächlich die Fragen beantwortet, sondern eine alternative Methode vorschlägt. Die Frage ist wirklich, was das Thema vorschlägt - wie stellen die Leute die Ports von FreeBSD in einer Umgebung mit mehreren Knoten bereit?

— vpetersson

13

Ich war mit dem Ports-System in einer großen Umgebung noch nie vollständig zufrieden. Es scheint immer so, als müssten Sie ein externes Management anwenden, damit es funktioniert.

Meine besten Tipps (in aufsteigender Reihenfolge, "schlechteste" Lösung zu "beste" Lösung):

Wenn Sie auf jedem Host aufbauen, tun Sie das nicht . Sie möchten wahrscheinlich die Paketkonfigurationsdateien (rsync oder ähnliches) von einem festgelegten "Konfigurationshost" synchronisieren, um die Konsistenz auf jedem Computer zu gewährleisten (Sie können sogar den gesamten Portbaum synchronisieren, anstatt csup auf jedem Knoten zu verwenden).
Wenn Sie dies tun müssen, tun Sie dies nicht über NFS mit Lese- / Schreib-Mounts, wie Sie es beschreiben: Normalerweise können Sie darauf vertrauen, dass die Ports das Richtige tun und nicht in der Ports-Struktur stampfen, wenn Sie alternative Arbeitsverzeichnisse bereitstellen, aber dies ist immer besser Gehen Sie auf Nummer sicher: Führen Sie einen lokalen CVS / csup-Spiegel aus und konfigurieren Sie alle Ihre Hosts von diesem Computer aus. Erstellen Sie dann lokal, als wären es einzelne Computer.
Ja, ich weiß, dies bedeutet mehr Speicherplatz auf den Hosts und einen zusätzlichen Schritt. Es ist auch fast garantiert problemlos.
Vorbehalt:

Verwenden Sie einen Build-Host, erstellen Sie Pakete und installieren Sie diese.
Eine viel bessere Lösung, als auf jedem einzelnen Computer zu bauen: Verwenden Sie einen Build-Host, um Pakete zu erstellen, und richten Sie Ihre Tools auf diese Pakete.
Dies bedeutet, dass Sie für jede Architektur, die Sie ausführen (oder die Sie übergreifend kompilieren), einen Build-Host bereithalten müssen. Letztendlich ist dies jedoch für Ihre Zielcomputer angenehmer (keine großen Kompilierungsaufträge, Garantie für Konsistenz).

Verwenden Sie ein Konfigurations- / Systemverwaltungstool.
Dies ist die Lösung, mit der ich zum Abschluss gekommen bin: Ich erstelle ein Standard-Server-Image und setze es in meiner Umgebung ein radmind. Sie können ähnliche Dinge mit Puppet oder Chef machen . Dies bietet alle Vorteile eines Build-Hosts (Konsistenz, geringere Belastung der einzelnen Server) und den Vorteil des Konfigurationsmanagements.

Vorsichtsmaßnahme: Dies funktioniert nur dann sehr gut, wenn Ihre Computer "identisch" sind. Sie können also auf allen Computern die gleichen Ports installieren. Es kann funktionieren, wenn Sie verschiedene Portgruppen haben, aber dies erhöht den Verwaltungsaufwand erheblich.

Haftungsausschluss: Ich bin der Portbetreuer für sysutils/radmind. Ja, ich mag es so sehr, dass ich es adoptiert habe.

All dies basiert auf meiner Erfahrung mit der Verwaltung von FreeBSD-Umgebungen unterschiedlicher Größe (von 1-2 Maschinen bis zu über 100). Nach meiner Erfahrung sind Konfigurations- / Systemverwaltungstools, die ein standardisiertes Image erstellen und beibehalten, der beste Weg, damit umzugehen.

— voretaq7
quelle

Gute Hinweise. Ich habe in der Vergangenheit ein bisschen mit Puppet gespielt und liebe es auf Ubuntu. Ich bin mir jedoch nicht sicher, wie gut es mit FreeBSD funktioniert. Das muss ich erst noch ausprobieren. Unabhängig davon, auch mit Puppet, denke ich, dass es Portupgrade erfordert, was uns zurück zum ersten Platz bringt. Ich sehe keine andere Möglichkeit, wie es funktionieren könnte, da dann pkg_delete / pkg_add oder 'pkg_add -f' ausgeführt werden müssten, was keine gute Idee wäre. Was die Hardware betrifft, sind sie alle identisch, da sie in einer öffentlichen Cloud (KVM / Qemu) ausgeführt werden.

— vpetersson

Wenn Ihre Hardware- und Basissoftwarekonfigurationen identisch sind, würde ich so etwas wie radmind vorschlagen, um das gesamte Systemimage zu verwalten. Puppet und Chef sind großartige Tools. Sie haben jedoch darauf hingewiesen, dass sie die zugrunde liegenden Betriebssystem-Binärdateien aufrufen, sodass Sie keinen Build-Host mehr verwenden und keine Pakete mehr verteilen können. radmind vermeidet dies, indem es die Verwaltung auf Dateisystemebene übernimmt ("Wenn es nicht das ist, was hier sein soll, ersetzen oder entfernen"), anstatt zu versuchen, ein Ersatz-Sysadmin zu sein ("Führen Sie diese Befehle aus / ändern Sie diese Dateien für mich, um das zu konfigurieren Box").

— Voretaq7

Nun, die Systeme haben identische Hardware, aber nicht identische Konfigurationen. Ich muss mich um Radmind kümmern, bin mir aber nicht sicher, ob das der beste Ansatz ist. Die Verwendung der integrierten Tools sollte meiner Meinung nach funktionieren. Deshalb wende ich mich an die Community, um festzustellen, ob ich etwas Offensichtliches verpasst habe. Ich kann kaum der Einzige sein, der das versucht.

— vpetersson

Die integrierten Tools auf jeden Fall DO Arbeit, die sie benötigen nur eine Menge Hilfe (Build - Server, lokale Verteilung von Paketen, etc.) - Sie sind wirklich auf die Führung einer Maschine ausgerichtet und skaliert nicht so gut wie sie konnten. Beachten Sie, dass ich die Möglichkeit, Ihren eigenen freebsd-update-Server zu rollen, weggelassen habe - ich habe dies nie für mehr als nur das Basissystem versucht, aber es ist theoretisch möglich. Ich habe mich nur an die Sachen gehalten, von denen ich weiß, dass sie funktionieren :)

— voretaq7

Ja, das ist eine interessante Idee. Ich bin mir nur nicht sicher, ob es mit dem Verteilen von Ports-Paketen ohne große Modifikationen funktionieren würde. Ich bin wirklich neugierig, wie Sysadmins großer Systeme dies verwalten, da es viele große Implementierungen von FreeBSD gibt. Rollen alle ihre eigene Lösung? Wenn ja, fühlt sich das ziemlich seltsam und nicht sehr Open Source-artig an.

— Vpetersson

6

Seltsam, dass niemand ports-mgmt / tinderbox erwähnt hat :

Tinderbox ist ein Paketerstellungssystem für FreeBSD-Ports, das auf offiziellen Portbuild-Skripten basiert, die auf pointyhat building cluster verwendet werden. Tinderbox wurde von Joe Marcus Clarke geschrieben.

Sie können mehrere Jails (Basissystemversionen) und mehrere Portstrees definieren. Die Kombination aus Gefängnis und Portstree wird Build genannt. Ein Tinderbox-Gefängnis ist kein Gefängnis in FreeBSD, sondern eine gegebene Welt in einer Chroot. Tinderbox unterstützt die automatische Nachverfolgung von Abhängigkeiten und erstellt nur Pakete neu, die sich seit der letzten Ausführung geändert haben. Tinderbox unterstützt die E-Mail-Benachrichtigung bei fehlgeschlagenen Builds. Tinderbox lässt sich auch gut in Ccache integrieren.

Tinderbox wurde entwickelt, um auf einfache Weise die benötigten Portpakete für die von Ihnen benötigten Plattformen und Architekturen bereitzustellen. Tinderbox eignet sich auch hervorragend zum Testen neuer Ports und von Port-Upgrades, insbesondere zum Testen von Abhängigkeiten und Packlisten. Es ist auch nützlich, um Ports auf verschiedenen Releases von FreeBSD zu testen, da Sie FreeBSD 6.X world als Jail auf FreeBSD 7.X / 8.X-Host ausführen können.

Der Wechsel zu pkgng vereinfacht die Paketbereitstellung erheblich.
Schau es dir auf github an: https://github.com/pkgng/pkgng

— SaveTheRbtz
quelle

1

Dies ist sicherlich nützlich, um die eigentlichen Pakete in einer unterschiedlichen Umgebung (mehrere Versionen, Architekturen usw.) zu erstellen, löst jedoch nicht wirklich das Problem der Bereitstellung der Pakete.

— vpetersson

Tinderbox stellt die Pakete über HTTP zur Verfügung, sodass Sie diese mit den Kommentaren zur Antwort von voretaq7 kombinieren können, um Ihre Bereitstellungslösung zu erhalten (z. B. set PACKAGEROOT/ PACKAGESITEund verwenden Sie radmind oder Puppet / Chef).

— James O'Gorman

Ja, aber das Erstellen und Verteilen von Paketen ist nicht das Problem. Ich kann portupgrade (-p) verwenden, um das Paket zu erstellen und über NFS zu verteilen (mit oder ohne Ports-Tree). Das Problem ist, dass dieses Modell weiterhin entweder a) einen vollständigen lokalen Port-Tree oder b) einen über NFS exportierten Port-Tree benötigt, was uns wieder zum eigentlichen Problem führt.

— vpetersson

2

Portupgrade wird genau das tun, was Sie tun müssen, wenn Sie aus dem Quellcode pkg_deleteerstellen oder Binärpakete verwenden - muss zuerst ausgeführt und dann die neue Version installiert werden. OpenBSD hat dies besser gemeistert, indem eine Upgrade-Option hinzugefügt wurde pkg_add. Portupgrade ist nicht sicher, aber portmaster kann nur mit INDEX und nicht mit einem vollständigen Portbaum arbeiten.

— James O'Gorman

1

Richtig, aber pkg_delete ist kaum ein vernünftiger Ansatz. Angenommen, Sie möchten Ruby, Python oder ein anderes Paket aktualisieren, das eine Voraussetzung für eine große Anzahl anderer Pakete ist. pkg_delete würde dann erfordern, dass Sie alle Abhängigkeiten löschen, was für ein Produktionssystem kaum eine Option ist. Portupgrade macht hier einen weitaus besseren Job, aber auch hier scheint es nicht skalierbar zu sein.

— vpetersson

3

Ich habe mehr als 100 FreeBSD-Server verwaltet, indem ich einfach / usr schreibgeschützt über gut abgestimmtes NFS ausgetauscht, die Paketdatenbanken von / var nach / usr verschoben und mit ihnen verknüpft habe (nicht unbedingt erforderlich, aber pkg_info und so weiter aktiviert). Es gab vielleicht ein oder zwei andere Dateien, die in die eine oder andere Richtung verschoben und mit Symbolen verknüpft werden mussten, aber das gesamte Setup hat ungefähr eine Stunde gedauert, bis ich es herausgefunden habe. Es hat sehr, sehr gut funktioniert. Wenn ich auf Skalierungsprobleme gestoßen wäre, hätte ich zusätzliche NFS-Server hinzugefügt und die Arbeitslast aufgeteilt, aber es ist nie aufgetreten. Leistung war nie ein Problem für mich (in der Tat war es großartig), aber ich nehme an, Sie könnten den / usr des NFS-Servers (oder eine Kopie davon) auf einen MD setzen.

— Flaum
quelle

Das Freigeben der erstellten Paketdateien über NFS (was ist der Sinn des Wortes?) Ist sicherlich ein weiterer vernünftiger Ansatz. Sie können dann so etwas wie Puppet (oder sogar selbst erstellte SSH- und Shell-Skripte) zum Installieren / Aktualisieren von Paketen verwenden von der NFS-Freigabe.

— Voretaq7

1

Es sieht so aus, als hätte dies leider niemand gut gelöst. Dies liegt höchstwahrscheinlich an Einschränkungen der Unterlegwerkzeuge.

Folgendes habe ich mir ausgedacht: Ich habe die Idee, den gesamten Ports-Tree exportieren zu lassen, verworfen. Stattdessen habe ich nachgegeben und jedem Knoten einen vollständigen Portbaum hinzugefügt. Ich habe dann "Pakete" über NFS eingehängt (um die Verteilung von Paketen zu ermöglichen).

Ich beabsichtige auch, einen Caching-Proxy (wahrscheinlich Squid) zu verwenden, um den Portnap-Prozess zu beschleunigen. Ich habe in meinem Blog einen kurzen Beitrag darüber geschrieben, wie man dies einrichtet .

Verweise:

— vpetersson
quelle