Erstellung von Foreman-RPM-Paketen mit Docker-Container
Das ATIX-Entwicklungsteam hat im letzten Scrum viel Zeit damit verbracht, die Build-Umgebung von orcharhino zu verbessern.
Bislang haben wir Jenkins-Build-Jobs verwendet, die die Aufgabe schon recht gut erledigt haben. Allerdings ist dieser Ansatz nicht immer so flexibel, wie wir es für die Aufrechterhaltung einer hochwertigen Produktlieferung für unsere Kunden benötigen. Die Jenkins-Build-Schritte waren hauptsächlich Shell-Skripte, die direkt in der Jenkins-Benutzeroberfläche konfiguriert wurden.
Für den Build-Prozess selbst wurden Docker-Container verwendet. Da die gesamte Struktur historisch gewachsen ist, hatten wir eine Menge Duplikate für nahezu identische Aufgaben, die nahezu identische Dockerdateien erzeugten. Dies war im Allgemeinen kein großes Problem, es sei denn, wir mussten Änderungen vornehmen. Abhängig von den notwendigen Änderungen konnte dies eine ganze Reihe von Dateien auf einmal betreffen, was eine ganze Reihe von notwendigen Änderungen und eine Verschwendung von Zeit und Mühe zur Folge hatte. Das mussten wir ändern und verbessern!
Nachdem wir mit verschiedenen Sandbox-Umgebungen auf der Basis von Jenkins-Pipelines herumgespielt hatten, kamen wir zu dem Schluss, dass der Weg über die Jenkins-Pipeline, d. h. eine „codebasierte“ Build-Umgebung, die eleganteste Lösung wäre. Da wir wussten, dass das vorgelagerte Foreman-Team erfolgreich tito / mock für die Erstellung von Foreman einsetzt, haben wir dieses Tool zunächst in Betracht gezogen. Wir kamen jedoch zu dem Schluss, dass die Erstellung der RPM-Pakete innerhalb von Docker mindestens genauso gut ist wie die tito / mock-Toolkette.
Darüber hinaus hat es den Vorteil, dass die Erstellungsumgebung nur einmal von Grund auf neu erstellt und wiederverwendet werden muss, anstatt sie für jedes Paket, das sich im Erstellungsprozess befindet, neu zu erstellen. Insgesamt bedeutet dies, dass wir die RPM-Erstellungszeit mit einem Docker-basierten Ansatz verringern können.
Die Herausforderungen bei der Erstellung von Foreman-Paketen sind wie folgt
- es gibt viele verschiedene Foreman-Pakete
- mehrere Git-Repositories: Die RPM-Spezifikationsdatei und einige Ressourcen sind in foreman-packaging gespeichert, der Hauptquellcode befindet sich jedoch im Foreman-Git-Repository
- der Foreman-Build erfordert eine Vielzahl von Abhängigkeiten
Die Ziele, die wir mit einem Jenkins-Pipeline-Ansatz unter Verwendung von Docker erreichen wollten, waren:
- Beschleunigung des gesamten Bauprozesses für eine bestimmte orcharhino release
- Alles als Code – sogar die Build-Anweisungen
- Wiederverwendung des guten Codes aus den alten Jenkins-Build-Schritten und Neuschreiben einiger schlechter Skripte
- DRY – Wiederholen Sie sich nicht. Keine doppelten Codes, Dockerdateien usw. mehr
- KISS – Keep it simple stupid, so dass jeder den gesamten Prozess verstehen und verbessern kann
Ich möchte Ihnen nun zeigen, wie unser neuer Prozess letztendlich funktioniert:
Wir verwenden CentOS 7 als Hostsystem. Wenn Sie eine andere Distribution verwenden, müssen Sie möglicherweise einige Befehle anpassen.
Falls Sie Docker nicht installiert haben, fügen Sie bitte das folgende Repo hinzu:
[docker] name=Docker Repository baseurl=https://yum.dockerproject.org/repo/main/centos/$releasever/ enabled=1 gpgcheck=1 gpgkey=https://yum.dockerproject.org/gpg
Anschließend installieren Sie Docker mit dem folgenden Befehl:
yum install docker-engine
Starten und aktivieren Sie den Docker-Dienst:
systemctl start docker systemctl enable docker
Der nächste Schritt besteht darin, den Docker-Container aus dem Docker Hub zu ziehen, da wir ihn später als Grundlage für den RPM-Baucontainer benötigen:
docker pull centos
Um das Skript foreman_docker_build zu verwenden, müssen Sie auch rpm-build und ruby installieren:
yum install rpm-build ruby git
Jetzt ist es an der Zeit, das foreman_docker_build github Repository auszuchecken und einen Blick in die README zu werfen:
git clone https://github.com/ATIX-AG/foreman_docker_build.git
Wechseln Sie zu foreman_docker_build und beginnen Sie mit der Erstellung Ihres Foreman-Pakets
cd foreman_docker_build ./build_foreman_packages.sh -n foreman -b 1.15-stable
Das war’s schon. Nachdem der Build abgeschlossen ist, befinden sich die RPMs im Verzeichnis „foreman/RPM“. Wie funktioniert das Ganze intern?
Nach dem Klonen des foreman-packaging und des Foreman-Repositorys sammelt das Skript alle erforderlichen Build-Dateien und verschiebt sie nach foreman/_pkg_build.
Dann kommt der interessante Teil.
Das Skript verwendet erb (eingebettetes Ruby), um dynamisch eine Dockerdatei und das Skript build_rpm.sh zu erstellen. Diese beiden Dateien werden in foreman/_pkg_build gespeichert. Das Skript build_rpm.sh wird später innerhalb des Docker-Containers verwendet, um das RPM zu erstellen. Das Dockerfile enthält die Build-Anweisungen für den Docker-Container. Da das Skript in der Lage ist, auch andere Foreman-Pakete aus der Foreman-Packaging-Distribution zu erstellen, wird das Dockerfile dynamisch generiert, basierend auf Variablen, die sich in foreman/_pkg_build/docker_vars.rb befinden. Die letztgenannte Datei wird durch das Skript build_foreman_packages.sh erstellt.
Im nächsten Schritt wird der Docker-Container mithilfe der Dockerdatei und einiger Dateien in foreman/_pkg_build erstellt.
Schließlich wird der Docker-Container gestartet, um das RPM zu bauen. Dies kann einige Zeit in Anspruch nehmen, da nun die Build-Abhängigkeiten aus der Datei foreman.spec ausgewertet und im Docker-Container installiert werden. Im letzten Schritt,
werden die RPM-Pakete erstellt und in „foreman/RPM“ gespeichert.
Ziemlich einfach, nicht wahr?
Das könnte Sie auch interessieren:
Der ATIX-Crew besteht aus Leuten, die in unterschiedlichen Bereichen tätig sind: Consulting, Development/Engineering, Support, Vertrieb und Marketing.
