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

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 :

Conditions préalables à la migration

Installez les outils CLI suivants :aws,,kubectl, eksctlhelm, Python 3.9+. Ces outils CLI sont nécessaires pour provisionner et gérer votre environnement Ray on EKS. eksctlsimplifie la création et la gestion de clusters EKS. kubectlest la CLI Kubernetes standard pour le déploiement et le dépannage des charges de travail sur votre cluster. helmest utilisé pour installer et gérer KubeRay (l'opérateur qui exécute Ray sur Kubernetes). Python 3.9+ 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 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 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 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, par exemplerayproject/ray:2.4.0-py39, qui est maintenue par le projet Ray.

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 avecnodeSelector: { kubernetes.io/arch: arm64 }.

spec:
  rayVersion: "2.4.0"
  headGroupSpec:
    template:
      spec:
        containers:
        - name: ray-head
          image: <your ECR 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 de la configuration des tâches

É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

# 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"

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 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.