Schiphol Takeoff - Automatisieren Sie die Bereitstellung, ohne Code zu schreiben!

Was macht Schiphol Takeoff so fantastisch? Schiphol Takeoff bietet Ihnen von Anfang an eine sinnvolle Möglichkeit, Ihre Anwendung in verschiedenen Umgebungen einzusetzen!

Während unserer Zeit bei der Schiphol Group haben wir ein Projekt entwickelt, das bei der Automatisierung von Implementierungen hilft. Die Schiphol Group war so freundlich, uns dieses Projekt als Open Source zur Verfügung zu stellen. Wir geben Ihnen eine kurze Einführung in die Funktionsweise und wie es Ihnen helfen kann, schneller in Produktion zu gehen.

Unser Anwendungsfall

Um Ihnen einen besseren Einblick zu geben, warum wir Schiphol Takeoff entwickelt haben, sollten Sie sich ein Beispiel für einen Anwendungsfall ansehen. Dieser Anwendungsfall verknüpft eine Reihe von Komponenten miteinander:

• Die Daten treffen in einem (nahezu) Echtzeit-Stream auf einem Azure Eventhub ein.
• Ein Spark-Auftrag, der auf Databricks läuft, konsumiert diese Daten von Eventhub, verarbeitet die Daten und gibt Vorhersagen aus.
• Auf Azure Kubernetes Service läuft eine REST-API, die die vom Spark-Job gemachten Vorhersagen offenlegt.

Vom Konzept her ist dies keine sehr komplexe Einrichtung. Es sind jedoch eine ganze Reihe von Komponenten beteiligt:

• Azure Eventhub
• Azure Datenbausteine
• Azure Kubernetes Dienst

Für jedes dieser Systeme gibt es irgendeine Form der Automatisierung, aber es gibt keine einheitliche Methode, um die Bereitstellung des Codes für alle gleichzeitig zu koordinieren und zu orchestrieren. Wenn Sie zum Beispiel den Namen der Verbrauchergruppe für Azure Eventhub ändern möchten, können Sie das per Skript tun. Allerdings müssten Sie auch Ihren Spark-Job, der auf Databricks läuft, manuell aktualisieren, um sicherzustellen, dass er die Daten weiterhin konsumieren kann.

Außerdem ist diese Liste der Komponenten nicht vollständig. Dies sind die Komponenten, die "im Vordergrund" arbeiten, um den Dienst bereitzustellen. Komponenten wie Azure Keyvault (für die Speicherung von Geheimnissen), das private PyPi-Repository (für die Speicherung von Python-Artefakten) und Azure Blob Storage (für die Speicherung von Artefakten auf der Festplatte) werden hier nicht erwähnt, spielen aber eine wichtige Rolle.

Schließlich erfordert dieses Setup nicht nur eine gewisse Konfiguration, um die Komponenten zu orchestrieren, sondern Sie werden in einer echten Produktionsumgebung wahrscheinlich mehr als eine Umgebung haben. Höchstwahrscheinlich werden Sie mindestens eine Entwicklungs- und eine Produktionsumgebung haben, um sicherzustellen, dass sich Fehler der Entwickler (wir sind schließlich alle Menschen) nicht auf Ihre Endbenutzer auswirken. Das macht die Sache noch komplizierter, denn jetzt müssen Sie nicht nur alle Komponenten aufeinander abstimmen, sondern auch sicherstellen, dass dies in allen Umgebungen zuverlässig geschieht, ohne dass die Benutzer davon betroffen sind.

Wie Sie sehen können, führt diese einfache Einrichtung zu einer komplexen Produktion mit vielen Fallstricken, ohne dass Sie in die technischen Details gehen müssen (dies würde eine Menge Screenshots, yaml und benutzerdefinierte Konfigurationen für jede Komponente erfordern).

Enter Schiphol Takeoff

Schiphol Takeoff verfolgt ein zweifaches Ziel:

1. Entlasten Sie Datenwissenschaftler und Entwickler von der Last, Details über mehrere Komponenten und die Funktionsweise ihrer APIs zu kennen.
2. Eine zuverlässige und vor allem einfache Bereitstellung eines Projekts ist möglich.

Um das oben beschriebene Projekt zu verwirklichen, wären für Schiphol Takeoff einige Dinge erforderlich:

1. Eine funktionierende CI-Umgebung (mit Docker-Unterstützung), in der es ausgeführt werden kann.
2. Azure Keyvault-Einrichtung mit den erforderlichen Geheimnissen für die verschiedenen Komponenten.
3. Zwei Dateien in Ihrem Projekt-Repository:
   • Eine Takeoff-Konfigurations-Yaml, die Takeoff mitteilt, wie die Namen Ihrer Geheimnisse im Keyvault lauten.
   • Eine Takeoff-Bereitstellungs-Yaml, die Takeoff mitteilt, welche Aufgaben es ausführen muss.

Wir möchten diesen Blogpost nicht zu einem Yaml-Fest machen, daher werden wir nicht auf die Details dieser beiden Dateien eingehen. Wenn Sie mehr wissen möchten, besuchen Sie die Dokumentations-Website von Takeoff oder das Github-Repository.

Es ist jedoch nützlich, das Takeoff Deployment Yaml zu zeigen, da es deutlich zeigt, wie wenig ein Entwickler tun muss, um die Dinge zum Laufen zu bringen und die Schritte für die Bereitstellung zu definieren. Bitte beachten Sie, dass Sie in einer "realen" Situation wahrscheinlich einige Dinge in separate Repositories aufteilen würden (d.h. Sie würden wahrscheinlich die REST API in einem separaten Repository haben). Dieses Beispiel dient lediglich der Demonstration der Möglichkeiten von Takeoff.

steps:
 - task: configure_eventhub
   create_consumer_groups:
     - eventhub_entity: input-eventhub
       consumer_group: algorithm-group
       create_databricks_secret: true
     - eventhub_entity: input-eventhub
       consumer_group: rest-sink-group
       create_databricks_secret: true
   create_producer_policies:
     - eventhub_entity: output-eventhub
       create_databricks_secret: true
 - task: build_artifact
   build_tool: python
 - task: publish_artifact
   language: python
   python_file_path: "main/main.py"
   target:
     - cloud_storage
 - task: deploy_to_databricks
   jobs:
     - main_name: main/main
       config_file: databricks.json.j2
       lang: python
 - task: deploy_to_kubernetes
   deployment_config_path: "k8s_config/deployment.yaml.j2"
   service_config_path: "k8s_config/service.yaml.j2"

Diese 27 Zeilen (ja, wir haben gezählt) sind alles, was Sie brauchen. Jedes Mal, wenn Sie Ihr Projekt jetzt festschreiben, werden diese Schritte ausgeführt und Ihre Anwendung pro Umgebung bereitgestellt (je nachdem, wie Sie Ihre Bereitstellungskonfiguration eingerichtet haben).

Grundlegende Prinzipien

Schiphol Takeoff ist ein Tool zur Orchestrierung der Bereitstellung, das einen Großteil der Komplexität bei der Verknüpfung verschiedener Cloud-Dienste eliminiert. So können sich die Entwickler auf die eigentliche Entwicklungsarbeit konzentrieren, ohne sich um die Koordinierung einer (großen) Anzahl von Cloud-Diensten kümmern zu müssen, damit die Dinge in verschiedenen Umgebungen zum Laufen kommen. Schiphol Takeoff selbst ist ein Python-Paket und wird in einem Docker-Image gebündelt. Auf diese Weise ist Schiphol Takeoff CI-unabhängig, vorausgesetzt, Ihr CI-Anbieter erlaubt die Ausführung von Docker-Containern. Bei der Entwicklung wurden einige Grundprinzipien berücksichtigt:

• Schiphol Takeoff ist dafür gedacht, während Ihrer CI/CD-Pipeline zu laufen; vorzugsweise in Docker, da die Containerisierung viele Komplikationen in Bezug auf Abhängigkeiten vermeidet. Die meisten CI-Anbieter unterstützen heutzutage die Ausführung von Docker.
• Schiphol Takeoff stellt keine Infrastruktur bereit und richtet keine virtuellen Maschinen ein und ist daher nicht mit Terraform oder Ansible vergleichbar. Stattdessen stellt es Ihre Anwendung bereit und arrangiert die Abhängigkeiten zwischen den Diensten, auf die die Anwendung zugreifen muss.
• Schiphol Takeoff wurde von Anfang an mit Blick auf die Modularität entwickelt. Wir haben es wie Lego™-Teile konzipiert und entwickelt: Es ist sehr einfach, Blöcke hinzuzufügen und zu entfernen, vorgefertigte Sets zu ändern und sogar neue Sets hinzuzufügen. Mehr dazu später!

Was Schiphol Takeoff großartig macht

Schiphol Takeoff bietet Ihnen direkt nach dem Auspacken eine sinnvolle Möglichkeit, Ihre Anwendung in verschiedenen Umgebungen einzusetzen.

Umgebungen

Schiphol Takeoff stellt Ihre Anwendung in einer beliebigen Umgebung in Ihrer Cloud bereit. Ihr CI-Anbieter zieht das Schiphol Takeoff-Image von Dockerhub. Schiphol Takeoff ermittelt dann, in welchem Git-Zweig sich Ihr Projekt gerade befindet, und entscheidet anhand dessen, wohin die Bereitstellung gehen soll. So verwenden wir Schiphol Takeoff zum Beispiel selbst:

• Feature-Zweige werden in Ihrer development Umgebung bereitgestellt;
• Die Master-Zweige werden auf acceptance bereitgestellt;
• git-Tags gelten als Veröffentlichungen und werden auf production bereitgestellt.

Es stellt auch sicher, dass die Versionen während der Bereitstellung in diesen Umgebungen erhalten bleiben - siehe das vorherige Beispiel

• development erhält eine Version, die dem Namen Ihres Funktionszweigs entspricht;
• acceptance erhalten die Version SNAPSHOT;
• production nimmt das Git-Tag als Version.

Konkret bedeutet dies, dass viele Funktionszweige gleichzeitig laufen können, aber nur ein SNAPSHOT oder eine Version läuft.

Damit dies alles funktioniert, macht Schiphol Takeoff einige Annahmen über Namenskonventionen. Im Falle von Microsoft Azure beispielsweise bedeutet jede dieser Umgebungen im Grunde eine eigene Ressourcengruppe. Diese Ressourcengruppen sind insofern identisch, als sie dieselben Dienste enthalten, können sich aber ansonsten in Bezug auf Skalierung und Benennung der Dienste unterscheiden. Anhand der Namenskonventionen bestimmt Schiphol Takeoff während der CI, welcher Dienst in welcher Ressourcengruppe bereitgestellt werden soll.

Plugins

Wir wissen, dass nicht jeder die gleichen Umgebungen hat oder eine andere Versionierungstaktik wünscht: vielleicht

• Release-Versionen sollten auch an acceptance gehen;
• und SNAPSHOT sollte auf testing gehen.

Hier kommen die Schiphol Takeoff Plugins ins Spiel. Mithilfe von Python können Sie Ihre eigene Logik dafür schreiben, was wann wohin gehen soll. Außerdem können Sie Ihre eigenen Namenskonventionen und Ihre eigene Logik in Form eines Python-Plugins einführen.

Modular

Schiphol Takeoff wurde unter Berücksichtigung von Microsoft Azure entwickelt, da dies der vom Schiphol Data Hub verwendete Cloud-Anbieter ist. Das bedeutet, dass die meisten Dienste Azure-Dienste sind, mit ein paar nützlichen Ausnahmen. Es ist jedoch sehr wichtig zu wissen, dass alles in Schiphol Takeoff unter Berücksichtigung der Modularität entwickelt wurde. Wir hoffen, dass wir in Zukunft auch andere (Cloud-)Plattformen unterstützen können.

Prüfbar und getestet

Schiphol Takeoff stützt sich stark auf die Großartigkeit von Python. Es ist leicht zu lesen, zu verstehen und vor allem sehr einfach zu testen - im Gegensatz zu Bash-Skripten, Makefiles oder generischen CI-Konfigurationen, die wesentlich schwieriger zu testen sind (wenn auch nicht unmöglich). Daher werden die meisten* Dienste mit leicht verfügbaren Python-SDKs implementiert.

• mit Ausnahme von sehr wenigen Diensten, die eine Shell zur Ausführung und Bereitstellung verwenden. Ein Beispiel: Die Erstellung von Scala-Projekten mit SBT erfolgt durch den Aufruf eines Python-Unterprozesses.

CI-agnostisch

Dank der Tatsache, dass Schiphol Takeoff in Docker läuft, sind wir völlig unabhängig von CI. Die meisten (wenn nicht sogar alle) großen CI-Anbieter sind in der Lage, Docker-Images auszuführen und unterstützen sogar Docker-in-Docker (DIND). Letzteres ist erforderlich, um sicherzustellen, dass Schiphol Takeoff Zugriff auf den Docker-Socket hat, um Docker-Images zu erstellen und zu pushen, was es auch kann! Aufgrund einiger Migrationen mussten wir ein paar Mal den CI-Anbieter wechseln und stellten fest, dass die Ausführung von Schiphol Takeoff nichts an unseren abhängigen Projekten änderte. In der Regel dauerte es etwa einen halben Tag, bis wir uns mit dem neuen CI-Anbieter vertraut gemacht hatten, DIND einrichteten und alles wieder reibungslos funktionierte!

Cloud-Agnostiker (sozusagen...)

Wie bereits erwähnt, wurde Schiphol Takeoff mit Blick auf Microsoft Azure entwickelt. Wir möchten jedoch betonen, dass dies nicht bedeutet, dass Sie Ihre eigene Komponente für das Deployment von Kubernetes-Anwendungen auf Google Cloud Platform auf der Google Kubernetes Engine schreiben müssen. Tatsächlich unterstützen wir bereits die Bereitstellung auf Azure Kubernetes Service!

Zusammengefasst...

Schiphol Takeoff ist ein Tool zur Automatisierung der Bereitstellung, das Ihnen das Leben leichter macht, indem es sich um die Interaktionen mit den verschiedenen Diensten kümmert, die Sie benötigen, um Ihre Anwendung für Ihre Benutzer bereitzustellen. Es ermöglicht Ihnen, sich auf Ihre Anwendung zu konzentrieren, anstatt auf all die (Cloud-)Komponenten, die Sie benötigen, und sorgt für eine zuverlässige Bereitstellung in verschiedenen Umgebungen. Natürlich kann es sein, dass wir die Komponente oder den Dienst, den Sie für Ihre Anwendung benötigen, nicht unterstützen. Zum Glück ist es Open Source, und wir würden uns über Beiträge (Issues, Pull Requests usw.) freuen, um Schiphol Takeoff noch weiter auszubauen. Sie können den Quellcode hier finden

Möchten Sie mehr über Apache Spark für Data Science im großen Maßstab erfahren?

Wir bieten einen großartigen dreitägigen Kurs zu Data Science mit Spark an, in dem Sie alles über die Verwendung von Spark für große Data-Science-Projekte lernen.