116 lines
2.5 KiB
Markdown
116 lines
2.5 KiB
Markdown
# EmboFlow Deployment Architecture
|
|
|
|
## V1 Deployment Target
|
|
|
|
The first deployment target is a single public server. The platform should be deployed in a way that is operationally simple now and migration-friendly later.
|
|
|
|
## Recommended V1 Deployment Topology
|
|
|
|
- Reverse proxy
|
|
- Web frontend service
|
|
- API service
|
|
- Worker service
|
|
- MongoDB
|
|
- Optional MinIO
|
|
- Host Docker runtime for execution containers
|
|
|
|
## Deployment Principles
|
|
|
|
- Single-host deployment first
|
|
- All major services containerized
|
|
- Persistent state mounted on host volumes
|
|
- Object storage can be external or self-hosted
|
|
- Execution workers separated from API service
|
|
- Future scheduler migration should not require domain model changes
|
|
|
|
## Recommended Runtime Layout
|
|
|
|
### Edge
|
|
|
|
- Nginx or equivalent reverse proxy
|
|
- HTTPS termination
|
|
- Static web delivery or web upstream routing
|
|
|
|
### Application
|
|
|
|
- `web`
|
|
- `api`
|
|
- `worker`
|
|
|
|
### Data
|
|
|
|
- `mongo`
|
|
- `minio` optional
|
|
|
|
## Object Storage Strategy
|
|
|
|
The product should support both:
|
|
|
|
- Cloud object storage such as BOS or S3-compatible services
|
|
- Self-hosted MinIO for development, demos, or private deployment
|
|
|
|
The application should expose a unified storage abstraction instead of embedding provider-specific logic across modules.
|
|
|
|
## Local Scheduler In V1
|
|
|
|
V1 should use a local scheduler. Worker processes execute tasks on the same deployment host.
|
|
|
|
Design constraints:
|
|
|
|
- RuntimeSpec must already exist
|
|
- Scheduler abstraction must already exist
|
|
- Docker executor must already be scheduler-compatible
|
|
|
|
This keeps future migration to Kubernetes or Volcano feasible.
|
|
|
|
## Host-Level Persistent Directories
|
|
|
|
Recommended host directories:
|
|
|
|
- application config
|
|
- mongodb data
|
|
- minio data
|
|
- uploaded file staging
|
|
- execution temp workspace
|
|
- logs
|
|
- backup data
|
|
|
|
## Execution Isolation
|
|
|
|
The host Docker runtime serves two different purposes:
|
|
|
|
- Running the platform deployment stack
|
|
- Running task execution containers
|
|
|
|
These must be treated as separate concerns in configuration and security design.
|
|
|
|
## Future Migration Path
|
|
|
|
### Stage 1
|
|
|
|
- Single-host deployment
|
|
- Local scheduler
|
|
- Docker executor
|
|
|
|
### Stage 2
|
|
|
|
- Kubernetes-based service deployment
|
|
- Kubernetes scheduler adapter for workflow tasks
|
|
|
|
### Stage 3
|
|
|
|
- Volcano scheduler adapter
|
|
- Better support for large batch jobs and training-adjacent workloads
|
|
|
|
## Operational Baseline
|
|
|
|
V1 should provide basic operational support for:
|
|
|
|
- health checks
|
|
- service restart
|
|
- execution failure visibility
|
|
- disk space monitoring
|
|
- object storage connectivity checks
|
|
- MongoDB backup and restore procedures
|
|
- worker online status
|