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. # AWS Glue fin du support pour Ray **Important** AWS Glue for Ray ne sera plus ouvert aux nouveaux clients à compter du 30 avril 2026. Si vous souhaitez utiliser AWS Glue for Ray, inscrivez-vous avant cette date. Les clients existants peuvent continuer à utiliser le service normalement. Pour des fonctionnalités similaires à celles de AWS Glue for Ray, explorez Amazon EKS. Pour plus d'informations, consultez la section [AWS Glue relative à la fin du support de Ray](https://docs.aws.amazon.com/glue/latest/dg/awsglue-ray-jobs-availability-change.html). Après mûre réflexion, nous avons décidé de fermer AWS Glue les portes de Ray à de nouveaux clients à compter du 30 avril 2026. Si vous souhaitez utiliser AWS Glue for Ray, inscrivez-vous avant cette date. Les clients existants peuvent continuer à utiliser le service normalement. AWS continue d'investir dans l'amélioration de la sécurité et de la disponibilité AWS Glue pour for Ray. Notez que nous ne prévoyons pas d'introduire de nouvelles fonctionnalités dans AWS Glue for Ray, à l'exception des améliorations de sécurité et de disponibilité. Comme alternative à AWS Glue for Ray, nous vous recommandons d'utiliser Amazon Elastic Kubernetes Service. Amazon Elastic Kubernetes Service est un service entièrement géré et certifié conforme à Kubernetes qui simplifie le processus de création, de sécurisation, d'exploitation et de maintenance de clusters Kubernetes sur. AWS Il s'agit d'une option hautement personnalisable qui repose sur l'open source KubeRay Operator pour déployer et gérer les clusters Ray sur Kubernetes, offrant une meilleure utilisation des ressources, une gestion simplifiée de l'infrastructure et un support complet des fonctionnalités Ray. ## Migration d'une tâche Ray vers Amazon Elastic Kubernetes Service Cette section décrit les étapes de migration de AWS Glue for Ray vers Ray sur Amazon Elastic Kubernetes Service. Ces étapes sont utiles pour deux scénarios de migration : + **Migration standard (x86/amd64)** : pour ces cas d'utilisation, la stratégie de migration utilise le conteneur OpenSource Ray pour les implémentations de base et exécute les scripts directement sur le conteneur de base. + **ARM64 Migration** : pour ces cas d'utilisation, la stratégie de migration prend en charge les versions de conteneurs personnalisées pour ARM64 des dépendances et des exigences d'architecture spécifiques. ### Conditions préalables à la migration Installez les outils CLI suivants :**aws**,,**kubectl**, **eksctl****helm**, Python 3.9\$1. Ces outils CLI sont nécessaires pour provisionner et gérer votre environnement Ray on EKS. **eksctl**simplifie la création et la gestion de clusters EKS. **kubectl**est la CLI Kubernetes standard pour le déploiement et le dépannage des charges de travail sur votre cluster. **helm**est utilisé pour installer et gérer KubeRay (l'opérateur qui exécute Ray sur Kubernetes). Python 3.9\$1 est requis pour Ray lui-même et pour exécuter des scripts de soumission de tâches localement. #### Installer eksctl Suivez les instructions des [options d'installation pour Eksctl](https://docs.aws.amazon.com/eks/latest/eksctl/installation.html) ou utilisez les instructions ci-dessous pour l'installation. Pour Mac OS : ``` brew tap weaveworks/tap brew install weaveworks/tap/eksctl ``` Pour Linux : ``` curl --silent --location "https://github.com/weaveworks/eksctl/releases/latest/download/eksctl_$(uname -s)_amd64.tar.gz" | tar xz -C /tmp # Move the extracted binary to /usr/local/bin sudo mv /tmp/eksctl /usr/local/bin # Test the installation eksctl version ``` #### Installer kubectl Suivez les instructions de la section [Configurer kubectl et eksctl](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html) ou utilisez les instructions ci-dessous pour l'installation. Pour Mac OS : ``` brew install kubectl ``` Pour Linux : ``` curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl" chmod +x kubectl sudo mv kubectl /usr/local/bin/ ``` #### Installer le casque Suivez les instructions d'[installation de Helm](https://helm.sh/docs/intro/install/) ou utilisez les instructions ci-dessous pour l'installation. Pour Mac OS : ``` brew install helm ``` Pour Linux : ``` curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash ``` ### Étape 1. Créez ou choisissez une image Docker pour Ray **Option 1 : utiliser l'image officielle de Ray (aucune compilation requise)** Cette option utilise l'image officielle de Ray Docker sur [Docker Hub](https://hub.docker.com/u/rayproject), par exemple`rayproject/ray:2.4.0-py39`, qui est maintenue par le projet Ray. **Note** Cette image est uniquement destinée à AMD64. Utilisez-le si vos dépendances sont compatibles avec amd64 et que vous n'avez pas besoin de versions spécifiques à ARM. **Option 2 : créez et publiez votre propre image arm64 Ray 2.4.0** Cette option est utile lorsque vous utilisez des nœuds Graviton (ARM), conformément à ce que AWS Glue Ray utilise en interne. Vous pouvez créer une image personnalisée épinglée aux mêmes versions de dépendance que AWS Glue pour Ray, afin de réduire les incompatibilités. Créez un Dockerfile localement : ``` # Build an ARM64 image FROM --platform=linux/arm64 python:3.9-slim-bullseye # Handy tools: wget for KubeRay probes; CA certs; keep image small RUN apt-get update && apt-get install -y --no-install-recommends \ wget ca-certificates \ && rm -rf /var/lib/apt/lists/* # Keep pip/setuptools modern enough for wheels resolution RUN python -m pip install -U "pip<24" "setuptools<70" wheel # ---- Install Ray 2.4.0 (ARM64 / Py3.9) and Glue-like dependencies ---- # 1) Download the exact Ray 2.4.0 wheel for aarch64 (no network at runtime) RUN python -m pip download --only-binary=:all: --no-deps --dest /tmp/wheels ray==2.4.0 # 2) Core libs used in Glue (pin to Glue-era versions) # + the dashboard & jobs API dependencies compatible with Ray 2.4.0. # (Pins matter: newer major versions break 2.4.0's dashboard.) RUN python -m pip install --no-cache-dir \ /tmp/wheels/ray-2.4.0-*.whl \ "pyarrow==11.0.0" \ "pandas==1.5.3" \ "boto3==1.26.133" \ "botocore==1.29.133" \ "numpy==1.24.3" \ "fsspec==2023.4.0" \ "protobuf<4" \ # --- dashboard / jobs server deps --- "aiohttp==3.8.5" \ "aiohttp-cors==0.7.0" \ "yarl<1.10" "multidict<7.0" "frozenlist<1.4" "aiosignal<1.4" "async_timeout<5" \ "pydantic<2" \ "opencensus<0.12" \ "prometheus_client<0.17" \ # --- needed if using py_modules --- "smart_open[s3]==6.4.0" # Optional: prove Ray & arch at container start ENV PYTHONUNBUFFERED=1 WORKDIR /app # KubeRay overrides the start command; this is just a harmless default CMD ["python","-c","import ray,platform; print('Ray', ray.__version__, 'on', platform.machine())"] ``` ``` # Set environment variables export AWS_REGION=us-east-1 export AWS_ACCOUNT=$(aws sts get-caller-identity --query Account --output text) export REPO=ray-2-4-arm64 export IMAGE=${AWS_ACCOUNT}.dkr.ecr.${AWS_REGION}.amazonaws.com/${REPO}:v1 # Create repository and login aws ecr create-repository --repository-name $REPO >/dev/null 2>&1 || true aws ecr get-login-password --region $AWS_REGION \ | docker login --username AWS --password-stdin ${AWS_ACCOUNT}.dkr.ecr.${AWS_REGION}.amazonaws.com # Enable Buildx (for cross-builds on non-ARM hosts) docker buildx create --name multi --driver docker-container --use 2>/dev/null || true # Build & push ARM64 image docker buildx build \ --platform linux/arm64 \ -t "$IMAGE" \ . --push # Verify the image architecture remotely aws ecr batch-get-image \ --repository-name $REPO \ --image-ids imageTag=v1 \ --accepted-media-types application/vnd.docker.distribution.manifest.v2+json \ | jq -r '.images[0].imageManifest' \ | jq -r 'fromjson.config.digest' ``` Une fois terminé, référencez cette ARM64 image dans les RayCluster spécifications avec`nodeSelector: { kubernetes.io/arch: arm64 }`. ``` spec: rayVersion: "2.4.0" headGroupSpec: template: spec: containers: - name: ray-head image: ``` ### Étape 2. Convertir AWS Glue la configuration de for Ray Job en Ray sur Amazon Elastic Kubernetes Service AWS Glue les tâches for Ray prennent en charge un ensemble d'arguments de tâche qui configurent les travailleurs, les dépendances, la mémoire et la journalisation. Lors de la migration vers Amazon Elastic Kubernetes KubeRay Service with, ces arguments doivent être RayCluster traduits en champs de spécification ou en paramètres d'environnement d'exécution Ray Job. #### Cartographie des arguments du poste **Cartographie AWS Glue des arguments de Ray avec les équivalents de Ray sur EKS** | AWS Glue pour Ray argument | Ce que cela apporte AWS Glue à Ray | Ray sur l'équivalent d'Amazon Elastic Kubernetes Service | | --- | --- | --- | | --min-workers | Nombre minimum de travailleurs que le poste doit affecter. | workerGroupSpecs[].minReplicasdans votre RayCluster | | --working-dir | Distribue un zip (URI S3) à tous les nœuds. | Utilisez Ray Runtime Env : working\$1dir si vous soumettez à partir de fichiers locaux ; py\$1modules pour que les zips S3 pointent vers l'artefact S3 | | --s3-py-modules | Ajoute Python wheels/dists à partir de S3. | Utilisez Ray Runtime Env : py\$1modules: ["s3://.../xxx.whl", ...] | | --pip-install | Installe des packages PyPI supplémentaires pour le travail. | Environnement d'exécution Ray : pip: ["pkg==ver", ...] (Ray Job CLI --runtime-env-json ou RayJobruntimeEnvYAML). | | --object\$1store\$1memory\$1head | % de mémoire pour le magasin de plasma du nœud principal. | headGroupSpec[].rayStartParams.object-store-memorydans votre RayCluster. Notez que cela doit être exprimé en octets. AWS Glue utilise un pourcentage, tandis que Ray utilise des octets. | | --object\$1store\$1memory\$1worker | % de mémoire pour le stockage de plasma des nœuds de travail. | Identique à celui ci-dessus mais défini dans celui de chaque groupe de travail rayStartParams.object-store-memory (octets). | | --object\$1spilling\$1config | Configurez le déversement d'objets Ray. | headGroupSpec[].rayStartParams.object-spilling-config | | --logging\$1configuration | AWS Glue-journaux gérés (CloudWatch, S3). | Vérifiez pod stdout/stderr : utiliser. kubectl -n ray logs --follow Consultez les journaux depuis Ray Dashboard (transfert de port vers : 8265), vous pouvez également y consulter les journaux des tâches et des tâches. | #### Cartographie de la configuration des tâches **Cartographie AWS Glue des configurations Ray Job avec les équivalents Ray on EKS** | Configuration | Ce que cela apporte AWS Glue à Ray | Ray sur l'équivalent EKS | | --- | --- | --- | | Type d’employé | Définissez le type de travailleur prédéfini autorisé lors de l'exécution d'une tâche. La valeur par défaut est Z 2X (8vCPU, 64 Go de RAM). | Type d'instance de groupe de nœuds dans EKS (par exemple, r7g.2xlarge ≈ 8 vCPU /64 Go pour ARM, r7a.2xlarge pour x86). | | Nombre maximum de travailleurs | Le nombre de travailleurs que vous AWS Glue souhaitez affecter à cette tâche. | Réglez workerGroupSpecs[].maxReplicas le même numéro que celui dans lequel vous l'avez utilisé AWS Glue. Il s'agit de la limite supérieure de la mise à l'échelle automatique. Défini de la même manière minReplicas comme limite inférieure. Vous pouvez commencer parreplicas: 0,minReplicas: 0. | ### Étape 3. Configuration d'Amazon Elastic Kubernetes Service Vous pouvez soit créer un nouveau cluster Amazon Elastic Kubernetes Service, soit réutiliser un cluster Amazon Elastic Kubernetes Service existant. Si vous utilisez un cluster existant, ignorez les commandes de création de cluster et passez à Ajouter un groupe de nœuds, IRSA, et installez KubeRay. #### Création d'un cluster Amazon Elastic Kubernetes Service **Note** Si vous possédez déjà un cluster Amazon Elastic Kubernetes Service, ignorez les commandes pour créer un nouveau cluster et ajoutez simplement un groupe de nœuds. ``` # Environment Variables export AWS_REGION=us-east-1 export CLUSTER=ray-eks export NS=ray # namespace for your Ray jobs (you can reuse another if you like) # Create a cluster (OIDC is required for IRSA) eksctl create cluster \ --name $CLUSTER \ --region $AWS_REGION \ --with-oidc \ --managed ``` #### Ajouter un groupe de nœuds ``` # ARM/Graviton (matches Glue's typical runtime): eksctl create nodegroup \ --cluster $CLUSTER \ --region $AWS_REGION \ --name arm64-ng \ --node-type m7g.large \ --nodes 2 --nodes-min 1 --nodes-max 5 \ --managed \ --node-labels "workload=ray" # x86/amd64 (use if your image is amd64-only): eksctl create nodegroup \ --cluster $CLUSTER \ --region $AWS_REGION \ --name amd64-ng \ --node-type m5.large \ --nodes 2 --nodes-min 1 --nodes-max 5 \ --managed \ --node-labels "workload=ray" ``` **Note** Si vous utilisez un cluster Amazon Elastic Kubernetes Service existant, `--with-oidc` utilisez-le pour activer OIDC lors de l'ajout d'un groupe de nœuds. #### Créer un espace de noms et un rôle IAM pour les comptes de service (IRSA) pour S3 Un espace de noms Kubernetes est un regroupement logique de ressources (pods, services, rôles, etc.). Vous pouvez créer ou réutiliser un espace de noms existant. Vous devrez également créer une politique IAM pour S3 qui reflète l'accès à votre AWS Glue tâche. Utilisez les mêmes autorisations personnalisées que celles dont bénéficiait votre AWS Glue rôle professionnel (généralement S3 read/write pour des compartiments spécifiques). Pour accorder des autorisations similaires à Amazon Elastic Kubernetes Service, créez un compte de service (IRSA) lié à AWSGlue ServiceRole cette politique IAM. Reportez-vous à la section [Rôles IAM pour les comptes de service](https://docs.aws.amazon.com/eks/latest/eksctl/iamserviceaccounts.html) pour obtenir des instructions sur la configuration de ce compte de service. ``` # Create (or reuse) namespace kubectl create namespace $NS || true ``` ``` { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": ["s3:PutObject", "s3:GetObject", "s3:ListBucket"], "Resource": [ "arn:aws:s3:::YOUR-BUCKET", "arn:aws:s3:::YOUR-BUCKET/*" ] }] } ``` ``` # Create the IAM policy and wire IRSA: aws iam create-policy \ --policy-name RayS3Policy \ --policy-document file://example.json || true # Create a service account (IRSA) bound to that policy. eksctl create iamserviceaccount \ --cluster $CLUSTER \ --region $AWS_REGION \ --namespace $NS \ --name ray-s3-access \ --attach-policy-arn arn:aws:iam::${AWS_ACCOUNT}:policy/RayS3Policy \ --approve \ --override-existing-serviceaccounts ``` #### KubeRay Opérateur d'installation (contrôleur qui exécute Ray sur K8s) ``` helm repo add kuberay https://ray-project.github.io/kuberay-helm/ helm repo update helm upgrade --install kuberay-operator kuberay/kuberay-operator \ --namespace kuberay-system \ --create-namespace # Validate the operator pod Running kubectl -n kuberay-system get pods ``` ### Étape 4 : Créez un cluster de rayons Créez un fichier YAML pour définir le cluster de rayons. Voici un exemple de configuration (raycluster.yaml) : ``` apiVersion: ray.io/v1 kind: RayCluster metadata: name: glue-like namespace: ray spec: rayVersion: "2.4.0" headGroupSpec: template: spec: nodeSelector: kubernetes.io/arch: amd64 serviceAccountName: ray-s3-access containers: - name: ray-head image: rayproject/ray:2.4.0-py39 imagePullPolicy: Always resources: requests: { cpu: "1", memory: "2Gi" } limits: { cpu: "1", memory: "2Gi" } workerGroupSpecs: - groupName: workers replicas: 0 # start with just a head (like small Glue dev job) and turn number of replicas later minReplicas: 0 maxReplicas: 5 template: spec: nodeSelector: kubernetes.io/arch: amd64 serviceAccountName: ray-s3-access containers: - name: ray-worker image: rayproject/ray:2.4.0-py39 imagePullPolicy: Always resources: requests: { cpu: "1", memory: "2Gi" } limits: { cpu: "1", memory: "2Gi" } ``` #### Déployez le cluster Ray sur le cluster Amazon Elastic Kubernetes Service ``` kubectl apply -n $NS -f raycluster.yaml # Validate that the head pod turns to READY/ RUNNING state kubectl -n $NS get pods -l ray.io/cluster=glue-like -w ``` S'il est nécessaire de modifier le yaml déployé, supprimez d'abord le cluster, puis réappliquez le yaml mis à jour : ``` kubectl -n $NS delete raycluster glue-like kubectl -n $NS apply -f raycluster.yaml ``` #### Accès au tableau de bord Ray Vous pouvez accéder au tableau de bord Ray en activant le transfert de port à l'aide de kubectl : ``` # Get service SVC=$(kubectl -n $NS get svc -l ray.io/cluster=glue-like,ray.io/node-type=head -o jsonpath='{.items[0].metadata.name}') # Make the Ray dashboard accessible at http://localhost:8265 on your local machine. kubectl -n $NS port-forward svc/$SVC 8265:8265 ``` ### Étape 5. Soumettre Ray Job Pour soumettre une tâche Ray, utilisez la CLI Ray jobs. La version de la CLI peut être plus récente que le cluster, elle est rétrocompatible. Comme condition préalable, stockez votre script de tâche localement dans un fichier, par exemple `job.py` ``` python3 -m venv ~/raycli && source ~/raycli/bin/activate pip install "ray[default]==2.49.2" # Submit your ray job by supplying all python dependencies that was added to your Glue job ray job submit --address http://127.0.0.1:8265 --working-dir . \ --runtime-env-json '{ "pip": ["boto3==1.28.*","pyarrow==12.*","pandas==2.0.*"] }' \ -- python job.py ``` La tâche peut être surveillée sur le tableau de bord Ray.