Learning paths / Containers / Persistent storage

On ComputeSphere: SphereStor volumes mounted on a service

Reading · 5 min · Module 7, lesson 4 of 510 min left in this module

Module 7 · Persistent storageLesson 4 of 5

Goal: Describe how a SphereStor volume attaches to a ComputeSphere service at a path, and the one-spherelet limit that comes with it.

Key idea

On ComputeSphere, the volume you used with docker run -v is a SphereStor volume. It lives in an environment, you mount it on a service at a path such as /data, and your app sees an ordinary folder there.

The same idea, one level up

Locally, you created a volume and mounted it into a container. ComputeSphere runs your container as a spherelet, and a restart, or a redeploy that applies a change, replaces the spherelet the way docker rm and docker run replaced your container in the last lesson. So the rule is the same: files on the spherelet's own filesystem go with it, and files on a mounted volume stay.

There's no -v flag to type. You set it up in the console, in three places, on the Pro, Team or Enterprise plan (Hobby doesn't include SphereStor):

  • Quota on your account: the storage you pay for, at $0.25 per GB per month.
  • A volume in the environment, on its Storage tab, carved out of that quota.
  • A mount on the service, on its Storage card in Settings, with the Mount path your app writes to.

Lesson 5.5.2, SphereStor volumes, walks through each one.

What carries over from Docker

  • The mount path must match your app. If your app writes to /app/data and you mount /data, the files still land on the spherelet's own filesystem.
  • Mount a folder your app only writes to, never your code folder. On ComputeSphere, the volume hides whatever the image had at that path.
  • A non-root app needs to own the folder, the same fix as in lesson 3.7.2.

What's different

A SphereStor volume attaches to one spherelet at a time. Keep a service with a volume at 1 spherelet: a second copy, including one that autoscaling adds, can't see the data. If several copies need the same files, the data belongs in a database or object storage.

Volumes are set up in the console. csph has no volume commands yet, and computesphere.yaml doesn't declare them, so note a service's volume and mount path in your README.

A volume also isn't a backup. It keeps data through redeploys, not through a deleted volume or a bug that corrupts a file.

Check yourself

Your service mounts a SphereStor volume at /data, and you scale it to 3 spherelets. What do the two new spherelets see at /data?

In the docs