Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

AWS Glue Ende des Supports für Ray

Nach reiflicher Überlegung haben wir beschlossen, Ray ab dem 30. April 2026 AWS Glue für Neukunden zu schließen. Wenn Sie AWS Glue For Ray nutzen möchten, melden Sie sich vor diesem Datum an. Bestandskunden können den Service weiterhin wie gewohnt nutzen.

AWS investiert weiterhin in Sicherheits- und Verfügbarkeitsverbesserungen für AWS Glue for Ray. Beachten Sie, dass wir nicht planen, neue Funktionen AWS Glue für Ray einzuführen, mit Ausnahme von Sicherheits- und Verfügbarkeitsverbesserungen.

Als Alternative zu AWS Glue for Ray empfehlen wir die Verwendung von Amazon Elastic Kubernetes Service. Amazon Elastic Kubernetes Service ist ein vollständig verwalteter, zertifizierter Kubernetes-konformer Service, der den Aufbau, die Sicherung, den Betrieb und die Wartung von Kubernetes-Clustern vereinfacht. AWS Es handelt sich um eine hochgradig anpassbare Option, die sich auf den KubeRay Open-Source-Operator für die Bereitstellung und Verwaltung von Ray-Clustern auf Kubernetes stützt. Sie bietet eine verbesserte Ressourcennutzung, ein vereinfachtes Infrastrukturmanagement und volle Unterstützung für Ray-Funktionen.

Migrieren eines Ray-Jobs zu Amazon Elastic Kubernetes Service

Dieser Abschnitt enthält Schritte für die Migration von AWS Glue for Ray zu Ray auf Amazon Elastic Kubernetes Service. Diese Schritte sind für zwei Migrationsszenarien hilfreich:

Voraussetzungen für die Migration

Installieren Sie die folgenden CLI-Tools:aws,kubectl, eksctlhelm, Python 3.9+. Diese CLI-Tools sind für die Bereitstellung und Verwaltung Ihrer Ray on EKS-Umgebung erforderlich. eksctlvereinfacht die Erstellung und Verwaltung von EKS-Clustern. kubectlist die Standard-Kubernetes-CLI für die Bereitstellung und Fehlerbehebung von Workloads in Ihrem Cluster. helmwird zur Installation und Verwaltung verwendet KubeRay (der Operator, der Ray auf Kubernetes ausführt). Python 3.9+ ist für Ray selbst und für die lokale Ausführung von Job-Übermittlungsskripten erforderlich.

eksctl installieren

Folgen Sie den Anweisungen unter Installationsoptionen für Eksctl oder verwenden Sie die folgenden Anweisungen für die Installation.

Für macOS:

brew tap weaveworks/tap
brew install weaveworks/tap/eksctl

Für 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

kubectl installieren

Folgen Sie den Anweisungen unter Kubectl und eksctl einrichten oder verwenden Sie die nachstehenden Anweisungen für die Installation.

Für macOS:

brew install kubectl

Für 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/

Installieren Sie Helm

Folgen Sie den Anweisungen zur Installation von Helm oder verwenden Sie die folgenden Anweisungen für die Installation.

Für macOS:

brew install helm

Für Linux:

curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash

Schritt 1. Erstellen oder wählen Sie ein Docker-Image für Ray

Option 1: Verwenden Sie das offizielle Ray-Image (kein Build erforderlich)

Diese Option verwendet beispielsweise das offizielle Ray Docker-Image auf Docker Hubrayproject/ray:2.4.0-py39, das vom Ray-Projekt verwaltet wird.

Option 2: Erstellen und veröffentlichen Sie Ihr eigenes arm64 Ray 2.4.0-Image

Diese Option ist nützlich, wenn Graviton (ARM) -Knoten verwendet werden, da sie mit dem übereinstimmt, was AWS Glue for Ray intern verwendet. Sie können ein benutzerdefiniertes Image erstellen, das an dieselben Abhängigkeitsversionen wie AWS Glue für Ray angeheftet ist, um Kompatibilitätskonflikte zu reduzieren.

Erstellen Sie lokal ein Dockerfile:

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

Wenn Sie fertig sind, referenzieren Sie dieses ARM64 Bild in der RayCluster Spezifikation mit. nodeSelector: { kubernetes.io/arch: arm64 }

spec:
  rayVersion: "2.4.0"
  headGroupSpec:
    template:
      spec:
        containers:
        - name: ray-head
          image: <your ECR image>

Schritt 2. AWS Glue Für die Ray-Job-Konfiguration auf Amazon Elastic Kubernetes Service in Ray konvertieren

AWS Glue for Ray-Jobs unterstützen eine Reihe von Job-Argumenten, die Worker, Abhängigkeiten, Speicher und Protokollierung konfigurieren. Bei der Migration zu Amazon Elastic Kubernetes Service mit KubeRay müssen diese Argumente in RayCluster Spezifikationsfelder oder Ray Job-Laufzeitumgebungseinstellungen übersetzt werden.

Zuordnung von Job-Argumenten

Zuordnung der Auftragskonfiguration

Schritt 3. Amazon Elastic Kubernetes Service einrichten

Sie können entweder einen neuen Amazon Elastic Kubernetes Service Service-Cluster erstellen oder einen vorhandenen Amazon Elastic Kubernetes Service Service-Cluster wiederverwenden. Wenn Sie einen vorhandenen Cluster verwenden, überspringen Sie die Befehle zum Erstellen eines Clusters und wechseln Sie zu Knotengruppe hinzufügen, IRSA, und installieren Sie. KubeRay

Erstellen Sie einen Amazon Elastic Kubernetes Service Service-Cluster

# 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

Fügen Sie eine Knotengruppe hinzu

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

Erstellen Sie die Rolle Namespace + IAM für Service Accounts (IRSA) für S3

Ein Kubernetes-Namespace ist eine logische Gruppierung für Ressourcen (Pods, Dienste, Rollen usw.). Sie können einen vorhandenen Namespace erstellen oder wiederverwenden. Sie müssen außerdem eine IAM-Richtlinie für S3 erstellen, die den Zugriff Ihres AWS Glue Jobs widerspiegelt. Verwenden Sie dieselben benutzerdefinierten Berechtigungen, über die Ihre AWS Glue Jobrolle verfügte (normalerweise S3 read/write für bestimmte Buckets). Um Amazon Elastic Kubernetes Service ähnliche Berechtigungen wie dem zu gewähren AWSGlueServiceRole, erstellen Sie ein Service Account (IRSA), das an diese IAM-Richtlinie gebunden ist. Anweisungen zur Einrichtung dieses Dienstkontos finden Sie unter IAM-Rollen für Dienstkonten.

# 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

Installieren Sie den KubeRay Operator (Controller, der Ray auf K8s ausführt)

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

Schritt 4. Richten Sie einen Ray-Cluster ein

Erstellen Sie eine YAML-Datei, um einen Ray-Cluster zu definieren. Im Folgenden finden Sie eine Beispielkonfiguration (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" }

Stellen Sie den Ray-Cluster auf dem Amazon Elastic Kubernetes Service Service-Cluster bereit

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

Wenn das bereitgestellte Yaml geändert werden muss, löschen Sie zuerst den Cluster und wenden Sie dann das aktualisierte Yaml erneut an:

kubectl -n $NS delete raycluster glue-like
kubectl -n $NS apply -f raycluster.yaml

Zugriff auf das Ray-Dashboard

Sie können auf das Ray-Dashboard zugreifen, indem Sie die Port-Weiterleitung mit kubectl aktivieren:

# 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

Schritt 5. Ray Job einreichen

Verwenden Sie die Ray Jobs-CLI, um einen Ray-Job einzureichen. Die CLI-Version kann neuer als der Cluster sein, sie ist abwärtskompatibel. Als Voraussetzung sollten Sie Ihr Jobskript lokal in einer Datei speichern, z. 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

Der Job kann auf dem Ray-Dashboard überwacht werden.