fpm – der schnelle Weg zum Paket

Unser heutiger Artikel behandelt das Tool „fpm“ – das ‚effing package management“.

Derzeit sprinten wir innerhalb unserer agilen Arbeitsmethodik ‚Scrum‘ in Richtung orcharhino 3.2.0. Ein Ziel der neuen Version des Werkzeugs zur Orchestrierung, Verwaltung und dem Lifecycle Management von Servern innerhalb eines Rechenzentrums soll der erste Schritt zur Vereinfachung der Installation von orcharhino bis hin zum ersten Erzeugen eines Hosts darstellen. Doch hierbei sind wir erstmals auf eine Herausforderung gestoßen: Beim automatischem Deployment einer bestimmten Linux Distribution wird eine DVD benötigt. Derzeit wird das ISO Image über VMware eingebunden und in orcharhino als Installationsmedium zur Verfügung gestellt. Kompliziert, ein manueller Schritt und dadurch auch fehleranfällig. Eine Lösung musste her…

Warum nicht einfach das ISO Image verpacken und bei der Installation von orcharhino mit installieren?

Aber wie verpacken wir das ISO Image?

Herkömmliche Distributionen bieten entsprechende Tools an, um saubere RPM bzw. deb Pakete zu erstellen. Das Erstellen und Warten der RPM Spec Datei kann jedoch viel Zeit in Anspruch nehmen. Der Vorteil liegt darin, dass man ein einmalig erstelltes RPM auf vielen unterschiedlichen Hosts einfach ausrollen und so z.B. Anwendungsprogramme, Plugins und Daten auf dem Zielsystem installiert. Zudem kann man das Zielpaket auch dem Upstream Projekt wie Fedora oder Debian zur Verfügung stellen und somit seinen Beitrag zur Open Source Community leisten.

Man könnte auch ganz auf das RPM verzichten und stattdessen einfach ein tar Archiv nach der orcharhino Installation an einem bestimmten Punkt ablegen. Der Nachteil darin ist jedoch, dass der Paketmanager nicht zum Update oder Löschen genutzt werden kann.

Was wir suchen, ist eine Lösung zwischen Volle-RPM-Nutzung und tar Archiv: Die Erstellung des Pakets soll schnell und einfach vonstatten gehen und der RPM Paketmanager soll seiner Aufgabe nachgehen können die Dateien zu verwalten und beim Aktualisieren/Löschen des Paket genutzt werden.

Schon mal etwas von fpm gehört?

Mit fpm kann man

  • von verschiedenen Datenquellen wie gem, rpm, deb, python, apk, tar oder einem Verzeichnis
  • schnell und einfach
  • für viele Zieltypen wie rpm, deb, freebsd
  • Pakete erstellen!

Bei der Entscheidung sollte man sich jedoch überlegen, ob man wirklich fpm nutzen möchte. fpm erstellt zwar ein Paket, welches installiert werden kann, jedoch werden gewisse Vorgaben und Konventionen der Linux Distributionen ggf. nicht beachtet (z.B. Angabe einer Lizenz, richtige Verwaltung einer Paket Changelog, keine Unterscheidung zwischen Merkmale der jeweiligen Linux Distribution).

Genug der warnenden Worte – Wie verwendet man nun fpm?

Gehen wir mal davon aus, dass wir das ISO Image vom vorherigen Beispiel unter /media/cdrom eingebunden haben und daraus ein RPM erstellen wollen. Hierbei muss man wissen, dass fpm die jeweiligen Build Tools beim Erstellen der Pakete benötigt – im Fall vom RPM wird also das Programm „rpmbuild“ benötigt. Gut, dass wir uns gerade auf einem CentOS  befinden, weshalb wir sofort das RPM mit folgendem Befehl erstellen können:

fpm -s dir -t rpm -n ReallyCoolLinuxDistribution -C /media/cdrom .

Mit diesem Befehl wird aus einem Verzeichnis („-s dir“) ein RPM („-t rpm“) mit dem Namen („-n ReallyCoolLinuxDistribution“) erzeugt, indem zuerst in das Zielverzeichnis gewechselt wird („-C /media/cdrom“) und dann dass Verzeichnis verpackt wird („.“). Das resultierende RPM wird im aktuellen Ordner mit dem Namen ReallyCoolLinuxDistribution-1.0-1.x86_64.rpm abgelegt.

Mit dem folgenden Befehl können wir uns anschauen, was uns fpm hier zusammengebaut hat:

rpm -qpl --info ReallyCoolLinuxDistribution-1.0-1.x86_64.rpm

Schon mal ganz gut, aber wir sehen, dass einige Sachen nicht richtig gesetzt sind – wie z.B. die Version, die Releasenummer, RPM Summary, Post-Installationsskript und Changelog.  Setzen wir das nun richtig!

fpm -s dir -t rpm -n ReallyCoolLinuxDistribution -C chroot/ --rpm-dist rcld --rpm-summary "Really Cool Linux Distribution 1.0 ISO" \
--description "`cat desc.txt`" \ --rpm-changelog changes.txt --after-install postinstall.sh --license MIT -a noarch -v 4.1 \
--iteration 2 --url http:///www.orcharhino.com .

fpm erstellt das Paket und gibt Folgendes aus:

Created package {:path=>"ReallyCoolLinuxDistribution-4.1-2.rcld.noarch.rpm"}

Sieht doch schon ganz gut aus. Version 4.1, Release auf 2 und RPM Distribution sind auf „rcld“ gesetzt. Mit dem folgenden Befehl können wir auch überprüfen, ob URL, Description, usw. auch richtig von fpm im Paket spezifiziert wurden:

rpm -qpl --info ReallyCoolLinuxDistribution-4.1-2.rcld.noarch.rpm

Möchte man im Detail verstehen, was fpm macht um das RPM zu erstellen, bzw. jagt man einen Bug, kann man fpm auch etwas gesprächiger machen mit „–verbose“. fpm benutzt entsprechende
workspaces zum Erstellen der Pakete, die im Schluss aufgeräumt werden. Dies kann man mit „–debug-workspace“ verhindern.

Sehr elegant ist auch die Option „-e“. Gibt man diese an, wird die RPM Spec Datei vom Standard Editor (mit „export EDITOR=vim“ kann man „vim“ als Editor setzen) geöffnet. Speichert man die RPM Spec ab (bei vim mit „:w“) und beendet den Editor (mit „:q“), wird der Build-Prozess des RPMs mit dieser RPM Spec fortgesetzt und schlussendlich das RPM geschrieben.

Mit fpm kann man, wie bereits erwähnt, nicht nur RPM von Verzeichnissen erstellen, sondern vieles mehr. Weitere Optionen können mit „fpm –help“ angezeigt werden. Jedoch sollte fpm nicht die erste Wahl sein – ich würde es nur für einmalige Aktionen und in einfachen Anwendungsfällen empfehlen. Es ist immerhin besser als ein einfaches tar Archiv. Für richtige, saubere RPMs  (bzw. Debian Pakete) sollten wie bisher auch, die Bordmittel der jeweiligen Linux Distribution genutzt werden.

The following two tabs change content below.

ATIX-Crew

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