Airflow in einer Umgebung mit mehreren Teams und mehreren Mietern. Strategien für den Einsatz

Dieser Artikel befasst sich mit der Verwendung von Airflow 2 in Umgebungen mit mehreren Teams (Tenants) und schließt mit einem kurzen Überblick über Out-of-the-Box-Funktionen, die (möglicherweise) in Airflow 3 bereitgestellt werden.

TLDR;

Airflow 2 unterstützt von Haus aus keine Mehrmandantenfähigkeit. Für eine starke Isolierung empfiehlt es sich, jedem Team eine eigene Airflow-Umgebung zur Verfügung zu stellen. Wenn Sie Airflow bereitstellen, können Sie einige Ressourcen gemeinsam nutzen und dabei die Isolierung aufrechterhalten. Darüber hinaus gibt es Umgehungslösungen, die es mehreren Teams ermöglichen, eine einzige Airflow-Instanz zu nutzen. Diese Lösungen setzen jedoch in der Regel Vertrauen zwischen den Benutzern voraus und bieten möglicherweise keine vollständige Isolierung (es ist nicht vollständig möglich zu verhindern, dass sich die Benutzer gegenseitig beeinflussen).

Es wird erwartet, dass Airflow 3 irgendwann den Einsatz mehrerer Teams unterstützt, da die entsprechende AIP-67 akzeptiert wurde, aber die Einzelheiten sind noch nicht vollständig definiert oder implementiert.

Einführung

In Umgebungen mit mehreren Teams benötigen Unternehmen eine einzige Bereitstellung von Airflow, bei der die einzelnen Teams in der Unternehmensstruktur nur auf eine Teilmenge der Ressourcen zugreifen können, die dem Team gehören. Sie wollen vor allem die Kosten senken und die Verwaltung im Vergleich zur Verwaltung mehrerer separater Bereitstellungen vereinfachen. Airflow ist zwar eine robuste Plattform für die Orchestrierung von Workflows, aber seine Architektur muss angepasst werden, um die unterschiedlichen Anforderungen von Teams, Zugriffskontrollen und Workloads zu unterstützen.

Es wurde eine gründliche Überprüfung verschiedener Quellen durchgeführt, darunter PRs, GitHub-Probleme und -Diskussionen, Stack Overflow-Fragen, Artikel, Blogbeiträge, die offizielle Airflow-Dokumentation und Präsentationen vom Airflow Summit. Ziel war es nicht nur, die möglichen Konfigurationen von Airflow für mehrere Teams zu untersuchen, sondern auch bewährte Verfahren zu ermitteln, zu prüfen, wie andere Unternehmen dieses Problem in realen Szenarien lösen, und mögliche "Hacks" oder innovative Ansätze aufzudecken, die zur Verbesserung der Lösung eingesetzt werden könnten.

Ein aufrichtiges Dankeschön an alle Mitglieder der Airflow-Community und an alle, die mit ihrem aufmerksamen Feedback zur Gestaltung dieses Dokuments beigetragen haben!

Separate Airflow-Bereitstellung pro Team

Dies ist der einzige Ansatz, der eine vollständige Isolierung bietet.

Beschreibung

Jedes Team hat seine eigene Airflow-Instanz, die isoliert von anderen Teams läuft. Bei dieser Lösung wird für jedes Team eine komplette Instanz von Airflow bereitgestellt, einschließlich aller erforderlichen Komponenten (Datenbank, Webserver, Scheduler, Worker und Konfiguration, einschließlich Ausführungsumgebung (Bibliotheken, Betriebssystem, Variablen und Verbindungen)).

Bei selbstverwalteten Airflow-Implementierungen können einige Ressourcen "gemeinsam genutzt" werden, um die Infrastrukturkosten zu senken und gleichzeitig die Airflow-Instanzen teamspezifisch zu halten, z. B. kann die Airflow-Metadaten-Datenbank für jede Airflow-Instanz in einem separaten Datenbankschema auf einem einzigen Datenbankserver gehostet werden. Dieser Ansatz der "gemeinsamen Datenbank" gewährleistet eine vollständige Isolierung aus der Sicht des Benutzers, auch wenn es auf der Ebene der Infrastruktur zu Ressourcenkonflikten kommen kann. Es ist wichtig zu beachten, dass dieses Setup besser für selbst verwaltete Airflow-Implementierungen geeignet ist - es erfordert die Kontrolle über die Umgebungskonfiguration, was bei verwalteten Diensten wie Google Cloud Composer, AWS MWAA oder Astronomer normalerweise nicht möglich ist. Verwaltete Dienste bieten in der Regel eine einzige Datenbankinstanz pro Airflow-Umgebung, was die Erstellung separater Schemata für verschiedene Teams unmöglich macht. Darüber hinaus erfordern verwaltete Airflow-Dienste oft einen separaten, dedizierten Kubernetes-Cluster, der von der Plattform bereitgestellt wird. Das bedeutet, dass Benutzer Airflow nicht auf einem Cluster ihrer Wahl bereitstellen können, was die Flexibilität und Anpassung weiter einschränkt.

Einrichtung

Stellen Sie mehrere Airflow-Umgebungen gemäß den Richtlinien Ihres Unternehmens bereit, sei es über ein Helm-Diagramm oder über einen verwalteten Service wie Composer. Diese Optionen bieten genügend Flexibilität bei der Konfiguration, um sicherzustellen, dass die Umgebung jedes Teams auf seine spezifischen Bedürfnisse zugeschnitten ist, von der Ressourcenzuweisung bis hin zu individuellen Ausführungsumgebungen.

Wenn Sie Airflow selbst hosten, z.B. auf Kubernetes (ohne verwaltete Airflow-Dienste), sollte für jede Airflow-Instanz ein eigener Namensraum innerhalb des Kubernetes-Clusters erstellt werden. Wenn Sie einen Datenbankserver gemeinsam nutzen, sollte die Datenbank für jede Airflow-Instanz in einem separaten Datenbankschema gehostet werden. Sie können auch erwägen, dieselben Kubernetes-Cluster für die Ausführung von Aufgaben zu verwenden (siehe Kubernetes Executor).

Profis

Nachteile

Am besten für

Mögliche Herausforderungen

Eine einzige Authentifizierungsstelle wird für mehrere Airflow-Umgebungen benötigt

Die Authentifizierung kann über diese verschiedenen Instanzen hinweg rationalisiert werden. Mit Funktionen wie dem Auth Manager von Airflow kann ein zentraler Authentifizierungs-Proxy wie Keycloak einen einheitlichen Zugriff auf alle Webserver-Instanzen bieten. Dies ermöglicht eine vereinfachte, teamübergreifende Authentifizierungsverwaltung mit einem Single Sign-On (SSO) und konsistenten URL-Strukturen für den Zugriff auf die Benutzeroberfläche.

Die Verwaltung mehrerer Bereitstellungen kostet zu viel Zeit und Mühe

Die Nutzung des Helm-Diagramms von Airflow vereinfacht die Kubernetes-Orchestrierung durch die Automatisierung von Bereitstellung, Skalierung und Konfiguration in verschiedenen Umgebungen. Darüber hinaus ermöglicht die Verwendung von Infrastructure-as-Code (IaC)-Tools wie Terraform konsistente, wiederholbare Infrastruktur-Setups, die die Verwaltung von Infrastrukturänderungen und die Verfolgung von Versionen erleichtern. Die Implementierung einer zentralen Protokollierung, die Überwachung mit Tools wie Prometheus oder Grafana und automatisierte Backups tragen weiter dazu bei, den Betrieb zu rationalisieren und den mit der Verwaltung mehrerer Airflow-Instanzen verbundenen Aufwand zu verringern.

Eine einzige Instanz von Airflow für alle Teams

Diese Lösung ist ideal, wenn Sie Kosteneffizienz und Einfachheit gegenüber einer strikten Teamisolierung bevorzugen. Managed Airflow-Services wie Google Composer oder AWS MWAA passen gut zu diesem Ansatz, da sie für den Betrieb einer einzigen, gemeinsam genutzten Airflow-Instanz optimiert sind.

Beschreibung

Eine einzelne Airflow-Instanz wird von mehreren Teams gemeinsam genutzt, wobei alle Ressourcen (Datenbank, Webserver, Scheduler und Worker) gemeinsam verwendet werden. Zwar kann jedes Team über separate Ausführungsumgebungen, Aufgabenwarteschlangen und DAG-Verarbeitungskonfigurationen verfügen, aber sie arbeiten dennoch mit derselben Kerninfrastruktur, insbesondere der Datenbank. Dieser Mangel an echter Isolierung birgt potenzielle Risiken, da sich die Aktionen eines Teams versehentlich auf die Workflows oder Konfigurationen eines anderen Teams auswirken könnten.

Wichtiger Haftungsausschluss

Eine vollständige Mandantenisolierung mit einer einzigen Airflow-Bereitstellung ist NICHT möglich, da jede Airflow-Umgebung eine einzige Datenbank verwendet und Airflow keine feinkörnige Zugriffskontrolle für die Datenbank besitzt. Infolgedessen gibt es keinen eingebauten Mechanismus, der verhindert, dass DAG-Autoren Änderungen an Datenbankinhalten vornehmen oder diese löschen, einschließlich der Änderung des Zustands oder der Rückgabewerte anderer DAGs oder der Änderung/Entfernung von DAGs, die von verschiedenen Teams erstellt wurden, sowie des Zugriffs auf kritische Elemente wie Verbindungen, Variablen und den gesamten Metadatenspeicher. Es gibt keine Möglichkeit, einen böswilligen Akteur eines Teams vollständig daran zu hindern, ein anderes Team zu beeinflussen, da jeder DAG-Autor uneingeschränkten Zugriff auf die gesamte Datenbank hat und Einschränkungen nur schwer effektiv zu implementieren sind.

Eine gewisse Kontrolle kann durch benutzerdefinierte CI/CD-Prüfungen oder durch Benutzereinschränkungen durchgesetzt werden, z. B. durch die Verwendung von DAG-Fabriken zur Begrenzung nicht autorisierter Operationen im Code. Dieser Ansatz verlagert jedoch das Problem der Zugriffskontrolle an eine andere Stelle und erfordert zusätzliche externe Implementierungen. Während CI/CD zum Beispiel überprüfen kann, dass DAGs nur auf erlaubte Daten zugreifen, stellt sich eine neue Frage: Wer überwacht und genehmigt den CI/CD-Prozess selbst?

Einrichtung

Wenn Sie eine gemeinsame Airflow-Instanz für mehrere Teams einrichten, müssen Sie Airflow so konfigurieren, dass es mehrere Ausführungsumgebungen handhaben kann und je nach den spezifischen Anforderungen möglicherweise mehrere Aufgaben-Warteschlangen verwalten muss. Dies kann mithilfe von Cluster Policies geschehen, um eine Trennung zwischen Team-Workloads und Operatoren zu erzwingen, z.B. durch die Festlegung von teamspezifischen Kubernetes Pod Templates oder Celery-Warteschlangen. Separate Knotenpools sollten auch verwendet werden, um Leistungsengpässe zu vermeiden.

Die Verwaltung von Benutzerrollen und die Einschränkung des Zugriffs auf bestimmte DAGs oder Airflow-Komponenten in der Benutzeroberfläche kann mit den integrierten Airflow-Mechanismen erfolgen. Da die Datenbank und die Kernressourcen jedoch gemeinsam genutzt werden, müssen Sie die Berechtigungen und Konfigurationen sorgfältig verwalten, um zu verhindern, dass sich die Teams gegenseitig in ihren Arbeitsabläufen behindern (siehe den "Wichtigen Haftungsausschluss" oben).

Teams können verschiedene Sätze von DAG-Dateiprozessoren für die DAGs-Ordner der einzelnen Teams im Airflow-DAG-Ordner verwenden. Mehrere DAG-Prozessoren können mit der Option -subdir ausgeführt werden.

Profis

Nachteile

Am besten für

Mögliche Herausforderungen

Starke Teams/Mieter müssen isoliert werden

Derzeit besteht die einzige Möglichkeit, eine starke Isolierung zu gewährleisten, darin, dass jedes Team/jeder Mieter seine eigene Airflow-Instanz hat, die keine Ressourcen mit anderen Airflow-Instanzen teilt. Das liegt daran, dass es in Airflow 2 keinen eingebauten Mechanismus gibt, der verhindern kann, dass ein dag-Autor auf irgendetwas in der DB zugreift und es verändert.

Benutzer müssen sich authentifizieren

Managed Airflow (Composer, MWAA, Astro usw.) kümmert sich in der Regel um die Authentifizierung für Sie und ist standardmäßig verfügbar. Standardmäßig verwendet Airflow den Authentifizierungsmanager von Flask AppBuilder (FAB) für die Authentifizierung/Autorisierung, damit Sie Benutzer und Rollen erstellen und Berechtigungen zuweisen können. Bei Bedarf können Sie aber auch ganz einfach Ihren eigenen Authentifizierungsmanager bereitstellen.

Nur ausgewählte Personen sollten in der Lage sein, bestimmte DAGs zu sehen und auszuführen

Airflow verfügt über einen Mechanismus für die Zugriffskontrolle, mit dem Sie entscheiden können, welche DAGs ein Benutzer sehen, bearbeiten, löschen usw. kann, aber er hat einige Einschränkungen, die es ermöglichen, ein solches Szenario nur auf der Ebene der Benutzeroberfläche zu verhindern.

Genauer gesagt steuert die Airflow UI-Zugriffskontrolle nur die Sichtbarkeit und den Zugriff auf die Airflow UI, die DAG UI und die stabile API in Airflow 2. Die Airflow UI-Zugriffskontrolle gilt nicht für andere Schnittstellen, die den Benutzern zur Verfügung stehen, wie z.B. Airflow CLI-Befehle. Dieses Modell wird im DAG- und Aufgabencode nicht durchgesetzt. Sie können zum Beispiel eine DAG bereitstellen, die Airflow-Rollen und Benutzerzuweisungen für diese Rollen ändert.

Ein Team kann nur auf die Verbindung/Variable zugreifen, die ihm selbst gehört

Wie bereits erwähnt, verfügt Airflow nicht über einen Mechanismus, um dies durchzusetzen. Airflow vertraut den DAG-Autoren, so dass auf jede Variable oder Verbindung innerhalb der DAG leicht zugegriffen werden kann bzw. diese geändert oder gelöscht werden kann.

In solchen Fällen kann die Verwendung eines externen Geheimhaltungs-Backends oder die Implementierung einer benutzerdefinierten Lösung, wie z.B. die Zuweisung eines separaten Servicekontos (SA) für jede DAG-ID und die Anforderung an die DAG-Autoren, den Zugriff auf dieses spezielle SA zu beantragen, zu einer besseren Isolierung und Sicherheit beitragen.

Es lohnt sich auch, Konventionen und ein gegenseitiges Vertrauensabkommen zwischen den Nutzern zu etablieren, das sicherstellt, dass sie, auch wenn sie technisch gesehen Zugang zu den Geheimnissen des jeweils anderen haben, sich verpflichten, diesen Zugang nicht zu missbrauchen. Letztendlich kann dieser Ansatz die Einrichtung und Wartung vereinfachen und gleichzeitig die Kosten durch die gemeinsame Nutzung einer einzigen Airflow-Instanz durch mehrere Benutzer oder Teams erheblich senken.

Eine gewisse Kontrolle kann auch durch benutzerdefinierte CI/CD-Prüfungen erzwungen werden. Dieser Ansatz verlagert jedoch das Problem der Zugriffskontrolle an eine andere Stelle und erfordert zusätzliche externe Implementierungen. Während CI/CD zum Beispiel überprüfen könnte, dass DAGs nur auf erlaubte Verbindungen zugreifen, stellt sich eine neue Frage: Wer beaufsichtigt und genehmigt den CI/CD-Prozess selbst?

Ein Team sollte nicht in der Lage sein, die DAGs eines anderen Teams zu überschreiben (z.B. indem es ihnen denselben Namen gibt)

Es gibt keinen eingebauten Airflow-Mechanismus, der dieses Szenario verhindern könnte.

Eine Möglichkeit ist, einige CI/CD-Prüfungen durchzuführen. Eine andere Möglichkeit ist die Verwendung der Cluster-Richtlinien von Airflow, die z.B. überprüfen können, ob dag aus einem bestimmten Verzeichnis stammt (mit dag.fileloc) und einigen vordefinierten Regeln entspricht (z.B. dag_id beginnt mit dem Namen des Verzeichnisses, auf das das Team Zugriff hat). Ein Team kann die DAG eines anderen Teams nicht überschreiben, wenn eine solche Validierung vorhanden ist. Die Cluster-Richtlinie kann eine solche DAG entweder überspringen oder ihre dag_id ändern (sie kann Workflows unterbrechen, die DAG auf der Grundlage der dag_id auslösen).

Ein Team sollte nicht in der Lage sein, die DAG-Dateien eines anderen Teams einzusehen oder darauf zuzugreifen.

Neben der Implementierung einiger Zugriffsrichtlinien in der Benutzeroberfläche, die verhindern, dass das Team etwas anderes als seine eigenen DAGs sieht, müssen auch einige Zugriffsrichtlinien für die Dateien selbst implementiert werden. Unabhängig davon, ob Sie eigenständiges oder verwaltetes Airflow verwenden, können Sie im Verzeichnis dags/ Unterverzeichnisse für jedes Team erstellen und ihnen nur Berechtigungen für ihr eigenes Verzeichnis erteilen. Airflow sollte dann alle Dateien aus dem Ordner dags/ und allen seinen Unterverzeichnissen verarbeiten.

Eine ungültige einzelne DAG-Definition eines Teams sollte nicht die DAG-Verarbeitung oder -Planung für alle unterbrechen.

Die Prozesse Scheduler und dag_processor sollten separat ausgeführt werden. Um eine hohe Verfügbarkeit zu gewährleisten, können Sie mehrere Scheduler gleichzeitig laufen lassen. Sie können auch mehrere dag-Prozessoren ausführen, z.B. einen pro Teamverzeichnis (mit der Option -subdir).

Ein Team sollte nicht in der Lage sein, die Berechtigungen eines anderen Teams zu nutzen

Jedes Team kann seinen eigenen Service Account (SA) Schlüssel verwenden, der in Kubernetes eingebunden ist. Auch wenn Secrets manuell gemountet werden, muss verhindert werden, dass der DAG-Autor den "falschen" Executor auswählt. Sie können den pod_mutation_hook verwenden, um die erforderlichen Konfigurationen dynamisch zu ändern und während der Laufzeit an die Worker-Definitionen anzuhängen, um zu verhindern, dass Benutzer die Worker-Einstellungen auf DAG-Ebene manipulieren. Wir können diese Einschränkung auch durchsetzen, indem wir DAG-Fabriken oder CI/CD-Prüfungen verwenden, die sicherstellen, dass das Team nur seine eigenen Geheimnisse und Verbindungen verwendet, oder indem wir Code-Reviews durchführen, um die Einhaltung zu überprüfen.

Alternativ können Sie für jedes Team einen separaten Satz von Arbeitern (und DAG-Prozessoren) konfigurieren und diese bestimmten Warteschlangen zuweisen. Eine Kombination aus Cluster-Richtlinien und DAG-Dateiprozessoren mit Unterverzeichnisorganisation kann DAGs aus einem Ordner auf bestimmte Arbeiter beschränken. Diese Methode ist zwar nicht ganz narrensicher, schränkt aber die Warteschlangen ein und erzwingt eine gewisse Trennung.

DAGs/Prozesse eines Teams müssen möglicherweise die Daten eines anderen Teams lesen

Gewähren Sie dem Servicekonto eines Teams die Berechtigung, nur auf die spezifische Präsentationsschicht der Daten des anderen Teams zuzugreifen. Dies gewährleistet eine kontrollierte und absichtliche gemeinsame Nutzung von Daten.

Verwaltung von Geheimnissen auf K8s, manuelles Einbinden bestimmter Geheimnisse in K8sExecutor

Anstatt sich auf Airflow-Variablen oder -Verbindungen zu verlassen, denen es an feingranularen Berechtigungen mangelt, können sensible Informationen mit Kubernetes-Geheimnissen gespeichert und verwaltet werden. Diese Secrets können manuell gemountet und an bestimmte Teams gebunden werden. Es sollten jedoch zusätzliche Sicherheitsprüfungen im Bereitstellungsprozess implementiert werden, um sicherzustellen, dass die Geheimnisse nur für die jeweiligen Teams zugänglich sind.

Wie andere das Problem mit mehreren Teams lösen

Beispiele aus der realen Welt

Haftungsausschluss: Diese Analyse basiert auf öffentlich zugänglichen Informationen darüber, wie Unternehmen Airflow einsetzen, wie z.B. Aufzeichnungen, Blogeinträge und andere gemeinsame Materialien. Sie besagt nicht, dass die beschriebenen Praktiken die Gesamtheit ihrer Einsatzstrategien darstellen.

Benutzerdefinierte Lösung auf der Grundlage von Airflow (einzelne oder mehrere Instanzen)

Eine einzige Instanz von Airflow für alle Teams...

Separate Airflow-Bereitstellung pro Team

Was die meisten Unternehmen wählen

Ausgehend von öffentlich zugänglichen Ressourcen variieren die realen Implementierungen von Airflow-Implementierungen für mehrere Teams stark. Die meisten entscheiden sich jedoch für separate Airflow-Umgebungen, die in der Regel auf Kubernetes oder verwalteten Diensten zur besseren Isolierung und Skalierbarkeit bereitgestellt werden.

Einige Unternehmen verwenden zwar eine einzige Airflow-Instanz als Grundlage, beschränken aber den direkten Benutzerzugriff durch benutzerdefinierte Schnittstellen oder DSLs. Dieser Ansatz erzwingt die Trennung der Teams auf Anwendungsebene und ermöglicht eine granulare Kontrolle, die Airflow allein nicht bieten kann. Diese Methode erfordert jedoch häufig den Aufbau einer völlig separaten Anwendungsschicht, die Airflow lediglich als Backend nutzt, was im Laufe der Zeit einen erheblichen Entwicklungs- und Wartungsaufwand erfordert.

Andere verfolgen einen hybriden Ansatz, bei dem eine einzige Airflow-Instanz für weniger kritische Teams gemeinsam genutzt wird, während für empfindlichere oder stark belastende Arbeitslasten separate, isolierte Bereitstellungen bereitgestellt werden. Dieser Ansatz ermöglicht Kosteneinsparungen, wenn das Vertrauen zwischen den Benutzern hergestellt werden kann und gleichzeitig ein Gleichgewicht zwischen Ressourceneffizienz und der Notwendigkeit einer strikten Trennung kritischer Vorgänge besteht.

Diese unterschiedlichen Strategien verdeutlichen die Kompromisse zwischen Isolation, betrieblicher Komplexität und Budgetbeschränkungen und liefern wertvolle Erkenntnisse für die Entwicklung von Airflow-Lösungen in einer Umgebung mit mehreren Teams.

Luftstrom 3

Wichtiger Haftungsausschluss

Obwohl die Arbeit an Airflow 3 im Gange ist und einige AIPs akzeptiert wurden, müssen noch Details geklärt werden. Obwohl man sich auf die wichtigsten Konzepte geeinigt hat, gibt es keine Garantie dafür, dass alles genau so umgesetzt wird, wie es geplant oder in diesem Dokument beschrieben ist.

AIPs und ETAs

Das Haupt-AIP für die Einrichtung mehrerer Teams in Airflow ist AIP-67 (darin finden Sie jedoch eine Liste anderer AIPs, die dies ermöglichen, z.B. AIP-72, das AIP-44ersetzt hat undnur über das Task SDK einen feinkörnigen Zugriff auf die Datenbank ermöglicht)

Sie können den Fortschritt der Arbeiten an Airflow 3 hier verfolgen. Wichtig ist jedoch, dass das AIP-67 NICHT mit 3.0, sondern erst später ausgeliefert werden soll.

Einige Aufzählungspunkte aus AIP-67 (was höchstwahrscheinlich in Zukunft möglich sein wird):

Zusammenfassung

Die Wahl der richtigen Airflow-Einrichtung erfordert eine sorgfältige Abwägung der Bedürfnisse Ihres Teams in Bezug auf Isolierung, Ressourcenmanagement und Zusammenarbeit. In seiner aktuellen Form bietet Airflow 2 keine native Unterstützung für Mandantenfähigkeit. Das bedeutet, dass Unternehmen, die eine starke Trennung zwischen Teams anstreben, idealerweise jedem Team eine eigene Airflow-Umgebung zur Verfügung stellen sollten. Dieser Ansatz stellt sicher, dass Probleme oder Fehler in den Arbeitsabläufen eines Teams sich nicht auf andere auswirken. Wenn jedoch die gemeinsame Nutzung von Ressourcen Priorität hat, gibt es Möglichkeiten, Airflow so einzusetzen, dass Teams eine Instanz gemeinsam nutzen können, auch wenn dies mit Abstrichen bei der Sicherheit und Isolierung verbunden ist. Vertrauen zwischen den Teams ist in solchen Konstellationen unerlässlich, da es schwierig ist, zu verhindern, dass sich die Aktionen eines Teams auf ein anderes auswirken.

Für die Zukunft verspricht Airflow 3 eine bessere Unterstützung für Umgebungen mit mehreren Teams. Diese bevorstehende Funktion könnte die Bereitstellung für Unternehmen, die mehrere Teams verwalten, vereinfachen, auch wenn die Implementierungsdetails noch in der Entwicklung sind. Wenn Sie Ihre Airflow-Architektur entwerfen, ist es wichtig, dass Sie die aktuellen Einschränkungen gegen die zukünftigen Möglichkeiten abwägen.

Zusätzliche Ressourcen

Luftstrom-Dokumente

Andere Ressourcen