Cluster and Runtime Environments

Package and save your application's dependencies. Re-run at any time in the future!

Types of environments

There are two types:

1. Cluster environments

2. Runtime environments

Let's dive in below.

Cluster environments

Environments are specially-built Docker images that work efficiently with Ray inside of Anyscale.

Builds are individual Docker images and associated metadata for an environment at a point in time. Environment builds are immutable and never deleted, so you can always reproduce or rollback to an old state.

As time goes on, you can create new environment builds and incrementally update your application's code and dependencies over time.

Creating cluster environments

You can use the UI to create a cluster environment by going to the Configurations page -> Cluster environments tab, and then clicking to create a new environment.

Here, you will be able to specify ray version, base images, pip packages, conda packages, debian packages, environmental variables, and finally post-build commands. If you want to update the cluster environment, you must select "create a new version" which create a new build for your environment.

You can also use the API to create cluster environments. Find out more by visiting the API docs.

Referencing cluster environments

When using the UI, you simply have to specify the cluster environment name and the build number by using the cluster environment drop down when creating a cluster.

When using ray client, you can reference the cluster environment by its name and build in this format cluster-env-name:1 where "1" is the build number you wish to use.

1ray.init(address="anyscale://", cluster_env="cluster-env-name:1")Copied!

ray.init(address="anyscale://", cluster_env="cluster-env-name:1")

Runtime environments

Runtime environments specify the Python environment that you want the driver, tasks, and actors of your job to run in. These are specified at runtime rather than being pre-built like Cluster Environments, and are nested within Cluster Environments. You may have different runtime environments for different jobs, tasks, or actors on the same cluster.

A runtime environment is a JSON-serializable dictionary that can contain a number of different options, such as pip dependencies or files. Please see the Ray documentation for more details and the full list of options. The example runtime environment below syncs the local directory and installs a few PyPI dependencies.

my_env={
    "working_dir": ".",
    "pip": ["requests", "torch==0.9.0"]
}

To specify this runtime environment for the whole job, you would specify it when you call ray.init():

ray.init(address="anyscale://my_cluster", runtime_env=my_env)

By default, all tasks and actors in a job will run in the job-level runtime environment, but you can also specify per-task and per-actor runtime environments. This can be useful when you have conflicting dependencies within the same application (e.g., need to use two different versions of tensorflow).

Note: If the runtime environment specifies pip or conda dependencies, these will be installed in an isolated conda environment. In particular, pip and conda dependencies from the cluster environment will not be inherited by the runtime environment.

You can specify the runtime environment in the @ray.remote decorator or using .options:

@ray.remote(runtime_env=env1)
def func():
    pass # Do something in env1.

# Task runs in env1.
func.remote()

# Alternative API:
func.options(runtime_env=env1).remote()

@ray.remote(runtime_env=env2)
class Actor:
    pass # Do something in env2.

# Actor runs in env2.
Actor.remote()

# Alternative API:
Actor.options(runtime_env=env2).remote()