# Fin del soporte de AWS Glue para Ray **importante** AWS Glue para Ray ya no estará disponible para 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. Para obtener capacidades similares a AWS Glue para Ray, explore Amazon EKS. Para obtener más información, consulte [Finalización del soporte de AWS Glue para Ray](https://docs.aws.amazon.com/glue/latest/dg/awsglue-ray-jobs-availability-change.html). 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: + **Migración estándar (x86/amd64)**: para estos casos de uso, la estrategia de migración utiliza el contenedor de Ray de código abierto para implementaciones básicas y ejecuta los scripts directamente en el contenedor base. + **Migración a ARM64**: para estos casos de uso, la estrategia de migración permite crear contenedores personalizados para satisfacer dependencias específicas de ARM64 y requisitos de arquitectura. ### 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](https://docs.aws.amazon.com/eks/latest/eksctl/installation.html) 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](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html) 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](https://helm.sh/docs/intro/install/) 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](https://hub.docker.com/u/rayproject), por ejemplo, `rayproject/ray:2.4.0-py39`, que es mantenida por el proyecto Ray. **nota** Esta imagen solo es compatible con amd64. Utilice esta opción si las dependencias son compatibles con amd64 y no requiere compilaciones específicas para ARM. **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: ``` ### 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 argumentos de AWS Glue para Ray a sus equivalentes en Ray en EKS** | Argumento de AWS Glue para Ray | Lo que hace en AWS Glue para Ray | Equivalente en Ray en Amazon Elastic Kubernetes Service | | --- | --- | --- | | --min-workers | Número mínimo de nodos de trabajo que el trabajo debe destinar. | workerGroupSpecs[].minReplicas en el RayCluster | | --working-dir | Distribuye un archivo zip (URI de S3) a todos los nodos. | Utilice el entorno de tiempo de ejecución de Ray: working\$1dir si envía desde archivos locales; py\$1modules para archivos zip en S3 para apuntar al artefacto en S3 | | --s3-py-modules | Agrega paquetes wheel o distribuciones de Python desde S3. | Utilice el entorno de tiempo de ejecución de Ray: py\$1modules: ["s3://.../xxx.whl", ...] | | --pip-install | Instala paquetes adicionales de PyPI para el trabajo. | Entorno de tiempo de ejecución de Ray: pip: ["pkg==ver", ...] (CLI de Ray Job --runtime-env-json o RayJob runtimeEnvYAML). | | --object\$1store\$1memory\$1head | Porcentaje de memoria para el almacén Plasma del nodo cabeza. | headGroupSpec[].rayStartParams.object-store-memory en el RayCluster. Tenga en cuenta que esto se debe indicar en bytes. AWS Glue utiliza un porcentaje, mientras que Ray utiliza bytes. | | --object\$1store\$1memory\$1worker | Porcentaje de memoria para el almacén Plasma de los nodos de trabajo. | Igual que lo anterior, pero se establece en el rayStartParams.object-store-memory de cada grupo de nodos de trabajo (en bytes). | | --object\$1spilling\$1config | Configure el almacenamiento externo de objetos de Ray. | headGroupSpec[].rayStartParams.object-spilling-config | | --logging\$1configuration | Registros administrados por AWS Glue (CloudWatch, S3). | Revise la salida estándar (stdout) y de error (stderr) del pod: utilice kubectl -n ray logs --follow. Revise los registros desde el panel de Ray (redirija el puerto a :8265); también puede ver allí los registros de tareas y trabajos. | #### Asignación de la configuración del trabajo **Asignación de configuraciones de trabajos de AWS Glue para Ray a sus equivalentes en Ray en EKS.** | Configuración | Lo que hace en AWS Glue para Ray | Equivalente en Ray en EKS | | --- | --- | --- | | Tipo de empleado | Defina el tipo de nodo de trabajo predefinido que se permite cuando se ejecuta un trabajo. Valor predeterminado: Z 2X (8 vCPU, 64 GB de RAM). | Tipo de instancia del grupo de nodos en EKS (por ejemplo, r7g.2xlarge ≈ 8 vCPU/64 GB para ARM, r7a.2xlarge para x86). | | Número máximo de nodos de trabajo | Número de nodos de trabajo que desea que AWS Glue destine a este trabajo. | Establezca workerGroupSpecs[].maxReplicas en el mismo número que utilizó en AWS Glue. Este es el límite superior para el escalado automático. De forma similar, establezca minReplicas como límite inferior. Puede comenzar con replicas: 0, minReplicas: 0. | ### 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 **nota** Si ya dispone de un clúster de Amazon Elastic Kubernetes Service, omita los comandos para crear uno nuevo y agregue simplemente un grupo de nodos. ``` # 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" ``` **nota** Si utiliza un clúster de Amazon Elastic Kubernetes Service existente, utilice `--with-oidc` para habilitar OIDC al agregar un grupo de nodos. #### 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](https://docs.aws.amazon.com/eks/latest/eksctl/iamserviceaccounts.html) 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.