Ich habe einen iX-Artikel für Dich: GitLab, GitLab, GitLab

Servus zusammen,

Dinge die man selbst gelernt hat, anderen Leuten beizubringen und helfend beiseite zu stehen, ist ein echt gutes Gefühl. Bei mir zieht sich das seit vielen Jahren durch die Icinga Community, einer der schönsten weil überraschensten Momente war wohl das Foto als “Danke” auf dem Icinga Camp Berlin 2019. Dann kommt noch dazu, dass ich sehr gerne Dokumentation schreibe, oder einfach alles aufschreibe, was ich irgendwann mal brauchen könnte. Und vielleicht jemand anders, der mal meinen Job macht, und ich mich neuen Aufgaben widmen kann. Nach den ersten Gehversuchen mit der Icinga-Schulung (2.x natürlich ;)) haben das nunmehr meine Kollegen übernommen, und meistern die Wissensvermittlung mit Bravour. Wir Entwickler sorgen dann in unseren Releases dafür, dass auch ihnen nicht langweilig wird 🙂

Ich für mich habe aber auch festgestellt, dass man nicht nur “das eine” machen soll und auch kann, sondern immer “über den Tellerrand” schauen sollte. Und so kams, dass ich auf meiner ersten OSDC 2013 keinen Dunst von Puppet, Elastic, Graphite, Container-Plattformen oder CI/CD hatte. Auch die Jahre danach waren hart, und meine Kollegen durften mir viel erklären, etwa Ceph und OpenStack. Jetzt nach vielen Jahren hilft mir dieses Wissen in meiner tagtäglichen Arbeit, und auf eine gewisse Art und Weise bin ich stolz, wenn mich meine Kollegen und Freunde nach Themen fragen, die nicht unmittelbar mit Icinga zu tun haben.

Dann gibts da noch Git, die schwarze Magie der Entwickler. 2004 in Hagenberg hab ich meinen VHDL-Code noch in CVS eingecheckt, 2009 .at-DNS-Zonen-Files nach SVN geschoben und irgendwann dank Icinga auch Git gesehen. Um gleich mal mit “force push” den Master zu zerstören – aller Anfang ist schwer. Seitdem ist viel passiert, und irgendwie hat jeder einen Git-Kniff, der gerne ausgetauscht wird. Die Nachfrage nach einer Schulung, seitens DEV (Kurzform für unsere Development-Abteilung), wurde immer größer und so wurde vor knapp 2,5 Jahren die Git-Schulung aus dem Boden gestampft.

Seither hat sich einiges getan, und wir haben unsere Open-Source-Entwicklung vollständig auf GitHub migriert, sowohl Icinga als auch NETWAYS. Aus dem vormaligen self-hosted Gitorious wurde dann mal ein GitLab, und mit jedem Release kam etwas neues dazu. GitLab verwenden wir an vielen Stellen – intern fürs Infrastrukturmanagement, betreut von MyEngineer im Hosting, als App in NWS und natürlich für Kunden und interne Projekte auf git.netways.de und git.icinga.com. Die Möglichkeiten, die einem CI mit den Runnern bietet, sowie den Merge-Request-Workflow haben wir seitdem bei uns stetig etabliert und ausgebaut.

All diese Erfahrungen aus der Praxis, und die tagtägliche Arbeit lassen wir in die neu gestaltete GitLab-Schulung einfliessen. Im Vortrag von Nicole und Gabriel auf der OSDC 2018 habe ich dann auch endlich mal Auto-DevOps verstanden und die Web IDE besser kennen gelernt. All das und noch viel mehr erzähle ich Schulungsteilnehmern im Kesselhaus und freu mich über die gemeinsamen Lernerfolge.

© 2019 Heise Medien GmbH & Co. KG

Doch damit hats nicht aufgehört – nachdem ich letztes Jahr für die IX einen Artikel zu IoT-Monitoring rund um Icinga, Elastic, Graylog und MQTT schreiben durfte, hab ich auch GitLab mit Golang in den Raum geworfen. Es ist ein bisserl Zeit ins Land gegangen, und ich hab dank IcingaDB auch mehr Golang gelernt. Im neuen Jahr hab ich eine GitLab-Schulung gehalten, und mich am Wochenende drauf hingesetzt und für die aktuelle iX 04/19 einen Artikel über GitLab und CI/CD geschrieben. Und auch vorab die GitHub Actions evaluiert, wo ich netterweise einen Invite habe 🙂

Wer mich kennt, weiss, dass ich endlos schreiben und reden kann über Dinge, die mir Spass machen. So empfehle ich Dir zur Lektüre auch einige Kaffee-Tassen (und falls vorhanden: Dragee-Keksi). Soferns dann noch offene Fragen gibt, komm einfach auf uns zu – egal ob Workshops, Schulungen oder Consulting, wir kriegen das hin, dass Dein GitLab genauso schnurrt wie unseres 🙂

Bevor ich es vergesse, auf der OSMC 2019 mach ich einen GitLab-Workshop rund um DevOps-Workflows und CI. Die Zeit vergeht eh so schnell – gleich anmelden 😉

Wir lesen uns – Icinga 2.11 wartet und nächste Woche ist Henrik aus der Schule wieder da. “Mein” Azubi der in die Welt von Icinga Core eintauchen darf, ich werd alt ❤️

 

 

Michael Friedrich
Michael Friedrich
Senior Developer

Michael ist seit vielen Jahren Icinga-Entwickler und hat sich Ende 2012 in das Abenteuer NETWAYS gewagt. Ein Umzug von Wien nach Nürnberg mit der Vorliebe, österreichische Köstlichkeiten zu importieren - so mancher Kollege verzweifelt an den süchtig machenden Dragee-Keksi und der Linzer Torte. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im Büro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht in der Community helfend meldet, arbeitet er am nächsten LEGO-Projekt oder geniesst...

GitLab CI + Docker + Traefik = ❤️

So wie vermutlich einige, bin auch ich zur Zeit sehr von GitLab und dessen CI/CD Features angetan. Vor einigen Monaten habe ich angefangen, für meine privaten Webprojekte eine Template .gitlab-ci.yml zu erstellen, welche für jeden Commit, auf jedem Branch, automatisch Docker Images baut und diese in meiner Docker-Umgebung mit zum Branch/Projekt passender Subdomain und SSL-Zertifikat bereitstellt.

Um zu funktionieren benötigt das ganze eine erreichbare Docker-API, ein darauf laufendes Traefik, ein Docker-Netzwerk namens Proxy (Traefik muss dieses auch nutzen) und einen Account + Repository auf hub.docker.com. Das ganze kann aber recht einfach umgeschrieben werden, falls man seine eigene Registry verwenden möchte.

Ablauf beim Commit:

  1. Bauen und Pushes des Images (Tag => Branch + Commit-Hash)
  2. Umbenennen des alten Containers, falls vorhanden (Suffix ‘-old’ wird angehangen)
  3. Erstellen des neuen Containers (Name => Deployment Domain bsp. master.dev.domain.tld)
  4. Löschen des alten Containers
  5. (Optional) Löschen & neu erstellen des Produktionscontainers, falls der Commit auf dem Masterbranch stattgefunden hat (Muss durch Button ausgelöst werden und läuft wie Schritte 2 bis 4 ab)
  6. Neue Container stehen unter den Deployment-Domains zur Verfügung

Pipeline eines Commits auf Master/andere Branches (Deploy auf Produktion kann durch “Play”-Button ausgelöst werden):

Pipeline eines Commits auf andere Branches:

Für jeden Branch wird auch ein Environment erstellt, welches über Operations/Environments in GitLab verwaltet werden kann.
Hier können Deployments angesehen, gelöscht, in Produktion ausgerollt und auf einen früheren Stand zurückgesetzt werden:

Zur Nutzung des Templates in einem Projekt wird ein Dockerfile im Repository, ein paar CI/CD-Variablen, und das Template selber benötigt.

Benötigte CI/CD-Variablen:

CI_DEV_URL_SUFFIX (Domain-Suffix der Development-Umgebungen): dev.domain.tld
CI_PRODUCTION_URL (Domain der Produktionsumgeben): domain.tld
CI_DOCKER_HOST (Adresse & Port der Docker-API): docker.domain.tld
CI_REGISTRY_IMAGE (Image-Name auf hub.docker.com): supertolleruser/supertollesoftware
CI_REGISTRY_USER (Docker-Hub Benutzer): supertolleruser
CI_REGISTRY_PASSWORD (Passwort des Docker-Hub Benutzers): supertollespasswort
CI_TRAEFIK_PORT (Port der Webanwendung im Container): 8080

Da das ganze Projekt bis jetzt nur Images baut und Container bereitstellt, könnten hier natürlich noch Tests eingebaut werden um das ganze abzurunden.

Zur Zeit arbeite ich an einer Umstellung auf Kubernetes und werde, sobald abgeschlossen, auch davon berichten.

Noah Hilverling
Noah Hilverling
Developer

Nachdem Noah bei einer vierjährigen Exkursion nach Belgien seine Liebe zum Programmieren entdeckte, holte der gebürtige Euskirchener innerhalb kürzester Zeit gleich zwei Schulabschlüsse nach. Danach verließ Noah sogar den schönen Chiemsee, um sich ab September 2016 im Rahmen der Ausbildung zum Fachinformatiker für Anwendungsentwicklung bei NETWAYS voll und ganz dem Programmieren hinzugeben und viele unterschiedliche Erfahrungen zu sammeln. Wenn er mal nicht am Programmieren und Zocken ist, brettert er mit seinem Snowboard die Pisten runter,...

Event Ticketverkauf mit Pretix

Seit etwa einem Jahr setzen wir bei NETWAYS für den Ticketverkauf für unsere Konferenzen und Schulungen auf Pretix. Ich habe unser Event-Team von der Evaluierung bis hin zur vollständigen Umstellung begleitet und dabei viele Eindrücke gewonnen.

Pretix ist eine Open Source Software die es Veranstaltern ermöglicht auf bequeme Weise Tickets für Veranstaltungen anzubieten, zu verkaufen und Teilnehmer zu verwalten. Bei den zahlreichen Schulungen und Konferenzen die NETWAYS organisiert ist so ein Instrument extrem wichtig. Die Wahl auf Pretix ist uns trotz unserer unzähligen Anforderungen relativ leicht gefallen, weil es nahezu alles bietet was das Event-Herz begehrt.

Alle Features aufzulisten wäre hier etwas zu viel. Ich habe daher die für uns wichtigsten Punkte ein mal zusammengefasst.

Verwaltung und Statistiken

Bei Pretix werden Events von verschiedenen Veranstaltern organisiert. Jeder Veranstalter hat dabei Teams die Zugriff auf die jeweiligen Events bekommen. Jedes Event hat eines oder mehrere Produkte (Tickets) die zum Verkauf angeboten werden. In einer aufgeräumten Übersicht bekommt man einen schnellen Überblick über anstehende Veranstaltungen und aktuelle Teilnehmerzahlen. Pretix unterstützt dabei nicht nur einmalige Events sondern auch wiederkehrende, so wie unsere Schulungen. Mit einer Vielzahl an Optionen und Plugins lässt sich der Ticketshop auf die eigenen Bedürfnisse anpassen.

 

Look and Feel

Neben den Farben des Shops erlaubt es Pretix auch die Tickets frei zu designen. Zusätzlich können alle Texte und das gesamte Design für die E-mail Kommunikation angepasst werden. Auch die automatisch generierten Rechnungen lassen sich mit etwas technischem Know-How abstimmen.

Integration

Die generelle Funktionalität wird bei Pretix durch Plugins erweitert. Zum Beispiel können verschiedene Bezahlmethoden eingebunden werden, von Sepa Lastschriftmandat, PayPal bis hin zur Kreditkartenzahlung. Ist man bei einem entsprechenden Provider registriert, lässt sich das problemlos einbinden. Pretix kann auch mit eigenen Plugins erweitern werden, wir verwenden zum Beispiel einen eigenen Renderer für Rechnungen und eine spezielle Export Variante für Teilnehmerdaten. Neben den bereits erwähnten textuellen Anpassungen, kann auch das gesamte Design von E-mails mithilfe eigener Plugins verändert werden. Die jeweiligen Ticket Shops werden auf die entsprechenden Konferenz-Webseiten eingebettet, so müssen Teilnehmer die Seite garnicht erst verlassen um ihre Tickets zu ordern. Ach ja, unser Request Tracker spricht auch mit Pretix über die Pretix REST API, die es natürlich auch gibt. Alles in allem lässt Pretix bezüglich Integrationen keine Wünsche offen.

On-premise oder in der Cloud

User können sich entscheiden ob sie Pretix selbst hosten (so wie wir) oder es lieber in der SaaS Variante einkaufen möchten. Beide Varianten haben ihre Vor- und Nachteile. Für uns war relativ schnell klar das wir selbst hosten werden. Die Installation ist sehr einfach und gut dokumentiert. Pretix grenzt klar ab welche Plugins open source sind und welche man nur gegen Bezahlung bekommt, so gibt es zu keinem Zeitpunkt unklarheiten. Die Software bekommt zuverlässig jeden Monat Updates mit Bugfixes und größeren kleineren Features. Auf GitHub erhält man in einem nahezu unmenschlich schnellem Tempo Antworten auf Fragen und Probleme.

Fazit

In Summe ist Pretix ein Vorzeigeprojekt wie Open Source Software im professionellen Umfeld funktionieren kann. Sowohl von der Funktionalität her als auch von den Möglichkeiten zur Erweiterung hat uns das Projekt überzeugt. Alle Features im Detail werden auf der Pretix Webseite aufgeführt.

Alle unsere Events findet ihr natürlich auf der NETWAYS Webseite.

Blerim Sheqa
Blerim Sheqa
Product Manager

Blerim ist seit 2013 bei NETWAYS und seitdem schon viel in der Firma rum gekommen. Neben dem Support und diversen internen Projekten hat er auch im Team Infrastruktur tatkräftig mitgewirkt. Hin und wieder lässt er sich auch den ein oder anderen Consulting Termin nicht entgehen. Inzwischen ist Blerim als Product Manager für Icinga tätig und kümmert sich dort auch um die Partner.

GitLab Training v2.5.0 released

We have released v2.5.0 of our GitLab training today. Based on the feedback from previous trainings, and many things learned together with the students, we aim for the next classes already.

Dive deep into Git rebase, merge, squash, cherry-pick, get to know real-life development workflows and explore the possibilities of CI/CD pipelines and even more fancy GitLab features. Check our training schedule and register now!

Michael Friedrich
Michael Friedrich
Senior Developer

Michael ist seit vielen Jahren Icinga-Entwickler und hat sich Ende 2012 in das Abenteuer NETWAYS gewagt. Ein Umzug von Wien nach Nürnberg mit der Vorliebe, österreichische Köstlichkeiten zu importieren - so mancher Kollege verzweifelt an den süchtig machenden Dragee-Keksi und der Linzer Torte. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im Büro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht in der Community helfend meldet, arbeitet er am nächsten LEGO-Projekt oder geniesst...

Logstash-Konfiguration im Team

Das folgende Setup hat sich als Entwurf bei einem Kundenprojekt ergeben. Es ist noch nicht in die Realität umgesetzt, aber ich fand es interessant genug, um es hier teilen zu wollen.

Aufgabe

Hier kurz die Ausganslage, für die das Konzept erstellt wurde.

  • Mehrere Teams wollen Logs über den Elastic Stack verarbeiten
  • Die Logs sind teilweise Debuglogs aus Eigenentwicklungen. (Erfahrene Logmanagement-Admins lesen hier “sich häufig ändernde und nicht immer klar strukturierte Logformate”)
  • Die Logmanagement-Admins haben nicht die Kapazität, Logstash-Regeln für alle verwalteten Applikationen zu schreiben und vor allem nicht ständig anzupassen
  • Das zentrale Logmanagement ist sehr wichtig und soll durch unerfahrene Anwender nicht gefährdet werden

Lösungsansatz

Im Gespräch hat sich dann ein Setup ergeben, das ungefähr so aussehen soll:

  • Es wird eine Entwicklungsmaschine geschaffen, auf der die einzelnen Teammitglieder ssh-Logins bekommen. Auf dieser Maschine ist Logstash installiert, wird aber nicht ausgeführt
  • Jedes Team bekommt ein Repository in der zentralen Versionsverwaltung (z.B. GitLab ) und kann das auf der Entwicklungsmaschine auschecken. In diesem Repository befindet sich die gesamte Logstash-Konfiguration einer Pipeline und ggf. Testdaten (siehe weiter unten)
  • Die Mitglieder des Teams entwickeln ihre Pipeline und nutzen den lokalen Logstash zum Testen auf syntaktische Richtigkeit.
  • Optional können zusätzliche Pipelines zur Verfügung gestellt werden, die Beispieldaten einlesen und wieder in Dateien rausschreiben. Diese beiden Dateien können mit eingecheckt werden, man muss nur darauf achten, sie nicht so zu benennen, dass Logstash sie als Konfiguration ansieht. Es empfiehlt sich, die Beispieldaten aus allen möglichen Logzeilen der Applikation zusammenzusetzen. Bei Änderungen sollten auch alte Zeilen belassen werden, um Logs aller möglichen Versionen einlesen zu können. Sollen die Daten mit Elasticsearch und Kibana veranschaulicht werden, kann in den Beispieldaten ein Platzhalter für den Zeitstempel verwendet werden, der vor dem Einlesen durch die aktuelle Zeit ersetzt wird. Die Pipelines werden einmal eingerichtet und bleiben dann statisch, sie werden nicht von den Teams bearbeitet und befinden sich nicht in zugänglichen Repositories
  • Beim Commit der Konfiguration in Git wird ein pre-commit-hook ausgeführt, der nochmal mit Logstash testet, ob die Konfiguration fehlerfrei ist. (Vertrauen ist gut, etc.)
  • Ist der Commit gut verlaufen, wird nach dem Push ein CI Tool wie Jenkins benutzt, um die aktuellen Stände sämtlicher Pipelines auf einer Testmaschine auszurollen. Dort wird Logstash dann kurz gestartet, mit fest konfigurierten Pipelines, die Daten einlesen und ausgeben. Statt wie auf einem Produktionssystem Ports zu öffnen und an Elasticsearch oder Icinga zu schreiben, werden die Logdaten aus den eingecheckten Dateien mit Beispieldaten gelesen und in Dateien geschrieben. Dabei ist es wichtig, dass alle Daten von allen Teams in die selbe Instanz gelesen werden. Nur so kann verhindert werden, dass sich die Teams  gegenseitig “dreinpfuschen”
  • Die ausgegebene Dateien werden auf ihre Richtigkeit geprüft. Das klingt aufwändiger als es ist. Es reicht eigentlich, eine funktionierende Konfiguration mit den oben genannten in- und outputs laufen zu lassen und das Ergebnis als Vorlage zu verwenden. Diese Vorlage wird dann mit dem tatsächlichen Ergebnis verglichen. Arbeiten die Teams schon im ersten Schritt mit den optionalen In- und Outputdateien, kann dieser Punkt stark vereinfacht werden, da man davon ausgehen kann, dass jeder seine eigenen Outputdateien schon berichtigt hat und sie nur mehr geprüft werden müssen
  • Abweichungen von der Vorlage werden überprüft und danach entweder die Logstash-Konfiguration erneut angepasst oder die Vorlage angepasst, sodass weitere Tests erfolgreich sind
  • War der Test erfolgreich, kann die Konfiguration getagged und auf den Produktionsservern ausgerollt werden

Weitere wichtige Punkte

Hier noch ein paar Punkte, die beim Umsetzen helfen sollen.

  • Logstash kann mit der Option -t auf der Shell gestartet werden. Dann prüft er nur die Konfiguration und beendet sich gleich wieder. Das kann auch in der logstash.yml hinterlegt werden
  • Um letztendlich zu verhindern, dass zwei Teams das selbe Feld mit unterschiedlichem Typ schreiben muss extra Aufwand betrieben werden. Entweder muss sich jeder an eine bestimmte Nomenklatur halten, oder jedes Team bekommt ein eigenes Feld und darf nur Unterfelder davon anlegen oder jedes Team schreibt in einen eigenen Index
  • Wenn jedes Team eine eigene Pipeline mit eigenem Input und Output bekommt, kann die Gefahr einer gegenseitigen Beeinflussung minimiert werden. Das ist aber nicht immer möglich oder sinnvoll. Oft schreibt ein Beat Logs von verschiedenen Applikationen oder es gibt nur einen gemeinsamen UDP/TCP input für syslog.
  • Jedes Team kann sich nach wie vor die eigene Konfig zerstören, aber mit dem oben geschilderten Setup kann man ziemlich umfassend sicherstellen, dass auch wirklich jeder nur seine eigene Konfig zerlegt und nicht alle anderen in den Tod reisst.
  • Die von den Teams verwalteten Pipelines haben jeweils nur einen Input aus einem Messagebroker (z.B. Redis) und einen Output ebenfalls in einen Messagebroker. Das kann der selbe sein, wobei dann darauf zu achten ist, dass der verwendete key ein anderer ist. So kann auf den verschiedenen Maschinen jeweils eine völlig andere Pipeline in den Broker schreiben oder raus lesen. Auf den Entwicklungsmaschinen wären es Pipelines, die mit Dateien interagieren, auf der Produktion dagegen z.B. ein beats input und ein elasticsearch output. Diese ändern sich ja nicht und können weitgehend statisch bleiben.
  • Das ganze ist momentan ein Konzept. Es kann natürlich sein, dass in der Umsetzung noch das eine oder andere Problem auftaucht, das bisher nicht bedacht wurde. Über Feedback würde ich mich auf jeden Fall freuen.
Thomas Widhalm
Thomas Widhalm
Lead Support Engineer

Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 möchte er aber lieber die große weite Welt sehen und hat sich deshalb dem NETWAYS Consulting Team angeschlossen. Er möchte ausserdem möglichst weit verbreiten, wie und wie einfach man persönliche Kommunikation sicher verschlüsseln kann, damit nicht dauernd über fehlenden Datenschutz gejammert, sondern endlich was dagegen unternommen wird. Mittlerweile wird er zum logstash - Guy bei NETWAYS und hält...

Request Tracker: Highlight tickets based on due dates

A while ago we’ve announced a new extension for Request Tracker which allows to highlight tickets in search results even better.

Next to “last updated by” and custom field conditions, we’ve now added a requirement from production:

  • light red coloring for tickets with a due date in 3 days
  • dark red coloring for everything where the due date already passed

When there’s a ticket which matches one of the other conditions, due date wins over “last updated by” which itself wins over custom field conditions.

v2.0.0 is available on GitHub. Consider asking our sales engineers when building a new RT instance in NWS 🙂

Michael Friedrich
Michael Friedrich
Senior Developer

Michael ist seit vielen Jahren Icinga-Entwickler und hat sich Ende 2012 in das Abenteuer NETWAYS gewagt. Ein Umzug von Wien nach Nürnberg mit der Vorliebe, österreichische Köstlichkeiten zu importieren - so mancher Kollege verzweifelt an den süchtig machenden Dragee-Keksi und der Linzer Torte. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im Büro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht in der Community helfend meldet, arbeitet er am nächsten LEGO-Projekt oder geniesst...