Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Bonnes pratiques relatives aux flux de travail gérés par Amazon pour Apache Airflow
Ce guide décrit les meilleures pratiques que nous recommandons lors de l'utilisation d'Amazon Managed Workflows pour Apache Airflow.
**Topics**
+ [Optimisation des performances pour Apache Airflow sur Amazon MWAA](best-practices-tuning.md)
+ [Gestion des dépendances Python dans requirements.txt](best-practices-dependencies.md)
# Optimisation des performances pour Apache Airflow sur Amazon MWAA
Cette rubrique décrit comment optimiser les performances d'un environnement Amazon Managed Workflows pour Apache Airflow à l'aide de. [Utilisation des options de configuration d'Apache Airflow sur Amazon MWAA](configuring-env-variables.md)
**Contents**
+ [Ajout d'une option de configuration d'Apache Airflow](#best-practices-tuning-console-add)
+ [Planificateur Apache Airflow](#best-practices-tuning-scheduler)
+ [Parameters](#best-practices-tuning-scheduler-params)
+ [Restrictions](#best-practices-tuning-scheduler-limits)
+ [Dossiers DAG](#best-practices-tuning-dag-folders)
+ [Parameters](#best-practices-tuning-dag-folders-params)
+ [fichiers DAG](#best-practices-tuning-dag-files)
+ [Parameters](#best-practices-tuning-dag-files-params)
+ [Tâches](#best-practices-tuning-tasks)
+ [Parameters](#best-practices-tuning-tasks-params)
## Ajout d'une option de configuration d'Apache Airflow
Utilisez la procédure suivante pour ajouter une option de configuration Airflow à votre environnement.
1. Ouvrez la page [Environnements](https://console.aws.amazon.com/mwaa/home#/environments) sur la console Amazon MWAA.
1. Choisissez un environnement.
1. Choisissez **Modifier**.
1. Choisissez **Suivant**.
1. Choisissez **Ajouter une configuration personnalisée** dans le volet des **options de configuration d'Airflow**.
1. Choisissez une configuration dans la liste déroulante et entrez une valeur, ou entrez une configuration personnalisée et entrez une valeur.
1. Choisissez **Ajouter une configuration personnalisée** pour chaque configuration que vous souhaitez ajouter.
1. Choisissez **Enregistrer**.
Pour en savoir plus, reportez-vous à[Utilisation des options de configuration d'Apache Airflow sur Amazon MWAA](configuring-env-variables.md).
## Planificateur Apache Airflow
Le planificateur Apache Airflow est un composant essentiel d'Apache Airflow. Un problème avec le planificateur peut DAGs empêcher l'analyse et la planification des tâches. Pour plus d'informations sur le réglage du planificateur Apache Airflow, reportez-vous à la section Optimisation des [performances de votre planificateur sur le site Web de documentation](https://airflow.apache.org/docs/apache-airflow/2.2.2/concepts/scheduler.html#fine-tuning-your-scheduler-performance) d'Apache Airflow.
### Parameters
Cette section décrit les options de configuration disponibles pour le planificateur Apache Airflow (Apache Airflow v2 et versions ultérieures) et leurs cas d'utilisation.
------
#### [ Apache Airflow v3 ]
| Configuration | Cas d’utilisation |
| --- | --- |
| **[celery.sync\$1parallelism](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#parallelism)** Nombre de processus utilisés par Celery Executor pour synchroniser l'état des tâches. **Par défaut** : 1 | Vous pouvez utiliser cette option pour éviter les conflits de files d'attente en limitant les processus utilisés par Celery Executor. Par défaut, une valeur est définie sur pour `1` éviter les erreurs lors de la transmission des journaux des tâches à CloudWatch Logs. Si la valeur est définie sur`0`, vous devez utiliser le nombre maximum de processus, mais cela peut entraîner des erreurs lors de la remise des journaux de tâches. |
| **[scheduler.scheduler\$1idle\$1sleep\$1time](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#scheduler-idle-sleep-time)** Le nombre de secondes à attendre entre deux traitements consécutifs de fichiers DAG dans la « boucle » du planificateur. **Par défaut** : 1 | *Vous pouvez utiliser cette option pour libérer l'utilisation du processeur sur le planificateur en **augmentant** le temps de veille du planificateur une fois qu'il a fini de récupérer les résultats de l'analyse DAG, de rechercher et de mettre en file d'attente des tâches et d'exécuter les tâches en file d'attente dans l'exécuteur.* L'augmentation de cette valeur consomme le nombre de threads du planificateur exécutés sur un environnement dans Apache Airflow `dag_processor.parsing_processes` v2 et Apache Airflow v3. Cela peut réduire la capacité d'analyse DAGs des planificateurs et augmenter le temps nécessaire DAGs au remplissage sur le serveur Web. |
| **[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)** Le nombre maximum de « boucles » DAGs à créer *DagRuns*pour chaque « boucle » du planificateur. **Par défaut** : 10 | Vous pouvez utiliser cette option pour libérer des ressources pour planifier des tâches en **diminuant** le nombre maximum de « boucles » *DagRuns*pour la « boucle » du planificateur. |
| **[dag\$1processor.parsing\$1processes](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#parsing-processes)** Le nombre de threads que le planificateur peut exécuter en parallèle pour planifier. DAGs **Par défaut :** Utiliser `(2 * number of vCPUs) - 1` | Vous pouvez utiliser cette option pour libérer des ressources en **diminuant** le nombre de processus que le planificateur exécute en parallèle pour analyser. DAGs Nous recommandons de maintenir ce nombre à un faible niveau si l'analyse DAG a un impact sur la planification des tâches. Vous **devez** spécifier une valeur inférieure au nombre de vCPU de votre environnement. Pour en savoir plus, reportez-vous à la section [Limites](#best-practices-tuning-scheduler-limits). |
------
#### [ Apache Airflow v2 ]
| Configuration | Cas d’utilisation |
| --- | --- |
| **[celery.sync\$1parallelism](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#parallelism)** Nombre de processus utilisés par Celery Executor pour synchroniser l'état des tâches. **Par défaut** : 1 | Vous pouvez utiliser cette option pour éviter les conflits de files d'attente en limitant les processus utilisés par Celery Executor. Par défaut, une valeur est définie sur pour `1` éviter les erreurs lors de la transmission des journaux des tâches à CloudWatch Logs. Si la valeur est définie sur`0`, vous devez utiliser le nombre maximum de processus, mais cela peut entraîner des erreurs lors de la remise des journaux de tâches. |
| **[scheduler.idle\$1sleep\$1time](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#scheduler-idle-sleep-time)** Le nombre de secondes à attendre entre deux traitements consécutifs de fichiers DAG dans la « boucle » du planificateur. **Par défaut** : 1 | *Vous pouvez utiliser cette option pour libérer l'utilisation du processeur sur le planificateur en **augmentant** le temps de veille du planificateur une fois qu'il a fini de récupérer les résultats de l'analyse DAG, de rechercher et de mettre en file d'attente des tâches et d'exécuter les tâches en file d'attente dans l'exécuteur.* L'augmentation de cette valeur consomme le nombre de threads du planificateur exécutés sur un environnement dans Apache Airflow `scheduler.parsing_processes` v2 et Apache Airflow v3. Cela peut réduire la capacité d'analyse DAGs des planificateurs et augmenter le temps nécessaire DAGs au remplissage sur le serveur Web. |
| **[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)** Le nombre maximum de « boucles » DAGs à créer *DagRuns*pour chaque « boucle » du planificateur. **Par défaut** : 10 | Vous pouvez utiliser cette option pour libérer des ressources pour planifier des tâches en **diminuant** le nombre maximum de « boucles » *DagRuns*pour la « boucle » du planificateur. |
| **[scheduler.parsing\$1processes](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#parsing-processes)** Le nombre de threads que le planificateur peut exécuter en parallèle pour planifier. DAGs **Par défaut :** Utiliser `(2 * number of vCPUs) - 1` | Vous pouvez utiliser cette option pour libérer des ressources en **diminuant** le nombre de processus que le planificateur exécute en parallèle pour analyser. DAGs Nous recommandons de maintenir ce nombre à un faible niveau si l'analyse DAG a un impact sur la planification des tâches. Vous **devez** spécifier une valeur inférieure au nombre de vCPU de votre environnement. Pour en savoir plus, reportez-vous à la section [Limites](#best-practices-tuning-scheduler-limits). |
------
### Restrictions
Cette section décrit les limites à prendre en compte lors de l'ajustement des paramètres par défaut du planificateur.
**scheduler.parsing\$1processes, scheduler.max\$1threads (version 2 uniquement)**
Deux threads sont autorisés par vCPU pour une classe d'environnement. Au moins un thread doit être réservé au planificateur d'une classe d'environnement. Si vous remarquez un retard dans la planification des tâches, vous devrez peut-être augmenter votre [classe d'environnement](environment-class.md). Par exemple, un environnement de grande taille possède une instance de conteneur Fargate à 4 vCPU pour son planificateur. Cela signifie qu'un maximum de `7` threads peuvent être utilisés pour d'autres processus. C'est-à-dire deux threads multipliés par quatre vCPUs, moins un pour le planificateur lui-même. La valeur que vous spécifiez dans `scheduler.max_threads` (v2 uniquement) ne `scheduler.parsing_processes` doit pas dépasser le nombre de threads disponibles pour une classe d'environnement, comme indiqué :
+ **mw1.small** — Ne doit pas dépasser le nombre de `1` threads pour les autres processus. Le thread restant est réservé au planificateur.
+ **mw1.medium** — Ne doit pas dépasser le nombre de `3` threads pour les autres processus. Le thread restant est réservé au planificateur.
+ **mw1.large** — Ne doit pas dépasser le nombre de `7` threads pour les autres processus. Le thread restant est réservé au planificateur.
## Dossiers DAG
Le planificateur Apache Airflow analyse en permanence le DAGs dossier de votre environnement. Tous `plugins.zip` les fichiers contenus ou les fichiers Python (`.py`) contenant des instructions d'importation « airflow ». Tous les objets DAG Python qui en résultent sont ensuite placés dans un fichier *DagBag*pour ce fichier afin d'être traités par le planificateur afin de déterminer quelles tâches, le cas échéant, doivent être planifiées. L'analyse des fichiers DAG a lieu indépendamment du fait que les fichiers contiennent ou non des objets DAG viables.
### Parameters
Cette section décrit les options de configuration disponibles pour le DAGs dossier (Apache Airflow v2 et versions ultérieures) et leurs cas d'utilisation.
------
#### [ Apache Airflow v3 ]
| Configuration | Cas d’utilisation |
| --- | --- |
| **[dag\$1processor.refresh\$1interval](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#config-dag-processor-refresh-interval)** Le nombre de secondes pendant lesquelles le DAGs dossier doit être scanné à la recherche de nouveaux fichiers. **Par défaut :** 300 secondes | Vous pouvez utiliser cette option pour libérer des ressources en **augmentant** le nombre de secondes nécessaires à l'analyse du DAGs dossier. Nous vous recommandons d'augmenter cette valeur si les temps d'analyse sont longs`total_parse_time metrics`, ce qui peut être dû au grand nombre de fichiers dans votre DAGs dossier. |
| **[dag\$1processor.min\$1file\$1process\$1interval](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#min-file-process-interval)** Le nombre de secondes après lequel le planificateur analyse un DAG et les mises à jour du DAG sont reflétées. **Par défaut :** 30 secondes | Vous pouvez utiliser cette option pour libérer des ressources en **augmentant** le nombre de secondes pendant lesquelles le planificateur attend avant d'analyser un DAG. Par exemple, si vous spécifiez une valeur de`30`, le fichier DAG est analysé toutes les 30 secondes. Nous vous recommandons de maintenir ce chiffre à un niveau élevé afin de réduire l'utilisation du processeur dans votre environnement. |
------
#### [ Apache Airflow v2 ]
| Configuration | Cas d’utilisation |
| --- | --- |
| **[scheduler.dag\$1dir\$1list\$1interval](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#dag-dir-list-interval)** Le nombre de secondes pendant lesquelles le DAGs dossier doit être scanné à la recherche de nouveaux fichiers. **Par défaut :** 300 secondes | Vous pouvez utiliser cette option pour libérer des ressources en **augmentant** le nombre de secondes nécessaires à l'analyse du DAGs dossier. Nous vous recommandons d'augmenter cette valeur si les temps d'analyse sont longs`total_parse_time metrics`, ce qui peut être dû au grand nombre de fichiers dans votre DAGs dossier. |
| **[scheduler.min\$1file\$1process\$1interval](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#min-file-process-interval)** Le nombre de secondes après lequel le planificateur analyse un DAG et les mises à jour du DAG sont reflétées. **Par défaut :** 30 secondes | Vous pouvez utiliser cette option pour libérer des ressources en **augmentant** le nombre de secondes pendant lesquelles le planificateur attend avant d'analyser un DAG. Par exemple, si vous spécifiez une valeur de`30`, le fichier DAG est analysé toutes les 30 secondes. Nous vous recommandons de maintenir ce chiffre à un niveau élevé afin de réduire l'utilisation du processeur dans votre environnement. |
------
## fichiers DAG
Dans le cadre de la boucle du planificateur Apache Airflow, les fichiers DAG individuels sont analysés pour extraire les objets Python du DAG. Dans Apache Airflow v2 et versions ultérieures, le planificateur analyse un nombre maximum de processus d'[analyse simultanément](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#parsing-processes). Le nombre de secondes spécifié dans `scheduler.min_file_process_interval` (v2) ou `dag_processor.min_file_process_interval` (v3) doit s'écouler avant que le même fichier ne soit à nouveau analysé.
### Parameters
Cette section décrit les options de configuration disponibles pour les fichiers DAG Apache Airflow (Apache Airflow v2 et versions ultérieures) et leurs cas d'utilisation.
------
#### [ Apache Airflow v3 ]
| Configuration | Cas d’utilisation |
| --- | --- |
| **[dag\$1processor.dag\$1file\$1processor\$1timeout](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#dag-file-processor-timeout)** Nombre de secondes avant l'expiration du délai *DagFileProcessor*de traitement d'un fichier DAG. **Par défaut :** 50 secondes | Vous pouvez utiliser cette option pour libérer des ressources en **augmentant** le temps nécessaire avant l'expiration des *DagFileProcessor*délais. Nous vous recommandons d'augmenter cette valeur si vous rencontrez des délais d'attente dans les journaux de traitement de votre DAG qui empêchent le chargement de fichiers viables DAGs . |
| **[core.dagbag\$1import\$1timeout](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#dagbag-import-timeout)** Expiration du délai en secondes avant l'importation d'un fichier Python. **Par défaut :** 30 secondes | Vous pouvez utiliser cette option pour libérer des ressources en **augmentant** le délai d'expiration du planificateur lors de l'importation d'un fichier Python pour extraire les objets DAG. Cette option est traitée dans le cadre de la « boucle » du planificateur et doit contenir une valeur inférieure à celle spécifiée dans. `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)** Nombre minimal de secondes après lequel les données sérialisées DAGs dans la base de données sont mises à jour. **Par défaut :** 30 | Vous pouvez utiliser cette option pour libérer des ressources en **augmentant** le nombre de secondes après lesquelles les numéros de série de la base de DAGs données sont mis à jour. Nous vous recommandons d'augmenter cette valeur si vous en avez un grand nombre ou si vous DAGs en avez un complexe DAGs. L'augmentation de cette valeur réduit la charge sur le planificateur et la base de données lors de la DAGs sérialisation. |
| **[core.min\$1serialized\$1dag\$1fetch\$1interval](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#min-serialized-dag-fetch-interval)** Le nombre de secondes pendant lesquelles un DAG sérialisé est extrait à nouveau de la base de données alors qu'il est déjà chargé dans le. DagBag **Par défaut** : 10 | Vous pouvez utiliser cette option pour libérer des ressources en **augmentant** le nombre de secondes pendant lesquelles un DAG sérialisé est à nouveau extrait. La valeur doit être supérieure à la valeur spécifiée dans `core.min_serialized_dag_update_interval` pour réduire les taux d' « écriture » de la base de données. L'augmentation de cette valeur réduit la charge sur le serveur Web et la base de données lors de la DAGs sérialisation. |
------
#### [ Apache Airflow v2 ]
| Configuration | Cas d’utilisation |
| --- | --- |
| **[core.dag\$1file\$1processor\$1timeout](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#dag-file-processor-timeout)** Nombre de secondes avant l'expiration du délai *DagFileProcessor*de traitement d'un fichier DAG. **Par défaut :** 50 secondes | Vous pouvez utiliser cette option pour libérer des ressources en **augmentant** le temps nécessaire avant l'expiration des *DagFileProcessor*délais. Nous vous recommandons d'augmenter cette valeur si vous rencontrez des délais d'attente dans les journaux de traitement de votre DAG qui empêchent le chargement de fichiers viables DAGs . |
| **[core.dagbag\$1import\$1timeout](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#dagbag-import-timeout)** Expiration du délai en secondes avant l'importation d'un fichier Python. **Par défaut :** 30 secondes | Vous pouvez utiliser cette option pour libérer des ressources en **augmentant** le délai d'expiration du planificateur lors de l'importation d'un fichier Python pour extraire les objets DAG. Cette option est traitée dans le cadre de la « boucle » du planificateur et doit contenir une valeur inférieure à celle spécifiée dans. `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)** Nombre minimal de secondes après lequel les données sérialisées DAGs dans la base de données sont mises à jour. **Par défaut :** 30 | Vous pouvez utiliser cette option pour libérer des ressources en **augmentant** le nombre de secondes après lesquelles les numéros de série de la base de DAGs données sont mis à jour. Nous vous recommandons d'augmenter cette valeur si vous en avez un grand nombre ou si vous DAGs en avez un complexe DAGs. L'augmentation de cette valeur réduit la charge sur le planificateur et la base de données lors de la DAGs sérialisation. |
| **[core.min\$1serialized\$1dag\$1fetch\$1interval](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#min-serialized-dag-fetch-interval)** Le nombre de secondes pendant lesquelles un DAG sérialisé est extrait à nouveau de la base de données alors qu'il est déjà chargé dans le. DagBag **Par défaut** : 10 | Vous pouvez utiliser cette option pour libérer des ressources en **augmentant** le nombre de secondes pendant lesquelles un DAG sérialisé est à nouveau extrait. La valeur doit être supérieure à la valeur spécifiée dans `core.min_serialized_dag_update_interval` pour réduire les taux d' « écriture » de la base de données. L'augmentation de cette valeur réduit la charge sur le serveur Web et la base de données lors de la DAGs sérialisation. |
------
## Tâches
Le planificateur et les outils de travail d'Apache Airflow sont tous deux impliqués dans les tâches de mise en file d'attente et de suppression des files d'attente. **Le planificateur fait passer les tâches analysées prêtes à être planifiées du statut **Aucune** au statut Planifié.** **L'exécuteur, qui s'exécute également sur le conteneur du planificateur de Fargate, met ces tâches en file d'attente et définit leur statut sur Queued.** Lorsque les travailleurs ont de la capacité, ils retirent la tâche de la file d'attente et lui attribuent le statut En **cours d'exécution**, ce qui change ensuite son statut en **Succès ou **Échec** en fonction de la réussite** ou de l'échec de la tâche.
### Parameters
Cette section décrit les options de configuration disponibles pour les tâches Apache Airflow et leurs cas d'utilisation.
Les options de configuration par défaut qu'Amazon MWAA remplace sont indiquées. *red*
------
#### [ Apache Airflow v3 ]
| Configuration | Cas d’utilisation |
| --- | --- |
| **[core.parallélisme](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#parallelism)** Nombre maximal d'instances de tâches pouvant avoir un `Running` statut. **Par défaut :** défini dynamiquement en fonction de`(maxWorkers * maxCeleryWorkers) / schedulers * 1.5`. | Vous pouvez utiliser cette option pour libérer des ressources en **augmentant** le nombre d'instances de tâches pouvant être exécutées simultanément. La valeur spécifiée doit être le nombre de travailleurs disponibles multiplié par la densité des tâches des travailleurs. Nous vous recommandons de modifier cette valeur uniquement lorsque vous rencontrez un grand nombre de tâches bloquées dans l'état « En cours » ou « En file d'attente ». |
| **[core.execute\$1tasks\$1new\$1python\$1interpreter](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#execute-tasks-new-python-interpreter)** Détermine si Apache Airflow exécute des tâches en bifurquant le processus parent ou en créant un nouveau processus Python. **Par défaut** : `True` | Lorsqu'il est défini sur`True`, Apache Airflow reconnaît les modifications que vous apportez à vos plugins en tant que nouveau processus Python créé pour exécuter des tâches. |
| **[celery.worker\$1concurrency](https://airflow.apache.org/docs/apache-airflow-providers-celery/stable/configurations-ref.html#worker-concurrency)** Amazon MWAA remplace l'installation de base d'Airflow pour cette option afin de dimensionner les travailleurs dans le cadre de son composant de dimensionnement automatique. **Par défaut :** Non applicable | *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)** La simultanéité des tâches pour les travailleurs. **Défauts :** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/mwaa/latest/userguide/best-practices-tuning.html) | Vous pouvez utiliser cette option pour libérer des ressources en **réduisant** la `maximum` simultanéité des `minimum` tâches entre les travailleurs. Les travailleurs acceptent jusqu'à la `maximum` limite des tâches simultanées configurées, que les ressources soient suffisantes ou non pour le faire. Si les tâches sont planifiées sans ressources suffisantes, elles échouent immédiatement. Nous recommandons de modifier cette valeur pour les tâches gourmandes en ressources en réduisant les valeurs à des valeurs inférieures aux valeurs par défaut afin d'augmenter la capacité par tâche. |
------
#### [ Apache Airflow v2 ]
| Configuration | Cas d’utilisation |
| --- | --- |
| **[core.parallélisme](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#parallelism)** Nombre maximal d'instances de tâches pouvant avoir un `Running` statut. **Par défaut :** défini dynamiquement en fonction de`(maxWorkers * maxCeleryWorkers) / schedulers * 1.5`. | Vous pouvez utiliser cette option pour libérer des ressources en **augmentant** le nombre d'instances de tâches pouvant être exécutées simultanément. La valeur spécifiée doit être le nombre de travailleurs disponibles multiplié par la densité des tâches des travailleurs. Nous vous recommandons de modifier cette valeur uniquement lorsque vous rencontrez un grand nombre de tâches bloquées dans l'état « En cours » ou « En file d'attente ». |
| **[core.dag\$1concurrency](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#dag-concurrency)** Le nombre d'instances de tâches autorisées à s'exécuter simultanément pour chaque DAG. **Par défaut :** 10000 | Vous pouvez utiliser cette option pour libérer des ressources en **augmentant** le nombre d'instances de tâches autorisées à s'exécuter simultanément. Par exemple, si vous avez cent tâches DAGs avec dix tâches parallèles et que vous souhaitez que toutes DAGs s'exécutent simultanément, vous pouvez calculer le parallélisme maximal en multipliant le nombre de travailleurs disponibles par la densité de tâches des travailleurs en`celery.worker_concurrency`, divisé par le nombre de. 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)** Détermine si Apache Airflow exécute des tâches en bifurquant le processus parent ou en créant un nouveau processus Python. **Par défaut** : `True` | Lorsqu'il est défini sur`True`, Apache Airflow reconnaît les modifications que vous apportez à vos plugins en tant que nouveau processus Python créé pour exécuter des tâches. |
| **[celery.worker\$1concurrency](https://airflow.apache.org/docs/apache-airflow-providers-celery/stable/configurations-ref.html#worker-concurrency)** Amazon MWAA remplace l'installation de base d'Airflow pour cette option afin de dimensionner les travailleurs dans le cadre de son composant de dimensionnement automatique. **Par défaut :** Non applicable | *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)** La simultanéité des tâches pour les travailleurs. **Défauts :** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/mwaa/latest/userguide/best-practices-tuning.html) | Vous pouvez utiliser cette option pour libérer des ressources en **réduisant** la `maximum` simultanéité des `minimum` tâches entre les travailleurs. Les travailleurs acceptent jusqu'à la `maximum` limite des tâches simultanées configurées, que les ressources soient suffisantes ou non pour le faire. Si les tâches sont planifiées sans ressources suffisantes, elles échouent immédiatement. Nous recommandons de modifier cette valeur pour les tâches gourmandes en ressources en réduisant les valeurs à des valeurs inférieures aux valeurs par défaut afin d'augmenter la capacité par tâche. |
------
# Gestion des dépendances Python dans requirements.txt
Cette rubrique explique comment installer et gérer les dépendances Python dans un `requirements.txt` fichier pour un environnement Amazon Managed Workflows for Apache Airflow.
**Contents**
+ [Tests DAGs à l'aide de l'utilitaire Amazon MWAA CLI](#best-practices-dependencies-cli-utility)
+ [Installation de dépendances Python à l'aide du format de fichier d'exigences PyPi .org](#best-practices-dependencies-different-ways)
+ [Option 1 : dépendances Python à partir de l'index des packages Python](#best-practices-dependencies-pip-extras)
+ [Deuxième option : roues Python (.whl)](#best-practices-dependencies-python-wheels)
+ [Utilisation du `plugins.zip` fichier dans un compartiment Amazon S3](#best-practices-dependencies-python-wheels-s3)
+ [Utilisation d'un fichier WHL hébergé sur une URL](#best-practices-dependencies-python-wheels-url)
+ [Création d'un fichier WHL à partir d'un DAG](#best-practices-dependencies-python-wheels-dag)
+ [Troisième option : dépendances Python hébergées sur un dépôt privé conforme à PyPi /PEP-503](#best-practices-dependencies-custom-auth-url)
+ [Activation des journaux sur la console Amazon MWAA](#best-practices-dependencies-troubleshooting-enable)
+ [Accès aux journaux sur la console CloudWatch Logs](#best-practices-dependencies-troubleshooting-view)
+ [Erreurs d'accès dans l'interface utilisateur d'Apache Airflow](#best-practices-dependencies-troubleshooting-aa)
+ [Connectez-vous à Apache Airflow](#airflow-access-and-login)
+ [Exemples de `requirements.txt` scénarios](#best-practices-dependencies-ex-mix-match)
## Tests DAGs à l'aide de l'utilitaire Amazon MWAA CLI
+ L'utilitaire d'interface de ligne de commande (CLI) reproduit localement un environnement Amazon Managed Workflows pour Apache Airflow.
+ La CLI crée localement une image de conteneur Docker similaire à une image de production Amazon MWAA. Vous pouvez l'utiliser pour exécuter un environnement Apache Airflow local afin de développer et de tester DAGs des plugins personnalisés et des dépendances avant le déploiement sur Amazon MWAA.
+ Pour exécuter la CLI, reportez-vous à la section [aws-mwaa-docker-images](https://github.com/aws/amazon-mwaa-docker-images)on GitHub.
## Installation de dépendances Python à l'aide du format de fichier d'exigences PyPi .org
La section suivante décrit les différentes manières d'installer les dépendances Python conformément au [format de fichier d'exigences PyPi](https://pip.pypa.io/en/stable/reference/pip_install/#requirements-file-format) .org.
### Option 1 : dépendances Python à partir de l'index des packages Python
La section suivante décrit comment spécifier les dépendances Python à partir de l'[index des packages Python](https://pypi.org/) dans un `requirements.txt` fichier.
------
#### [ Apache Airflow v3 ]
1. **Testez localement**. Ajoutez des bibliothèques supplémentaires de manière itérative pour trouver la bonne combinaison de packages et de leurs versions, avant de créer un `requirements.txt` fichier. Pour exécuter l'utilitaire Amazon MWAA CLI, reportez-vous à [aws-mwaa-docker-images](https://github.com/aws/amazon-mwaa-docker-images)on GitHub.
1. **Consultez les suppléments du package Apache Airflow**. Pour accéder à la liste des packages installés pour Apache Airflow v3 sur Amazon MWAA, consultez le site Web. [aws-mwaa-docker-images `requirements.txt`](https://github.com/aws/amazon-mwaa-docker-images/blob/main/requirements.txt) GitHub
1. **Ajoutez une déclaration de contraintes**. Ajoutez le fichier de contraintes pour votre environnement Apache Airflow v3 en haut de votre fichier. `requirements.txt` Les fichiers de contraintes d'Apache Airflow spécifient les versions des fournisseurs disponibles au moment de la publication d'Apache Airflow.
Dans l'exemple suivant, remplacez *\$1environment-version\$1* par le numéro de version de votre environnement et *\$1Python-version\$1* par la version de Python compatible avec votre environnement.
Pour plus d'informations sur la version de Python compatible avec votre environnement Apache Airflow, reportez-vous à la section Versions d'[Apache Airflow](airflow-versions.md#airflow-versions-official).
```
--constraint "https://raw.githubusercontent.com/apache/airflow/constraints-{Airflow-version}/constraints-{Python-version}.txt"
```
Si le fichier de contraintes détermine que le `xyz==1.0` package n'est pas compatible avec les autres packages de votre environnement`pip3 install`, il n'empêche pas l'installation de bibliothèques incompatibles dans votre environnement. Si l'installation d'un package échoue, vous pouvez accéder aux journaux d'erreurs de chaque composant Apache Airflow (le planificateur, le programme de travail et le serveur Web) dans le flux de journal correspondant sur Logs. CloudWatch Pour plus d'informations sur les types de journaux, reportez-vous à[Accès aux journaux Airflow sur Amazon CloudWatch](monitoring-airflow.md).
1. **Paquets Apache Airflow**. Ajoutez les [extras du package](http://airflow.apache.org/docs/apache-airflow/2.5.1/extra-packages-ref.html) et la version (`==`). Cela permet d'éviter que des packages portant le même nom, mais dont la version est différente, ne soient installés sur votre environnement.
```
apache-airflow[package-extra]==2.5.1
```
1. **Bibliothèques Python**. Ajoutez le nom du package et la version (`==`) dans votre `requirements.txt` fichier. Cela permet d'éviter qu'une future mise à jour de rupture de [PyPi.org](https://pypi.org) ne soit automatiquement appliquée.
```
library == version
```
**Example Boto3 et psycopg2-binary**
Cet exemple est fourni à des fins de démonstration. Les bibliothèques boto et psycopg2-binary sont incluses dans l'installation de base d'Apache Airflow v3 et n'ont pas besoin d'être spécifiées dans un fichier. `requirements.txt`
```
boto3==1.17.54
boto==2.49.0
botocore==1.20.54
psycopg2-binary==2.8.6
```
[Si un package est spécifié sans version, Amazon MWAA installe la dernière version du package depuis PyPi .org.](https://pypi.org) Cette version peut entrer en conflit avec les autres packages de votre`requirements.txt`.
------
#### [ Apache Airflow v2 ]
1. **Testez localement**. Ajoutez des bibliothèques supplémentaires de manière itérative pour trouver la bonne combinaison de packages et de leurs versions, avant de créer un `requirements.txt` fichier. Pour exécuter l'utilitaire Amazon MWAA CLI, reportez-vous à [aws-mwaa-docker-images](https://github.com/aws/amazon-mwaa-docker-images)on GitHub.
1. **Consultez les suppléments du package Apache Airflow**. Pour accéder à la liste des packages installés pour Apache Airflow v2 sur Amazon MWAA, rendez-vous [aws-mwaa-docker-images `requirements.txt`](https://github.com/aws/amazon-mwaa-docker-images/blob/main/requirements.txt)sur le site Web. GitHub
1. **Ajoutez une déclaration de contraintes**. Ajoutez le fichier de contraintes pour votre environnement Apache Airflow v2 en haut de votre `requirements.txt` fichier. Les fichiers de contraintes d'Apache Airflow spécifient les versions des fournisseurs disponibles au moment de la publication d'Apache Airflow.
À partir de la version 2.7.2 d'Apache Airflow, votre fichier d'exigences doit inclure une déclaration. `--constraint` Si vous ne fournissez aucune contrainte, Amazon MWAA vous en indiquera une afin de garantir que les packages répertoriés dans vos exigences sont compatibles avec la version d'Apache Airflow que vous utilisez.
Dans l'exemple suivant, remplacez *\$1environment-version\$1* par le numéro de version de votre environnement et *\$1Python-version\$1* par la version de Python compatible avec votre environnement.
Pour plus d'informations sur la version de Python compatible avec votre environnement Apache Airflow, reportez-vous à la section Versions d'[Apache Airflow](airflow-versions.md#airflow-versions-official).
```
--constraint "https://raw.githubusercontent.com/apache/airflow/constraints-{Airflow-version}/constraints-{Python-version}.txt"
```
Si le fichier de contraintes détermine que le `xyz==1.0` package n'est pas compatible avec les autres packages de votre environnement`pip3 install`, il n'empêche pas l'installation de bibliothèques incompatibles dans votre environnement. Si l'installation d'un package échoue, vous pouvez accéder aux journaux d'erreurs de chaque composant Apache Airflow (le planificateur, le programme de travail et le serveur Web) dans le flux de journal correspondant sur Logs. CloudWatch Pour plus d'informations sur les types de journaux, reportez-vous à[Accès aux journaux Airflow sur Amazon CloudWatch](monitoring-airflow.md).
1. **Paquets Apache Airflow**. Ajoutez les [extras du package](http://airflow.apache.org/docs/apache-airflow/2.5.1/extra-packages-ref.html) et la version (`==`). Cela permet d'éviter que des packages portant le même nom, mais dont la version est différente, ne soient installés sur votre environnement.
```
apache-airflow[package-extra]==2.5.1
```
1. **Bibliothèques Python**. Ajoutez le nom du package et la version (`==`) dans votre `requirements.txt` fichier. Cela permet d'éviter qu'une future mise à jour de rupture de [PyPi.org](https://pypi.org) ne soit automatiquement appliquée.
```
library == version
```
**Example Boto3 et psycopg2-binary**
Cet exemple est fourni à des fins de démonstration. Les bibliothèques boto et psycopg2-binary sont incluses dans l'installation de base d'Apache Airflow v2 et n'ont pas besoin d'être spécifiées dans un fichier. `requirements.txt`
```
boto3==1.17.54
boto==2.49.0
botocore==1.20.54
psycopg2-binary==2.8.6
```
[Si un package est spécifié sans version, Amazon MWAA installe la dernière version du package depuis PyPi .org.](https://pypi.org) Cette version peut entrer en conflit avec les autres packages de votre`requirements.txt`.
------
### Deuxième option : roues Python (.whl)
Une roue Python est un format de package conçu pour expédier des bibliothèques contenant des artefacts compilés. Les packages Wheel présentent plusieurs avantages en tant que méthode d'installation de dépendances dans Amazon MWAA :
+ **Installation plus rapide** : les fichiers WHL sont copiés dans le conteneur sous la forme d'un seul fichier ZIP, puis installés localement, sans qu'il soit nécessaire de les télécharger.
+ **Moins de conflits** : vous pouvez déterminer à l'avance la compatibilité des versions de vos packages. Par conséquent, il n'est pas nécessaire de trouver `pip` de manière récursive des versions compatibles.
+ **Plus de résilience** : avec les bibliothèques hébergées en externe, les exigences en aval peuvent changer, ce qui entraîne une incompatibilité des versions entre les conteneurs d'un environnement Amazon MWAA. En ne dépendant pas d'une source externe pour les dépendances, chaque conteneur possède les mêmes bibliothèques, quel que soit le moment où chaque conteneur est instancié.
Nous recommandons les méthodes suivantes pour installer les dépendances Python à partir d'une archive Python Wheel (`.whl`) dans votre`requirements.txt`.
**Topics**
+ [Utilisation du `plugins.zip` fichier dans un compartiment Amazon S3](#best-practices-dependencies-python-wheels-s3)
+ [Utilisation d'un fichier WHL hébergé sur une URL](#best-practices-dependencies-python-wheels-url)
+ [Création d'un fichier WHL à partir d'un DAG](#best-practices-dependencies-python-wheels-dag)
#### Utilisation du `plugins.zip` fichier dans un compartiment Amazon S3
Le planificateur, les outils de traitement et le serveur Web d'Apache Airflow (pour Apache Airflow v2.2.2 et versions ultérieures) recherchent des plugins personnalisés lors du démarrage sur le conteneur Fargate géré pour votre environnement à l'adresse. AWS`/usr/local/airflow/plugins/*` Ce processus commence avant Amazon MWAA `pip3 install -r requirements.txt` pour les dépendances Python et le démarrage du service Apache Airflow. Un `plugins.zip` fichier peut être utilisé pour tous les fichiers que vous ne souhaitez pas modifier en permanence pendant l'exécution de l'environnement ou pour lesquels vous ne souhaitez pas accorder l'accès aux utilisateurs qui écrivent DAGs. Par exemple, les fichiers de roue de la bibliothèque Python, les fichiers PEM de certificats et les fichiers de configuration YAML.
La section suivante décrit comment installer une roue qui se trouve dans le `plugins.zip` fichier de votre compartiment Amazon S3.
1. **Téléchargez les fichiers WHL nécessaires** Vous pouvez les utiliser [https://pip.pypa.io/en/stable/cli/pip_download/](https://pip.pypa.io/en/stable/cli/pip_download/)avec votre conteneur Amazon MWAA existant [aws-mwaa-docker-images](https://github.com/aws/amazon-mwaa-docker-images)ou `requirements.txt` sur un autre conteneur [Amazon Linux 2](https://aws.amazon.com/amazon-linux-2) pour résoudre et télécharger les fichiers Python Wheel nécessaires.
```
pip3 download -r "$AIRFLOW_HOME/dags/requirements.txt" -d "$AIRFLOW_HOME/plugins"
cd "$AIRFLOW_HOME/plugins"
zip "$AIRFLOW_HOME/plugins.zip" *
```
1. **Spécifiez le chemin dans votre `requirements.txt`**. Spécifiez le répertoire des plugins en haut de votre fichier requirements.txt en utilisant [https://pip.pypa.io/en/stable/cli/pip_install/#install-find-links](https://pip.pypa.io/en/stable/cli/pip_install/#install-find-links)et demandez de `pip` ne pas les installer à partir d'autres sources en utilisant [https://pip.pypa.io/en/stable/cli/pip_install/#install-no-index](https://pip.pypa.io/en/stable/cli/pip_install/#install-no-index), comme indiqué dans le code suivant :
```
--find-links /usr/local/airflow/plugins
--no-index
```
**Example roue dans requirements.txt**
L'exemple suivant suppose que vous avez chargé la roue dans un `plugins.zip` fichier à la racine de votre compartiment Amazon S3. Par exemple :
```
--find-links /usr/local/airflow/plugins
--no-index
numpy
```
Amazon MWAA récupère la `numpy-1.20.1-cp37-cp37m-manylinux1_x86_64.whl` roue `plugins` dans le dossier et l'installe dans votre environnement.
#### Utilisation d'un fichier WHL hébergé sur une URL
La section suivante décrit comment installer une roue hébergée sur une URL. L'URL doit être accessible au public ou accessible depuis le VPC Amazon personnalisé que vous avez spécifié pour votre environnement Amazon MWAA.
+ **Fournissez une URL**. Fournissez l'URL d'une roue dans votre`requirements.txt`.
**Example archive de roues sur une URL publique**
L'exemple suivant télécharge une roue depuis un site public.
```
--find-links https://files.pythonhosted.org/packages/
--no-index
```
Amazon MWAA récupère la roue à partir de l'URL que vous avez spécifiée et l'installe dans votre environnement.
**Note**
URLs ne sont pas accessibles à partir de serveurs Web privés, exigences d'installation dans Amazon MWAA v2.2.2 et versions ultérieures.
#### Création d'un fichier WHL à partir d'un DAG
Si vous avez un serveur Web privé utilisant Apache Airflow v2.2.2 ou version ultérieure et que vous ne parvenez pas à installer les exigences car votre environnement n'a pas accès à des référentiels externes, vous pouvez utiliser le DAG suivant pour prendre vos exigences Amazon MWAA existantes et les intégrer à Amazon S3 :
```
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}"
)
```
Après avoir exécuté le DAG, utilisez ce nouveau fichier comme Amazon MWAA`plugins.zip`, éventuellement, empaqueté avec d'autres plugins. Ensuite, mettez à jour votre `requirements.txt` liste précédée par `--find-links /usr/local/airflow/plugins` `--no-index` ou sans ajout`--constraint`.
Vous pouvez utiliser cette méthode pour utiliser les mêmes bibliothèques hors ligne.
### Troisième option : dépendances Python hébergées sur un dépôt privé conforme à PyPi /PEP-503
La section suivante décrit comment installer un Apache Airflow extra hébergé sur une URL privée avec authentification.
1. Ajoutez votre nom d'utilisateur et votre mot de passe comme options de [configuration d'Apache Airflow](configuring-env-variables.md). Par exemple :
+ `foo.user` : `YOUR_USER_NAME`
+ `foo.pass` : `YOUR_PASSWORD`
1. Créez votre `requirements.txt` dossier. Dans l'exemple suivant, remplacez les espaces réservés par votre URL privée, ainsi que par le nom d'utilisateur et le mot de passe que vous avez ajoutés comme options de configuration d'[Apache Airflow](configuring-env-variables.md). Par exemple :
```
--index-url https://${AIRFLOW__FOO__USER}:${AIRFLOW__FOO__PASS}@my.privatepypi.com
```
1. Ajoutez des bibliothèques supplémentaires à votre `requirements.txt` fichier. Par exemple :
```
--index-url https://${AIRFLOW__FOO__USER}:${AIRFLOW__FOO__PASS}@my.privatepypi.com
my-private-package==1.2.3
```
## Activation des journaux sur la console Amazon MWAA
Le [rôle d'exécution](mwaa-create-role.md) de votre environnement Amazon MWAA nécessite une autorisation pour envoyer des CloudWatch journaux à Logs. Pour mettre à jour les autorisations d'un rôle d'exécution, reportez-vous à[Rôle d'exécution Amazon MWAA](mwaa-create-role.md).
Vous pouvez activer les journaux Apache Airflow au niveau`INFO`, `WARNING``ERROR`, ou`CRITICAL`. Lorsque vous choisissez un niveau de journalisation, Amazon MWAA envoie des journaux correspondant à ce niveau et à tous les niveaux de gravité supérieurs. Par exemple, si vous activez les journaux au `INFO` niveau, Amazon MWAA envoie `INFO` les journaux et `WARNING` les niveaux de `CRITICAL` journalisation à CloudWatch Logs. `ERROR` Nous recommandons d'activer les journaux Apache Airflow au `INFO` niveau du planificateur afin qu'il puisse accéder aux journaux reçus pour le. `requirements.txt`
![\[Cette image montre comment activer les journaux au niveau INFO.\]](http://docs.aws.amazon.com/fr_fr/mwaa/latest/userguide/images/mwaa-console-logs-info.png)
## Accès aux journaux sur la console CloudWatch Logs
Vous pouvez accéder aux journaux d'Apache Airflow pour le planificateur qui planifie vos flux de travail et analyse votre dossier. `dags` Les étapes suivantes décrivent comment ouvrir le groupe de journaux pour le planificateur sur la console Amazon MWAA et accéder aux journaux Apache Airflow sur la console Logs. CloudWatch
**Pour accéder aux journaux d'un `requirements.txt`**
1. Ouvrez la page [Environnements](https://console.aws.amazon.com/mwaa/home#/environments) sur la console Amazon MWAA.
1. Choisissez un environnement.
1. **Choisissez le **groupe de journaux du planificateur Airflow** dans le volet de surveillance.**
1. Choisissez le `requirements_install_ip` **log in Log streams**.
1. Reportez-vous à la liste des packages installés sur l'environnement à l'adresse`/usr/local/airflow/.local/bin`. Par exemple :
```
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. Consultez la liste des packages et vérifiez si l'un d'entre eux a rencontré une erreur lors de l'installation. En cas de problème, vous pouvez obtenir un message d'erreur similaire à ce qui suit :
```
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))
```
## Erreurs d'accès dans l'interface utilisateur d'Apache Airflow
Vous pouvez également vérifier l'interface utilisateur d'Apache Airflow pour déterminer si une erreur est liée à un autre problème. L'erreur la plus courante que vous pouvez rencontrer avec Apache Airflow sur Amazon MWAA est la suivante :
```
Broken DAG: No module named x
```
Si vous trouvez cette erreur dans l'interface utilisateur d'Apache Airflow, il vous manque probablement une dépendance requise dans votre `requirements.txt` fichier.
### Connectez-vous à Apache Airflow
Vous avez besoin d'[Politique d'accès à l'interface utilisateur d'Apache Airflow : Amazon MWAAWeb ServerAccess](access-policies.md#web-ui-access)autorisations pour que votre Compte AWS identifiant Gestion des identités et des accès AWS (IAM) puisse accéder à votre interface utilisateur Apache Airflow.
**Pour accéder à votre interface utilisateur Apache Airflow**
1. Ouvrez la page [Environnements](https://console.aws.amazon.com/mwaa/home#/environments) sur la console Amazon MWAA.
1. Choisissez un environnement.
1. Choisissez **Open Airflow UI**.
## Exemples de `requirements.txt` scénarios
Vous pouvez mélanger et assortir différents formats dans votre`requirements.txt`. L'exemple suivant utilise une combinaison des différentes méthodes pour installer des options supplémentaires.
**Example Des suppléments sur PyPi .org et une URL publique**
Vous devez utiliser `--index-url` cette option lorsque vous spécifiez des packages provenant de PyPi .org, en plus des packages sur une URL publique, tels que le dépôt URLs personnalisé conforme à la norme PEP 503.
```
aws-batch == 0.6
phoenix-letter >= 0.3
--index-url http://dist.repoze.org/zope2/2.10/simple
zopelib
```