Fin del soporte de AWS Glue para Ray

Tras una evaluación exhaustiva, hemos decidido cerrar AWS Glue para Ray a nuevos clientes a partir del 30 de abril de 2026. Si desea utilizar AWS Glue para Ray, regístrese antes de esa fecha. Los clientes existentes pueden seguir utilizando el servicio con normalidad.

AWS continúa su inversión en mejoras de seguridad y disponibilidad para AWS Glue para Ray. Tenga en cuenta que no está previsto incorporar nuevas características a AWS Glue para Ray, salvo mejoras de seguridad y disponibilidad.

Como alternativa a AWS Glue para Ray, recomendamos utilizar Amazon Elastic Kubernetes Service Amazon Elastic Kubernetes Service es un servicio completamente administrado y certificado conforme a Kubernetes que simplifica el proceso de crear, proteger, operar y mantener clústeres de Kubernetes en AWS. Es una opción muy flexible que utiliza el operador de código abierto KubeRay Operator para implementar y administrar clústeres de Ray en Kubernetes. Esto permite aprovechar mejor los recursos, simplificar la administración de la infraestructura y contar con compatibilidad total con todas las características de Ray.

Migración de un trabajo de Ray a Amazon Elastic Kubernetes Service

En esta sección se describen los pasos para migrar de AWS Glue para Ray a Ray en Amazon Elastic Kubernetes Service. Estos pasos resultan útiles para dos escenarios de migración:

Requisitos previos para la migración

Instale las siguientes herramientas de interfaz de línea de comandos (CLI): aws, kubectl, eksctl, helm y Python 3.9 o posterior. Estas herramientas de interfaz de línea de comandos (CLI) son necesarias para aprovisionar y administrar el entorno de Ray en EKS. eksctl facilita la creación y administración de clústeres de EKS. kubectl es la CLI estándar de Kubernetes para implementar y solucionar problemas de cargas de trabajo en el clúster. helm se utiliza para instalar y administrar KubeRay (el operador que ejecuta Ray en Kubernetes). Python 3.9 o posterior es necesario para Ray y para ejecutar localmente los scripts de envío de trabajos.

Instalación de eksctl

Siga las instrucciones que aparecen en Opciones de instalación para Eksctl o utilice las instrucciones que se indican a continuación para la instalación.

Para macOS:

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

Para 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

Instale kubectl

Siga las instrucciones que aparecen en Configuración de kubectl y eksctl o utilice las instrucciones que se indican a continuación para la instalación.

Para macOS:

brew install kubectl

Para 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/

Instalación de Helm

Siga las instrucciones que aparecen en Instalación de Helm o utilice las instrucciones que se indican a continuación para la instalación.

Para macOS:

brew install helm

Para Linux:

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

Paso 1. Cómo crear o elegir una imagen de Docker para Ray

Opción 1: utilizar la imagen oficial de Ray (no se requiere compilación)

Esta opción utiliza la imagen de docker oficial de Ray en Docker Hub, por ejemplo, rayproject/ray:2.4.0-py39, que es mantenida por el proyecto Ray.

Opción 2: cree y publique su propia imagen de Ray 2.4.0 para arm64

Esta opción resulta útil cuando se utilizan nodos Graviton (ARM), en consonancia con lo que AWS Glue para Ray utiliza internamente. Puede crear una imagen personalizada fijada a las mismas versiones de dependencias que AWS Glue para Ray, para reducir incompatibilidades.

Cree un Dockerfile localmente:

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

Una vez finalizado, haga referencia a esta imagen ARM64 en la especificación de RayCluster con nodeSelector: { kubernetes.io/arch: arm64 }.

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

Paso 2. Convierta la configuración de trabajos de AWS Glue para Ray a Ray en Amazon Elastic Kubernetes Service.

Los trabajos de AWS Glue para Ray admiten un conjunto de argumentos de trabajo que configuran los nodos de trabajo, las dependencias, la memoria y el registro. Al migrar a Amazon Elastic Kubernetes Service con KubeRay, estos argumentos se deben traducir a campos de la especificación de RayCluster o a la configuración del entorno de tiempo de ejecución de Ray Job.

Asignación de argumentos de trabajo

Asignación de la configuración del trabajo

Paso 3. Configuración de Amazon Elastic Kubernetes Service

Puede crear un nuevo clúster de Amazon Elastic Kubernetes Service o reutilizar uno existente. Si utiliza un clúster existente, omita los comandos de creación del clúster y pase a Agregar un grupo de nodos, IRSA e instalar KubeRay.

Creación de un clúster de 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

Cómo agregar un grupo de nodos

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

Creación del espacio de nombres y del rol de IAM para cuentas de servicio (IRSA) para S3

Un espacio de nombres de Kubernetes es una agrupación lógica de recursos (pods, servicios, roles, etc.). Puede crear un espacio de nombres o reutilizar uno existente. También deberá crear una política de IAM para S3 que refleje el acceso del trabajo de AWS Glue. Utilice los mismos permisos personalizados que tenía el rol del trabajo de AWS Glue (normalmente, lectura/escritura en S3 para buckets específicos). Para otorgar permisos a Amazon Elastic Kubernetes Service similares a los de AWSGlueServiceRole, cree una cuenta de servicio (IRSA) vinculada a esta política de IAM. Consulte Roles de IAM para cuentas de servicio para obtener instrucciones sobre cómo configurar esta cuenta de servicio.

# 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

Instalación del operador KubeRay (controlador que ejecuta Ray en 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

Paso 4. Puesta en marcha de un clúster de Ray

Cree un archivo YAML para definir el clúster de Ray. A continuación, se muestra una configuración de ejemplo (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" }

Implementación del clúster de Ray en un clúster de 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

Si necesita modificar el archivo YAML implementado, elimine primero el clúster y, a continuación, vuelva a aplicar el YAML actualizado:

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

Acceso al panel de Ray

Para acceder al panel de Ray, habilite el reenvío de puertos mediante 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

Paso 5. Cómo enviar un trabajo de Ray

Para enviar un trabajo de Ray, utilice la CLI de trabajos de Ray. La versión de la CLI puede ser más reciente que la del clúster; es compatible con versiones anteriores. Como requisito previo, almacene el script de trabajo localmente en un archivo, por ejemplo, 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

El trabajo se puede supervisar en el panel de Ray.