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

Transcript

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

   View Slide

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
   

   View Slide

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
   

   View Slide

4. Überblick
   • Begriffsdefinition »CI«
   
   • meine Anforderungen:
   
   • Automatisierung
   
   • Mehrstufigkeit
   
   • Abhängige Projekte
   
   • identische Umgebung für Builds
   

   View Slide

5. Einführung
   

   View Slide

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«)
   

   View Slide

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)
   

   View Slide

8. Anforderungen
   

   View Slide

9. Anforderung 1:
   Automatisierung
   • CI startet nach Commit
   
   • nach Fehlschlag wird mir dieser gemeldet
   
   • Schritte der CI sind konfigurierbar
   

   View Slide

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
    

    View Slide

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
    

    View Slide

12. .gitlab-ci.yml
    

    View Slide

13. .gitlab-ci.yml
    

    View Slide

14. View Slide

15. View Slide

16. View Slide

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
    

    View Slide

18. Stages in der .gitlab-ci.yml
    

    View Slide

19. Stages in der .gitlab-ci.yml
    

    View Slide

20. Ansicht der Pipelines
    

    View Slide

21. Stages in der Pipeline
    

    View Slide

22. Anforderung 3:

    abhängige Projekte
    • ein Build eines Projekts kann einen anderen Build
    auslösen
    
    • auf bestimmte Branches oder Dateien beschränken
    

    View Slide

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
    

    View Slide

24. Trigger in der .gitlab-ci.yml
    

    View Slide

25. Trigger in der Pipeline (upstream)
    

    View Slide

26. Trigger in der Pipeline (downstream)
    

    View Slide

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
    

    View Slide

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
    

    View Slide

29. cpanm zügeln
    

    View Slide

30. Docker anstoßen
    

    View Slide

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
    

    View Slide

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
    

    View Slide

33. Docker-Image bauen: 1. Hälfte
    

    View Slide

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

    View Slide

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
    

    View Slide

36. Dockerfile 1
    

    View Slide

37. Dockerfile 2
    

    View Slide

38. Dockerfile 3
    

    View Slide

39. Ausgabe des Builds
    

    View Slide

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

    View Slide

41. Backup: Erfahrungen
    

    View Slide

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
    

    View Slide