Ray
hosomaki.ray
A Docker Compose file for Ray alone, generated from the catalog and checked by the safety inspector. No account needed.
Distributed execution framework for Python that spreads tasks, stateful actors and machine-learning workloads across a cluster, with libraries for tuning, training, data processing and inference.
Ray turns ordinary Python functions and classes into distributed tasks and actors through decorators, leaving scheduling, object transfer and failure recovery to the runtime. On top of that core sit libraries for hyperparameter search, distributed training, batch data processing and online inference, all sharing one cluster and one object store. A cluster is a head node plus any number of workers, and the same code runs unchanged on a single machine, which is what makes local development to cluster deployment a configuration change rather than a rewrite. A first deployment starts the head node alone, submits a job through its dashboard or client, and confirms the task landed on a worker.
You know it worked when
- The head node starts and its dashboard reports the expected number of workers.
- A remote task submitted from a client returns its result.
- An actor retains state across two successive calls.
- The dashboard shows a task assigned to a named worker with its resource usage.
Known sharp edges
- Head and worker nodes must run identical Python and Ray versions; a mismatch fails at connection time with an opaque serialisation error.
- The object store lives in shared memory sized as a fraction of host RAM, and large intermediate objects spill to disk and slow jobs sharply.
- The dashboard and job submission ports accept work without authentication and must stay on an internal network.
- Tasks holding references to large closures serialise them on every call, which is a common and hard-to-spot cause of slow jobs.