Kubernetes Cluster mit RaspberryPIs

Plattformen wie Kubernetes haben die Software Entwicklung in den letzten Jahren nahezu revolutioniert. Kubernetes ist ein wesentlicher Bestandteil der DevOps-Welt. Entwickler können damit ausfallsichere und skalierbare Anwendungen bzw. Anwendungscluster selbst in Betrieb nehmen und verwalten. Man kann Kubernetes mit vielen Cloud-Anbietern nutzen, aber auch im eigenen Rechenzentrum installieren.

In der Software Entwicklung bei Nordhof Service GmbH gibt es seit kurzem einen eigenen Kubernetes Cluster. Er basiert momentan auf drei Raspberrys und dient als Spielwiese bzw. zu Demonstrationszwecken. Installiert hat ihn unser allererster Praktikant, Georg Schlager. Georg besuchte die zweite Klasse der Handelsakademie Waidhofen an der Thaya im Zweig Digital Business und zeigt sehr großes Interesse an der Software Entwicklung. Für uns war es auch ein Experiment, womit wir sehen wollten, wie weit man ohne Erfahrung in dem Bereich kommt.

Das Ergebnis lässt sich sehen. Wir haben

  • eine Kubernetes Installation auf drei RaspberryPIs
  • Prometheus zum Speichern von Daten für Metriken
  • Grafana zum Anzeigen von Metriken
  • Portainer zum Verwalten von Containern
  • eine kleine Java Anwendung die man unter Last setzen kann (wurde auch von Georg implementiert)
  • viel gelernt

Trunk-based Branching Modell – Fundament für DevOps Teams

Nach einigen durchwegs erfolgreichen Jahren der Produktentwicklung mit dem Git flow branching model scheint sich für erfolgreiche DevOps orientierte Teams das Trunk-based Development Branching Modell zu etablieren. Aus diesem Modell der Zusammenarbeit ergeben sich ein paar Konsequenzen:

  • Um den Masterbranch immer „lauffähig“ zu haben, tendieren Entwickler dazu kleine Änderungen zu mergen. Kleine Änderungen bedeuten wenig Risiko.
  • Feature Branches werden aufgrund kleiner Code Änderungen sehr kurzlebig, wodurch Entwickler äußerst selten in die unangenehme Situation mit Berge-Konflikten kommen. Dave Farley hat einen Rat dazu: „Don’t branch“
  • Entwickler zerlegen ihre Arbeit in viele kleinere Bestandteile und „liefern“ viel öfter. Dadurch entstehen im Rahmen einer Feature Entwicklung viel mehr Punkte wo man theoretisch die Richtung noch anpassen kann.
  • Entwickler tendieren dazu sich mehr Gedanken über Unit Tests und Testabdeckung zu machen.
  • Entwickler neigen außerdem dazu die Commits mit besseren Commit-Messages zu versehen, was insgesamt zu einer besseren Dokumentation im Commit-Log führt.

Aus eigener Erfahrung wissen wir, dass es ein paar Wochen dauert, bis man den Sprung zum Trunk-based Branching Modell geschafft hat. Wenn man es aber einmal verinnerlicht hat, will man nicht mehr zurück.

Für Teams und Firmen die DevOps praktizieren wollen, sodass Code Änderungen oft, schnell, mit wenig Risiko, in guter Qualität und automatisiert produktiv gestellt werden können ist das Trunk-based Branching Modell eine fundamentale Basis in der täglichen Arbeit.

HTTP Schnittstelle für iOS-, Android und Browser-App

Wir sind sehr stolz darauf beim Projekt A1 Mastercard unterstützt zu haben: https://futurezone.at/digital-life/a1-und-mastercard-starten-mit-neuer-kreditkarte/400666703. Für die Verwaltung der Kreditkarte per iOS-, Android- sowie Browser-App war eine zentrale Schnittstelle gefordert, sodass so wenig Logik wie möglich in den Clients implementiert werden muss.  Wir sind dem Entwicklungsteam dieser auf HTTP basierten Anwendung beratend sowie umsetzend bei folgenden Aufgaben zur Seite gestanden:

  • System Design und Software Design der Anwendung
  • Verbesserung des Build Prozesses mit Gradle
  • Implementierung von Lasttests mit https://gatling.io
  • Integration automatischer OWASP Top 10 Prüfung in den Build Prozess

Außerdem musste der digitale Anmeldeprozess neu implementiert werden. Bei dieser haben wir vor allem geholfen einen schlanken und agilen Entwicklungsprozess aufzusetzen mit 2-Wochen Sprints und Demos der geschafften Features am Ende eines jeden Sprints.

Bei beiden Anwendungen unterstützten wir auch dabei eine automatisierte Deployment-Pipeline zu bekommen, mit der in wenigen Minuten eine Code Änderung auf Produktion deployed werden kann. Unsere Erfahrung mit Continuous Delivery sowie mit CI/CD Pipelines hat dabei geholfen einen nachhaltigen Mehrwert für das Projekt, das Produkt sowie deren Nutzer zu schaffen. Vereinbaren Sie gleich jetzt einen Beratungstermin falls Sie auch Unterstützung in diesem Bereich brauchen. Sie finden unseren Kontaktdaten unter Kontakt.

CI / CD Pipeline

Eines der größeren Kundenprojekte im Jahr 2018 war die Verbesserung einer Continuous Integration / Continuous Deployment Pipeline. Dabei hatte ich das Glück auf ein sehr aufgeschlossenes Team zu treffen, das bereits Continuous Integration praktizierte. Continuous Deployment ins Produktionssystem wurde grundsätzlich auch schon gemacht, allerdings war es die erste Version der Pipeline. Diese hatte folgende Probleme:

  • sehr komplex da
    • Ausführungsdetails schwer nachvollziehbar
    • Ausführungslogik auf mehrer Repositories verteilt war
  • Neustart/wiederholte Ausführung nicht möglich
  • Inkonsistenzen möglich
  • Pipelines müssen per Web-UI erstellt bzw. gewartet werden

Das System besteht aus vielen Microservices, wobei jedes den Source Code in einem eigenen Github Repository hostet. Für Continuous Integration ist Travis CI zuständig. Für Continuous Deployment Spinnaker zusammen mit Travis CI und einem eigenen in Python geschriebenen Tool. Die Konfiguration einzelner Services sowie einzelner Mandanten ist in in einem Github Repository abgelegt.

Mit der Einführung von Spinnaker Pipeline templates konnte Komplexität erheblich reduziert werden, da die Pipeline Stages in einer Vorlage definiert wurden und jedes Service nur mehr seine eigenen Pipeline Parameter definieren muss. Somit war auch die Ausführungslogik nurmehr in einem Travis Exekutor Repository womit man im Fehlerfall nur mehr auf ein Ausgabe-Log schauen musste. Durch den Umbau des sh-Skriptes das für das tatsächliche Deployment verantwortlich war, konnten eventuelle Inkonsistenzen bereinigt werden. Dadurch war immer garantiert, dass der Zustand im Produktionssystem dem Zustand im Konfigurations-Repository entspricht.

Mit einem weiteren sh-Skript lässt sich nun auch automatisiert die Version des Pipeline Templates erhöhen sowie ein Pull Request dafür erstellen. Dabei wird noch ein bestimmtes Label für den PR gesetzt, sodass der PR nach erfolgreichem CI-Build wiederrum automatisch gemerged wird was wiederrum automatisch die Ausführung der zugehörigen Spinnaker Pipeline anstößt.

Was Kollegen bzw. Benutzer des Setups dazu meinten:

Fazit

Eine CI/CD Pipeline ist ein sehr wertvolles Werkzeug und sollte in keinem DevOps Setup fehlen. Sie hilft dabei den gesamten Release-Prozess zu automatisieren und ermöglicht es Änderungen an einem System ohne viel Risiko und hoch frequentiert in Produktion zu deployen. Für das initiale Setup muss man zwar mit einer Investition von einigen Mannmonaten rechnen, jedoch nimmt diese den Entwicklern bzw. dem Operations-Team viel lästige Release- und Deploymentarbeit ab. Spinnaker ist außerdem nicht das einzige Tool. Es gibt viele mehr, wie zBsp.

Cloudprovider wie Amazon Web Services, Google Cloud Platform oder Azure haben mittlerweile auch schon ihre eigenen Lösungen für CI/CD.

 

Technology Value Stream

In der DevOps Literatur liest man immer wieder vom sogenannten „Value Stream“, grob übersetzt der Wertschöpfungskette. In der Software Entwicklung kennt man den „Technology Value Stream“, das ist laut DevOps Handbook

The process required to convert a business hypothesis into a technology- enabled service that delivers value to the customer

Bei einem meiner Kunden durfte ich den Entwicklungsprozess dahingehend analysieren und dabei ist folgende Präsentation entstanden:

 

Systemische Betrachtung zu CI/CD – Impulsvortrag bei Teamleiter Workshop

Im April 2018 durfte ich bei einem willhaben Teamleiter Workshop einen Impulsvortrag halten. Ich nutzte die Gelegenheit um über die DevOps Prinzipen aus der Perspektive einer Continuous Integration / Continuous Deployment (CI/CD) Pipeline zu sprechen.

Die Folien dazu sind hier zu finden: