ComputeSphereLearn
Console
Learning paths / Containers / Docker Compose

From Compose to ComputeSphere with csph import compose

Reading · 6 min · Module 6, lesson 3 of 551 min left in this module

Module 6 · Docker ComposeLesson 3 of 5

Goal: Turn a Compose file into a computesphere.yaml manifest and read what it could and couldn't carry across.

You need csph installed, from lesson 5.1.1, Set up. Importing needs no sign-in; the lab after this lesson does.

Key idea

csph import compose reads a Compose file and writes the matching computesphere.yaml. It runs on your machine and deploys nothing, and it warns about every setting it can't carry, so you review the manifest before csph apply runs it.

How the pieces map

  • A service with ports becomes a web service on the container's port. Without ports, it becomes a background worker.
  • environment becomes variables. Keys that look like secrets (*_PASSWORD, *_KEY, *_TOKEN) become empty secret placeholders: the value is dropped, and you set it separately.
  • A variable that points at another web service, like http://api:8080, becomes a reference to that service's private address.
  • build: needs your code in a repository, because ComputeSphere builds from git, not from a folder on your laptop.

Import the database stack

Run it in the compose-stack folder. With no -f, it reads compose.yaml, the file from the last lesson:

csph import compose

✓ wrote computesphere.yaml (2 services)

6 warnings:
  db:
    - PostgreSQL imported as a plain container. Its data is lost on every redeploy unless it's on a volume; consider a PostgreSQL you run elsewhere and set its connection string as a secret
    - POSTGRES_PASSWORD looks like a secret; emitted as a placeholder — set it out of band
    - field "volumes" isn't supported and was skipped
    - field "healthcheck" isn't supported and was skipped
  web:
    - compose builds from a local context; set build_source/git connection before deploying
    - DATABASE_URL references another service; review whether it should use fromService

Read the first warning twice. ComputeSphere doesn't offer managed databases, so Postgres would run as an ordinary container with no volume. A database belongs with a database provider; your app gets its connection string as a secret, which lesson 5.5.3 shows.

So the stack you deploy is app only. That's what compose.deploy.yaml is: the web app plus a small API, both as images.

Import the app-only stack

csph import compose -f compose.deploy.yaml -o -

-o - prints the manifest instead of writing a file:

version: "2"
services:
    - name: web
      type: web-service
      image: <your-registry>/compose-web:1.0.0
      port: 3000
      env_vars:
        API_URL:
            fromService: api
            property: internal_url
    - name: api
      type: web-service
      image: quay.io/computesphere/learn-sample-api:1.0.0
      port: 8080
      env_vars:
        GREETING: Hello from the API
✓ wrote stdout (2 services)

No warnings this time. API_URL was http://api:8080; now it's filled in at deploy time with api's private address inside the environment. Services only reach each other that way when the environment has Private network on, so the lab creates one that does.

What import leaves for you to fix

Some references stay as written, with a warning, because a service name alone isn't enough on ComputeSphere:

  • API_HOST: api or a separate port key: pass the whole address as one URL variable instead.
  • A URL pointing at a background worker: a worker has no address. Give it ports if something calls it.
  • A service name inside a hand-built connection string, like DATABASE_URL above.

An existing computesphere.yaml is never overwritten unless you add --force.

Check yourself

Your Compose file has web, worker and postgres. What should the stack you deploy to ComputeSphere contain?

In the docs