This project is no longer actively maintained by Astronomer. Development has been paused and we are not accepting new contributions, bug fixes or releases. The code is still here for you to explore, fork and adapt under the terms of its license. Please note that it may not work with the latest dependencies or platforms, and it could contain security vulnerabilities. Astronomer can't offer guarantees or warranties for its use.
Google Cloud alternative (partial): If you run Ray on Google Cloud, the official Apache Airflow Google provider (
apache-airflow-providers-google) ships Ray operators that cover a subset of what this provider does:
- Ray cluster lifecycle on Vertex AI —
CreateRayClusterOperator,ListRayClustersOperator,GetRayClusterOperator,UpdateRayClusterOperator,DeleteRayClusterOperator- Ray job management —
RaySubmitJobOperator,RayStopJobOperator,RayDeleteJobOperator,RayGetJobInfoOperator,RayListJobsOperatorThis provider is Kubernetes-generic, so the Google operators are a Google Cloud-specific alternative, not a drop-in replacement.
If you're interested in adopting or stewarding this project, we'd be happy to chat — reach us at oss@astronomer.io. Thanks for being part of the open-source journey and helping keep great ideas alive!
📚 Docs | 🚀 Getting Started | 💬 Slack (#airflow-ray) | 🔥 Contribute
Orchestrate your Ray jobs using Apache Airflow® combining Airflow's workflow management with Ray's distributed computing capabilities.
Benefits of using this provider include:
- Integration: Incorporate Ray jobs into Airflow DAGs for unified workflow management.
- Distributed computing: Use Ray's distributed capabilities within Airflow pipelines for scalable ETL, LLM fine-tuning etc.
- Monitoring: Track Ray job progress through Airflow's user interface.
- Dependency management: Define and manage dependencies between Ray jobs and other tasks in DAGs.
- Resource allocation: Run Ray jobs alongside other task types within a single pipeline.
Check out the Getting Started guide in our docs. Sample DAGs are available at example_dags/.
The below example showcases how to use the @ray.task decorator to manage the full lifecycle of a Ray cluster: setup, job execution, and teardown.
This approach is ideal for jobs that require a dedicated, short-lived cluster, optimizing resource usage by cleaning up after task completion
astro-provider-ray/example_dags/ray_taskflow_example.py
Lines 1 to 57 in bd6d847
This example shows how to use separate operators for cluster setup, job submission, and teardown, providing more granular control over the process.
This approach allows for more complex workflows involving Ray clusters.
Key Points:
- Uses SetupRayCluster, SubmitRayJob, and DeleteRayCluster operators separately.
- Allows for multiple jobs to be submitted to the same cluster before deletion.
- Demonstrates how to pass cluster information between tasks using XCom.
This method is ideal for scenarios where you need fine-grained control over the cluster lifecycle, such as running multiple jobs on the same cluster or keeping the cluster alive for a certain period.
astro-provider-ray/example_dags/setup-teardown.py
Lines 1 to 44 in bd6d847
| Platform | Purpose | Est. Response time |
|---|---|---|
| Discussion Forum | General inquiries and discussions | < 3 days |
| GitHub Issues | Bug reports and feature requests | < 1-2 days |
| Slack | Quick questions and real-time chat | 12 hrs |
We follow Semantic Versioning for releases. Check CHANGELOG.rst for the latest changes.
All contributions, bug reports, bug fixes, documentation improvements, enhancements are welcome.
A detailed overview on how to contribute can be found in the Contributing Guide.
This project follows Astronomer's Privacy Policy <https://www.astronomer.io/privacy/>_