Why the scheduler becomes the orchestrator
A laptop Compose stack uses one tool to start services, connect them, and manage their lifetime. On shared HPC, one scheduler allocation becomes that boundary. A launch script starts each component as a tracked step, uses a rootless runtime, keeps writable state in approved storage, and verifies results before the allocation ends.
Map each responsibility
Scroll horizontally to view all table columns.
| Compose concept | Scheduler-managed HPC mapping | Decision to make |
|---|---|---|
| service | tracked step inside one allocation | Which process coordinates, and which processes are workers? |
| image or build | immutable image launched by a rootless runtime | Who builds and approves the image? |
| dependency or health check | bounded semantic readiness gate | What response proves the coordinator is ready? |
| volume | explicit job-scoped scratch or approved storage bind | Which state is temporary, and which must persist? |
| port | loopback or a center-approved access path | Who needs access, and what does policy permit? |
| device request | scheduler CPU, memory, wall-time, or accelerator request | Which resources must be requested before launch? |
Make the local decisions
For one workflow, assign allocation, startup order, runtime state, access, and accelerator ownership to scheduler policy, runtime behavior, launch-script logic, or local-center configuration. The completion exercise below turns those assignments into a reviewable decision record.
Limitations
This mapping does not make a workflow portable unchanged. Scheduler syntax, network policy, storage, security controls, runtime modules, and accelerator flags vary by center. Multi-node discovery, persistent databases, privileged ports, and production availability are outside the single-node baseline.
Next step
Continue to Baseline Pattern: Single-Node Service + Workers to run the bounded shape, or check your center before execution.