Erstellen und Bereitstellen von Paketen für Ihre FreeBSD-Server mit Buildbot und Poudriere

Die FreeBSD-Ports- und Paketsammlung, im Folgenden ports tree genannt, ist das Build-System von FreeBSD für externe Software. Es bietet eine https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/tools-make.html[Makefile‹ -basierte, konsistente Methode zum Erstellen von Paketen. Der port bezieht sich auf das Build-Rezept, also das Makefile und die zugehörigen Dateien. während package die Ausgabe des Aufbaus eines Ports in ein binäres (komprimiertes) Archiv der Paketdateien und ihrer Metainformationen ist.

Das manuelle Erstellen und Installieren einer Teilmenge oder aller über 30.000 Ports ist mit + make install + möglich. Die Builds würden jedoch auf einem Ihrer Server ausgeführt - keine saubere Umgebung. Für Produktionsanwendungsfälle würde manuelles Erstellen auch bedeuten, dass jeder Host dieselbe Revision des Ports-Baums benötigt und alle Pakete für sich kompilieren muss. Dies bedeutet wiederholte, fehleranfällige Arbeiten von Menschen und Servern. Es ist vorzuziehen, identische, vorgefertigte Binärpakete auf jedem Host abzurufen und zu verwenden und sie von einem zentralen, sicheren Paket-Repository aus bereitzustellen.

Um dies zu erreichen, ist Poudriere das Standardwerkzeug von FreeBSD zum Erstellen, Testen und Überwachen von Paketen sowie zum Verwalten der Paket-Repositorys. Jeder Build wird isoliert in einem neuen https://www.digitalocean.com/community/tutorials/how-to-install-buildbot-freebsd#step-1-%E2%80%93-setting-up-jails-for ausgeführt -the-buildbot-master-and-worker [Gefängnis], das die gewünschte Version von FreeBSD ausführt und ohne installierte Pakete startet. Nur das Basissystem sowie alle explizit angegebenen Abhängigkeiten stehen für den Neuaufbau zur Verfügung. Poudriere kümmert sich bei Bedarf um die Neuerstellung von Paketen sowie um die Aktualisierung des Paket-Repositorys nach Abschluss eines Builds. Das Kommandozeilen-Tool + poudriere + ist von zentraler Bedeutung für die Verwaltung verschiedener Port-Bäume, FreeBSD-Versionen, Port-Build-Optionen und schließlich für die Ausführung der Builds.

In diesem Lernprogramm konfigurieren Sie Poudriere, erstellen eine Reihe gewünschter Pakete, richten HTTP-basiertes Pakethosting ein und automatisieren die Erstellung mithilfe von Buildbot als kontinuierliche Integrationsplattform. Schließlich greifen Sie von einem Client-Computer aus sicher auf die Pakete zu.

Bevor Sie mit diesem Handbuch beginnen, benötigen Sie:

Nach Abschluss des Lernprogramms für die Voraussetzungen verfügen Sie über ein funktionsfähiges Buildbot-Master- und Worker-Gefängnis sowie über ein Nginx-Setup. Sie werden in den folgenden Schritten auf diesem vorhandenen Setup aufbauen. In diesem ersten Schritt installieren Sie das Build-Tool Poudriere im Worker-Gefängnis, da der Buildbot-Worker-Prozess später Builds auslöst.

Stellen Sie eine Verbindung zu Ihrem Server her, auf dem Buildbot gehostet wird, und öffnen Sie im Worker-Gefängnis eine * root * -Shell mit dem folgenden Befehl:

Installieren Sie Poudriere als Paket:

Bestätigen Sie die Installation mit + y + und dann + ENTER +.

Sie haben das neueste Poudriere-Tool und die neuesten Abhängigkeiten erfolgreich installiert. In den nächsten Schritten werden Sie die Vorbereitungen für die Konfiguration von Poudriere durchführen.

Es wird empfohlen, digitale Signaturen für erstellte Pakete einzurichten, um mehr Sicherheit zu bieten. Überspringen Sie diesen Schritt, wenn Sie Ihre Installation später oder auf andere Weise sichern möchten. Andernfalls erstellen wir ein Schlüsselpaar, mit dem Pakete signiert (mit dem privaten Schlüssel) und Pakete überprüft werden (mit dem öffentlichen Teil).

Pakete werden standardmäßig als "+ .txz " - Dateien erstellt, bei denen es sich um stark komprimierte Tarballs des Paketinhalts handelt. Die Prüfsummen der komprimierten Dateien bieten zusammen mit der Bereitstellung der Dateien über HTTP / HTTPS (TCP-Prüfsummen) bereits einen gewissen Schutz vor beschädigten Daten. Der Paketinhalt umfasst normalerweise Dateien und Verzeichnisse sowie Metainformationen wie den Paketnamen, die Version und verschiedene Optionen. Die Dateien können sogar https://en.wikipedia.org/wiki/Setuid#Security[`+setuid-able programs] enthalten (wie im `+ sudo + -Paket zu sehen, obwohl sudo nicht in FreeBSD integriert ist) Installationsskripte werden als * root * Benutzer ausgeführt. Die Installation aus nicht überprüften Quellen birgt daher ein Sicherheitsrisiko.

Wenn Sie die Pakete über HTTPS bereitstellen, können Sie nicht erkennen, ob jemand die Pakete auf der Festplatte manipuliert hat. Integrität und Authentizität Ihrer Pakete können hinzugefügt werden, indem Poudriere so konfiguriert wird, dass das Paket-Repository mit einem privaten RSA-Schlüssel signiert wird. Signierte Digests und der entsprechende öffentliche Schlüssel werden dabei in der Datei + digests.txz + des Paket-Repositorys gespeichert. Das erforderliche Schlüsselpaar (privater und öffentlicher RSA-Schlüssel) kann so lange unverändert bleiben, bis der private Schlüssel verloren gegangen oder kompromittiert wurde.

In diesem Schritt erstellen Sie das Schlüsselpaar, in dem die Builds ausgeführt werden (Worker-Jail), und laden den öffentlichen Teil zur späteren Verwendung auf Paket-Clients herunter (wird in einem späteren Schritt erläutert).

Stellen Sie sicher, dass Sie sich noch in der Worker-Jail * root * Shell befinden.

Erstellen Sie einen neuen privaten RSA-Schlüssel:

Auf die private Schlüsseldatei muss nur der Benutzer * root * zugreifen können, der Poudriere ausführt. Schützen Sie die Zugriffsberechtigungen:

Später benötigen Sie den öffentlichen Schlüsselteil, der auf den Clients zur Überprüfung der Paketsignaturen verfügbar ist. Extrahieren wir jetzt den öffentlichen Schlüssel:

Zuletzt laden Sie die öffentliche Schlüsseldatei von Ihrem eigenen Computer herunter:

Damit ist die optionale Erstellung eines Schlüsselpaares für die Paketsignatur abgeschlossen. Sie werden später die eigentliche Signatur mit Poudriere konfigurieren und die heruntergeladene öffentliche Schlüsseldatei auf den Clients für die Überprüfung verwenden.

Ein weiterer optionaler Schritt folgt: Wenn Sie das ZFS-Dateisystem verwenden, kann Poudriere es verwenden, um Builds zu beschleunigen. Andernfalls können Sie zu https://www.digitalocean.com/community/tutorials/how-to-build-and-deploy-packages-for-your-freebsd-servers-using-buildbot-and-poudriere#step- springen. 4-% E2% 80% 94-Konfigurieren-von-Poudriere,-des-Build-Gefängnisses, -und-des-Ports-Baums [Schritt 4], um Poudriere zu konfigurieren und sich auf die Ausführung des ersten Builds vorzubereiten.

Dieser Schritt gilt nur, wenn Sie ein FreeBSD-System auf dem ZFS-Dateisystem ausführen. Wenn Sie beispielsweise ein DigitalOcean-Droplet verwenden, trägt das Bild die Bezeichnung * x64 zfs * (für FreeBSD). In diesem Schritt erstellen Sie die Dateisysteme, mit denen Poudriere Jails schneller erstellen und verwalten kann, wodurch möglicherweise Ihre Builds beschleunigt werden.

Sie können herausfinden, ob Sie ZFS verwenden, indem Sie Pools auflisten. Stellen Sie sicher, dass Sie sich in der Shell des Servers befinden und nicht in einem Gefängnis.

Führen Sie den folgenden Befehl aus, um die Zpools aufzulisten:

Wenn ein Pool verfügbar ist, werden Informationen dazu gedruckt:

Andernfalls druckt das Tool, wenn keine ZFS-Unterstützung verfügbar ist, "+ keine Pools verfügbar" oder "+ konnte die ZFS-Bibliothek nicht initialisieren". Dies bedeutet, dass kein System ZFS verwendet. Fahren Sie in diesem Fall mit dem nächsten Schritt fort. Wenn Sie sich für einen anderen Datenträger oder Speichertyp entschieden haben, z. B. das UFS-Dateisystem, können Sie auch mit dem nächsten Schritt fortfahren.

Wenn Sie vorhaben, ZFS zu verwenden, merken Sie sich den Namen des gedruckten Pools, in dem Sie Build-bezogene Daten speichern möchten. Sie sollten mehrere Gigabyte Speicher einplanen.

ZFS ist hilfreich, um die verschiedenen Datasets von Poudriere zu trennen, z. B. Build-Jails, Port-Bäume, Protokolle, Pakete und andere Daten. Diese werden unabhängig voneinander gespeichert und können so schnell gelöscht werden, ohne dass Speicherplatz oder Spuren zurückbleiben.

Damit Poudriere ZFS nutzen kann, müssen Sie drei Dinge tun: Ein übergeordnetes ZFS-Dataset erstellen, das Erstellen und Löschen von ZFS-Datasets zulassen (was vom Buildbot-Worker-Jail oder einem anderen Jail standardmäßig nicht möglich ist) und bearbeiten Poudrieres Konfiguration entsprechend.

Im vorausgesetzten Lernprogramm haben Sie das Buildbot-Worker-Gefängnis in "+ /etc/jail.buildbot-worker0.conf " konfiguriert. Öffnen Sie diese Datei mit Ihrem bevorzugten Texteditor und fügen Sie die folgenden hervorgehobenen Zeilen hinzu, um ein übergeordnetes Dataset zu delegieren, damit das Gefängnis ZFS-Datasets unter dem übergeordneten Dataset verwalten kann. Denken Sie daran, " zroot +" durch Ihren gewünschten Poolnamen zu ersetzen:

/etc/jail.buildbot-worker0.conf

In diesem Artikel speichern wir Build-bezogene Daten im ZFS-Pool "+ zroot +". Passen Sie diese ZFS-bezogene Konfiguration hier und im Rest des Artikels an, wenn Sie einen Pool mit einem anderen Namen ausgewählt haben.

Speichern und beenden Sie den Editor, nachdem Sie diesen Inhalt hinzugefügt haben. Wenn Sie "+ ee " verwenden, drücken Sie dazu " STRG + C ", geben Sie " exit " ein und drücken Sie " ENTER +".

Erstellen Sie das übergeordnete ZFS-Dataset, das in der Konfigurationsdatei angegeben ist:

Dies setzt absichtlich voraus, dass Sie möglicherweise in Zukunft weitere Mitarbeiter hinzufügen möchten, und erstellt daher einen Unterdatensatz für Ihren ersten Mitarbeiter. Der Dataset-Name ist absichtlich kurz, da ältere Versionen von FreeBSD (vor 12.0) eine maximale Anzahl von 88 Zeichen für Mount-Namen hatten.

Damit ein Gefängnis die Kontrolle über ein Eltern-Dataset übernehmen und Kinder verwalten kann, muss das Dataset mit dem folgenden Flag gekennzeichnet sein:

Wenn die Voraussetzungen jetzt erfüllt sind, wird das Gefängnis mit der neuen Konfiguration korrekt gestartet:

Mit diesen Anweisungen haben Sie die erforderlichen Dateisysteme (ZFS-Datasets) erfolgreich erstellt und dem Jail die Verwaltung des übergeordneten Datasets ermöglicht. Im nächsten Schritt konfigurieren Sie Poudriere, indem Sie den ausgewählten Zpool und das Dataset angeben, die zum Speichern von Build-bezogenen Daten verwendet werden.

Bis zu diesem Zeitpunkt haben Sie Poudriere installiert und optional die Anforderungen für die Paketsignatur und ZFS abgedeckt. Damit Poudriere in der Lage ist, im Gefängnis zu arbeiten, das heißt, innerhalb des Buildbot-Worker-Gefängnisses ordnungsgemäß zu funktionieren, müssen Sie dem Gefängnis bestimmte Berechtigungen erteilen. Wenn Sie beispielsweise ZFS verwenden, haben Sie bereits ein übergeordnetes Dataset für die Verwendung und Verwaltung durch das Gefängnis delegiert.

Konfigurieren wir zuerst die Loopback-IP und alle Berechtigungen und gehen dann die jeweilige Bedeutung nach den Änderungen durch.

Poudriere möchte zwei Build-Jails pro Build starten: eines mit Loopback-Netzwerk und eines mit Internetzugang. Letzteres wird nur für Build-Phasen verwendet, die das Internet erreichen sollen. Zum Beispiel kann das "+ fetch " Quell-Tarballs herunterladen, aber die " build " - Phase erlaubt keinen Internetzugang. Die vorhandene Konfiguration des Arbeitergefängnisses hat " ip4.addr =" lo1 | 10.0.0.3/24 "", was den Internetzugang ermöglicht. Damit Poudriere neu gestarteten Build-Jails eine Loopback-Adresse zuweisen kann, muss die IP auch an das übergeordnete (das Worker-Jail) übergeben werden. Damit dies funktioniert, stellen Sie bitte sicher, dass Sie die neueste Version der Firewall-Konfigurationsdatei " / usr / local / etc / ipfw.rules " aus dem vorausgesetzten Lernprogramm angewendet haben, die das Öffnen ausgehender Verbindungen durch die Loopback-Schnittstelle " lo0 +" blockiert durch NAT.

Fügen Sie die hervorgehobenen Zeilen zu Ihrer Worker-Jail-Konfiguration hinzu:

/etc/jail.buildbot-worker0.conf

Hier haben Sie Folgendes hinzugefügt (siehe auch die Manpage jail(8)):

Speichern und beenden Sie die Konfigurationsdatei.

Starten Sie das Jail neu, damit die Konfiguration sofort wirksam wird:

Die entsprechenden Kernel-Module müssen geladen sein, damit Poudriere Mount-Vorgänge durchführen kann. Führen Sie die folgenden Befehle aus, um die Module beim Start und sofort zu laden:

Sie haben das Poudriere-Paket bereits früher installiert, wobei die Beispieldatei "+ / usr / local / etc / poudriere.conf.sample " nach " / usr / local / etc / poudriere.conf +" kopiert wurde. Als Nächstes nehmen Sie Änderungen an der Konfigurationsdatei vor. Alle möglichen Konfigurationsvariablen sind bereits im Beispiel vorhanden. Entfernen Sie das Kommentarzeichen oder passen Sie die entsprechende Zeile in der Datei an, um eine Variable auf einen bestimmten Wert festzulegen.

Stellen Sie für die folgenden Befehle sicher, dass Sie sich noch in einer * root * -Shell im Worker-Gefängnis befinden:

Öffnen Sie die Datei mit dem folgenden Befehl:

Wenn Sie sich für die Verwendung von ZFS entschieden haben, geben Sie bitte Ihren gewünschten Zpool und übergeordneten Datensatz ein:

/usr/local/etc/poudriere.conf (Snippet)

Wenn Sie sich dagegen entschieden haben, deaktivieren Sie bitte die ZFS-Unterstützung:

/usr/local/etc/poudriere.conf (Snippet)

Sie werden später Poudriere anweisen, ein FreeBSD-Basissystem herunterzuladen und damit das erste Build-Jail zu booten. Dazu muss ein Download-Host angegeben werden. Fügen Sie die folgende hervorgehobene Zeile hinzu:

/usr/local/etc/poudriere.conf (Snippet)

Da Poudriere im Gefängnis ausgeführt wird, ist die Beschränkung der Mount-Namen auf 88 Zeichen in FreeBSD-Versionen vor 12.0 besonders schädlich, da der vollständige Pfad des Gefängnisses + / usr / jails / buildbot-worker0 + Teil jedes Mount-Pfades ist. Das Überschreiten des Grenzwerts würde die Builds tödlich beschädigen. Achten Sie daher gut darauf, die Pfadlängen zu verringern. Anstelle des typischen Verzeichnisses "+ / usr / local / poudriere " können Sie " / pdr +" wie folgt verwenden:

/usr/local/etc/poudriere.conf (Snippet)

Erstellen Sie nun dieses Verzeichnis:

Wechseln Sie erneut zu Ihrem Editor von + poudriere.conf +:

Poudriere stellt während der Ausführung von Builds ein zentrales Verzeichnis für dist files (die Quellcode-Tarballs für jeden Port) bereit, sodass alle Builder denselben Cache gemeinsam nutzen. Das Standardverzeichnis ist:

/usr/local/etc/poudriere.conf (Snippet)

Erstellen Sie nun dieses Verzeichnis:

Wenn Sie Schritt 2 befolgt und einen Signaturschlüssel für das Paket-Repository erstellt haben, rufen Sie den Editor erneut auf und geben Sie ihn an:

/usr/local/etc/poudriere.conf (Snippet)

Builds werden viel schneller ausgeführt, wenn Sie C / C ++ - Compiler- und Linker-Ausgaben für das nächste Mal zwischenspeichern. Der Ports-Baum unterstützt dies direkt, indem er das Tool ccache verwendet. Bitte aktivieren Sie es und erstellen Sie das entsprechende Cache-Verzeichnis, wenn Sie mindestens 5 GB mehr Speicherplatz (die Standard-Cache-Größe) einsparen können:

/usr/local/etc/poudriere.conf (Snippet)

Das Erstellen und Ausführen von Linux-Software ist ungewöhnlich. Deaktivieren Sie sie, bis Sie sie benötigen:

/usr/local/etc/poudriere.conf (Snippet)

Den Gefängnissen sollte eine Loopback-Adresse zugewiesen werden, oder Poudriere warnt davor. Wir können die IP des Gefängnisses erben, da es sich um eine reine Loopback-Netzwerkschnittstelle handelt (+ lo1 +). Fügen Sie dazu bitte die folgende Zeile am Ende der Konfigurationsdatei hinzu:

/usr/local/etc/poudriere.conf (Snippet)

Speichern und beenden Sie die Konfigurationsdatei.

Für funktionierende Builds benötigen wir zwei weitere Ressourcen: ein FreeBSD-Basissystem, das als Build-Jail-Vorlage verwendet wird, und einen aktuellen Ports-Baum. Wählen Sie die FreeBSD-Version, auf die Sie abzielen. In diesem Tutorial werden wir Poudriere anweisen, FreeBSD für die Architektur herunterzuladen. Sie können das Gefängnis benennen, wie Sie möchten, aber ein einheitliches Benennungsschema wie "+ 112amd64 " wird empfohlen. Denken Sie auch an die Wahl zwischen vierteljährlichen, stabilen Ports-Ästen (hier verwenden wir " 2019Q2 +") und dem "Kopf" -Ästchen der blutenden Kante, der nach Aktualisierungen hin und wieder zum Abbrechen von Builds führen kann. FreeBSD-Versionen, die neuer sind als die auf dem Server, können nicht im Build-Jail verwendet werden.

Laden Sie das Build-Jail herunter und erstellen Sie es:

Zuletzt laden wir den Ports-Baum herunter. Die Standardmethode zum Herunterladen ist portsnap, bei der komprimierte Momentaufnahmen des Baums ohne Verlaufsinformationen verwendet werden. Entweder Subversion oder Git sind vorzuziehen, um vorgelagerte Änderungen zusammenzuführen oder einen Beitrag zu leisten. Dies ist auch wichtig, wenn Sie einen benutzerdefinierten, selbst gehosteten Baum in einem Versionskontrollsystem verwenden möchten. Geben Sie im folgenden Befehl das aktuelle Jahr und das aktuelle Quartal ein.

Wenn Sie mit dem vorgelagerten, offiziellen Portbaum beginnen möchten:

Die Methode + svn + https + würde vom FreeBSD Subversion-Host synchronisiert (viewable online here). Wenn Sie eine alternative Quelle verwenden möchten, lesen Sie den folgenden Hinweis, andernfalls überspringen Sie ihn.

Verfügbare Bäume können mit + poudriere ports -l + aufgelistet werden, was eine Auflistung wie folgt ausgibt:

Sie haben nun die Konfiguration und die Ressourcen von Poudriere eingerichtet. Sie haben Poudriere mit den erforderlichen Daten konfiguriert, um die ersten Builds auszulösen, und das Jail zum Erstellen von Unterjails aktiviert. Als Nächstes führen Sie den ersten Build manuell aus, um zu überprüfen, ob das Setup funktioniert.

Sie können den Befehl + poudriere bulk + verwenden, um ein oder mehrere Pakete und all ihre Abhängigkeiten zu erstellen. Nach der ersten Erstellung eines Pakets erkennt Poudriere automatisch, ob eine Neuerstellung erforderlich ist, oder lässt die vorhandene Paketdatei auf andere Weise unberührt. Während der Unterbefehl "+ bulk " nur Pakete erstellt, werden beim Ausführen eines Builds mit " poudriere testport +" auch die angegebenen Ports anhand der Definition von "testing" im Makefile des Ports getestet. Im Rahmen dieses Artikels möchten wir nur Pakete für die Installation auf Clients bereitstellen. Daher verwenden wir Bulk-Builds.

Stellen Sie sicher, dass Sie sich noch in einer Root-Shell des Worker-Gefängnisses befinden, in dem Sie Poudriere installiert haben. Später wird hier auch der Buildbot-Arbeitsprozess Builds automatisch ausführen.

Führen Sie den Build aus und füllen Sie die Platzhalter mit dem Namen des Build-Jails und dem Namen des Ports-Baums, die Sie zuvor ausgewählt haben:

Dadurch wird der Port "+ ports-mgmt / pkg " erstellt. Ports in der offiziellen Baumstruktur werden in einer Hierarchie " <Kategorie> / <Name> +" gespeichert, und diese Pfade (als "Paketursprung" bezeichnet) werden verwendet, um Poudriere mitzuteilen, welche Pakete erstellt werden sollen. Für den Anfang haben wir uns entschieden, nur den Paketmanager pkg zu erstellen, der keine Abhängigkeiten von Drittanbietern aufweist und daher eine gute, schnelle Überprüfung der Konfiguration darstellt. Wenn alles gut läuft, wird folgende Ausgabe angezeigt:

Diese Ausgabe zeigt, wo die Pakete nach dem Erstellen abgelegt werden und woher die vorhandenen Pakete entnommen werden, falls sie nicht neu erstellt werden müssen (hier: "+ / pdr / data / packages / 112amd64-2019Q2 "). Außerdem zeigt die Ausgabe eine Übersicht über laufende Builds, während Poudriere ausgeführt wird (Sie können in einer interaktiven Shell STRG + T + drücken, um den Fortschritt zu drucken). In der letzten Zusammenfassung sehen Sie, dass ein Paket erstellt wurde. Sie können die ausführliche Build-Ausgabe im Protokollverzeichnis anzeigen (` / pdr / data / logs / bulk / 112amd64-2019Q2 / * +`).

Diese Ausgabe bestätigt eine erfolgreiche Erstellung. Wenn Poudriere mindestens ein Paket erfolgreich erstellt hat, wird es automatisch in das Paket-Repository übernommen. Dies bedeutet, dass Pakete nur verfügbar sind, nachdem alle Builds abgeschlossen wurden, auch wenn andere Pakete nicht erstellt werden konnten. Sie haben jetzt ein Arbeitspaket-Repository unter + / pdr / data / packages / 112amd64-2019Q2 + im Buildbot-Worker-Gefängnis.

Sie haben die gesamte Konfiguration abgeschlossen, die erforderlich ist, um funktionierende Poudriere-Builds zurückzugeben, und Sie haben erfolgreich mit einem manuellen Build verifiziert. Dieselbe Ausgabe wird später im Lernprogramm angezeigt, wenn Sie den Bulk-Build in Buildbot automatisiert haben. Außerdem muss ein Link zum Anzeigen der detaillierten Protokolle über die Webschnittstelle verfügbar sein. Um dies zu erreichen und das Paket-Repository für Clients bereitzustellen, richten Sie als Nächstes einen Webserver ein.

Poudriere bietet mehrere Ausgabe-Artefakte, die wir über einen Webserver hosten möchten:

Die Konfigurationsänderung in Nginx ist kurz, da nur statische Dateien bereitgestellt werden müssen. Da Sie sie der Außenwelt bereitstellen, konfigurieren Sie jetzt die vorhandene Nginx-Instanz auf dem Server außerhalb der Jails, um die genannten Dateien über Pfade innerhalb des Worker-Jails bereitzustellen.

Bitte beenden Sie die Jail-Shell, da Sie jetzt auf dem Server arbeiten werden:

Öffnen Sie einen Editor mit der Nginx-Konfiguration + / usr / local / etc / nginx / nginx.conf +:

Fügen Sie die folgenden Positionen innerhalb des Blocks + server {+ hinzu:

/usr/local/etc/nginx/nginx.conf

Speichern und schließen Sie die Nginx-Konfigurationsdatei. Laden Sie dann den Nginx-Dienst neu:

Schauen wir uns nun die Artefakte an, die mit dem ersten manuellen Build erstellt wurden. Öffnen Sie Ihren bevorzugten Webbrowser auf Ihrem lokalen Computer, um auf die Ressourcen zuzugreifen.

Das * Paket-Repository * befindet sich unter + http: /// packages / + (oder + http: /// +). Sie finden Metainformationen im Stammverzeichnis, z. + 112amd64-2019Q2 + und alle erstellten Pakete im Unterverzeichnis + All +:

image: https://assets.digitalocean.com/articles/buildbot_poudriere/step6a.png [Auflistung der Paketdatenbank]

Bild: https://assets.digitalocean.com/articles/buildbot_poudriere/step6b.png [Poudriere-Weboberfläche]

Wenn Sie keinen Domainnamen für Ihren Server eingerichtet haben, müssen Sie für diese Beispiele die öffentliche IP-Adresse Ihres Servers eingeben, z. + http: /// logs / +.

Dies schließt alle manuellen Einstellungen ab, um funktionierende Builds zu erhalten und Einblick in die Ausgabe (Pakete und Protokolle) zu erhalten. Zukünftig werden Sie Builds automatisieren, um kontinuierliche Integration zu erreichen.

Ihr Ziel in diesem Schritt ist es, die Erstellung von Massenpaketen zu automatisieren, indem Sie Poudriere auf dieselbe Weise ausführen, wie Sie es bereits getan haben, indem Sie es der vorhandenen Buildbot-Beispielkonfiguration hinzufügen. Am Ende dieses Schritts löst Buildbot die Paketerstellung aus, wenn sich der ausgewählte Zweig des Ports-Baums ändert. In den Beispielen dieses Lernprogramms ist dies der vierteljährliche Zweig "+ 2019Q2 +".

Alle erforderlichen Änderungen werden in der Buildbot-Masterkonfiguration vorgenommen. Öffnen Sie daher eine * root * -Shell im Master-Jail:

Zunächst muss ein builder definiert werden, der die Befehle und Aktionen beschreibt, die zum Ausführen eines Builds ausgeführt werden. In der vorhandenen Konfiguration "+ / var / buildbot-master / master.cfg " finden Sie einen Abschnitt " BUILDERS ". Öffnen Sie einen Editor und ersetzen Sie den gesamten Abschnitt, bis die nächste Überschrift beginnt mit ` …​ +`, mit folgender Konfiguration:

/var/buildbot-master/master.cfg (Snippet)

Beachten Sie, wie dies die Erweiterbarkeit von Buildbot nutzt: Benutzerdefinierte Klassen werden verwendet, um Informationen aus der Poudriere-Protokollausgabe zu beobachten und zu analysieren. "+ PoudriereLogLineObserver +" wird nämlich als "Protokollbeobachter" hinzugefügt, d. H. wird aufgerufen, wenn während des Builds eine neue Protokollzeile gedruckt wird. Die Klasse durchsucht die Protokolle nach dem Protokollverzeichnis und konvertiert dieses in Hyperlinks. Diese Links werden neben dem Erstellungsschritt angezeigt und führen den Benutzer direkt zur Weboberfläche und zu den Protokollen von Poudriere.

Im ersten Build-Schritt "Update Ports Tree" verwenden wir den in Poudriere integrierten Update-Befehl ("+ ports -u +"), um die neueste Version des Ports Tree abzurufen. Dies verwendet automatisch die zuvor konfigurierte Methode (z. B. SVN / Git). Auf diese Weise können Sie sicher sein, dass die Pakete immer anhand des neuesten festgeschriebenen Baums erstellt werden. Dies ist besonders hilfreich, wenn Sie über ein eigenes versioniertes Repository verfügen, in dem Sie Softwareversionen und Patches verwalten.

Oben gibt die Liste "+ PORTS_TO_BUILD +" an, welche Ports erstellt werden sollen. Es wird in den Schritten der build factory verwendet, die am Ende des Blocks angegeben sind. Die Build-Factory ist eine Vorlage, mit der ein Build instanziiert wird. Buildbot erstellt bei jedem Auslösen einen eindeutigen Build, und der Build verwendet eine Kopie der Schritte, die zu diesem Zeitpunkt für die Buildfactory definiert waren. In diesem Fall haben wir genau zwei Schritte konfiguriert:

Damit der hinzugefügte Codeblock funktioniert, fügen Sie oben in der Datei einen erforderlichen Import hinzu:

/var/buildbot-master/master.cfg (Snippet)

Die + re + - Bibliothek in Python implementiert regular expressions, eine Funktion zum Suchen oder Ersetzen von Teilen eines Strings. Die Klasse + PoudriereLogLineObserver + verwendet sie, um nach einer Zeile zu suchen. + `, das das Protokollverzeichnis erwähnt.

Die Build-Befehle verwenden "+ sudo ", um bestimmte Befehle auszuführen. Dies ist erforderlich, da Poudriere beim Ausführen eines Build-Ins Superuser-Berechtigungen benötigt, um die Build-Jails zu erstellen, zu verwalten und zu zerstören. Außerdem werden die von Poudriere verwalteten Port-Bäume mit dem Root-Benutzer als Eigentümer erstellt. Im vorherigen Lernprogramm haben wir den Benutzer, der den Buildbot-Arbeitsprozess ausführt, mit " sysrc buildbot_worker_uid = buildbot-worker " konfiguriert. Aus diesem Grund möchten wir dem Benutzer " buildbot-worker " erlauben, genau die erforderlichen Befehle als root auszuführen, jedoch keine anderen Befehle (aus Sicherheitsgründen). Installieren wir das Programm " sudo +" und konfigurieren es entsprechend.

Dies muss auf dem Arbeitergefängnis erfolgen, nicht auf dem Meister. Bitte verlassen Sie die Master Jail Shell und betreten Sie das Arbeitergefängnis:

Installieren Sie das + sudo + Paket:

Bestätigen Sie die Installation mit + y + und + ENTER +.

Unter FreeBSD liest das sudo-Paket standardmäßig Konfigurationsdateien aus + / usr / local / etc / sudoers.d / +. Öffnen Sie einen Editor, um eine neue Konfigurationsdatei zu erstellen:

Die Verwendung von + visudo + ist beabsichtigt, da es bei Syntaxfehlern warnt und deren Behebung ermöglicht, anstatt eine fehlerhafte Konfiguration festzulegen.

Geben Sie an, welche Befehle der Benutzer "+ buildbot-worker +" als root ausführen kann, ohne dass ein Kennwort erforderlich ist:

/usr/local/etc/sudoers.d/buildbot-worker

Speichern Sie die Datei und wechseln Sie zurück in das Master-Gefängnis, um den Buildbot-Master weiter zu konfigurieren:

Sie haben gerade die Voraussetzungen erfüllt, um den Bulk-Build zum Laufen zu bringen. Aber wie bereits erwähnt, muss jeder Build ausgelöst werden, um ausgeführt zu werden. Buildbot verwendet den Ausdruck scheduler für ein Objekt, das definiert, wann ein Build ausgelöst wird und mit welchen zusätzlichen Informationen, z. B. welcher Zweig geändert wurde. Entfernen Sie den vorhandenen Abschnitt "+ SCHEDULERS " aus der Konfigurationsdatei und fügen Sie den folgenden Inhalt nach dem Abschnitt " BUILDERS +" ein, damit der Code alle vorhandenen Buildernamen verwenden kann:

/var/buildbot-master/master.cfg (Snippet)

Dies ersetzt die Beispielkonfiguration, sodass auf jedem Builder eine Schaltfläche * force * angezeigt wird. Und das Wichtigste ist, dass ein Scheduler erstellt wird, der alle Änderungen in Bezug auf das angegebene "+ project " / " branch " überwacht und für jede Änderung einen Build auslöst. Es können jedoch keine derartigen Änderungsereignisse auftreten - Sie müssen zuerst eine _änderungsquelle_ erstellen. In der Regel handelt es sich dabei um Versionskontrollsysteme wie SVN oder Git, auf denen Änderungen in einem Zweig erkannt werden können. Buildbot unterstützt die gängigsten, daher können wir seine Funktionalität nutzen, um unser ausgewähltes Upstream-Ports-Tree-Repository als Quelle hinzuzufügen. Ersetzen Sie den Abschnitt " CHANGESOURCES +" vollständig durch die folgende Konfiguration:

/var/buildbot-master/master.cfg (Snippet)

Dadurch wird das SVN-Repository alle vier Stunden auf dem Buildbot-Master abgefragt, und alle neuen (noch nicht gesehenen) Änderungen werden an übereinstimmende Scheduler weitergeleitet, was wiederum Builds auslösen würde, die schließlich zur Ausführung auf unserem einzelnen Buildbot-Worker gesendet werden. Der Ports-Baum ist sehr groß, und beim ersten Start laden diese Poller den vollständigen Verlauf herunter (für Git nur die angegebenen Zweige). Dies kann einige Minuten dauern und erheblichen Speicherplatz beanspruchen (mehrere Gigabyte).

Wenden Sie die neue Konfigurationsdatei an, indem Sie Buildbot neu starten:

In diesem Beispiel haben Sie die Auflistung der Upstream-Ports aus "+ svn: // svn.freebsd.org / ports / " verwendet und Builds werden immer dann geplant, wenn sich der Zweig " 2019Q2 +" ändert. Wie bereits erwähnt, sind die vierteljährlichen Zweigstellen größtenteils stabil und werden nur selten aktualisiert. Da Sie wahrscheinlich nicht warten möchten, bis eine solche Änderung eingeht, bevor der Build zum ersten Mal ausgelöst wird, lassen Sie es uns einmal von Hand ausführen.

Öffnen Sie Ihr Buildbot-Webinterface (+ http: /// buildbot / +) und navigieren Sie zu * Builds> Builders> bulk-112amd64-2019Q2 *. Es werden noch keine Builds angezeigt.

image: https: //assets.digitalocean.com/articles/buildbot_poudriere/step7a.png [Bulk-Builder-Seite - noch keine Builds]

Klicken Sie oben rechts auf die Schaltfläche * force * und dann auf * Start Build *. Dadurch wird der Build mit seinen Standardeinstellungen ausgelöst, d. H. Grund, Zweig und andere Werte werden nicht überschrieben. Es kann eine Minute dauern, bis der Schritt "Update Ports Tree" ausgeführt wird. Schließlich sollte der Poudriere-Build auch erfolgreich ausgeführt werden. Das Webinterface zeigt den Build als erfolgreich an.

image: https://assets.digitalocean.com/articles/buildbot_poudriere/step7b.png [Erfolgreiche Erstellung]

Durch Klicken auf einen der Links (* Poudriere-Build * - und * Poudriere-Protokolle *) gelangen Sie zur Poudriere-Weboberfläche und erstellen Protokolle für diesen bestimmten Build (wie in Schritt 6 gezeigt). Erweitern Sie durch Klicken auf den Pfeil neben * make bulk * und dann * stdio> view all… lines *, um die vollständige Ausgabe des Befehls + poudriere bulk …​ + anzuzeigen.

Nach Abschluss des ersten Builds sind die Pakete nun verfügbar, wie in Nginx in Schritt 6 konfiguriert. Gehen Sie in einem Browser zu "+ http: /// packages / " (oder " http: /// packages / ") und klicken Sie sich durch das von Poudriere erstellte Paket-Repository. Sie finden die eigentlichen Paketdateien (` *. Txz `), sobald Sie eines der Repositorys betreten und zum Unterverzeichnis ` All / +` navigieren.

image: https://assets.digitalocean.com/articles/buildbot_poudriere/step7c.png [Liste der Paket-Repositorys]

Jetzt, da Pakete über HTTPS verfügbar sind (oder HTTP, wenn Sie dies entschieden haben) und automatisch auf Änderungen der Portstruktur basieren, können Sie einen oder mehrere Hosts für die Verwendung dieser Pakete konfigurieren.

In diesem Schritt benötigen Sie einen zweiten FreeBSD-Server und richten ihn so ein, dass er die auf dem CI-Server erstellten Pakete abrufen und installieren kann. Wir werden diesen zweiten Server den * Paket-Client * nennen.

SSH in den * Client * Host. Die meisten verbleibenden Anweisungen in diesem Abschnitt werden auf dem * Client * ausgeführt:

Erstellen Sie das Verzeichnis für benutzerdefinierte Paket-Repository-Konfigurationen:

Öffnen Sie als * root * -Benutzer einen Editor, um die Datei + / usr / local / etc / pkg / repos / ci.conf + zu erstellen, und geben Sie an, wie und wo Pakete abgerufen werden sollen:

Wenn Sie sich für die Paketsignatur entschieden haben, verwenden Sie diesen Inhalt:

/usr/local/etc/pkg/repos/ci.conf

Wenn Sie auf die Paketsignatur verzichten möchten, deaktivieren Sie alternativ die Signaturprüfungen wie folgt:

/usr/local/etc/pkg/repos/ci.conf

Sie haben das Paket-Repository fertig konfiguriert und aktiviert. Bei einer regulären FreeBSD-Installation wird jedoch auch das offizielle Paket-Repository "FreeBSD" aktiviert. Das Mischen von installierten Paketen aus verschiedenen Quellen ist eine kinderleichte Möglichkeit, Ihre Produktionssoftware irgendwann aufgrund von inkompatiblen Softwareversionen oder unterschiedlichen ABI-, API- oder Build-Optionen zum Absturz zu bringen. Alle Pakete auf einem Host sollten aus derselben Quelle stammen.

Die Standardkonfiguration des offiziellen Repository ist in + / etc / pkg / FreeBSD.conf + gespeichert. Diese Datei gehört zum Basissystem und sollte nicht berührt werden. Sie können jedoch die Einstellungen überschreiben, dh wir möchten das Repository vollständig deaktivieren, indem Sie das entsprechende Flag in eine Konfigurationsdatei unter "+ / usr / local / etc / pkg / repos " einfügen, in der auch Ihr eigenes Repository konfiguriert ist. Bitte erstellen Sie eine neue Datei " / usr / local / etc / pkg / repos / FreeBSD.conf +" mit einem Editor und verwenden Sie den folgenden Inhalt, um das FreeBSD-Repository zu deaktivieren:

/usr/local/etc/pkg/repos/FreeBSD.conf

Wenn Sie sich auf einem vollständig unberührten * Paket-Client * -Host befinden, sind noch keine Pakete installiert, und Sie können sofort mit der Verwendung Ihres eigenen Paket-Repositorys beginnen. Wenn jedoch nur ein Paket von einer anderen Quelle installiert wurde, wird empfohlen, diese Pakete zu deinstallieren und mit Ihrer eigenen Quelle von vorne zu beginnen. Der Paketmanager "+ pkg " selbst wird als Paket installiert. Um das Henne-Ei-Problem zu lösen, wird das FreeBSD-Basissystem mit einer kleinen ausführbaren Datei " / usr / sbin / pkg " ausgeliefert, die den Paketmanager booten kann. Das heißt, laden Sie das Paket " pkg " herunter und installieren Sie es als erstes Paket auf dem System. Ab diesem Zeitpunkt unterstützt Sie die ausführbare Datei " / usr / local / sbin / pkg +" dieses Pakets als vollständiger Paketmanager.

Führen Sie den folgenden Befehl aus, um + pkg + zu booten:

In der Ausgabe von "+ package bootstrap" sollten Sie sehen, dass Pakete aus Ihrem eigenen Paket-Repository stammen, das wir in der Konfigurationsdatei "+ ci +" genannt haben. Wenn Sie einen Paketsignaturschlüssel verwenden, wird in der Ausgabe auch auf die Sicherheitsüberprüfung hingewiesen.

Wenn Sie diese erfolgreiche Ausgabe sehen, fahren Sie mit dem nächsten Notenblock fort. Wenn jedoch der Paketmanager oder andere Pakete bereits von einer anderen Quelle installiert wurden und diese Fehlermeldung angezeigt wird:

Folgen Sie dann bitte den Anweisungen im Hinweis.

In dem wahrscheinlichen Fall, dass Sie Ihren Paket-Host mit einem Let’s Encrypt-Zertifikat für HTTPS einrichten, stoßen Sie auf das Hühnchen-und-Ei-Problem, bei dem Ihr Paket-Host nicht vertrauenswürdig ist, Sie jedoch das Paket + ca_root_nss + installieren müssen ( vertrauenswürdige Stammzertifizierungsstellen enthalten), um der Let’s Encrypt-Zertifizierungsstelle zu vertrauen und damit auch dem Server zu vertrauen, auf dem Ihre benutzerdefinierten Pakete gehostet werden. Das gleiche Problem würde auftreten, wenn Sie eine interne Zertifizierungsstelle verwenden (von Ihnen oder Ihrem Unternehmen selbst signiert). Zertifikatsüberprüfungsfehler führen zu einer Fehlerausgabe wie folgt, wenn der Paketmanager gebootet wird:

Wenn Sie diesen Fehler sehen, befolgen Sie bitte die Anweisungen im Hinweis unten. Andernfalls sind Sie fertig und können diesen Teil überspringen und nach der Notiz fortfahren.

Wenn Sie bereits vorhandene Pakete gelöscht haben, ist es jetzt ein guter Zeitpunkt, wichtige Tools neu zu installieren (z. sudo) sowie alle anderen gewünschten Pakete.

Und aus der Root-Shell aussteigen, falls das noch der Fall ist:

Um zu testen, ob alles funktioniert, installieren Sie Pakete von der in der Buildbot-Masterkonfiguration angegebenen Liste (Variable + PORTS_TO_BUILD +). Zum Beispiel die Bash-Shell und sudo:

Bestätigen Sie die Installation erneut mit + y + und dann + ENTER +. Die Paketinstallation sollte ohne Probleme ausgeführt werden.

Sie können "+ pkg info " verwenden, um die derzeit installierten Pakete (einschließlich eventueller Abhängigkeiten) aufzulisten. Um sicherzustellen, dass keine Pakete aus anderen Quellen installiert sind, was zu Konflikten oder Inkompatibilitäten führen kann, können Sie installierte Pakete mit diesen Details mit der Abfrage ` pkg"% n: autoinstalled =% a from repo =% R "` auflisten. Beachten Sie, dass " pkg " als Bootstrap aus " unknown-repository +" angezeigt wird. Aus diesem Grund haben Sie zuvor die Bootstrap-Ausgabe überprüft, um festzustellen, dass der Paket-Manager selbst auch aus Ihrem eigenen Paket-Repository stammt.

In diesem letzten Schritt haben Sie den Zugriff auf das Paket-Repository des CIs auf einem Client konfiguriert und die Prüfung der Paketsignatur zu Sicherheitszwecken optional aktiviert. Sie haben sichergestellt, dass Pakete nur aus einer Quelle stammen, um Kompatibilitätsprobleme zu vermeiden installierte Ihre gewünschten Pakete wie vom CI erstellt.

In diesem Lernprogramm haben Sie Poudriere installiert und konfiguriert, die Paketerstellung automatisiert ausgeführt und den sicheren Zugriff auf das Paket-Repository von einem Client-Host aus konfiguriert. Das Ergebnis sind die neuesten erstellten Pakete, die von einer einzigen zentralen Quelle installiert wurden. Das Setup versetzt Sie in eine hervorragende Lage, um Ihre Server konsistent und auf dem neuesten Stand zu halten und Versions-Upgrades externer Softwarepakete zu verwalten.

Um Ihr aktuelles Setup weiter zu verbessern, können Sie ausgewählte Folgeschritte in Betracht ziehen: