Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Bewährte Methoden für Amazon Managed Workflows für Apache Airflow
In diesem Handbuch werden die bewährten Methoden beschrieben, die wir für die Verwendung von Amazon Managed Workflows für Apache Airflow empfehlen.
**Topics**
+ [Leistungsoptimierung für Apache Airflow auf Amazon MWAA](best-practices-tuning.md)
+ [Verwaltung von Python-Abhängigkeiten in requirements.txt](best-practices-dependencies.md)
# Leistungsoptimierung für Apache Airflow auf Amazon MWAA
In diesem Thema wird beschrieben, wie Sie die Leistung einer Amazon Managed Workflows for Apache Airflow Airflow-Umgebung mithilfe von [Verwenden der Apache Airflow Airflow-Konfigurationsoptionen auf Amazon MWAA](configuring-env-variables.md) optimieren können.
**Contents**
+ [Hinzufügen einer Apache Airflow Airflow-Konfigurationsoption](#best-practices-tuning-console-add)
+ [Apache Airflow Airflow-Scheduler](#best-practices-tuning-scheduler)
+ [Parameters](#best-practices-tuning-scheduler-params)
+ [Einschränkungen](#best-practices-tuning-scheduler-limits)
+ [DAG-Ordner](#best-practices-tuning-dag-folders)
+ [Parameters](#best-practices-tuning-dag-folders-params)
+ [DAG-Dateien](#best-practices-tuning-dag-files)
+ [Parameters](#best-practices-tuning-dag-files-params)
+ [Aufgaben](#best-practices-tuning-tasks)
+ [Parameters](#best-practices-tuning-tasks-params)
## Hinzufügen einer Apache Airflow Airflow-Konfigurationsoption
Gehen Sie wie folgt vor, um Ihrer Umgebung eine Airflow-Konfigurationsoption hinzuzufügen.
1. Öffnen Sie die Seite [Umgebungen](https://console.aws.amazon.com/mwaa/home#/environments) auf der Amazon MWAA-Konsole.
1. Wählen Sie eine Umgebung aus.
1. Wählen Sie **Bearbeiten** aus.
1. Wählen Sie **Weiter** aus.
1. Wählen Sie im Bereich mit den ****Airflow-Konfigurationsoptionen die Option Benutzerdefinierte Konfiguration** hinzufügen** aus.
1. Wählen Sie eine Konfiguration aus der Dropdownliste aus und geben Sie einen Wert ein, oder geben Sie eine benutzerdefinierte Konfiguration ein und geben Sie einen Wert ein.
1. Wählen Sie für jede **Konfiguration, die Sie hinzufügen möchten, die Option Benutzerdefinierte** Konfiguration hinzufügen aus.
1. Wählen Sie **Speichern**.
Weitere Informationen finden Sie unter[Verwenden der Apache Airflow Airflow-Konfigurationsoptionen auf Amazon MWAA](configuring-env-variables.md).
## Apache Airflow Airflow-Scheduler
Der Apache Airflow Scheduler ist eine Kernkomponente von Apache Airflow. Ein Problem mit dem Scheduler kann DAGs verhindern, dass Aufgaben analysiert und Aufgaben geplant werden. Weitere Informationen zur Optimierung des Apache Airflow Airflow-Schedulers finden Sie unter [Feinabstimmung der Leistung Ihres Schedulers](https://airflow.apache.org/docs/apache-airflow/2.2.2/concepts/scheduler.html#fine-tuning-your-scheduler-performance) auf der Apache Airflow Airflow-Dokumentationswebsite.
### Parameters
In diesem Abschnitt werden die für den Apache Airflow Scheduler (Apache Airflow v2 und höher) verfügbaren Konfigurationsoptionen und deren Anwendungsfälle beschrieben.
------
#### [ Apache Airflow v3 ]
| Konfiguration | Anwendungsfall |
| --- | --- |
| **[celery.sync\$1parallelism](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#parallelism)** Die Anzahl der Prozesse, die der Celery Executor verwendet, um den Aufgabenstatus zu synchronisieren. **Standard**: 1 | Sie können diese Option verwenden, um Warteschlangenkonflikte zu vermeiden, indem Sie die Prozesse einschränken, die der Celery Executor verwendet. Standardmäßig ist ein Wert auf festgelegt, `1` um Fehler bei der Übermittlung von Aufgabenprotokollen an Logs zu CloudWatch verhindern. Wenn Sie den Wert auf festlegen`0`, wird die maximale Anzahl von Prozessen verwendet, es kann jedoch zu Fehlern bei der Übermittlung von Aufgabenprotokollen kommen. |
| **[scheduler.scheduler\$1idle\$1sleep\$1time](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#scheduler-idle-sleep-time)** Die Anzahl der Sekunden, die zwischen aufeinanderfolgenden Verarbeitungen von DAG-Dateien in der Scheduler-"Schleife“ gewartet werden müssen. **Standard**: 1 | *Sie können diese Option verwenden, um CPU-Auslastung auf dem Scheduler zu verringern, indem Sie die Zeit **verlängern**, in der der Scheduler in den Ruhezustand versetzt wird, nachdem er die Ergebnisse der DAG-Analyse abgerufen, Aufgaben gesucht und in die Warteschlange gestellt hat, sowie Aufgaben in der Warteschlange im Executor ausgeführt hat.* Wenn Sie diesen Wert erhöhen, wird die Anzahl der in einer Umgebung ausgeführten Scheduler-Threads `dag_processor.parsing_processes` für Apache Airflow v2 und Apache Airflow v3 verbraucht. Dies kann die Kapazität der Scheduler zum Parsen verringern und die Zeit erhöhen DAGs, die zum DAGs Füllen des Webservers benötigt wird. |
| **[scheduler.max\$1dagruns\$1to\$1create\$1per\$1loop](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#max-dagruns-to-create-per-loop)** Die maximale Anzahl von zu erstellenden Daten pro Scheduler- „Schleife“. DAGs *DagRuns* **Standard**: 10 | Sie können diese Option verwenden, um Ressourcen für die Planung von Aufgaben freizugeben, indem Sie die maximale Anzahl von „Schleifen“ *DagRuns*für den Scheduler **verringern**. |
| **[dag\$1processor.parsing\$1processes](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#parsing-processes)** Die Anzahl der Threads, die der Scheduler parallel zum Zeitplan DAGs ausführen kann. **Standard: Verwenden** `(2 * number of vCPUs) - 1` | Sie können diese Option verwenden, um Ressourcen freizugeben, indem Sie die Anzahl der Prozesse **verringern**, die der Scheduler parallel zum DAGs Parsen ausführt. Wir empfehlen, diese Zahl niedrig zu halten, wenn sich das DAG-Parsing auf die Aufgabenplanung auswirkt. Sie **müssen** einen Wert angeben, der unter der Anzahl der vCPUs in Ihrer Umgebung liegt. Weitere Informationen finden Sie unter [Grenzwerte](#best-practices-tuning-scheduler-limits). |
------
#### [ Apache Airflow v2 ]
| Konfiguration | Anwendungsfall |
| --- | --- |
| **[celery.sync\$1parallelism](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#parallelism)** Die Anzahl der Prozesse, die der Celery Executor verwendet, um den Aufgabenstatus zu synchronisieren. **Standard**: 1 | Sie können diese Option verwenden, um Warteschlangenkonflikte zu vermeiden, indem Sie die Prozesse einschränken, die der Celery Executor verwendet. Standardmäßig ist ein Wert auf festgelegt, `1` um Fehler bei der Übermittlung von Aufgabenprotokollen an Logs zu CloudWatch verhindern. Wenn Sie den Wert auf festlegen`0`, wird die maximale Anzahl von Prozessen verwendet, es kann jedoch zu Fehlern bei der Übermittlung von Aufgabenprotokollen kommen. |
| **[scheduler.idle\$1sleep\$1time](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#scheduler-idle-sleep-time)** Die Anzahl der Sekunden, die zwischen aufeinanderfolgenden Verarbeitungen von DAG-Dateien in der Scheduler-"Schleife“ gewartet werden müssen. **Standard**: 1 | *Sie können diese Option verwenden, um CPU-Auslastung auf dem Scheduler zu verringern, indem Sie die Zeit **verlängern**, in der der Scheduler in den Ruhezustand versetzt wird, nachdem er die Ergebnisse der DAG-Analyse abgerufen, Aufgaben gesucht und in die Warteschlange gestellt hat, sowie Aufgaben in der Warteschlange im Executor ausgeführt hat.* Wenn Sie diesen Wert erhöhen, wird die Anzahl der in einer Umgebung ausgeführten Scheduler-Threads `scheduler.parsing_processes` für Apache Airflow v2 und Apache Airflow v3 verbraucht. Dies kann die Kapazität der Scheduler zum Parsen verringern und die Zeit erhöhen DAGs, die zum DAGs Füllen des Webservers benötigt wird. |
| **[scheduler.max\$1dagruns\$1to\$1create\$1per\$1loop](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#max-dagruns-to-create-per-loop)** Die maximale Anzahl von zu erstellenden Daten pro Scheduler- „Schleife“. DAGs *DagRuns* **Standard**: 10 | Sie können diese Option verwenden, um Ressourcen für die Planung von Aufgaben freizugeben, indem Sie die maximale Anzahl von „Schleifen“ *DagRuns*für den Scheduler **verringern**. |
| **[scheduler.parsing\$1processes](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#parsing-processes)** Die Anzahl der Threads, die der Scheduler parallel zum Zeitplan DAGs ausführen kann. **Standard: Verwenden** `(2 * number of vCPUs) - 1` | Sie können diese Option verwenden, um Ressourcen freizugeben, indem Sie die Anzahl der Prozesse **verringern**, die der Scheduler parallel zum DAGs Parsen ausführt. Wir empfehlen, diese Zahl niedrig zu halten, wenn sich das DAG-Parsing auf die Aufgabenplanung auswirkt. Sie **müssen** einen Wert angeben, der unter der Anzahl der vCPUs in Ihrer Umgebung liegt. Weitere Informationen finden Sie unter [Grenzwerte](#best-practices-tuning-scheduler-limits). |
------
### Einschränkungen
In diesem Abschnitt werden die Grenzwerte beschrieben, die bei der Anpassung der Standardparameter für den Scheduler zu berücksichtigen sind.
**scheduler.parsing\$1processes, scheduler.max\$1threads (nur v2)**
Zwei Threads sind pro vCPU für eine Umgebungsklasse zulässig. Mindestens ein Thread muss für den Scheduler einer Umgebungsklasse reserviert sein. Wenn Sie eine Verzögerung bei der Planung von Aufgaben feststellen, müssen Sie möglicherweise Ihre [Umgebungsklasse](environment-class.md) erhöhen. Eine große Umgebung verfügt beispielsweise über eine Fargate-Container-Instance mit 4 vCPUs als Scheduler. Das bedeutet, dass `7` insgesamt ein Maximum an Threads zur Verfügung steht, die für andere Prozesse verwendet werden können. Das heißt, zwei Threads multiplizieren vier VCPUs, minus eins für den Scheduler selbst. Der Wert, den Sie in `scheduler.max_threads` (nur v2) angeben und `scheduler.parsing_processes` der die Anzahl der für eine Umgebungsklasse verfügbaren Threads nicht überschreiten darf, wie angegeben:
+ **mw1.small** — Der `1` Thread-Wert für andere Prozesse darf nicht überschritten werden. Der verbleibende Thread ist für den Scheduler reserviert.
+ **mw1.medium** — Die Anzahl der `3` Threads für andere Prozesse darf nicht überschritten werden. Der verbleibende Thread ist für den Scheduler reserviert.
+ **mw1.large** — Die Anzahl der `7` Threads für andere Prozesse darf nicht überschritten werden. Der verbleibende Thread ist für den Scheduler reserviert.
## DAG-Ordner
Der Apache Airflow Scheduler scannt kontinuierlich den DAGs Ordner in Ihrer Umgebung. Alle enthaltenen `plugins.zip` Dateien oder Python (`.py`) -Dateien, die „Airflow“ -Importanweisungen enthalten. Alle resultierenden Python-DAG-Objekte werden dann in eine *DagBag*Datei eingefügt, damit sie vom Scheduler verarbeitet werden können, um zu bestimmen, welche Aufgaben gegebenenfalls geplant werden müssen. Die Analyse von DAG-Dateien erfolgt unabhängig davon, ob die Dateien brauchbare DAG-Objekte enthalten.
### Parameters
In diesem Abschnitt werden die für den DAGs Ordner verfügbaren Konfigurationsoptionen (Apache Airflow v2 und höher) und ihre Anwendungsfälle beschrieben.
------
#### [ Apache Airflow v3 ]
| Konfiguration | Anwendungsfall |
| --- | --- |
| **[dag\$1processor.refresh\$1interval](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#config-dag-processor-refresh-interval)** Die Anzahl der Sekunden, für die der DAGs Ordner nach neuen Dateien durchsucht werden muss. **Standard:** 300 Sekunden | Sie können diese Option verwenden, um Ressourcen freizugeben, indem Sie die Anzahl der Sekunden für die Analyse des DAGs Ordners **erhöhen**. Wir empfehlen, diesen Wert zu erhöhen, wenn Sie lange Analysezeiten haben`total_parse_time metrics`, was möglicherweise auf eine große Anzahl von Dateien in Ihrem DAGs Ordner zurückzuführen ist. |
| **[dag\$1processor.min\$1file\$1process\$1interval](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#min-file-process-interval)** Die Anzahl der Sekunden, nach denen der Scheduler eine DAG analysiert und Aktualisierungen der DAG berücksichtigt werden. **Standard: 30 Sekunden** | Sie können diese Option verwenden, um Ressourcen freizugeben, indem Sie die Anzahl der Sekunden **erhöhen**, die der Scheduler wartet, bevor er eine DAG analysiert. Wenn Sie beispielsweise einen Wert von angeben`30`, wird die DAG-Datei alle 30 Sekunden analysiert. Wir empfehlen, diese Zahl hoch zu halten, um die CPU-Auslastung in Ihrer Umgebung zu verringern. |
------
#### [ Apache Airflow v2 ]
| Konfiguration | Anwendungsfall |
| --- | --- |
| **[scheduler.dag\$1dir\$1list\$1interval](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#dag-dir-list-interval)** Die Anzahl der Sekunden, für die der Ordner nach neuen Dateien durchsucht werden muss. DAGs **Standard:** 300 Sekunden | Sie können diese Option verwenden, um Ressourcen freizugeben, indem Sie die Anzahl der Sekunden für die Analyse des DAGs Ordners **erhöhen**. Wir empfehlen, diesen Wert zu erhöhen, wenn Sie lange Analysezeiten haben`total_parse_time metrics`, was möglicherweise auf eine große Anzahl von Dateien in Ihrem DAGs Ordner zurückzuführen ist. |
| **[scheduler.min\$1file\$1process\$1interval](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#min-file-process-interval)** Die Anzahl der Sekunden, nach denen der Scheduler eine DAG analysiert und Aktualisierungen der DAG berücksichtigt werden. **Standard: 30 Sekunden** | Sie können diese Option verwenden, um Ressourcen freizugeben, indem Sie die Anzahl der Sekunden **erhöhen**, die der Scheduler wartet, bevor er eine DAG analysiert. Wenn Sie beispielsweise einen Wert von angeben`30`, wird die DAG-Datei alle 30 Sekunden analysiert. Wir empfehlen, diese Zahl hoch zu halten, um die CPU-Auslastung in Ihrer Umgebung zu verringern. |
------
## DAG-Dateien
Als Teil der Apache Airflow Airflow-Scheduler-Schleife werden einzelne DAG-Dateien analysiert, um DAG-Python-Objekte zu extrahieren. In Apache Airflow v2 und höher analysiert der Scheduler eine maximale Anzahl von [Parsing-Prozessen](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#parsing-processes) gleichzeitig. Die in `scheduler.min_file_process_interval` (v2) oder `dag_processor.min_file_process_interval` (v3) angegebene Anzahl von Sekunden muss vergehen, bevor dieselbe Datei erneut analysiert wird.
### Parameters
In diesem Abschnitt werden die für Apache Airflow DAG-Dateien (Apache Airflow v2 und höher) verfügbaren Konfigurationsoptionen und deren Anwendungsfälle beschrieben.
------
#### [ Apache Airflow v3 ]
| Konfiguration | Anwendungsfall |
| --- | --- |
| **[dag\$1processor.dag\$1file\$1processor\$1timeout](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#dag-file-processor-timeout)** Die Anzahl der Sekunden vor dem Timeout bei der Verarbeitung einer DAG-Datei. *DagFileProcessor* **Standard:** 50 Sekunden | **Sie können diese Option verwenden, um Ressourcen freizugeben, indem Sie die Zeit bis zum *DagFileProcessor*Timeout verlängern.** Wir empfehlen, diesen Wert zu erhöhen, wenn es in Ihren DAG-Verarbeitungsprotokollen zu Timeouts kommt, die dazu führen, dass keine brauchbaren Dateien geladen DAGs werden. |
| **[core.dagbag\$1import\$1timeout](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#dagbag-import-timeout)** Die Anzahl der Sekunden vor dem Import einer Python-Datei wird überschritten. **Standard:** 30 Sekunden | Sie können diese Option verwenden, um Ressourcen freizugeben, indem Sie die Zeit **erhöhen**, die benötigt wird, bis der Scheduler beim Import einer Python-Datei zum Extrahieren der DAG-Objekte ein Timeout durchführt. Diese Option wird als Teil der Scheduler-"Schleife“ verarbeitet und muss einen Wert enthalten, der unter dem in angegebenen Wert liegt. `dag_processor.dag_file_processor_timeout` |
| **[core.min\$1serialized\$1dag\$1update\$1interval](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#min-serialized-dag-update-interval)** Die Mindestanzahl von Sekunden, nach der serialisierte Daten in der Datenbank aktualisiert werden. DAGs **Standard: 30** | Sie können diese Option verwenden, um Ressourcen freizugeben, indem Sie die Anzahl der Sekunden **erhöhen**, nach denen serialisierte Daten DAGs in der Datenbank aktualisiert werden. Wir empfehlen, diesen Wert zu erhöhen, wenn Sie über eine große Anzahl von oder komplexe DAGs DAGs Daten verfügen. Eine Erhöhung dieses Werts reduziert die Belastung des Schedulers und der Datenbank, da sie DAGs serialisiert werden. |
| **[core.min\$1serialized\$1dag\$1fetch\$1interval](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#min-serialized-dag-fetch-interval)** Die Anzahl der Sekunden, für die eine serialisierte DAG erneut aus der Datenbank abgerufen wird, wenn sie bereits in die geladen ist. DagBag **Standard**: 10 | Sie können diese Option verwenden, um Ressourcen freizugeben, indem Sie die Anzahl der Sekunden **erhöhen**, für die eine serialisierte DAG erneut abgerufen wird. Der Wert muss größer als der unter angegebene Wert sein, `core.min_serialized_dag_update_interval` um die Schreibraten der Datenbank zu reduzieren. Eine Erhöhung dieses Werts reduziert die Belastung des Webservers und der Datenbank, sofern sie serialisiert DAGs werden. |
------
#### [ Apache Airflow v2 ]
| Konfiguration | Anwendungsfall |
| --- | --- |
| **[core.dag\$1file\$1processor\$1timeout](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#dag-file-processor-timeout)** Die Anzahl der Sekunden vor dem Timeout bei der Verarbeitung einer DAG-Datei. *DagFileProcessor* **Standard:** 50 Sekunden | **Sie können diese Option verwenden, um Ressourcen freizugeben, indem Sie die Zeit bis zum *DagFileProcessor*Timeout verlängern.** Wir empfehlen, diesen Wert zu erhöhen, wenn es in Ihren DAG-Verarbeitungsprotokollen zu Timeouts kommt, die dazu führen, dass keine brauchbaren Dateien geladen DAGs werden. |
| **[core.dagbag\$1import\$1timeout](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#dagbag-import-timeout)** Die Anzahl der Sekunden vor dem Import einer Python-Datei wird überschritten. **Standard:** 30 Sekunden | Sie können diese Option verwenden, um Ressourcen freizugeben, indem Sie die Zeit **erhöhen**, die benötigt wird, bis der Scheduler beim Import einer Python-Datei zum Extrahieren der DAG-Objekte ein Timeout durchführt. Diese Option wird als Teil der Scheduler-"Schleife“ verarbeitet und muss einen Wert enthalten, der unter dem in angegebenen Wert liegt. `core.dag_file_processor_timeout` |
| **[core.min\$1serialized\$1dag\$1update\$1interval](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#min-serialized-dag-update-interval)** Die Mindestanzahl von Sekunden, nach der serialisierte Daten in der Datenbank aktualisiert werden. DAGs **Standard: 30** | Sie können diese Option verwenden, um Ressourcen freizugeben, indem Sie die Anzahl der Sekunden **erhöhen**, nach denen serialisierte Daten DAGs in der Datenbank aktualisiert werden. Wir empfehlen, diesen Wert zu erhöhen, wenn Sie über eine große Anzahl von oder komplexe DAGs DAGs Daten verfügen. Eine Erhöhung dieses Werts reduziert die Belastung des Schedulers und der Datenbank, da sie DAGs serialisiert werden. |
| **[core.min\$1serialized\$1dag\$1fetch\$1interval](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#min-serialized-dag-fetch-interval)** Die Anzahl der Sekunden, für die eine serialisierte DAG erneut aus der Datenbank abgerufen wird, wenn sie bereits in die geladen ist. DagBag **Standard**: 10 | Sie können diese Option verwenden, um Ressourcen freizugeben, indem Sie die Anzahl der Sekunden **erhöhen**, für die eine serialisierte DAG erneut abgerufen wird. Der Wert muss größer als der unter angegebene Wert sein, `core.min_serialized_dag_update_interval` um die Schreibraten der Datenbank zu reduzieren. Eine Erhöhung dieses Werts reduziert die Belastung des Webservers und der Datenbank, sofern sie serialisiert DAGs werden. |
------
## Aufgaben
Der Apache Airflow Airflow-Scheduler und die Mitarbeiter sind beide an Aufgaben zum Warteschlangen und Entfernen von Warteschlangen beteiligt. ****Der Scheduler versetzt analysierte Aufgaben, die zur Planung bereit sind, vom Status „Keine“ in den Status „Geplant“.**** **Der Executor, der ebenfalls auf dem Scheduler-Container in Fargate läuft, stellt diese Aufgaben in die Warteschlange und setzt ihren Status auf In Warteschlange.** Wenn die Mitarbeiter über Kapazitäten verfügen, nimmt er die Aufgabe aus der Warteschlange und setzt den Status auf Wird **ausgeführt**. Anschließend wird der Status auf Erfolgreich oder **Fehlgeschlagen geändert, je nachdem, ob die Aufgabe **erfolgreich** war oder nicht**.
### Parameters
In diesem Abschnitt werden die für Apache Airflow Airflow-Aufgaben verfügbaren Konfigurationsoptionen und deren Anwendungsfälle beschrieben.
Die Standardkonfigurationsoptionen, die Amazon MWAA überschreibt, sind markiert. *red*
------
#### [ Apache Airflow v3 ]
| Konfiguration | Anwendungsfall |
| --- | --- |
| **[core.parallelism](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#parallelism)** Die maximale Anzahl von Task-Instanzen, die einen Status haben können. `Running` **Standard:** Dynamisch festgelegt basierend auf`(maxWorkers * maxCeleryWorkers) / schedulers * 1.5`. | Sie können diese Option verwenden, um Ressourcen freizugeben, indem Sie die Anzahl der Task-Instanzen **erhöhen**, die gleichzeitig ausgeführt werden können. Der angegebene Wert muss der Anzahl der verfügbaren Arbeitskräfte multipliziert mit der Aufgabendichte der Mitarbeiter entsprechen. Es wird empfohlen, diesen Wert nur zu ändern, wenn Sie feststellen, dass eine große Anzahl von Aufgaben im Status „Wird ausgeführt“ oder „In der Warteschlange“ hängen bleibt. |
| **[core.execute\$1tasks\$1new\$1python\$1interpreter](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#execute-tasks-new-python-interpreter)** Bestimmt, ob Apache Airflow Aufgaben ausführt, indem es den übergeordneten Prozess forkt oder einen neuen Python-Prozess erstellt. **Standardwert**: `True` | Wenn diese Option auf gesetzt ist`True`, erkennt Apache Airflow Änderungen, die Sie an Ihren Plugins vornehmen, als neuen Python-Prozess, der zur Ausführung von Aufgaben erstellt wurde. |
| **[celery.worker\$1concurrency](https://airflow.apache.org/docs/apache-airflow-providers-celery/stable/configurations-ref.html#worker-concurrency)** Amazon MWAA überschreibt die Airflow-Basisinstallation für diese Option, um Worker als Teil seiner Autoscaling-Komponente zu skalieren. **Standard: Nicht zutreffend** | *Any value specified for this option is ignored.* |
| **[celery.worker\$1autoscale](https://airflow.apache.org/docs/apache-airflow-providers-celery/stable/configurations-ref.html#worker-autoscale)** Die Parallelität von Aufgaben für Mitarbeiter. **Standardwerte:** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/mwaa/latest/userguide/best-practices-tuning.html) | Sie können diese Option verwenden, um Ressourcen freizugeben, indem Sie die **Parallelität der `maximum` Mitarbeiter reduzieren**`minimum`. Mitarbeiter akzeptieren bis zu den konfigurierten `maximum` gleichzeitigen Aufgaben, unabhängig davon, ob genügend Ressourcen dafür zur Verfügung stehen. Wenn Aufgaben ohne ausreichende Ressourcen geplant werden, schlagen die Aufgaben sofort fehl. Es wird empfohlen, diesen Wert für ressourcenintensive Aufgaben zu ändern, indem die Werte so reduziert werden, dass sie unter den Standardwerten liegen, um mehr Kapazität pro Aufgabe zu ermöglichen. |
------
#### [ Apache Airflow v2 ]
| Konfiguration | Anwendungsfall |
| --- | --- |
| **[core.parallelism](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#parallelism)** Die maximale Anzahl von Task-Instanzen, die einen Status haben können. `Running` **Standard:** Dynamisch festgelegt basierend auf`(maxWorkers * maxCeleryWorkers) / schedulers * 1.5`. | Sie können diese Option verwenden, um Ressourcen freizugeben, indem Sie die Anzahl der Task-Instanzen **erhöhen**, die gleichzeitig ausgeführt werden können. Der angegebene Wert muss der Anzahl der verfügbaren Arbeitskräfte multipliziert mit der Aufgabendichte der Mitarbeiter entsprechen. Es wird empfohlen, diesen Wert nur zu ändern, wenn Sie feststellen, dass eine große Anzahl von Aufgaben im Status „Wird ausgeführt“ oder „In der Warteschlange“ hängen bleibt. |
| **[core.dag\$1concurrency](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#dag-concurrency)** Die Anzahl der Task-Instanzen, die für jede DAG gleichzeitig ausgeführt werden dürfen. **Standard: 10000** | Sie können diese Option verwenden, um Ressourcen freizugeben, indem Sie die Anzahl der Task-Instanzen **erhöhen**, die gleichzeitig ausgeführt werden dürfen. Wenn Sie beispielsweise einhundert Aufgaben DAGs mit zehn parallel Aufgaben haben und möchten, dass alle DAGs gleichzeitig ausgeführt werden, können Sie die maximale Parallelität als die Anzahl der verfügbaren Arbeitskräfte multipliziert mit der Aufgabendichte der Mitarbeiter in`celery.worker_concurrency`, geteilt durch die Anzahl von berechnen. DAGs |
| **[core.execute\$1tasks\$1new\$1python\$1interpreter](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#execute-tasks-new-python-interpreter)** Bestimmt, ob Apache Airflow Aufgaben ausführt, indem es den übergeordneten Prozess forkt oder einen neuen Python-Prozess erstellt. **Standardwert**: `True` | Wenn diese Option auf gesetzt ist`True`, erkennt Apache Airflow Änderungen, die Sie an Ihren Plugins vornehmen, als neuen Python-Prozess, der zur Ausführung von Aufgaben erstellt wurde. |
| **[celery.worker\$1concurrency](https://airflow.apache.org/docs/apache-airflow-providers-celery/stable/configurations-ref.html#worker-concurrency)** Amazon MWAA überschreibt die Airflow-Basisinstallation für diese Option, um Worker als Teil seiner Autoscaling-Komponente zu skalieren. **Standard: Nicht zutreffend** | *Any value specified for this option is ignored.* |
| **[celery.worker\$1autoscale](https://airflow.apache.org/docs/apache-airflow-providers-celery/stable/configurations-ref.html#worker-autoscale)** Die Parallelität von Aufgaben für Mitarbeiter. **Standardwerte:** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/mwaa/latest/userguide/best-practices-tuning.html) | Sie können diese Option verwenden, um Ressourcen freizugeben, indem Sie die **Parallelität der `maximum` Mitarbeiter reduzieren**`minimum`. Mitarbeiter akzeptieren bis zu den konfigurierten `maximum` gleichzeitigen Aufgaben, unabhängig davon, ob genügend Ressourcen dafür zur Verfügung stehen. Wenn Aufgaben ohne ausreichende Ressourcen geplant werden, schlagen die Aufgaben sofort fehl. Es wird empfohlen, diesen Wert für ressourcenintensive Aufgaben zu ändern, indem die Werte so reduziert werden, dass sie unter den Standardwerten liegen, um mehr Kapazität pro Aufgabe zu ermöglichen. |
------
# Verwaltung von Python-Abhängigkeiten in requirements.txt
In diesem Thema wird beschrieben, wie Python-Abhängigkeiten in einer `requirements.txt` Datei für eine Amazon Managed Workflows for Apache Airflow Airflow-Umgebung installiert und verwaltet werden.
**Contents**
+ [Testen DAGs mit dem Amazon MWAA CLI Utility](#best-practices-dependencies-cli-utility)
+ [Installation von Python-Abhängigkeiten mit dem PyPi .org-Anforderungsdateiformat](#best-practices-dependencies-different-ways)
+ [Option eins: Python-Abhängigkeiten aus dem Python-Paketindex](#best-practices-dependencies-pip-extras)
+ [Option zwei: Python-Räder (.whl)](#best-practices-dependencies-python-wheels)
+ [Verwenden der `plugins.zip` Datei in einem Amazon S3 S3-Bucket](#best-practices-dependencies-python-wheels-s3)
+ [Verwenden einer WHL-Datei, die auf einer URL gehostet wird](#best-practices-dependencies-python-wheels-url)
+ [Erstellen von WHL-Dateien aus einer DAG](#best-practices-dependencies-python-wheels-dag)
+ [Option drei: Python-Abhängigkeiten, die auf einem privaten PyPi /PEP-503-konformen Repo gehostet werden](#best-practices-dependencies-custom-auth-url)
+ [Aktivieren von Protokollen auf der Amazon MWAA-Konsole](#best-practices-dependencies-troubleshooting-enable)
+ [Zugriff auf Protokolle in der CloudWatch Logs-Konsole](#best-practices-dependencies-troubleshooting-view)
+ [Zugreifen auf Fehler in der Apache Airflow Airflow-Benutzeroberfläche](#best-practices-dependencies-troubleshooting-aa)
+ [Melden Sie sich bei Apache Airflow an](#airflow-access-and-login)
+ [Beispielszenarien `requirements.txt`](#best-practices-dependencies-ex-mix-match)
## Testen DAGs mit dem Amazon MWAA CLI Utility
+ Das Befehlszeilenschnittstellenprogramm (CLI) repliziert eine Amazon Managed Workflows for Apache Airflow Airflow-Umgebung lokal.
+ Die CLI erstellt lokal ein Docker-Container-Image, das einem Amazon MWAA-Produktionsimage ähnelt. Sie können damit eine lokale Apache Airflow Airflow-Umgebung ausführen, um benutzerdefinierte Plugins und Abhängigkeiten zu entwickeln und zu testen DAGs, bevor Sie sie auf Amazon MWAA bereitstellen.
+ Informationen zum Ausführen der CLI finden Sie unter [aws-mwaa-docker-images](https://github.com/aws/amazon-mwaa-docker-images)on GitHub.
## Installation von Python-Abhängigkeiten mit dem PyPi .org-Anforderungsdateiformat
Im folgenden Abschnitt werden die verschiedenen Möglichkeiten beschrieben, Python-Abhängigkeiten gemäß dem PyPi .org [Requirements File Format](https://pip.pypa.io/en/stable/reference/pip_install/#requirements-file-format) zu installieren.
### Option eins: Python-Abhängigkeiten aus dem Python-Paketindex
Im folgenden Abschnitt wird beschrieben, wie Python-Abhängigkeiten aus dem [Python-Paketindex](https://pypi.org/) in einer `requirements.txt` Datei angegeben werden.
------
#### [ Apache Airflow v3 ]
1. **Testen Sie lokal**. Fügen Sie iterativ weitere Bibliotheken hinzu, um die richtige Kombination von Paketen und ihren Versionen zu finden, bevor Sie eine `requirements.txt` Datei erstellen. Informationen zum Ausführen des Amazon MWAA-CLI-Dienstprogramms finden Sie [aws-mwaa-docker-images](https://github.com/aws/amazon-mwaa-docker-images)unter. GitHub
1. **Sehen Sie sich die Extras des Apache Airflow-Pakets** an. Eine Liste der für Apache Airflow v3 auf Amazon MWAA installierten Pakete finden Sie [aws-mwaa-docker-images `requirements.txt`](https://github.com/aws/amazon-mwaa-docker-images/blob/main/requirements.txt)auf der Website. GitHub
1. **Fügen Sie eine Beschränkungsanweisung hinzu**. Fügen Sie die Einschränkungsdatei für Ihre Apache Airflow v3-Umgebung am Anfang Ihrer `requirements.txt` Datei hinzu. Apache Airflow Airflow-Einschränkungsdateien spezifizieren die Anbieterversionen, die zum Zeitpunkt einer Apache Airflow Airflow-Veröffentlichung verfügbar waren.
Ersetzen Sie im folgenden Beispiel *\$1environment-version\$1* durch die Versionsnummer Ihrer Umgebung und *\$1Python-version\$1* durch die Version von Python, die mit Ihrer Umgebung kompatibel ist.
Informationen zu der Version von Python, die mit Ihrer Apache Airflow Airflow-Umgebung kompatibel ist, finden Sie unter [Apache Airflow Airflow-Versionen](airflow-versions.md#airflow-versions-official).
```
--constraint "https://raw.githubusercontent.com/apache/airflow/constraints-{Airflow-version}/constraints-{Python-version}.txt"
```
Wenn die Beschränkungsdatei feststellt, dass das `xyz==1.0` Paket nicht mit anderen Paketen in Ihrer Umgebung kompatibel ist, verhindert sie `pip3 install` nicht, dass inkompatible Bibliotheken in Ihrer Umgebung installiert werden. Wenn die Installation für eines der Pakete fehlschlägt, können Sie auf die Fehlerprotokolle für jede Apache Airflow Airflow-Komponente (den Scheduler, den Worker und den Webserver) im entsprechenden Protokollstream unter Logs zugreifen. CloudWatch Weitere Informationen zu Protokolltypen finden Sie unter. [Zugreifen auf Airflow-Protokolle in Amazon CloudWatch](monitoring-airflow.md)
1. **Apache Airflow-Pakete**. Fügen Sie die [Paket-Extras](http://airflow.apache.org/docs/apache-airflow/2.5.1/extra-packages-ref.html) und die Version (`==`) hinzu. Dies hilft zu verhindern, dass Pakete mit demselben Namen, aber unterschiedlicher Version in Ihrer Umgebung installiert werden.
```
apache-airflow[package-extra]==2.5.1
```
1. **Python-Bibliotheken**. Fügen Sie den Paketnamen und die Version (`==`) in Ihre `requirements.txt` Datei ein. Auf diese Weise wird verhindert, dass ein future aktuelles Update von [PyPi.org](https://pypi.org) automatisch angewendet wird.
```
library == version
```
**Example Boto3 und psycopg2-binary**
Dieses Beispiel dient zu Demonstrationszwecken. Die Bibliotheken boto und psycopg2-binary sind in der Basisinstallation für Apache Airflow v3 enthalten und müssen nicht in einer Datei angegeben werden. `requirements.txt`
```
boto3==1.17.54
boto==2.49.0
botocore==1.20.54
psycopg2-binary==2.8.6
```
[Wenn ein Paket ohne Version angegeben wird, installiert Amazon MWAA die neueste Version des Pakets von PyPi .org.](https://pypi.org) Diese Version kann zu Konflikten mit anderen Paketen in Ihrem führen. `requirements.txt`
------
#### [ Apache Airflow v2 ]
1. **Testen Sie lokal**. Fügen Sie iterativ weitere Bibliotheken hinzu, um die richtige Kombination von Paketen und ihren Versionen zu finden, bevor Sie eine `requirements.txt` Datei erstellen. Informationen zum Ausführen des Amazon MWAA-CLI-Dienstprogramms finden Sie [aws-mwaa-docker-images](https://github.com/aws/amazon-mwaa-docker-images)unter. GitHub
1. **Sehen Sie sich die Extras des Apache Airflow-Pakets** an. Eine Liste der für Apache Airflow v2 auf Amazon MWAA installierten Pakete finden Sie [aws-mwaa-docker-images `requirements.txt`](https://github.com/aws/amazon-mwaa-docker-images/blob/main/requirements.txt)auf der Website. GitHub
1. **Fügen Sie eine Beschränkungsanweisung hinzu**. Fügen Sie die Einschränkungsdatei für Ihre Apache Airflow v2-Umgebung am Anfang Ihrer `requirements.txt` Datei hinzu. Apache Airflow Airflow-Einschränkungsdateien spezifizieren die Anbieterversionen, die zum Zeitpunkt einer Apache Airflow Airflow-Veröffentlichung verfügbar waren.
Ab Apache Airflow v2.7.2 muss Ihre Anforderungsdatei eine Erklärung enthalten. `--constraint` Wenn Sie keine Einschränkung angeben, gibt Amazon MWAA eine für Sie an, um sicherzustellen, dass die in Ihren Anforderungen aufgeführten Pakete mit der Version von Apache Airflow kompatibel sind, die Sie verwenden.
Ersetzen Sie im folgenden Beispiel *\$1environment-version\$1* durch die Versionsnummer Ihrer Umgebung und *\$1Python-version\$1* durch die Version von Python, die mit Ihrer Umgebung kompatibel ist.
Informationen zu der Version von Python, die mit Ihrer Apache Airflow Airflow-Umgebung kompatibel ist, finden Sie unter [Apache Airflow Airflow-Versionen](airflow-versions.md#airflow-versions-official).
```
--constraint "https://raw.githubusercontent.com/apache/airflow/constraints-{Airflow-version}/constraints-{Python-version}.txt"
```
Wenn die Beschränkungsdatei feststellt, dass das `xyz==1.0` Paket nicht mit anderen Paketen in Ihrer Umgebung kompatibel ist, verhindert sie `pip3 install` nicht, dass inkompatible Bibliotheken in Ihrer Umgebung installiert werden. Wenn die Installation für eines der Pakete fehlschlägt, können Sie auf die Fehlerprotokolle für jede Apache Airflow Airflow-Komponente (den Scheduler, den Worker und den Webserver) im entsprechenden Protokollstream unter Logs zugreifen. CloudWatch Weitere Informationen zu Protokolltypen finden Sie unter. [Zugreifen auf Airflow-Protokolle in Amazon CloudWatch](monitoring-airflow.md)
1. **Apache Airflow-Pakete**. Fügen Sie die [Paket-Extras](http://airflow.apache.org/docs/apache-airflow/2.5.1/extra-packages-ref.html) und die Version (`==`) hinzu. Dies hilft zu verhindern, dass Pakete mit demselben Namen, aber unterschiedlicher Version in Ihrer Umgebung installiert werden.
```
apache-airflow[package-extra]==2.5.1
```
1. **Python-Bibliotheken**. Fügen Sie den Paketnamen und die Version (`==`) in Ihre `requirements.txt` Datei ein. Auf diese Weise wird verhindert, dass ein future aktuelles Update von [PyPi.org](https://pypi.org) automatisch angewendet wird.
```
library == version
```
**Example Boto3 und psycopg2-binary**
Dieses Beispiel dient zu Demonstrationszwecken. Die Bibliotheken boto und psycopg2-binary sind in der Apache Airflow v2-Basisinstallation enthalten und müssen nicht in einer Datei angegeben werden. `requirements.txt`
```
boto3==1.17.54
boto==2.49.0
botocore==1.20.54
psycopg2-binary==2.8.6
```
[Wenn ein Paket ohne Version angegeben wird, installiert Amazon MWAA die neueste Version des Pakets von PyPi .org.](https://pypi.org) Diese Version kann zu Konflikten mit anderen Paketen in Ihrem führen. `requirements.txt`
------
### Option zwei: Python-Räder (.whl)
Ein Python-Rad ist ein Paketformat, das entwickelt wurde, um Bibliotheken mit kompilierten Artefakten auszuliefern. Wheel-Pakete als Methode zur Installation von Abhängigkeiten in Amazon MWAA bieten mehrere Vorteile:
+ **Schnellere Installation** — Die WHL-Dateien werden als einzelne ZIP-Datei in den Container kopiert und dann lokal installiert, ohne dass jede Datei heruntergeladen werden muss.
+ **Weniger Konflikte** — Sie können die Versionskompatibilität für Ihre Pakete im Voraus ermitteln. Daher ist es nicht erforderlich, rekursiv kompatible Versionen `pip` zu ermitteln.
+ **Höhere Stabilität** — Bei extern gehosteten Bibliotheken können sich die nachgelagerten Anforderungen ändern, was zu Versionsinkompatibilität zwischen Containern in einer Amazon MWAA-Umgebung führt. Da Abhängigkeiten nicht von einer externen Quelle abhängig sind, verfügt jeder Container über dieselben Bibliotheken, unabhängig davon, wann jeder Container instanziiert wird.
Wir empfehlen die folgenden Methoden, um Python-Abhängigkeiten aus einem Python-Radarchiv (`.whl`) in Ihrem zu installieren`requirements.txt`.
**Topics**
+ [Verwenden der `plugins.zip` Datei in einem Amazon S3 S3-Bucket](#best-practices-dependencies-python-wheels-s3)
+ [Verwenden einer WHL-Datei, die auf einer URL gehostet wird](#best-practices-dependencies-python-wheels-url)
+ [Erstellen von WHL-Dateien aus einer DAG](#best-practices-dependencies-python-wheels-dag)
#### Verwenden der `plugins.zip` Datei in einem Amazon S3 S3-Bucket
Der Apache Airflow-Scheduler, die Worker und der Webserver (für Apache Airflow v2.2.2 und höher) suchen beim Start auf dem AWS-verwalteten Fargate-Container für Ihre Umgebung unter nach benutzerdefinierten Plugins. `/usr/local/airflow/plugins/*` Dieser Prozess beginnt vor den Abhängigkeiten von Amazon MWAA `pip3 install -r requirements.txt` für Python und dem Start des Apache Airflow Airflow-Dienstes. Eine `plugins.zip` Datei kann für alle Dateien verwendet werden, die während der Ausführung der Umgebung nicht ständig geändert werden sollen oder für die Sie Benutzern, die schreiben, keinen Zugriff gewähren möchten. DAGs Zum Beispiel Raddateien für die Python-Bibliothek, Zertifikats-PEM-Dateien und YAML-Konfigurationsdateien.
Im folgenden Abschnitt wird beschrieben, wie Sie ein Rad, das sich in der `plugins.zip` Datei befindet, in Ihrem Amazon S3 S3-Bucket installieren.
1. **Laden Sie die erforderlichen WHL-Dateien** herunter, die Sie [https://pip.pypa.io/en/stable/cli/pip_download/](https://pip.pypa.io/en/stable/cli/pip_download/)mit Ihrem `requirements.txt` auf Amazon MWAA [aws-mwaa-docker-images](https://github.com/aws/amazon-mwaa-docker-images)oder einem anderen [Amazon Linux 2-Container](https://aws.amazon.com/amazon-linux-2) vorhandenen Container verwenden können, um die erforderlichen Python-Wheel-Dateien aufzulösen und herunterzuladen.
```
pip3 download -r "$AIRFLOW_HOME/dags/requirements.txt" -d "$AIRFLOW_HOME/plugins"
cd "$AIRFLOW_HOME/plugins"
zip "$AIRFLOW_HOME/plugins.zip" *
```
1. **Geben Sie den Pfad in Ihrem an**. `requirements.txt` Geben Sie das Plugins-Verzeichnis oben in Ihrer Datei requirements.txt an [https://pip.pypa.io/en/stable/cli/pip_install/#install-find-links](https://pip.pypa.io/en/stable/cli/pip_install/#install-find-links)und weisen Sie an, `pip` nicht aus anderen Quellen zu installieren [https://pip.pypa.io/en/stable/cli/pip_install/#install-no-index](https://pip.pypa.io/en/stable/cli/pip_install/#install-no-index), wie im folgenden Code aufgeführt:
```
--find-links /usr/local/airflow/plugins
--no-index
```
**Example Rad in requirements.txt**
Im folgenden Beispiel wird davon ausgegangen, dass Sie das Rad in eine `plugins.zip` Datei im Stammverzeichnis Ihres Amazon S3 S3-Buckets hochgeladen haben. Beispiel:
```
--find-links /usr/local/airflow/plugins
--no-index
numpy
```
Amazon MWAA ruft das `numpy-1.20.1-cp37-cp37m-manylinux1_x86_64.whl` Rad aus dem `plugins` Ordner ab und installiert es in Ihrer Umgebung.
#### Verwenden einer WHL-Datei, die auf einer URL gehostet wird
Im folgenden Abschnitt wird beschrieben, wie Sie ein Rad installieren, das auf einer URL gehostet wird. Die URL muss entweder öffentlich zugänglich sein oder von der benutzerdefinierten Amazon VPC aus zugänglich sein, die Sie für Ihre Amazon MWAA-Umgebung angegeben haben.
+ **Geben Sie eine URL an**. Geben Sie die URL zu einem Rad in Ihrem an`requirements.txt`.
**Example Radarchiv auf einer öffentlichen URL**
Im folgenden Beispiel wird ein Rad von einer öffentlichen Site heruntergeladen.
```
--find-links https://files.pythonhosted.org/packages/
--no-index
```
Amazon MWAA ruft das Rad von der von Ihnen angegebenen URL ab und installiert es in Ihrer Umgebung.
**Anmerkung**
URLs sind nicht von privaten Webservern aus zugänglich, die Anforderungen in Amazon MWAA v2.2.2 und höher installieren.
#### Erstellen von WHL-Dateien aus einer DAG
Wenn Sie einen privaten Webserver haben, der Apache Airflow v2.2.2 oder höher verwendet, und Sie die Anforderungen nicht installieren können, weil Ihre Umgebung keinen Zugriff auf externe Repositorys hat, können Sie die folgende DAG verwenden, um Ihre bestehenden Amazon MWAA-Anforderungen zu übernehmen und sie auf Amazon S3 zu packen:
```
from airflow import DAG
from airflow.operators.bash_operator import BashOperator
from airflow.utils.dates import days_ago
S3_BUCKET = 'my-s3-bucket'
S3_KEY = 'backup/plugins_whl.zip'
with DAG(dag_id="create_whl_file", schedule_interval=None, catchup=False, start_date=days_ago(1)) as dag:
cli_command = BashOperator(
task_id="bash_command",
bash_command=f"mkdir /tmp/whls;pip3 download -r /usr/local/airflow/requirements/requirements.txt -d /tmp/whls;zip -j /tmp/plugins.zip /tmp/whls/*;aws s3 cp /tmp/plugins.zip s3://amzn-s3-demo-bucket/{S3_KEY}"
)
```
Nachdem Sie die DAG ausgeführt haben, verwenden Sie diese neue Datei als Amazon MWAA`plugins.zip`, optional im Paket mit anderen Plug-ins. Aktualisieren Sie dann Ihre vorherige Version `requirements.txt` mit `--find-links /usr/local/airflow/plugins` und `--no-index` ohne Hinzufügen. `--constraint`
Mit dieser Methode können Sie dieselben Bibliotheken offline verwenden.
### Option drei: Python-Abhängigkeiten, die auf einem privaten PyPi /PEP-503-konformen Repo gehostet werden
Im folgenden Abschnitt wird beschrieben, wie Sie ein Apache Airflow Airflow-Extra installieren, das auf einer privaten URL mit Authentifizierung gehostet wird.
1. Fügen Sie Ihren Benutzernamen und Ihr Passwort als [Apache Airflow Airflow-Konfigurationsoptionen](configuring-env-variables.md) hinzu. Beispiel:
+ `foo.user` : `YOUR_USER_NAME`
+ `foo.pass` : `YOUR_PASSWORD`
1. Erstellen Sie Ihre `requirements.txt` Datei. Ersetzen Sie die Platzhalter im folgenden Beispiel durch Ihre private URL und den Benutzernamen und das Passwort, die Sie als [Apache Airflow Airflow-Konfigurationsoptionen](configuring-env-variables.md) hinzugefügt haben. Beispiel:
```
--index-url https://${AIRFLOW__FOO__USER}:${AIRFLOW__FOO__PASS}@my.privatepypi.com
```
1. Fügen Sie Ihrer Datei weitere Bibliotheken hinzu`requirements.txt`. Beispiel:
```
--index-url https://${AIRFLOW__FOO__USER}:${AIRFLOW__FOO__PASS}@my.privatepypi.com
my-private-package==1.2.3
```
## Aktivieren von Protokollen auf der Amazon MWAA-Konsole
Die [Ausführungsrolle](mwaa-create-role.md) für Ihre Amazon MWAA-Umgebung benötigt die Erlaubnis, Protokolle an Logs zu CloudWatch senden. Informationen zum Aktualisieren der Berechtigungen einer Ausführungsrolle finden Sie unter. [Amazon MWAA-Ausführungsrolle](mwaa-create-role.md)
Sie können Apache Airflow Airflow-Protokolle auf der `CRITICAL` Ebene `INFO``WARNING`,`ERROR`, oder aktivieren. Wenn Sie eine Protokollebene wählen, sendet Amazon MWAA Protokolle für diese Stufe und alle höheren Schweregrade. Wenn Sie beispielsweise Protokolle auf der `INFO` Ebene aktivieren, sendet Amazon MWAA `INFO` Protokolle und `WARNING``ERROR`, und Protokollebenen an `CRITICAL` CloudWatch Logs. Wir empfehlen, die Apache Airflow Airflow-Protokolle auf der `INFO` Ebene zu aktivieren, auf die für den Scheduler empfangenen Protokolle zugreifen kann. `requirements.txt`
![\[Dieses Bild zeigt, wie Protokolle auf der INFO-Ebene aktiviert werden.\]](http://docs.aws.amazon.com/de_de/mwaa/latest/userguide/images/mwaa-console-logs-info.png)
## Zugriff auf Protokolle in der CloudWatch Logs-Konsole
Sie können auf die Apache Airflow Airflow-Protokolle für den Scheduler zugreifen, um Ihre Workflows zu planen und Ihren Ordner zu analysieren. `dags` In den folgenden Schritten wird beschrieben, wie Sie die Protokollgruppe für den Scheduler auf der Amazon MWAA-Konsole öffnen und auf die Apache Airflow Airflow-Protokolle in der Logs-Konsole zugreifen. CloudWatch
**Um auf Protokolle für einen zuzugreifen `requirements.txt`**
1. Öffnen Sie die Seite [Umgebungen](https://console.aws.amazon.com/mwaa/home#/environments) auf der Amazon MWAA-Konsole.
1. Wählen Sie eine Umgebung aus.
1. Wählen Sie im **Bereich **Überwachung** die Protokollgruppe Airflow Scheduler** aus.
1. **Wählen Sie unter `requirements_install_ip` Log-Streams die Option Log Streams aus.**
1. Eine Liste der Pakete, die in der Umgebung installiert wurden, finden Sie unter`/usr/local/airflow/.local/bin`. Beispiel:
```
Collecting appdirs==1.4.4 (from -r /usr/local/airflow/.local/bin (line 1))
Downloading https://files.pythonhosted.org/packages/3b/00/2344469e2084fb28kjdsfiuyweb47389789vxbmnbjhsdgf5463acd6cf5e3db69324/appdirs-1.4.4-py2.py3-none-any.whl
Collecting astroid==2.4.2 (from -r /usr/local/airflow/.local/bin (line 2))
```
1. Überprüfen Sie die Liste der Pakete und ob bei der Installation eines dieser Pakete ein Fehler aufgetreten ist. Wenn etwas schief gelaufen ist, erhalten Sie möglicherweise eine Fehlermeldung, die der folgenden ähnelt:
```
2021-03-05T14:34:42.731-07:00
No matching distribution found for LibraryName==1.0.0 (from -r /usr/local/airflow/.local/bin (line 4))
No matching distribution found for LibraryName==1.0.0 (from -r /usr/local/airflow/.local/bin (line 4))
```
## Zugreifen auf Fehler in der Apache Airflow Airflow-Benutzeroberfläche
Sie können auch Ihre Apache Airflow Airflow-Benutzeroberfläche überprüfen, um festzustellen, ob ein Fehler mit einem anderen Problem zusammenhängt. Der häufigste Fehler, der bei Apache Airflow auf Amazon MWAA auftreten kann, ist:
```
Broken DAG: No module named x
```
Wenn Sie diesen Fehler in Ihrer Apache Airflow Airflow-Benutzeroberfläche finden, fehlt Ihnen wahrscheinlich eine erforderliche Abhängigkeit in Ihrer `requirements.txt` Datei.
### Melden Sie sich bei Apache Airflow an
Sie benötigen [Zugriffsrichtlinie für die Apache Airflow Airflow-Benutzeroberfläche: Amazon MWAAWeb ServerAccess](access-policies.md#web-ui-access) Berechtigungen für Ihr AWS-Konto In AWS Identity and Access Management (IAM), um auf Ihre Apache Airflow Airflow-Benutzeroberfläche zugreifen zu können.
**So greifen Sie auf Ihre Apache Airflow Airflow-Benutzeroberfläche zu**
1. Öffnen Sie die Seite [Umgebungen](https://console.aws.amazon.com/mwaa/home#/environments) auf der Amazon MWAA-Konsole.
1. Wählen Sie eine Umgebung aus.
1. Wählen Sie „**Airflow-Benutzeroberfläche öffnen**“.
## Beispielszenarien `requirements.txt`
Sie können verschiedene Formate in Ihrem kombinieren`requirements.txt`. Das folgende Beispiel verwendet eine Kombination der verschiedenen Möglichkeiten zur Installation von Extras.
**Example Extras auf PyPi .org und eine öffentliche URL**
Sie müssen `--index-url` diese Option verwenden, wenn Sie Pakete von PyPi .org angeben, zusätzlich zu Paketen auf einer öffentlichen URL, wie z. B. einem benutzerdefinierten PEP 503-kompatiblen Repo URLs.
```
aws-batch == 0.6
phoenix-letter >= 0.3
--index-url http://dist.repoze.org/zope2/2.10/simple
zopelib
```