Mit Paketen im Laufschritt ins Ziel - Paketerstellung für Linux-Systeme (Continuous Lifecycle 2014)

Mit Paketen im Laufschritt ins Ziel – Paketerstellung für Linux-Systeme
continuous.lifecycle, Mannheim, 10.-12. November 2014
© msg systems, 11.11.2014
1 Paketerstellung für Linux-Systeme / A. Schwartz, C. Exner

View Slide

Paketerstellung für Linux-Systeme / A. Schwartz, C. Exner
2
AGENDA
1. Build Pipeline und Continuous Delivery
2. Varianten für Software-Installationspakete
3. Erzeugen von Software-Installationspaketen für Linux
4. Verwalten und Installieren von Paketen
5. Zusammenfassung

View Slide

3
Mein Arbeitgeber
1980 gegründet
mehr als 4.500 Kollegen
583 Mio € Umsatz 2013
23 Länder
in 13 Städten
in Deutschland präsent
msg systems ag

View Slide

4
Wer ich bin
Alexander Schwartz
Principal IT Consultant im GB Travel und Logistics
12 Jahre Java
7 Jahre PL/SQL
7 Jahre
Absatzfinanzierung
3,5 Jahre Direktbank
1 Frau
2 Kinder
387 gefundene
Geocaches
@ahus1de

View Slide

5
AGENDA
5. Zusammenfassung

View Slide

6
Build Pipeline
Die Build Pipeline automatisiert die Übergabe der Software von Entwicklung über Test in Produktion.
• Software-Artefakte werden automatisch erstellt.
• Installation erfolgt automatisch oder auf Knopfdruck.
• Automatische Tests verhindern Regressions-Fehler.
• In allen Umgebungen wird dasselbe Artefakt installiert
(es unterscheidet sich nur die
umgebungsspezifische Konfiguration).
Ergebnis ist ein reproduzierbarer Prozess ohne Überraschungen.
CI-Server
Paket
Produktions-
Umgebung
Test-
Umgebung
automatische
Tests

View Slide

7
Begleitende Maßnahmen für Continuous Delivery
Continuous Delivery ermöglicht taggleiche Produktionssetzung.
• Loadbalancer und geteilte Umgebungen ermöglichen
Installationen ohne Wartungsfenster und
Probeinstallationen (Canary Release).
• Detailliertes, automatisch aufgesetztes Monitoring in allen
Umgebungen macht Probleme frühzeitig erkennbar.
• Zentrales Log-Management ermöglicht Problemanalyse
ohne Zeitverlust.
• Automatisch aufgesetzte Systeme garantieren einheitliche
Umgebungen (Infrastructure as Code).
Software-Änderungen können taggleich oder mehrmals täglich in Produktion übernommen werden.
Load-
balancer
Produktions-
Umgebung 1
Produktions-
Umgebung 2
Logs
Monitoring

View Slide

8
AGENDA
5. Zusammenfassung

View Slide

9
Optionen für Software-Installationspakete
Varianten für Software-Installationspakete
1. Installationsanleitung für manuelle Installation
• Jede Installation benötigt einen menschlichen Installateur.
• Unschärfe in der Installationsanleitung wird durch Erfahrung des Installateurs ausgeglichen.
⇒ Hohes Fehlerpotential.
⇒ Zu teuer bei häufigen Installationen.
2. Individuelles automatisches Installationsskript
• Individuell für die jeweilige Anwendung und Zielplattform entwickelt.
• Häufig genutzte Funktionen sind enthalten.
⇒ Funktionen für Deinstallation und Inventarisierung fehlen in der Regel.
⇒ Projektspezifisches Know-How für die Pflege des Scripts notwendig.

View Slide

10
3. Software besteht aus einer Datei und kann direkt gestartet werden
• Spezifisch für Entwicklungsplattform (z.B. ein JAR für Dropwizard).
• Software kann mit einem Einzeiler gestartet werden.
⇒ Einfach zu warten und zu automatisieren.
⇒ Funktionen für Deinstallation und Inventarisierung fehlen in der Regel.
4. Paketierung als Linux-Standardpaket
• Spezifisch für die Zielplattform entwickelt.
• Standardfunktionen des Paketmanagers stehen zur Verfügung (Deinstallation, Staging, etc.).
⇒ Hohe Standardisierung in Pflege, Erstellung, Installation und Betrieb.

View Slide

11
5. Paketierung der Software als Container
• Installation der Software auf einem Basis-Betriebssystem (z. B. Docker).
• Container ist die Summe der Installation mehrerer Software-Installationspakete.
⇒ Höchste Automatisierung bei Übernahme in Produktion.
⇒ Sobald sich ein Paket ändert, muss der Container neu gepackt werden.
⇒ Komplexität der Containerinstallation ergibt sich aus der Summe der Einzelinstallationen.
(Er ist daher nur eine Ergänzung zu den Varianten 2-4)

View Slide

12
AGENDA
4. Verwaltung und Installieren von Paketen
5. Zusammenfassung

View Slide

13
Wann passt die Paketierung als Linux-Paket?
Standardanwendungsfall für Linux-Pakete
Vorbedingungen:
• Zielverzeichnis und Benutzerrechte für die Installation sind zum Zeitpunkt der Paketierung bekannt.
• Software soll in genau einer Version auf dem Zielsystem installiert werden.
• Gleiches binäres Paket für alle Umgebungen (Entwicklung, Test, Produktion)
mit umgebungsspezifischer Konfiguration.
Infrastruktur (durch Paket-Manager):
• Prüfen und automatisches Installieren von Abhängigkeiten auf dem Zielsystem.
• Option für Scripts, die bei Installation, Update und Deinstallation laufen.
• Option für Scripts, die bei der Installation anderer Pakete gestartet werden (Trigger).
• Schutz für Konfigurationsdateien, damit diese bei einem Update nicht überschrieben werden.
• Deinstallationsroutine, die alle installierten Dateien löscht.

View Slide

14
Linux-Softwarepakete
Linux-Softwarepakete standardisieren die Installation.
• Paketierung ist unabhängig von der Programmiersprache.
• Automatische Installation ersetzt die Installationsanleitung.
• Sehr einfache Inventarisierung der aktuell verwendeten Software.
Fortgeschrittene Szenarien:
• Digital signierte Softwarepakete garantieren Integrität.
• Jede Umgebung erhält ihr eigenes Repository.
• Nach erfolgreichem Test wird ein Softwarestand in das
nächste Repository übergeben.
• Die Schritte der Build-Pipeline werden im
Continuous-Integration-Server per Browser gestartet.
Produktions-
Umgebung
Test-
Umgebung
Test-
Repository
Produktions-
Repository
Übergabe ins Produktionsrepository
erfolgt nach erfolgreichem Test

View Slide

15
Werkzeuge für die Paketerstellung
Die Standardwerkzeuge bieten größtmögliche Flexibilität
rpmbuild
• Das Standard-Paketformat unter CentOS/RedHat Enterprise Linux/
SUSE ist RPM.
• Das Standard-Werkzeug dafür ist rpmbuild.
dpkg-buildpackage
• Das Standard-Paketformat unter Debian/Ubuntu ist DEB.
• Das Standard-Werkzeug dafür ist dpkg-buildpackage.

View Slide

16
Erstellung von Paketen mit rpmbuild
Paketierung von Paketen mit rpmbuild:
1. Erstellen einer SPEC-Datei mit Parametern.
2. Bereitstellen aller Dateien in einem BUILDROOT-Verzeichnis als Teil von
%setup, %prep, %check, %build und %install.
3. Benennen von Dateien für die Installation im Abschnitt %files.
Wofür die SPEC-Datei ursprünglich geschrieben wurde:
1. Linux-Software wird für eine Linux-Distribution gepackt (Entwickler ist i.d.R. nicht der Paketierer).
2. Quellcode der Entwickler wird gepatched und mit make gebaut und
mit make install installiert (ggf. in ein neues Verzeichnis BUILDROOT).
3. Artefakte werden zusammengepackt und als Paket ausgeliefert.

View Slide

17
SPEC Beispiel
SPEC Beispiel: at Job Scheduling Tools
• 1 Quellcode-Archiv
• 4 zusätzliche Quelldateien
• 22 Patches (als Teil von %setup)
• 15 Zeilen %build (autoconf, configure, make)
• 8 Zeilen %check (make test)
• 37 Zeilen %install (make install)
• 18 Zeilen %files zum Zusammenstellen des Paketinhalts

View Slide

18
Werkzeuge für die Paketerstellung
Die folgenden Werkzeuge ermöglichen eine hohe Prozessautomatisierung
Maven Release Plugin & Maven RPM Plugin
• Mit beiden Plugins kann in einem Schritt eine neue Version
inklusive eines RPMs erstellt werden.
Effing Package Management (fpm)
• Über eine einfache Linux-Kommandozeile können RPM-Pakete, DEB-Pakete, etc.
erstellt werden.
• Paketierung von Node, Ruby und Python als Linux-Paket möglich.

View Slide

19
Paketieren mit Apache Maven RPM Plugin
Paketieren als Teil des Builds in Apache Maven
Voraussetzungen:
1. Maven-RPM-Plugin eingebunden in pom.xml.
2. Build erfolgt unter Linux (buildrpm Kommando im Pfad).
# Paketieren eines RPMs (SNAPSHOT)
mvn package
# Release eines RPMs
mvn release:perform

View Slide

20
Aktivieren des Maven RPM Plugins
Paketieren als Teil des Builds in Apache Maven (1/2)

org.codehaus.mojo
rpm-maven-plugin
2.1

attached-rpm

...

View Slide

21
Paketieren als Teil des Builds in Apache Maven (2/2)
...

mywebapp
${rpm.version}
${rpm.release}
...

/usr/share/tomcat/webapps

View Slide

22
Paketieren als Teil des Builds in Apache Maven (Optionen)
1. für Paketabhängigkeiten.
2. für das Einpacken zusätzlicher Maven-Artefakte.
3. für das Einpacken zusätzlicher Dateien.
4. , , für Dateiberechtigungen.
5. etc. für Scripte bei der Installation.
6. build-helper-maven-plugin für das Konvertieren von Maven in RPM und .
Maven-Version RPM Version RPM Release
2.5.2.1 2.5.2 1
2.5.2.1-SNAPSHOT 2.5.2 1~SNAPSHOT.${buildnumber}
Tilde

View Slide

23
Paketieren mit Effing Package Management
Continuous Delivery: Build war erfolgreich, die Dateien sollen „nur noch“ gepackt werden
• Entwickler nutzen Build-Tools, die Artefakte testen und erzeugen.
• Es gibt einen Satz von Quellen (keine Patches).
• In der Regel eine Zielplattform.
Effing Package Management (fpm)
# packe die Website als RPM Paket
fpm -s dir -t rpm -v 1.0 --iteration=1 \
--description "Our Website" -a all -n "website" --depends=http \
output/html=/var/www/html/

View Slide

24
Packen einer Ruby-Anwendung: Redmine
Redmine soll als Paket packt werden und ohne Zugriff auf das Internet installiert werden
Redmine ist ein Bug-Tracker, der mit Ruby entwickelt ist. Redmine hat Abhängigkeiten zu verschiedenen
Ruby-Gems. Die Verwaltung erfolgt durch Bundler.
# Packen von bundler als RPM
fpm -s gem -t rpm --epoch 1 -v 1.7.4 bundler
# Im Redmine-Verzeichnis: Herunterladen von Ruby-Gems in das Unterverz. vendor/cache
bundle package
# Packen des Verzeichnisses als RPM inkl. aller Abhängigkeiten
fpm -s dir -t rpm \
-d ruby -d rubygems -d mysql-devel -d gcc -d ruby-devel -d make -d rubygem-bundler \
-v 2.5.2 --iteration 1 -n redmine /vagrant/redmine/redmine-2.5.2/=/opt/redmine

View Slide

25
AGENDA
5. Zusammenfassung

View Slide

26
Werkzeuge für die Paketverwaltung
Pulp Software Repository
• Verwaltet RPM-Pakete als YUM-Repository.
• Automatisierung über Kommandozeile (auch remote) und REST-API.
• Basis für den neuen RedHat Satellite Server 6.
APTLY repository manager
• Verwaltet DEB-Pakete als Repository.
• Automatisierung über Kommandozeile (REST-API geplant).
A P T L Y

View Slide

27
Beispiel für Pulp
# Einrichten eines RPM-Repositorys
pulp-admin rpm repo create --repo-id=qa --display-name='QA Repo'
# Paketieren der Software
mvn ... || fpm ...
# Hochladen in Pulp und Bereitstellen im YUM Repository
pulp-admin rpm repo uploads rpm --repo-id=qa -f ...
pulp-admin rpm repo publish run --repo-id=qa
# Anzeige des Repositories
pulp-admin rpm repo content rpm --repo-id=qa --match 'name=...'
# Anzeigen aller Versionen eines Pakets aus Sicht des Paketmanagers (Zielsystem)
yum list --showduplicates ...

View Slide

28
Werkzeuge für die Paketverwaltung
JFrog Artifactory Pro (kommerzielle Alternative zu Pulp und APTLY)
• Verwaltet verschiedene Paketformate (Maven, RPM, Docker, etc.)
• Sehr gute Integration in Jenkins und andere CI-Server
Jenkins CI mit Build Pipeline Plugin
• Schritte inkl. Abhängigkeiten automatisiert.
• Freigaben können von Test- und Fachabteilung erfolgen, der
Prozess läuft dann automatisch weiter.

View Slide

29
Werkzeuge für die Installation von Umgebungen
Saltstack Salt
• Über Deklarationen werden Pakete, Installationsreihenfolge und
umgebungsspezifische Konfiguration für Server hinterlegt.
• Server in Entwicklung, Test und Produktion werden komplett
automatisch installiert.
HashiCorp Vagrant
• Entwickler können Server lokal virtualisiert starten und nutzen zentral
hinterlegte Images.
• Lokale Virtualisierung auf dem Entwicklerrechner erfolgt z.B. über
Oracle VirtualBox.
• Aktueller Softwarestand wird durch Salt automatisch installiert
und konfiguriert.

View Slide

30
Beispiel für Salt
Redmine RPM soll installiert werden inkl. Gems und DB-Initialisierung
# Salt Konfiguration für redmine-Installation
redmine:
pkg.latest:
- name: redmine
# ...
# Datenbank-Konfiguration, etc.
# ...
cmd.run:
- name: bundle install --local --without development test rmagick;
RAILS_ENV=production rake db:migrate
- cwd: /opt/redmine/

View Slide

31
Beispiele für Pulp und Salt
# Hochladen in Pulp und Bereitstellen im YUM Repository
pulp-admin rpm repo uploads rpm --repo-id=qa -f ...
pulp-admin rpm repo publish run --repo-id=qa
# Aktualisierung der Testsysteme mit einem neuen Softwarestand
salt 'test*' state.highstate
# Nach erfolgreichem Test Staging der Pakete
pulp-admin rpm repo copy rpm --from-repo-id qa --to-repo-id prod \
--recursive --match 'name=...'
pulp-admin rpm repo publish run --repo-id=prod
# Aktualisierung der Produktionssysteme mit einem neuen Softwarestand
salt 'prod*' state.highstate
# Inventarisierung aller Umgebungen für ein bestimmtes Paket oder alle Pakete
salt '*' pkg.version ...
salt '*' pkg.list_pkgs

View Slide

32
AGENDA
5. Zusammenfassung

View Slide

33
Zusammenfassung
Linux-Pakete …
• … sind für Continuous Delivery sehr gut geeignet, da die Zielplattform bekannt ist.
• … können durch Plugins für Build-Werkzeuge und durch Stand-Alone-Werkzeuge erzeugt werden.
• … können von Paket-Repositories verwaltet werden.
• … können auf Test-Systemen und Produktions-Systemen inventarisiert werden.
• … ermöglichen standardisierte und automatisierte Installationsroutinen mit Deployment-Werkzeugen
Linux-Pakete sind der Integrationspunkt verschiedener Module einer Continuous Delivery Pipeline.
Die einzelnen Module können bei Bedarf ausgetauscht werden. Der Rest der Pipeline bleibt unverändert.
@ahus1de

View Slide

Vielen Dank für Ihre Aufmerksamkeit
msg systems ag
Alexander Schwartz
Principal IT Consultant
Travel & Logistics
Mergenthalerallee 73-75
65760 Eschborn/Frankfurt
Mobil: +49 171 5625767
E-Mail: [email protected]
www.msg-systems.com
34

View Slide

Mit Paketen im Laufschritt ins Ziel - Paketerstellung für Linux-Systeme (Continuous Lifecycle 2014)

Mit Paketen im Laufschritt ins Ziel - Paketerstellung für Linux-Systeme (Continuous Lifecycle 2014)

Alexander Schwartz

More Decks by Alexander Schwartz

Other Decks in Technology

Featured

Transcript