|
| 1 | +# Implementation Plan – Issue #110 (Dockerize FlowSynx Engine) |
| 2 | + |
| 3 | +**Scope & Answers Incorporated** |
| 4 | +- **Component scope:** Engine only for now. Console support is deferred; add later once config needs are clear. |
| 5 | +- **Registry & tags:** Public images on Docker Hub (`docker.io/flowsynx/flowsynx`). Tags follow semantic versioning (e.g., `1.2.4-linux-amd64`, `1.2.4-windows-ltsc2022-amd64`). |
| 6 | +- **Ports:** Engine listens on **6262** (Console would be 6264 when added). |
| 7 | +- **Config/storage:** Persist install mode and Docker metadata alongside `flowctl` in an `appsettings.json` file (same directory as the CLI). |
| 8 | +- **Persistence (recommended):** Default to a host bind mount `~/.flowsynx/data -> /app/data` so workflows, logs/telemetry, and plugins survive container restarts. Allow overrides for power users (named volumes or custom paths). |
| 9 | +- **Testing expectation:** Unit tests only for the Docker pathway. |
| 10 | + |
| 11 | +--- |
| 12 | + |
| 13 | +## Goals |
| 14 | +- Add Docker-based initialization and run support for the FlowSynx engine via an explicit flag. |
| 15 | +- Keep binary flow as the default and fully functional. |
| 16 | +- Provide friendly UX when Docker is absent or not running and offer fallback guidance to binary mode. |
| 17 | + |
| 18 | +--- |
| 19 | + |
| 20 | +## Architecture & Key Decisions |
| 21 | +- **Docker client approach:** Use the existing process wrapper to shell out to the Docker CLI (simpler dependency story). Consider Docker.DotNet later if needed. |
| 22 | +- **Configuration:** `appsettings.json` (sibling to `flowctl`) stores deployment mode and Docker artifact metadata. |
| 23 | +- **Persistence:** Single host bind by default: mount `~/.flowsynx/data` to `/app/data`. Inside `/app/data`, keep subfolders for state/db, logs/telemetry, and plugins. This keeps user data portable and inspectable. CLI flags allow overriding to a named volume or a different host path. |
| 24 | +- **Mode selection:** Binary remains default. Docker requires `--docker` (or `--use-docker`); we record the last successful mode in config to provide actionable hints. |
| 25 | + |
| 26 | +--- |
| 27 | + |
| 28 | +## Workplan |
| 29 | + |
| 30 | +### 1) Docker Service Abstraction |
| 31 | +- Add `IDockerService` in Core and a CLI-based implementation in Infrastructure that can: |
| 32 | + - Check availability of Docker daemon. |
| 33 | + - Pull images with progress feedback. |
| 34 | + - Create/run/stop/remove containers. |
| 35 | + - Inspect container status and fetch logs (tail). |
| 36 | +- Keep surface area focused on engine needs (no console operations yet). |
| 37 | + |
| 38 | +### 2) Configuration & State |
| 39 | +- Add/load `appsettings.json` beside the `flowctl` binary to track: |
| 40 | + - `deploymentMode`: `binary` or `docker`. |
| 41 | + - Docker details: image name, tag, container name/id, mapped host port, and host mount path used. |
| 42 | + - Last successful run mode to shape UX hints. |
| 43 | +- Provide a small config service to read/update this file safely. |
| 44 | + |
| 45 | +### 3) Init Command (`flowctl init --docker`) |
| 46 | +- Add `--docker` flag (explicit opt-in). |
| 47 | +- Options: |
| 48 | + - `--flowsynx-version` (tag), defaults to latest tag lookup if omitted. |
| 49 | + - `--container-name` (default: `flowsynx-engine`). |
| 50 | + - `--port` (host) default: 6262. |
| 51 | + - `--mount` (hostPath:containerPath) with default bind `~/.flowsynx/data:/app/data`. |
| 52 | + - `--platform` auto-detected to choose the right arch tag (linux-amd64, windows-ltsc2022-amd64). |
| 53 | +- Flow: |
| 54 | + 1. Check Docker availability; emit friendly guidance if missing/stopped and suggest binary fallback. |
| 55 | + 2. Resolve tag (use provided tag or fetch latest), pick platform-specific image. |
| 56 | + 3. Pull image. |
| 57 | + 4. Create container with port mapping 6262 and bind mount `~/.flowsynx/data:/app/data` (unless overridden). |
| 58 | + 5. Start container and wait for the engine to report healthy/up. |
| 59 | + 6. Persist Docker metadata + mode in `appsettings.json`. |
| 60 | + 7. Output connection info and how to run/stop. |
| 61 | + |
| 62 | +### 4) Run Command (`flowctl run --docker`) |
| 63 | +- Detect mode from `appsettings.json`; require `--docker` to enter Docker path. |
| 64 | +- Behavior: |
| 65 | + - If container exists, start it (background by default). |
| 66 | + - If missing, recreate using stored image/tag/port/mount. |
| 67 | + - `--background` keeps container detached; without it, attach logs and handle Ctrl+C gracefully. |
| 68 | +- Friendly errors when Docker is unavailable; suggest binary run when appropriate. |
| 69 | + |
| 70 | +### 5) Stop/Remove Helpers (Scoped to Engine) |
| 71 | +- `flowctl stop --docker`: stop the engine container if running. |
| 72 | +- `flowctl uninstall --docker`: remove container; prompt before removing the host data directory if requested (default is to leave `~/.flowsynx/data` intact). |
| 73 | + |
| 74 | +--- |
| 75 | + |
| 76 | +## Persistence Details (Best Course) |
| 77 | +- **Default:** Bind mount `~/.flowsynx/data` to `/app/data` to persist workflow state/db, logs/telemetry, and plugins in one place that users can inspect and back up. |
| 78 | +- **Why:** Easy to reason about, works across platforms, no hidden Docker volumes, and aligns with existing FlowSynx data expectations. |
| 79 | +- **Overrides:** Allow users to: |
| 80 | + - Supply a different host path via `--mount hostPath:/app/data`. |
| 81 | + - Opt into a named volume via `--mount flowsynx-data:/app/data` if they prefer Docker-managed storage. |
| 82 | +- Document permissions considerations for Linux/macOS when binding host paths. |
| 83 | + |
| 84 | +--- |
| 85 | + |
| 86 | +## Testing |
| 87 | +- Unit tests for Docker service (availability, pull/create/run/stop flows mocked). |
| 88 | +- Unit tests for init/run option parsing and config persistence. |
| 89 | +- No integration tests required for this scope. |
| 90 | + |
| 91 | +--- |
| 92 | + |
| 93 | +## Risks & Mitigations |
| 94 | +- Docker not installed or daemon down → clear error + link to install; suggest binary fallback. |
| 95 | +- Port 6262 conflict → detect before run/create and allow `--port` override. |
| 96 | +- Permission issues on host binds → document chmod/chown guidance; allow named volume override. |
| 97 | +- Tag/platform mismatch → auto-detect OS/arch to choose the correct tag suffix, surface a clear error if unsupported. |
| 98 | + |
| 99 | +--- |
| 100 | + |
| 101 | +## Future (Out of Scope Here) |
| 102 | +- Add Console container support (port 6264) once its config story is defined. |
| 103 | +- Broader Docker commands (logs/status/exec) and integration tests if needed. |
| 104 | +- Registry auth/PAT handling if images ever become private. |
| 105 | + |
0 commit comments