© sdecoret/Shutterstock.com
Buddy – die moderne Lösung zur DevOps-Automation

Von Pipelines und Automatisierung


Webentwicklung kann mitunter ein kompliziertes Terrain sein: Während Updates bei komplexen Applikationen weiterhin eine beliebte Fehlerquelle sind, sank die Akzeptanz für Komplikationen in diesem Bereich. Eine mögliche Lösung liegt in CI/CD Pipelines. Das Tool Buddy soll nun Entwicklern das Leben dabei deutlich vereinfachen.

Viele können sich wahrscheinlich noch an die guten alten Zeiten erinnern, in denen ein Update einer Website nicht mehr als das Hochladen von ein paar Dateien via FTP war. Ausfallzeiten waren zu verkraften und Fehler in gewisser Weise noch toleriert. Mit zunehmendem Traffic und der Aufholjagd des Onlinegeschäfts über das letzte Jahrzehnt ist sicher jedem klar geworden, dass Akzeptanz und Toleranz gegenüber fehlerhaften Updates oder sogar Ausfallzeiten gesunken sind. Je nach Typ der Website kann ein Fehler oder können sogar nur geringe Ausfallzeiten beim Rollout zu immensen Umsatzeinbußen führen.

Mit modernen Technologien, wie zum Beispiel webpack, npm Packages etc., werden die erforderlichen Schritte beim Durchführen von Updates nicht unbedingt weniger. Wo früher noch ein bis zwei Schritte mit manuellem Aufwand nötig waren, bedarf es beim Rollout von modernen und komplexeren Applikationen einer Vielzahl von Schritten, die man auch in Bezug auf Kritikalität nur ungern manuell durchführen möchte. Willkommen in der heutigen Welt der Webentwicklung!

Buddy: die DevOps-Automation-Lösung

Die wohl einzig saubere Lösung, um trotzdem möglichst risikofrei Rollouts durchführen zu können, lässt sich am besten über eine sogenannte Pipeline via DevOps Automation Framework durchführen. Buddy ist eines dieser Tools, das sich in den letzten Jahren mehr und mehr von der Konkurrenz abheben konnte. Dabei ist ein wesentliches Ziel der Software, Pipelines, Automatisierungen und alles rundherum für Entwickler und Teams so einfach wie möglich zu gestalten – ohne Kompromisse bei Qualität oder Professionalität.

dangl_buddy_1.tif_fmt1.jpgAbb. 1: Das übersichtliche Actions-Interface von Buddy

Mit sogenannten Actions können verschiedene Aufgaben seriell oder parallel abgearbeitet werden. Dabei steht eine große Menge von Optionen zur Auswahl, wie in Abbildung 1 zu sehen ist: von Deployment-Tasks wie SFTP, RSync bis hin zu Docker, Build-Tasks, Monitoring, SSHs und vielem mehr. Sollte dennoch ein Aspekt fehlen, ist mit den frei erstellbaren SSH-Kommandos in wählbaren Docker Images prinzipiell alles möglich. Es können also völlig frei Tests durchgeführt, Artefakte erstellt, auf Server übertragen und Post-Deployment-Tasks ausgeführt werden. Das Ganze kann zu guter Letzt mit zusätzlichen Tests und Monitoringaufgaben abgerundet werden. Wer sich jetzt fragt, was das Besondere an Buddy gegenüber Tools wie Jenkins ist, der findet seine Antwort bei genauerem Hinsehen schnell.

Ob nun erfahrener DevOps Engineer oder „einfacher“ Entwickler, das erste Deployment kann bereits nach ca. 15 Minuten durchgeführt werden. Stundenlange Einrichtungszeit, um überhaupt loszulegen, ist nicht nötig. Buddy verwendet dabei unter der Haube Docker Container, womit die gesamte Software ausgerollt wird. Das bietet nicht nur eine einfache Variante der Installation (sofern man On Premise wählt und nicht ohnehin die SaaS-Lösung bevorzugt), sondern verbessert automatisch die Standardperformance, da z. B. Application Dependencies durch die Docker Container und Layers direkt gecacht werden – was sich positiv auf die sequenzielle Ausführungen einer Pipeline auswirkt. Es braucht also keinerlei DevOps-Erfahrung oder komplexen Wartungsaufwand, um ein performantes und stabiles System zu erhalten.

Das Ausführen von Pipelines kann dann entweder manuell oder automatisch auf Basis von Triggern wie Git Push erfolgen. Für zeitgesteuerte Pipelines gibt es dank einer an Cronjob angelegten Konfiguration die Möglichkeit von fixen Intervallen oder punktuell gesteuerten Durchführungen. Sollten trotz der einfachen Bedienung dennoch Probleme auftreten, hilft der Gratissupport mit integriertem Chat meist in kürzester Zeit weiter. Dieser Artikel widmet sich einer fiktiven Applikation sowie deren Pipeline. Dabei werden nicht nur die verschiedenen Schritte thematisiert, die in einer Pipeline heutzutage beachtet werden sollten, sondern auch einzelne Features von Buddy im Detail.

Eine neue Pipeline braucht das Land

Mittelpunkt ist eine für unsere Zwecke erfundene Webapplikation. Diese steht als Platzhalter für alle möglichen Technologien, seien es Symfony, E-Commerce-Systeme wie Shopware, Node.js-Anwendungen oder auch andere Typen. Ziel ist ein reibungsloses Update dieser Website, inklusive eines automatischen Wartungsmodus für die Anwendung. Natürlich funktionieren auch Dinge wie Atomic Deployment mit Zero Downtime wunderbar. Allerdings ist für dieses Beispiel ein klassischer Wartungsmodus wohl das passende Beispiel. Unsere Projekt-Pipeline wird folgende Bereiche beinhalten:

  • Installation und Building

  • Testing

  • Wartungsmodus

  • Rollout auf Server

  • Post Deployment und Finalisierung

  • E2E Test Suite und Monitoring

Vorbereitung

Zunächst muss in Buddy ein neues Projekt angelegt werden, wie Abbildung 2 illustriert. Dies ist im Wesentlichen ein Klon eines Git-Verzeichnisses, wahlweise von GitHub, Bitbucket etc.

dangl_buddy_2.tif_fmt1.jpgAbb. 2: Anlegen eines neuen Projekts

Es kann auch direkt ein Repository innerhalb von Buddy erstellt werden, auf das gepusht werden kann – der Autor dieses Artikels benutzt diese Möglichkeit allerdings lieber für „freie“ Projekte, die z. B. Source Code unabhängig von Cronjob oder Monitoringtasks durchführen. Nachdem das Projekt geklont wurde, besteht die Möglichkeit, verschiedene Pipelines für unterschiedliche Anwendungsfälle oder Umgebungen zu erstellen. Eine Vorgehensweise ist dabei etwa das Anlegen von separaten Ordnern für Umgebungen wie Test, Stage und Produktion, um die Pipelines etwas geordnet zu halten. Eine Pipeline selbst beinhaltet verschiedene Unterpunkte und Möglichkeiten. Dazu zählt der Bereich der Variablen, in denen zentral wichtige Informationen wie Zugänge, Passwörter etc. abgelegt werden können. Diese können verschlüsselt werden und sind auch auf verschiedenen Ebenen, vom Projekt bis hin zur gesamten Buddy-Installation, verfügbar. Somit ist es möglich, globale Variablen, aber auch Variablen auf Projekt- oder Pipeline-Ebene zu erstellen.

dangl_buddy_3.tif_fmt1.jpgAbb. 3: Überblick der Einstellungen in Buddy

In den Einstellungen, die auch in Abbildung 3 dargestellt werden, kann neben allgemeinen Daten auch der Branch der Pipeline explizit oder via Wildcards definiert werden. Eine sehr interessante Einstellung ist auch der Trigger Mode. Er gibt an, wann die Pipeline gestartet wird. Das kann manuell, on push, wiederholend mit festen Zeitintervallen oder per Cronjob-Schema erfolgen. Was wäre eine Pipeline ohne Aufgaben, die durchgeführt werden? Deshalb ist der nächste und essenzielle Teil der Bereich der Actions. Hier wird die Pipeline individuell an das Projekt angepasst.

1. Dependencies

Beim Ausführen einer Pipeline wird ein Working Directory mit den jeweiligen Dateien und Ordnern angelegt und steht via Cache auch bei zukünftigen Ausführungen zur Verfügung.

dangl_buddy_4.tif_fmt1.jpgAbb. 4: Das Installieren der Dependencies

Unser Projekt nutzt wie die me...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang