Frage Wie verwalten und implementieren Sie die Ports von FreeBSD in einer großen Umgebung?


Ich bin gespannt, wie Leute die Ports von FreeBSD in ihrer Umgebung einsetzen. Ich nehme an, dass die meisten Leute, die FreeBSD benutzen, tatsächlich Ports benutzen (und oft upgraded für das Upgrade mit Binaries). Ich bin jedoch daran interessiert, wie Sie dieses Setup haben, da ich mit der Funktionsweise der letzten Versionen nicht zufrieden bin. Ich laufe jetzt FreeBSD 9.0 und habe Probleme.

Ich habe die Dinge wie folgt eingerichtet:

  • / usr / ports wird über NFS von einem Knoten aus geteilt (mit nächtlichem 'portsnap fetch update').
  • Jeder Knoten mountet / usr / ports mit Lese- / Schreibzugriff
  • 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 laufen portupgrade -p package ein Paket zu bauen und dann portupgrade -P package um die Binärdatei auf den anderen Knoten zu installieren.

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

Ich kann mir keine anderen Optimierungen vorstellen, die ich mit dem System machen kann, da der Index jetzt lokal residiert und das einzige, was wirklich exportiert wird, ist der Ports-Baum, und von den Knoten wird nie etwas dorthin geschrieben.


19
2018-02-28 16:45


Ursprung


Eine Option wäre, einen vollständigen lokalen Ports-Baum auf jedem Knoten zu haben (und vielleicht nur "distfiles" und "packages" mounten), aber das fühlt sich an wie eine riesige Platzverschwendung (und nicht zu vergessen viele unnötige Updates). - vpetersson
Vpeterson: Dies ist eine Frage, die gefragt werden muss (ich bin jetzt blockiert. Und +5 Stimmen und 3 Sterne legen nahe, dass wir nicht alleine sind). Vielleicht bereinigen Sie diese Frage und geben Sie einige spezifische Probleme an, die Sie zu lösen versuchen. (FWIW, jemand hat dafür gestimmt, deine Frage zu schließen. Persönlich würde ich gerne sehen, dass dies oder eine ähnliche Frage gespeichert wird). - Stefan Lasiewski
Ich bin mir nicht sicher, wie ich die Frage klarer machen soll. Ich glaube auch nicht, dass @voretaq7 tatsächlich die Fragen beantwortet, sondern eher eine alternative Methode vorschlägt. Die Frage ist wirklich, was das Thema vorschlägt - wie setzen die Leute FreeBSD-Ports in einer Umgebung mit mehreren Knoten ein. - vpetersson


Antworten:


Ich war nie völlig zufrieden mit dem Ports-System in einer großen Umgebung - Es scheint immer so, als müssten Sie ein externes Management darauf anwenden, damit es gut funktioniert.

Meine besten Tipps (in Reihenfolge der aufsteigenden Präferenz, "schlechteste" Lösung zur "besten" Lösung):


Wenn Sie auf jedem Host aufbauen, nicht.
Wenn Sie müssen, tun Sie es nicht über NFS mit Read-Write-Mounts wie Sie beschreiben: Sie können den Ports normalerweise vertrauen, die richtige Sache zu tun und nicht auf die Ports-Struktur stampfen, wenn Sie alternative Arbeitsverzeichnisse bereitstellen, aber es ist immer besser Seien Sie sicher, dass es keinen Fehler gibt: Führen Sie einen lokalen CVS / csup-Mirror aus und csup alle Ihre Hosts aus dieser Box und erstellen Sie dann lokal wie bei einzelnen Computern.
Ja, ich weiß, das bedeutet mehr Speicherplatz auf den Hosts und einen zusätzlichen Schritt. Es ist auch fast garantiert problemlos.
Vorbehalt: Wahrscheinlich möchten Sie die Paketkonfigurationsdateien (rsync oder Ähnliches) von einem bestimmten "Konfigurationshost" synchronisieren, um Konsistenz auf jedem Rechner zu gewährleisten (Sie können sogar den gesamten Ports-Baum rsyncieren, anstatt csup auf jedem Knoten zu verwenden).


Verwenden Sie einen Build-Host, erstellen Sie Pakete und installieren Sie diese.
Eine viel bessere Lösung, als auf jeder einzelnen Maschine aufzubauen: Verwenden Sie einen Build-Host, um Pakete zu erstellen, und richten Sie Ihre Tools auf diese Pakete aus.
Dies bedeutet, dass für jede Architektur, die Sie ausführen (oder Cross-Compiling), ein Build-Host vorhanden ist, aber letztlich ist dies für Ihre Zielcomputer besser (keine großen Kompilierungsjobs, eine Garantie für Konsistenz).


Verwenden Sie ein Konfigurations- / Systemverwaltungstool.
Dies ist die Lösung, mit der ich fertig bin - ich erstelle ein Standard-Server-Image und stelle es mit meiner Umgebung um radmind. Sie können ähnliche Dinge mit tun Marionetteoder Koch. Dies hat alle Vorteile, einen Build-Host zu verwenden (Konsistenz, weniger Last auf den einzelnen Servern) und fügt den Vorteil der Konfigurationsverwaltung hinzu.

Vorbehalt: Dies funktioniert nur sehr gut, wenn Ihre Maschinen "identisch" sind - Das heißt, Sie können die gleiche Reihe von Ports auf allen von ihnen installieren. Es können funktionieren, wenn Sie unterschiedliche Portsätze haben, aber das erhöht den Verwaltungsaufwand erheblich.

Haftungsausschluss: Ich bin der Portwächter für sysutils/radmind. Ja, ich mag es so sehr, dass ich es angenommen habe.


All dies basiert auf meiner Erfahrung in der Verwaltung von verschiedenen FreeBSD-Umgebungen (von 1-2 Maschinen bis über 100). Konfigurations- / System-Management-Tools, die ein standardisiertes Image pushen und pflegen, sind meiner Erfahrung nach der beste Weg, damit umzugehen.


13
2018-02-28 19:41



Gute Hinweise. Ich habe in der Vergangenheit schon ein bisschen mit Puppet gespielt und liebe es auf Ubuntu. Aber ich bin mir nicht sicher, wie gut es mit FreeBSD spielt. Ich muss das noch ausprobieren. Egal, sogar mit Puppet, ich denke, es ist Portupgrade, was uns zurück auf Platz eins bringt. Ich sehe keine andere Möglichkeit, es könnte funktionieren, da es dann pkg_delete / pkg_add oder 'pkg_add -f' tun müsste, was keine gute Idee wäre. Soweit es die Hardware betrifft, sind sie alle identisch, da sie in einer Public Cloud (KVM / Qemu) laufen. - vpetersson
Wenn Ihre Hardware- und Baseline-Software-Konfigurationen identisch sind, würde ich etwas wie radmind vorschlagen und das gesamte System-Image verwalten. Puppet und Chef sind großartige Werkzeuge, aber Sie haben darauf hingewiesen, dass sie die zugrundeliegenden Betriebssystem-Binärdateien aufrufen, was Sie bei der Verwendung eines Build-Hosts und der Verteilung von Paketen zurücklässt. radmind vermeidet dies, indem er die Verwaltung auf Dateisystemebene übernimmt ("Wenn es nicht das ist, was hier sein soll, ersetzen oder entfernen"), anstatt zu versuchen, ein Ersatzsysadmin zu sein ("Führe diese Befehle aus / ändere diese Dateien für mich Box"). - voretaq7
Nun, die Systeme haben identische Hardware, aber nicht identische Konfigurationen. Ich werde Radmind untersuchen müssen, aber ich bin mir nicht sicher, ob das der beste Ansatz ist. Verwenden der integrierten Tools sollte arbeite IMHO, weshalb ich die Community anspreche, um zu sehen, ob ich etwas Offensichtliches verpasst habe. Ich kann kaum der einzige sein, der das versucht. - vpetersson
Die eingebauten Werkzeuge definitiv TUN Arbeit, sie benötigen nur eine Menge Hilfe (Build-Server, lokale Verteilung von Paketen, etc.) - Sie sind wirklich darauf ausgerichtet, eine Maschine zu verwalten, und skalieren nicht so gut sie konnten. Beachten Sie, dass ich die Option ausgelassen habe Rollen Sie Ihren eigenen freebsd-Update-Server - Ich habe das nie für mehr als nur das Basissystem ausprobiert, aber es ist theoretisch möglich. Ich bin einfach bei dem Zeug geblieben, von dem ich weiß, dass es funktioniert :) - voretaq7
Ja, das ist eigentlich eine interessante Idee. Ich bin mir nur nicht sicher, ob es mit dem Verteilen von Ports-Paketen ohne viel Modifikationen funktionieren würde. Ich bin wirklich neugierig darauf, wie Systemadministratoren großer Systeme das handhaben, da es viele große Bereitstellungen von FreeBSD gibt. Bringen sie alle ihre eigene Lösung? Wenn dem so ist, fühlt sich das ziemlich merkwürdig an und nicht sehr Open Source-isch. - vpetersson


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

Tinderbox ist ein Paketerstellungs-System für FreeBSD-Ports, basierend auf   Offizielle Portbuild-Skripte, die auf pointhat verwendet werden, um Cluster zu erstellen.   Tinderbox wurde von Joe Marcus Clarke geschrieben.

Sie können mehrere Jails (Basissystemversionen) und mehrere definieren   Porträts. Die Kombination von jail und portstree wird als Build bezeichnet. EIN   Tinderbox-Jail ist nicht, was in FreeBSD als ein Jail verstanden wird, ist es   in der Tat eine gegebene Welt in einer Chroot. Tinderbox unterstützt automatisch   Verfolgen von Abhängigkeiten und erstellt nur Pakete neu, die sich seitdem geändert haben   Letzter Lauf. Tinderbox unterstützt die Benachrichtigung per E-Mail von fehlgeschlagen   baut. Tinderbox integriert sich auch gut mit ccache.

Tinderbox wurde entwickelt, um einfach Paket-Sets von Ports zu erstellen   brauchen, für Plattformen und Architekturen, die Sie brauchen. Tinderbox ist auch   ausgezeichnetes Tool zum Testen neuer Ports und Port - Upgrades, insbesondere für   Testen von Abhängigkeiten und Packlisten. Es ist auch nützlich zum Testen   Ports auf verschiedenen Releases von FreeBSD, da Sie FreeBSD 6.X ausführen können   Welt als Gefängnis auf FreeBSD 7.X / 8.X-Host.

Auch umschalten auf pkgng vereinfacht Paketbereitstellungen erheblich
Schau es dir auf github an: https://github.com/pkgng/pkgng


6
2018-03-06 00:47



Während das sicherlich nützlich sein könnte, um die eigentlichen Pakete in einer heterogenen Umgebung (mehrere Versionen, Architekturen usw.) zu erstellen, löst es nicht wirklich das Problem der Bereitstellung der Pakete. - vpetersson
Tinderbox stellt die Pakete über HTTP zur Verfügung, so dass Sie diese mit den Kommentaren auf der Antwort von voretaq7 kombinieren können, um Ihre Deployment-Lösung (z. B. gesetzt) ​​zu erhalten PACKAGEROOT / PACKAGESITE und benutze 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 (mit oder ohne Ports-Struktur) zu verteilen. Das Problem ist, dass dieses Modell immer noch entweder a) einen vollständigen Ports-Baum lokal oder b) einen über NFS exportierten Ports-Baum benötigt, was uns zurück zum Problem bringt. - vpetersson
Portupgrade wird genau das tun, was Sie tun müssten, wenn Sie aus der Quelle oder mit Binärpaketen bauen würden - pkg_delete muss zuerst ausgeführt werden und dann die neue Version installieren. OpenBSD hat dies besser gelöst, indem es eine Upgrade - Option in pkg_add. Ich bin mir über Portupgrade nicht sicher, aber Portmaster kann nur mit INDEX und nicht mit einer vollständigen Ports-Struktur arbeiten. - James O'Gorman
Richtig, aber pkg_delete ist kaum ein vernünftiger Ansatz. Angenommen, Sie möchten Ruby, Python oder ein anderes Paket aktualisieren, das für eine große Anzahl anderer Pakete erforderlich ist. pkg_delete würde dann erfordern, dass Sie alle Abhängigkeiten löschen, was für ein Produktionssystem kaum eine Option darstellt. Portupgrade macht a weit bessere Arbeit damit, aber wieder scheint es nicht zu skalieren. - vpetersson


Ich habe mehr als 100 FreeBSD-Server verwaltet, indem ich / usr nur über gut abgestimmtes NFS freigegeben habe, die Paketdatenbanken von / var nach / usr verschoben und mit ihnen verlinkt habe (nicht unbedingt notwendig, aber pkg_info und so). Es hat vielleicht ein oder zwei andere Dateien gegeben, die in die eine oder andere Richtung verschoben werden mussten und die symlinked waren, aber das ganze Setup brauchte ungefähr eine Stunde, um es herauszufinden. Es hat sehr, sehr gut funktioniert. Hätte ich Probleme mit der Skalierung gehabt, hätte ich zusätzliche NFS-Server hinzugefügt und die Arbeitslast aufgeteilt, aber es kam nie auf. Leistung war nie ein Problem für mich (in der Tat war es großartig), aber ich nehme an, Sie könnten den / usr / NFS-Server (oder eine Kopie davon) auf einem MD setzen.


3
2017-07-27 19:44



Das Teilen der gebauten Paketdateien über NFS (so klingt es, von dem du sprichst?) Ist sicherlich ein anderer vernünftiger Ansatz - du kannst dann etwas wie Puppet (oder sogar selbst erstellte SSH- und Shell-Skripte) zum Installieren / Aktualisieren von Paketen verwenden von der NFS-Freigabe. - voretaq7


Es scheint, als ob niemand dafür eine gute Lösung gefunden hat. Dies ist höchstwahrscheinlich auf Einschränkungen in den zugrunde liegenden Tools zurückzuführen.

Folgendes habe ich mir ausgedacht: Ich habe die Idee, den gesamten Ports-Tree exportieren zu lassen, verschrottet. Stattdessen gab ich nach und legte einen vollständigen Ports-Baum auf jeden Knoten. Ich habe dann 'Pakete' über NFS gemountet (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 ein kurzes geschrieben Post wie man das in meinem Blog einrichtet.

Verweise:


1
2018-05-07 13:26