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. # Utilisation d'Amazon MWAA avec Amazon EKS L'exemple suivant montre comment utiliser Amazon Managed Workflows pour Apache Airflow avec Amazon EKS. **Topics** + [Version](#mwaa-eks-example-version) + [Conditions préalables](#eksctl-prereqs) + [Création d'une clé publique pour Amazon EC2](#eksctl-create-key) + [Créer le cluster](#create-cluster-eksctl) + [Création d'un espace `mwaa` de noms](#eksctl-namespace) + [Création d'un rôle pour l'espace de `mwaa` noms](#eksctl-role) + [Création et attachement d'un rôle IAM pour le cluster Amazon EKS](#eksctl-iam-role) + [Créez le fichier requirements.txt](#eksctl-requirements) + [Création d'un mappage d'identité pour Amazon EKS](#eksctl-identity-map) + [Créer le `kubeconfig`](#eksctl-kube-config) + [Création d'un DAG](#eksctl-create-dag) + [Ajoutez le DAG et `kube_config.yaml` au compartiment Amazon S3](#eksctl-dag-bucket) + [Activer et déclencher l'exemple](#eksctl-trigger-pod) ## Version [Vous pouvez utiliser l'exemple de code présenté sur cette page avec **Apache Airflow v2** en [Python 3.10](https://peps.python.org/pep-0619/) et **Apache Airflow v3** en Python 3.11.](https://peps.python.org/pep-0664/) ## Conditions préalables Pour utiliser l'exemple présenté dans cette rubrique, vous aurez besoin des éléments suivants : + Un [environnement Amazon MWAA.](get-started.md) + eksctl. Pour en savoir plus, reportez-vous à la section [Installer eksctl](https://docs.aws.amazon.com/eks/latest/userguide/getting-started-eksctl.html#install-eksctl). + kubectl. Pour en savoir plus, reportez-vous à [Installer et configurer kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/). Dans certains cas, cela est installé avec eksctl. + Une paire de clés EC2 dans la région où vous créez votre environnement Amazon MWAA. Pour en savoir plus, reportez-vous à la section [Création ou importation d'une paire de clés](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html#prepare-key-pair). **Note** Lorsque vous utilisez une `eksctl` commande, vous pouvez inclure un `--profile` pour spécifier un profil autre que le profil par défaut. ## Création d'une clé publique pour Amazon EC2 Utilisez la commande suivante pour créer une clé publique à partir de votre paire de clés privées. ``` ssh-keygen -y -f myprivatekey.pem > mypublickey.pub ``` Pour en savoir plus, reportez-vous à la section [Récupération de la clé publique de votre paire de clés](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html#retrieving-the-public-key). ## Créer le cluster Utilisez la commande suivante pour créer le cluster. Si vous souhaitez donner un nom personnalisé au cluster ou le créer dans une autre région, remplacez le nom et les valeurs de région. Vous devez créer le cluster dans la même région que celle dans laquelle vous créez l'environnement Amazon MWAA. Remplacez les valeurs des sous-réseaux pour qu'elles correspondent aux sous-réseaux de votre réseau Amazon VPC que vous utilisez pour Amazon MWAA. Remplacez la valeur de pour `ssh-public-key` qu'elle corresponde à la clé que vous utilisez. Vous pouvez utiliser une clé existante d'Amazon EC2 qui se trouve dans la même région, ou créer une nouvelle clé dans la même région où vous créez votre environnement Amazon MWAA. ``` eksctl create cluster \ --name mwaa-eks \ --region us-west-2 \ --version 1.18 \ --nodegroup-name linux-nodes \ --nodes 3 \ --nodes-min 1 \ --nodes-max 4 \ --with-oidc \ --ssh-access \ --ssh-public-key MyPublicKey \ --managed \ --vpc-public-subnets "subnet-11111111111111111, subnet-2222222222222222222" \ --vpc-private-subnets "subnet-33333333333333333, subnet-44444444444444444" ``` La création du cluster prend un certain temps. Une fois terminé, vous pouvez vérifier que le cluster a été créé correctement et que le fournisseur IAM OIDC est configuré à l'aide de la commande suivante : ``` eksctl utils associate-iam-oidc-provider \ --region us-west-2 \ --cluster mwaa-eks \ --approve ``` ## Création d'un espace `mwaa` de noms Après avoir confirmé que le cluster a bien été créé, utilisez la commande suivante pour créer un espace de noms pour les pods. ``` kubectl create namespace mwaa ``` ## Création d'un rôle pour l'espace de `mwaa` noms Après avoir créé l'espace de noms, créez un rôle et une liaison de rôles pour un utilisateur Amazon MWAA sur EKS qui peut exécuter des pods dans un espace de noms MWAA. Si vous avez utilisé un autre nom pour l'espace de noms, remplacez mwaa `-n mwaa` par le nom que vous avez utilisé. ``` cat << EOF | kubectl apply -f - -n mwaa kind: Role apiVersion: rbac.authorization.k8s.io/v1 metadata: name: mwaa-role rules: - apiGroups: - "" - "apps" - "batch" - "extensions" resources: - "jobs" - "pods" - "pods/attach" - "pods/exec" - "pods/log" - "pods/portforward" - "secrets" - "services" verbs: - "create" - "delete" - "describe" - "get" - "list" - "patch" - "update" --- kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: mwaa-role-binding subjects: - kind: User name: mwaa-service roleRef: kind: Role name: mwaa-role apiGroup: rbac.authorization.k8s.io EOF ``` Vérifiez que le nouveau rôle peut accéder au cluster Amazon EKS en exécutant la commande suivante. Assurez-vous d'utiliser le nom correct si vous n'avez pas utilisé *mwaa* : ``` kubectl get pods -n mwaa --as mwaa-service ``` Vous recevez un message qui dit : ``` No resources found in mwaa namespace. ``` ## Création et attachement d'un rôle IAM pour le cluster Amazon EKS Vous devez créer un rôle IAM, puis le lier au cluster Amazon EKS (k8s) afin qu'il puisse être utilisé pour l'authentification via IAM. Le rôle est uniquement utilisé pour se connecter au cluster et ne dispose d'aucune autorisation pour les appels de console ou d'API. Créez un nouveau rôle pour l'environnement Amazon MWAA en suivant les étapes décrites dans[Rôle d'exécution Amazon MWAA](mwaa-create-role.md). Toutefois, au lieu de créer et de joindre les politiques décrites dans cette rubrique, associez la stratégie suivante : ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "airflow:PublishMetrics", "Resource": "arn:aws:airflow:us-east-1:111122223333:environment/${MWAA_ENV_NAME}" }, { "Effect": "Deny", "Action": "s3:ListAllMyBuckets", "Resource": [ "arn:aws:s3:::{MWAA_S3_BUCKET}", "arn:aws:s3:::{MWAA_S3_BUCKET}/*" ] }, { "Effect": "Allow", "Action": [ "s3:GetObject*", "s3:GetBucket*", "s3:List*" ], "Resource": [ "arn:aws:s3:::{MWAA_S3_BUCKET}", "arn:aws:s3:::{MWAA_S3_BUCKET}/*" ] }, { "Effect": "Allow", "Action": [ "logs:CreateLogStream", "logs:CreateLogGroup", "logs:PutLogEvents", "logs:GetLogEvents", "logs:GetLogRecord", "logs:GetLogGroupFields", "logs:GetQueryResults", "logs:DescribeLogGroups" ], "Resource": [ "arn:aws:logs:us-east-1:111122223333:log-group:airflow-${MWAA_ENV_NAME}-*" ] }, { "Effect": "Allow", "Action": "cloudwatch:PutMetricData", "Resource": "*" }, { "Effect": "Allow", "Action": [ "sqs:ChangeMessageVisibility", "sqs:DeleteMessage", "sqs:GetQueueAttributes", "sqs:GetQueueUrl", "sqs:ReceiveMessage", "sqs:SendMessage" ], "Resource": "arn:aws:sqs:us-east-1:*:airflow-celery-*" }, { "Effect": "Allow", "Action": [ "kms:Decrypt", "kms:DescribeKey", "kms:GenerateDataKey*", "kms:Encrypt" ], "NotResource": "arn:aws:kms:*:111122223333:key/*", "Condition": { "StringLike": { "kms:ViaService": [ "sqs.us-east-1.amazonaws.com" ] } } }, { "Effect": "Allow", "Action": [ "eks:DescribeCluster" ], "Resource": "arn:aws:eks:us-east-1:111122223333:cluster/${EKS_CLUSTER_NAME}" } ] } ``` ------ Après avoir créé le rôle, modifiez votre environnement Amazon MWAA pour utiliser le rôle que vous avez créé comme rôle d'exécution pour l'environnement. Pour modifier le rôle, modifiez l'environnement à utiliser. Vous sélectionnez le rôle d'exécution sous **Autorisations**. **Problèmes connus :** + Il existe un problème connu lié au fait que les rôles ARNs associés aux sous-chemins ne peuvent pas s'authentifier auprès d'Amazon EKS. La solution consiste à créer le rôle de service manuellement plutôt que d'utiliser celui créé par Amazon MWAA lui-même. Pour en savoir plus, reportez-vous à la section [Les rôles avec des chemins ne fonctionnent pas lorsque le chemin est inclus dans leur ARN dans la carte de configuration aws-auth](https://github.com/kubernetes-sigs/aws-iam-authenticator/issues/268) + Si la liste des services Amazon MWAA n'est pas disponible dans IAM, vous devez choisir une autre politique de service, telle qu'Amazon EC2, puis mettre à jour la politique de confiance du rôle pour qu'elle corresponde à ce qui suit : ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ "airflow-env.amazonaws.com", "airflow.amazonaws.com" ] }, "Action": "sts:AssumeRole" } ] } ``` ------ Pour en savoir plus, consultez [Comment utiliser les politiques de confiance avec les rôles IAM](https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles/). ## Créez le fichier requirements.txt Pour utiliser l'exemple de code présenté dans cette section, assurez-vous d'avoir ajouté l'une des options de base de données suivantes à votre`requirements.txt`. Pour en savoir plus, reportez-vous à[Installation des dépendances Python](working-dags-dependencies.md). ``` kubernetes apache-airflow[cncf.kubernetes]==3.0.0 ``` ## Création d'un mappage d'identité pour Amazon EKS Utilisez l'ARN du rôle que vous avez créé dans la commande suivante afin de créer un mappage d'identité pour Amazon EKS. Remplacez la région *us-east-1* par la région dans laquelle vous avez créé l'environnement. Remplacez l'ARN du rôle, puis remplacez-le par le *mwaa-execution-role* rôle d'exécution de votre environnement. ``` eksctl create iamidentitymapping \ --region us-east-1 \ --cluster mwaa-eks \ --arn arn:aws:iam::123456789012:role/mwaa-execution-role \ --username mwaa-service ``` ## Créer le `kubeconfig` Utilisez la commande suivante pour créer `kubeconfig` : ``` aws eks update-kubeconfig \ --region us-west-2 \ --kubeconfig ./kube_config.yaml \ --name mwaa-eks \ --alias aws ``` Si vous avez utilisé un profil spécifique lors de l'exécution, `update-kubeconfig` vous devez supprimer la `env:` section ajoutée au fichier kube\$1config.yaml afin qu'il fonctionne correctement avec Amazon MWAA. Pour ce faire, supprimez les éléments suivants du fichier, puis enregistrez-le : ``` env: - name: AWS_PROFILE value: profile_name ``` ## Création d'un DAG Utilisez l'exemple de code suivant pour créer un fichier Python, par exemple `mwaa_pod_example.py` pour le DAG. ``` """ Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved. Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. """ from airflow import DAG from datetime import datetime from airflow.providers.cncf.kubernetes.operators.kubernetes_pod import KubernetesPodOperator default_args = { 'owner': 'aws', 'depends_on_past': False, 'start_date': datetime(2019, 2, 20), 'provide_context': True } dag = DAG( 'kubernetes_pod_example', default_args=default_args, schedule_interval=None) #use a kube_config stored in s3 dags folder for now kube_config_path = '/usr/local/airflow/dags/kube_config.yaml' podRun = KubernetesPodOperator( namespace="mwaa", image="ubuntu:18.04", cmds=["bash"], arguments=["-c", "ls"], labels={"foo": "bar"}, name="mwaa-pod-test", task_id="pod-task", get_logs=True, dag=dag, is_delete_operator_pod=False, config_file=kube_config_path, in_cluster=False, cluster_context='aws' ) ``` ## Ajoutez le DAG et `kube_config.yaml` au compartiment Amazon S3 Placez le DAG que vous avez créé et le `kube_config.yaml` fichier dans le compartiment Amazon S3 pour l'environnement Amazon MWAA. Vous pouvez placer des fichiers dans votre compartiment à l'aide de la console Amazon S3 ou du AWS Command Line Interface. ## Activer et déclencher l'exemple Dans Apache Airflow, activez l'exemple, puis déclenchez-le. Une fois qu'il a été exécuté et terminé avec succès, utilisez la commande suivante pour vérifier le pod : ``` kubectl get pods -n mwaa ``` Vous obtenez un résultat similaire à ce qui suit : ``` NAME READY STATUS RESTARTS AGE mwaa-pod-test-aa11bb22cc3344445555666677778888 0/1 Completed 0 2m23s ``` Vous pouvez ensuite vérifier la sortie du pod à l'aide de la commande suivante. Remplacez la valeur du nom par la valeur renvoyée par la commande précédente : ``` kubectl logs -n mwaa mwaa-pod-test-aa11bb22cc3344445555666677778888 ```