ATIX AG
  • Leistungen
    • Consulting
      • Linux Platform Operations​
      • Infrastructure Automation​
      • Container Plattformen und Cloud​
      • DevOps Prozesse, Tooling und Kultur​
      • Cloud Native Software Entwicklung​
    • Produkt
      • orcharhino
        • Über orcharhino
        • orcharhino Support
        • orcharhino Betrieb
    • Technologien
      • Ansible
      • AWX und Ansible Automation Platform
      • Docker
      • Foreman
      • GitLab
      • Istio
      • Kubernetes
      • Linux-Distributionen
      • OpenShift
      • Puppet
      • OpenVox
      • Rancher
      • Rundeck
      • Saltstack
      • SUSE Manager
      • Terraform
  • Schulungen
    • Ansible-Schulungen
    • AWX-Schulung
    • Docker & Container-Schulung
    • Git-Schulung
    • Kubernetes-Schulung
    • OpenShift-Schulung
    • orcharhino-Schulung
    • OpenVox/Puppet-Schulungen
    • Terraform-Schulung
  • Events
    • Webinare
  • Blog
  • Unternehmen
    • Über uns
    • Referenzen
    • Unternehmenswerte
    • Soziales Engagement
    • Newsroom
    • Newsletter
    • Kontakt
  • Karriere
  • English
  • Click to open the search input field Click to open the search input field Suche
  • Menü Menü

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.

ebook Infrastucture Automation

Kostenloses E-Book

Infrastructure Automation mit Linux und Open Source Tools

Das kostenlose E-Book zeigt praxisnah, wie Sie mit Linux und Open-Source-Tools wiederkehrende Aufgaben vereinfachen, Fehler reduzieren und skalierbare IT-Prozesse aufbauen.
Jetzt entdecken.

Jetzt kostenlos herunterladen
dockerlogo

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
Foremanhat

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?

Link to source code at github

Das könnte Sie auch interessieren:
Docker Image Docker: Komposition von Containern
orcharhino orcharhino und Sophos – eine Malware Spurensuche
Sustainable Open Source Open-Source Software heute und morgen
Snapshots für alle! Snapshots für alle!
Migrating CentOS 8 to Rocky Linux 8 or AlmaLinux 8 using orcharhino Migrating CentOS 8 to Rocky Linux 8 or AlmaLinux 8 using orcharhino
ansible logo Automatisierte Windows Patches mit Ansible
ATIX-Crew
+ postsBio

Der ATIX-Crew besteht aus Leuten, die in unterschiedlichen Bereichen tätig sind: Consulting, Development/Engineering, Support, Vertrieb und Marketing.

  • ATIX-Crew
    Foreman Birthday Party 2024
  • ATIX-Crew
    CrewDay 2024
  • ATIX-Crew
    Die XZ-Sicherheitsschwachstelle: Eine Übersicht
  • ATIX-Crew
    Kafka mit Ansible automatisieren
  • ATIX-Crew
    Große Debian Repositories mit Pulp verwalten
  • ATIX-Crew
    Konfigurationsmanagement über verschiedene Netze mit AWX
  • ATIX-Crew
    Vergangenheit, Gegenwart und Zukunft von pulp_deb
  • ATIX-Crew
    DevOps Kultur „ohne Bullshit“
  • ATIX-Crew
    Die Zukunft von Ansible
  • ATIX-Crew
    Ein etwas anderer OSAD
  • ATIX-Crew
    Save The Rhino
  • ATIX-Crew
    Ansible Collections – Mehr Übersichtlichkeit und einfachere Teilhabe bei Ansible
  • ATIX-Crew
    SBOL: Open Source basierter Austausch für Biotech Enthusiasten
  • ATIX-Crew
    ATIX @ CfgMgmt Camp 2020
  • ATIX-Crew
    Ansible Rollen testen mit Molecule
  • ATIX-Crew
    Workshops in da Cloud – Was Ansible, Docker und die GitLab CI/CD hierfür bietet
  • ATIX-Crew
    ATIX-Crew on Tour: Geocaching und Nudelsalat am Wasser
  • ATIX-Crew
    Der Debian/Ubuntu Erratum Dienst von ATIX ist jetzt Open Source!
  • ATIX-Crew
    Die ATIX-Crew @ Config Management Camp 2019
  • ATIX-Crew
    Vom Startblock in die Traufe!
  • ATIX-Crew
    orcharhino-installer Plugin Selection
  • ATIX-Crew
    fpm – der schnelle Weg zum Paket
  • ATIX-Crew
    ATIX #CrewDay: Rhino lernt Sprechen!
  • ATIX-Crew
    SaltStack: Salzige Alternative zum Puppetspieler
  • ATIX-Crew
    Konfigurationmanagement mit Ansible
  • ATIX-Crew
    Snapshots für alle!
  • ATIX-Crew
    Rancher: Neue Container für die (Server-)Farm – schnell und einfach
  • ATIX-Crew
    Rancher: Dirigieren eines Container-Rudels
  • ATIX-Crew
    Docker Swarm: Container im Rudel
  • ATIX-Crew
    Die ATIX auf den Chemnitzer Linux Tagen 2017 – Ein Bericht aus der Sicht unserer Lernenden
  • ATIX-Crew
    Software defined Storage
  • ATIX-Crew
    Docker Container – eine leichtgewichtige Alternative zu Virtualisierungen
  • ATIX-Crew
    Selenium IDE – Automatisiertes Testen von Webanwendungen mit einem Browser

Auf dieser Seite

ISO 27001 Zertifizierung ISO 27001 Zertifikat herunterladen
ISO 9001 Zertifizierung ISO 9001 Zertifikat herunterladen
Newsletter
Nichts mehr verpassen. Melden Sie sich für den ATIX Newsletter an!
Jetzt anmelden
Blog
  • Blog Startseite
  • ATIX Insights
  • Cloud Native
  • Container Plattformen und Cloud
  • DevOps
  • Infrastructure Automation
  • Linux Platform Operations
  • orcharhino
Datenschutz & Impressum

Datenschutz

Impressum

AGB

B2B
Twitter     Facebook    LinkedIn    Youtube     mastodon=

© Copyright – ATIX AG

Nach oben scrollen Nach oben scrollen Nach oben scrollen