Modulare und wiederverwendbare Docker-Umgebung mit Carnotzet

Wir haben ein Tool entwickelt, das Docker und Maven integriert, um Hunderten unserer Entwickler dabei zu helfen, komplexe Entwicklungsumgebungen mit Hunderten von Diensten zu verwalten und dabei nur ein Minimum an Aufwand zu betreiben. Dies ist eine Geschichte darüber, wie eine verrückte Idee Wirklichkeit wurde. Dies ist die Geschichte von Carnotzet .

Angefangen hat alles vor rund fünf Jahren (ca. Erscheinungsdatum 3. August 2017). Swissquote ist schnell gewachsen und hat sich weiterentwickelt. Zu dieser Zeit hatten wir ungefähr 70 Entwickler, die an großen (ca. monolithischen) Java-Projekten arbeiteten, wobei jeder von ihnen 1 bis 2 Tage benötigte, um den Start des Projekts lokal zu konfigurieren. Wir hassen es, Zeit für sich wiederholende Aufgaben zu verschwenden! Daher wurde beschlossen, diesen Prozess zu verbessern, indem Vagrant und Chef verwendet wurden, um die Bereitstellung unserer lokalen Entwicklungsumgebung zu automatisieren. Dies war der Beginn unseres ersten Sandbox-Projekts (Sandbox, ca.).

Wir möchten leichte, reproduzierbare, isolierte und portable Entwicklungs- und Testumgebungen teilen.

Für eine Weile war alles glatt. Entwickler können das Projekt einfach herunterladen, "vagrant up" ausführen und an die Arbeit gehen. Wir haben diesen Ansatz etwa zwei Jahre lang angewendet und waren sehr zufrieden.

In der Folge wurde die Arbeit an diesen großen Anwendungen schwieriger, da die Geschäftslogik komplexer wurde (White-Labeling unserer Handelsplattform). Und wir haben beschlossen, das zu tun, was die meisten Unternehmen bereits 2014 getan haben: die Logik in Microservices zu unterteilen.

Alles ist gut gelaufen und bis 2016 hatten wir ca. 150 (Mikro-) Services in der Produktion. Die Chef-Skripte zur Konfiguration der virtuellen Maschinen sind jedoch gewachsen und außer Kontrolle geraten. Entwicklungsumgebungen sind für einige Anwendungen mit etwa 30 Abhängigkeiten wesentlich komplizierter geworden. Wir haben auch herausgefunden, dass das Wissen über Chefkoch nicht Teil der Standardfähigkeiten unserer Entwickler ist. Aus diesem Grund haben viele Leute das Skript manchmal einfach zum Laufen gebracht, indem sie schlechte Beispiele kopierten. Sie versuchten, die Konfiguration für andere Teams nicht zu unterbrechen, und erstellten langlebige Brunchs für ihre eigenen Teamanforderungen. Infolgedessen war der Konfigurationscode für die Entwicklungsumgebung nicht mehr öffentlich.



Wir mussten es reparieren.

Die folgenden Schwächen unserer Sandbox wurden festgestellt:

• Muss Chef wissen. Für bestehende Entwickler und für Anfänger war das Erlernen dieses Frameworks ein ziemlich teures Vergnügen.
  Auch dies war nur für die Entwicklungs- / Testumgebung überflüssig.
• Es gab keine Möglichkeit für eine einfache Abstraktion / Komposition oder Wiederverwendung eines Teils der Konfiguration der Umgebung. Dies führte dazu, dass sich die Mitarbeiter mit allen Details und Nuancen der Abhängigkeitskonfiguration ihrer Projekte befassen mussten, die in der Regel von anderen Teams unterstützt wurden. Dies führte zu Meinungsverschiedenheiten und unnötiger Interaktion zwischen den Teams.

Um den ersten Punkt zu beheben, wurde beschlossen, Docker zu verwenden. Es hat eine niedrigere Eintrittsschwelle und bietet auch andere Vorteile, wie z. B. Standardisierung, PaaS-Unterstützung und einfachere Bereitstellung in mehreren Umgebungen.

Wir haben auch in Betracht gezogen, nur Docker-Compose zu verwenden. Es sah sehr vielversprechend aus, aber trotz seines Namens fehlten Dinge wie die Möglichkeit der Komposition und gleichzeitig Abstraktion und Wiederverwendung. Es sind diese Aspekte, die wir brauchten. Wir haben davon geträumt, die vorhandene Entwicklungs- / Testumgebung zu übernehmen, einen Service hinzuzufügen und optional einen Teil der Konfiguration neu zu definieren. Wir wollten dies erreichen, ohne die Konfiguration des hinzugefügten Dienstes kopieren oder die Details der transitiven Abhängigkeiten und ihrer Konfiguration untersuchen zu müssen.

Zu diesem Zeitpunkt hatten wir die Idee: „Was ist, wenn wir Maven, das Abhängigkeitsverwaltungssystem, mit dem wir unsere Java-Anwendungen erstellen, verwenden und damit beginnen, unsere Umgebungen zu erstellen?“ Dies würde es uns ermöglichen, unsere transitiven Abhängigkeiten zu abstrahieren, Konfigurationen zu verpacken, Versionen davon zu erstellen und sie wiederzuverwenden. Es ist auch nicht erforderlich, ein neues Abhängigkeitsverwaltungssystem zu erlernen.

Nach mehreren Versuchen kamen wir zu folgender Lösung:

• Jedes Maven-Artefakt stellt eine voll funktionsfähige Umgebung dar, die als Abhängigkeit in anderen Umgebungen verwendet werden kann. (Minimale Umgebung kann durch einen Dienst dargestellt werden, z. B. eine Datenbank.)
• JAR-Dateien enthalten Konfiguration. Umgebungsvariablen, Anwendungskonfigurationsdateien, Image-Docker-Name usw.
• Diese Konfiguration kann bei Bedarf in Modulen überschrieben werden, die sich höher in der Abhängigkeitshierarchie befinden.
• Die Java-Bibliothek kann die gesamte Umgebung (mithilfe von Docker-Compose unter der Haube) aus einem Maven-Modul (GAV oder pom.xml) herausheben.

Maven ermöglicht es, diese Artefakte („Umgebungsartefakte“) zu verteilen und zu versionieren, und wir können den Quellcode problemlos zwischen den Teams teilen. Der Prozess wurde einfacher und die Entwickler begannen, Module anderer Teams zu verwenden. Und erstellen und pflegen Sie auch Ihre eigenen.

Als Bonus können hier alle Tools verwendet werden, die die Arbeit mit Maven erleichtern. Das mit IntelliJ IDEA generierte Abhängigkeitsdiagramm zeigt uns nun als Beispiel ein Diagramm der Architektur für die Interaktion unserer Abhängigkeiten :)


Architektur eines Voting-Anwendungsbeispiels von docker-compose

Gleichzeitig gab es einige Implementierungsschwierigkeiten, z. B. das Erzwingen, dass alle Teams Anwendungen mit Docker (Dockerize) packen und Konfigurationen in separate Maven-Module packen. In jedem Fall ist es einfacher geworden, Anwendungen aus anderen Teams zu importieren und komplexe Entwicklungsumgebungen zu unterstützen.

Wir haben vor ungefähr einem Jahr begonnen, in diese Richtung zu arbeiten, und jetzt haben wir ungefähr 200 dieser Module für die Entwicklung und das Testen verwendet. Wir sind zu dem Schluss gekommen, dass diese Bibliothek auch hervorragend für die Verwaltung der temporären Umgebung für End-to-End-Tests auf unserer CI-Plattform geeignet ist.

Wir prüfen derzeit, wie diese Technologie für die Verwaltung unserer UAT- / Integrationsumgebungen wiederverwendet werden kann, indem Container in Kubernetes anstelle von Docker-Compose gestartet werden, um auf diese Weise Aktualisierungen und die Elastizität der Datenverarbeitung in erheblich größeren Umgebungen sicherzustellen.

Ich hoffe, Sie werden froh sein zu wissen, dass unser Projekt unter der Apache 2.0-Lizenz eröffnet wurde und auf Github verfügbar ist: github.com/swissquote/carnotzet

Verwenden Sie :)