

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
<a name="awsglue-ray-jobs-availability-change"></a>

**Wichtig**  
AWS Glue for Ray wird ab dem 30. April 2026 nicht mehr für Neukunden geöffnet sein. 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. Funktionen, die denen von AWS Glue für Ray ähneln, finden Sie in Amazon EKS. Weitere Informationen finden Sie unter [Ende des Supports AWS Glue für Ray](https://docs.aws.amazon.com/glue/latest/dg/awsglue-ray-jobs-availability-change.html).

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
<a name="awsglue-ray-jobs-availability-change-migration"></a>

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:
+ **Standardmigration (x86/amd64)**: Für diese Anwendungsfälle verwendet die Migrationsstrategie den OpenSource Ray-Container für grundlegende Implementierungen und führt Skripts direkt auf dem Basiscontainer aus.
+ **ARM64 Migration**: Für diese Anwendungsfälle unterstützt die Migrationsstrategie benutzerdefinierte Container-Builds für spezifische Abhängigkeiten und Architekturanforderungen. ARM64

### Voraussetzungen für die Migration
<a name="awsglue-ray-jobs-availability-change-prerequisites"></a>

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

#### eksctl installieren
<a name="awsglue-ray-jobs-availability-change-install-eksctl"></a>

Folgen Sie den Anweisungen unter [Installationsoptionen für Eksctl](https://docs.aws.amazon.com/eks/latest/eksctl/installation.html) 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
<a name="awsglue-ray-jobs-availability-change-install-kubectl"></a>

Folgen Sie den Anweisungen unter [Kubectl und eksctl einrichten](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html) 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
<a name="awsglue-ray-jobs-availability-change-install-helm"></a>

Folgen Sie den Anweisungen zur [Installation von Helm](https://helm.sh/docs/intro/install/) 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
<a name="awsglue-ray-jobs-availability-change-step1"></a>

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

Diese Option verwendet beispielsweise das offizielle Ray Docker-Image auf [Docker Hub](https://hub.docker.com/u/rayproject)`rayproject/ray:2.4.0-py39`, das vom Ray-Projekt verwaltet wird.

**Anmerkung**  
Dieses Image ist nur für AMD64 verfügbar. Verwenden Sie dies, wenn Ihre Abhängigkeiten mit amd64 kompatibel sind und Sie keine ARM-spezifischen Builds benötigen.

**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
<a name="awsglue-ray-jobs-availability-change-step2"></a>

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
<a name="awsglue-ray-jobs-availability-change-job-argument-mapping"></a>


**Zuordnung von AWS Glue Ray-Argumenten zu Ray auf EKS-Äquivalenten**  

| AWS Glue für Ray-Argument | Was es AWS Glue für Ray bedeutet | Ray auf Amazon Elastic Kubernetes Service Service-Äquivalent | 
| --- | --- | --- | 
| --min-workers | Mindestanzahl an Arbeitskräften, die der Job zuweisen muss. | workerGroupSpecs[].minReplicasin deinem RayCluster | 
| --working-dir | Verteilt eine ZIP-Datei (S3-URI) an alle Knoten. | Verwenden Sie Ray Runtime env:, working\$1dir wenn Sie aus lokalen Dateien senden; py\$1modules damit S3-Zips auf das S3-Artefakt verweisen | 
| --s3-py-modules | Fügt Python wheels/dists aus S3 hinzu. | Verwenden Sie Ray Runtime env: py\$1modules: ["s3://.../xxx.whl", ...] | 
| --pip-install | Installiert zusätzliche PyPI-Pakete für den Job. | Ray-Laufzeitumgebung: pip: ["pkg==ver", ...] (Ray Job CLI --runtime-env-json oder RayJobruntimeEnvYAML). | 
| --object\$1store\$1memory\$1head | % des Speichers für den Plasmaspeicher des Hauptknotens. | headGroupSpec[].rayStartParams.object-store-memoryin deinem RayCluster. Beachten Sie, dass dies in Byte angegeben werden sollte. AWS Glue verwendet Prozent, während Ray Bytes verwendet. | 
| --object\$1store\$1memory\$1worker | % des Speichers für den Plasmaspeicher der Worker-Knoten. | Wie oben, aber in den Werten der einzelnen Worker-Gruppen rayStartParams.object-store-memory (Byte) festgelegt. | 
| --object\$1spilling\$1config | Konfigurieren Sie die Übertragung von Ray-Objekten. | headGroupSpec[].rayStartParams.object-spilling-config | 
| --logging\$1configuration | AWS Glue-verwaltete Protokolle (CloudWatch, S3). | Überprüfen Sie pod stdout/stderr: use. kubectl -n ray logs <pod-name> --follow Überprüfe die Logs im Ray Dashboard (Port-Forward zu:8265). Dort kannst du auch Aufgaben- und Jobprotokolle einsehen. | 

#### Zuordnung der Auftragskonfiguration
<a name="awsglue-ray-jobs-availability-change-job-config-mapping"></a>


**Zuordnung von AWS Glue Ray-Job-Konfigurationen zu Ray auf EKS-Äquivalenten**  

| Konfiguration | Was bedeutet das für Ray AWS Glue  | Ray auf EKS-Äquivalent | 
| --- | --- | --- | 
| Worker type (Worker-Typ) | Legt den Typ des vordefinierten Workers fest, der bei der Ausführung eines Jobs zulässig ist. Die Standardeinstellung ist Z 2X (8 vCPU, 64 GB RAM). | Nodegroup-Instanztyp in EKS (z. B. r7g.2xlarge ≈ 8 vCPU/64 GB für ARM, r7a.2xlarge für x86). | 
| Maximale Anzahl von Mitarbeitern | Die Anzahl der Arbeitskräfte, AWS Glue die Sie diesem Job zuordnen möchten. | Stellen Sie workerGroupSpecs[].maxReplicas die gleiche Anzahl ein, wie Sie in AWS Glue verwendet haben. Dies ist die Obergrenze für Autoscaling. Wird in ähnlicher Weise minReplicas als Untergrenze festgelegt. Sie können mitreplicas: 0, beginnenminReplicas: 0. | 

### Schritt 3. Amazon Elastic Kubernetes Service einrichten
<a name="awsglue-ray-jobs-availability-change-step3"></a>

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
<a name="awsglue-ray-jobs-availability-change-create-cluster"></a>

**Anmerkung**  
Wenn Sie bereits über einen Amazon Elastic Kubernetes Service Service-Cluster verfügen, überspringen Sie die Befehle zum Erstellen eines neuen Clusters und fügen Sie einfach eine Knotengruppe hinzu.

```
# 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
<a name="awsglue-ray-jobs-availability-change-add-nodegroup"></a>

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

**Anmerkung**  
Wenn Sie einen vorhandenen Amazon Elastic Kubernetes Service Service-Cluster verwenden, verwenden Sie diesen, um OIDC `--with-oidc` zu aktivieren, wenn Sie eine Knotengruppe hinzufügen.

#### Erstellen Sie die Rolle Namespace \$1 IAM für Service Accounts (IRSA) für S3
<a name="awsglue-ray-jobs-availability-change-irsa"></a>

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](https://docs.aws.amazon.com/eks/latest/eksctl/iamserviceaccounts.html).

```
# 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)
<a name="awsglue-ray-jobs-availability-change-install-kuberay"></a>

```
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
<a name="awsglue-ray-jobs-availability-change-step4"></a>

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
<a name="awsglue-ray-jobs-availability-change-deploy-cluster"></a>

```
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
<a name="awsglue-ray-jobs-availability-change-ray-dashboard"></a>

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
<a name="awsglue-ray-jobs-availability-change-step5"></a>

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.