Perl und Gitlab – ein Erfahrungsbericht II

Perl und Gitlab – ein Erfahrungsbericht II

In diesem Vortrag zeige ich anhand einfacher öffentlicher Beispielprojekte, wie Perl-Projekte in Gitlab mittels der Gitlab-CI gebaut, getestet und in ein Docker-Image installiert werden können.

Die Projekte setzen folgende Werkzeuge ein:
- cpanm zum Installieren benötigter Module
- Dist::Zilla zum Testen und Paketieren einer Distribution und zum Ermitteln benötigter Abhängigkeiten

Dieser Vortrag ist aktualisierte Fassung meines Vortrags vom letzten Jahr.

Demo-Projekte:
https://gitlab.com/perlservices-demo/base-module
https://gitlab.com/perlservices-demo/perlservices-demo-base

45ba25063a79aefef3d9885c37694903?s=128

Gregor Goldbach

March 06, 2019
Tweet

Transcript

  1. Perl und Gitlab Ein Erfahrungsbericht II Gregor Goldbach grg@perl-services.de

  2. Inhalt Was erzähle ich hier? • Nutzung des Werkzeugkastens von

    Perl in CI-Pipeline als Ausgangspunkt für eigene Projekte • Meine Erfahrungen seit dem Vortrag im letzten Jahr - kein Anspruch auf Vollständigkeit • Dies ist eine Einführung
  3. Ziel Warum solltest du mir zuhören? • Einführung in Gitlab-CI

    • Konfiguration der Gitlab-CI • Testen und Paketieren von Perl-Distributionen • automatisiertes Erstellen eines Docker-Images • funktionierende öffentliche Beispielprojekte
  4. Überblick • Begriffsdefinition »CI« • meine Anforderungen: • Automatisierung •

    Mehrstufigkeit • Abhängige Projekte • identische Umgebung für Builds
  5. Einführung

  6. Was ist Gitlab? • Webanwendung zur Versionsverwaltung von Software auf

    Basis von git • kostenlos: (private) Repos, Wiki, Tickets, CI-System, Docker-Registry, Deployment-Pipeline • Geschäftsmodell: »open core« • Lizenz: MIT (»expat«)
  7. Was ist CI? • »continuous integration«, etwa »fortlaufende Integration« •

    Nachfolger von »nightly build«, Vorstufe von »continuous delivery« • Entwickler nutzen gemeinsame Codebasis und fügen ihre Änderungen hinzu • Nach einem Commit automatisierter Ablauf (Bauen, Linken, Testen)
  8. Anforderungen

  9. Anforderung 1: Automatisierung • CI startet nach Commit • nach

    Fehlschlag wird mir dieser gemeldet • Schritte der CI sind konfigurierbar
  10. CI-Konfiguration • eigenes Beschreibungsformat, YAML-basiert • in Docker-Container werden Befehle

    ausgeführt • was nicht im Image enthalten ist, muss während des Builds nachinstalliert werden
  11. Beispiel: Konfiguration • Dist::Zilla-basierte Perl-Distribution • Unit-Tests mit Messung des

    Grads der Abdeckung • Bei erfolgreichem Build steht die Distribution als Artefakt zur Verfügung • nutzt eigenes Docker-Image, das für die Perl-Entwicklung zugeschnitten wurde • https://gitlab.com/perlservices-demo/base-module
  12. .gitlab-ci.yml

  13. .gitlab-ci.yml

  14. None
  15. None
  16. None
  17. Anforderung 2: Mehrstufigkeit • CI läuft in Stufen ab, die

    aufeinander aufbauen • nach Fehlschlag einer Stufe bricht der Build ab • mehrere Blöcke einer Stufe laufen parallel
  18. Stages in der .gitlab-ci.yml

  19. Stages in der .gitlab-ci.yml

  20. Ansicht der Pipelines

  21. Stages in der Pipeline

  22. Anforderung 3:
 abhängige Projekte • ein Build eines Projekts kann

    einen anderen Build auslösen • auf bestimmte Branches oder Dateien beschränken
  23. Trigger • Gitlab kann Builds per API auslösen • Projekt

    2 soll gebaut werden, wenn Build im Master- Branch von Projekt 1 erfolgreich durchläuft • Authentisierung über Token, das nur während des Jobs gültig ist
  24. Trigger in der .gitlab-ci.yml

  25. Trigger in der Pipeline (upstream)

  26. Trigger in der Pipeline (downstream)

  27. Anforderung 4:
 identische Umgebung für Builds • bei Fehlersuche auf

    Code beschränkt bleiben, nicht auch noch Build-Umgebung • verhindern, dass das Betriebssystem Pakete aktualisiert • verhindern, dass neue Perl-Module von CPAN installiert werden
  28. Lösung
 identische Umgebung für Builds • verhindern, dass das Betriebssystem

    Pakete aktualisiert: kein apt-get install • verhindern, dass neue Perl-Module von CPAN installiert werden: • auf Versionen festnageln • Docker-Image zuschneiden
  29. cpanm zügeln

  30. Docker anstoßen

  31. Gitlab ❤ Docker • Builds laufen in eigenem Container •

    Wenn ich jetzt ein Docker-Image in einem Build bauen möchte, dann läuft Docker in Docker (!) • Es gibt ein auf Alpine-Linux basierendes Image dafür • https://gitlab.com/perlservices-demo/perlservices-demo- base
  32. Beispiel: Docker-Image automatisiert bauen • Gitlab-Projekt, das Docker-in-Docker nutzt •

    Drei Stages: build, test, release • Bei Erfolg wird Image in die Registry auf Gitlab geladen • https://gitlab.com/perlservices-demo/perlservices-demo- base
  33. Docker-Image bauen: 1. Hälfte

  34. Docker-Image bauen: 2. Hälfte

  35. In Docker Repos clonen • Docker-Image muss cpanm, dzil und

    Weiteres enthalten • Während des Baus wollen wir CPAN-Module installieren • Wir installieren sie für die Projekte, die auf diesem Image basieren • Dadurch erhalten wir ein Image, das genau zugeschnitten ist • Dafür brauchen wir cpanfile und dist.ini aus den Projekten
  36. Dockerfile 1

  37. Dockerfile 2

  38. Dockerfile 3

  39. Ausgabe des Builds

  40. Danke für eure Aufmerksamkeit! • Fragen? • Anmerkungen? !40

  41. Backup: Erfahrungen

  42. Gitlab • Arbeiten damit macht Spaß, Vieles funktioniert einfach so

    • Doku und Beispiele gibt es in Massen • Authentisierung ist durch CI_JOB_TOKEN besser geworden • Schrauben an .gitlab-ci.yml kann Nerven kosten, besser eigenen Server nutzen