Merge _configs/ into config/ for single configuration directory. Update all path references. Changes: - Move _configs/* to config/ - Update .gitignore for new patterns - No code references to _configs/ found Impact: -1 root directory (layout_conventions.md compliance)
16 KiB
Syntaxis Provisioning Architecture
Overview
This document describes how syntaxis (binary distribution) and project-provisioning (infrastructure orchestration) integrate together to provide a complete deployment solution.
Key Principle: Clear separation of concerns with syntaxis handling what services are available and project-provisioning handling how to deploy them.
Architecture Diagram
┌─────────────────────────────────────────────────────────────────┐
│ DEVELOPER/OPERATOR │
└────────────────────────┬────────────────────────────────────────┘
↓
┌───────────────────────────────────┐
│ 1. LOCAL SETUP (laptop) │
│ ───────────────────────────── │
│ syntaxis installer: │
│ • Build binaries locally │
│ • Install to ~/.local/bin │
│ • Start services locally │
│ • Access via localhost │
└───────────────────┬───────────────┘
↓
Outputs: binaries, configs
↓
┌───────────────────────────────────┐
│ 2. REMOTE SETUP (staging/prod) │
│ ─────────────────────────────── │
│ project-provisioning: │
│ • Reads service definitions │
│ • Provisions infrastructure │
│ • Deploys services │
│ • Manages multi-host │
│ • Handles observability │
└───────────────────┬───────────────┘
↓
Infrastructure running syntaxis
Component Responsibilities
SYNTAXIS (Binary Distribution Layer)
Location: /Users/Akasha/Development/syntaxis
Responsibilities:
- ✅ Build and package binaries for multiple platforms
- ✅ Define what services are available (
configs/services-catalog.toml) - ✅ Show how to use each service (examples, ports, health checks)
- ✅ Manage local installation and setup
- ✅ Provide service metadata for integration
Does NOT do:
- ❌ Infrastructure provisioning (VMs, networks, storage)
- ❌ Multi-host deployment orchestration
- ❌ Service registry and discovery (beyond local)
- ❌ Secrets management
- ❌ Observability setup
- ❌ Complex deployment workflows
Key Files:
configs/
├── services-catalog.toml ← Central service registry
├── installation.toml ← Installation presets
└── provisioning/services/ ← Service definitions
scripts/provisioning/
├── service-catalog.nu ← Service discovery tool
├── install-with-presets.nu ← LOCAL installer only
├── pack.nu ← Bundle creation
├── install.nu ← Binary installation
└── deploy.nu ← Config deployment
docs/
├── INSTALLATION_CONTEXTS.md ← User guide for LOCAL setup
└── PROVISIONING_ARCHITECTURE.md ← This file
PROJECT-PROVISIONING (Orchestration Layer)
Location: /Users/Akasha/project-provisioning
Responsibilities:
- ✅ Read service definitions from syntaxis
- ✅ Provision infrastructure (Terraform, CloudFormation, etc.)
- ✅ Deploy services to multiple hosts
- ✅ Manage service registry and discovery
- ✅ Setup secrets and configuration management
- ✅ Configure monitoring and observability
- ✅ Implement deployment workflows (rolling, canary, blue-green)
- ✅ Handle multi-environment management
- ✅ Integration via
provctl-bridge
Does NOT do:
- ❌ Build binaries (syntaxis does that)
- ❌ Package distribution (syntaxis does that)
- ❌ User-facing installation UI (syntaxis does that)
Integration Point:
project-provisioning/platform/provctl-bridge/
├── Reads: configs/services-catalog.toml (from syntaxis)
├── Reads: configs/installation.toml (presets)
├── Reads: configs/provisioning/services/*.toml
└── Calls: provisioning/platform/* (deployment backends)
Service Catalog: The Integration Contract
What is the Service Catalog?
File: configs/services-catalog.toml
The service catalog is a complete specification of:
- What services syntaxis provides
- How to use each service
- Service dependencies and compatibility
- Networking requirements (ports, protocols)
- Resource requirements (CPU, memory, disk)
- Configuration and data locations
Example: syntaxis-api
[service.syntaxis-api]
name = "syntaxis-api"
display_name = "syntaxis REST API"
description = "REST API server for programmatic access"
type = "server"
[service.syntaxis-api.server]
default_host = "127.0.0.1"
default_port = 3000
scheme = "http"
[service.syntaxis-api.usage]
health_check_endpoint = "/health"
examples = [
"syntaxis-api --bind 127.0.0.1:3000",
"curl http://127.0.0.1:3000/health",
]
[service.syntaxis-api.dependencies]
requires = ["syntaxis-cli"]
How project-provisioning Uses It
# 1. Read service definitions
nu scripts/provisioning/service-catalog.nu export dev
# 2. Get service details
cat configs/services-catalog.toml | grep -A 20 '\[service.syntaxis-api\]'
# 3. Generate infrastructure as code
# For Terraform:
resource "docker_container" "syntaxis_api" {
image = "syntaxis:latest"
ports = {
"3000" = "3000" # from services-catalog.toml
}
healthcheck = {
test = ["CMD", "curl", "-f", "http://localhost:3000/health"]
# from service definition
}
}
# 4. Deploy to infrastructure
provctl provision --preset dev --backend terraform
How to Use the System
Scenario 1: Local Development (Use syntaxis)
# 1. List available presets
nu scripts/provisioning/install-with-presets.nu --list-presets
# 2. View what's in a preset
nu scripts/provisioning/service-catalog.nu preset dev
# 3. Install locally
nu scripts/provisioning/install-with-presets.nu --preset dev
# 4. Start services
syntaxis-api --bind 127.0.0.1:3000
surreal start --bind 127.0.0.1:8000 memory
# 5. Check health
curl http://127.0.0.1:3000/health
# 6. Access dashboard
open http://127.0.0.1:8080 # requires syntaxis-api running
Responsibility: syntaxis
- Shows what's available (via service catalog)
- Installs binaries and configs locally
- Provides usage examples
Scenario 2: Remote Deployment (Use project-provisioning)
# 1. Export preset for infrastructure deployment
nu scripts/provisioning/service-catalog.nu export staging
# 2. Use project-provisioning to deploy
cd /Users/Akasha/project-provisioning
# 3. Deploy using provctl-bridge
provctl provision \
--preset staging \
--version 0.1.0 \
--environment staging \
--backend terraform
# 4. Monitor deployment
provctl status staging
# 5. Access deployed services
curl https://api.staging.example.com/health
open https://dashboard.staging.example.com
Responsibility: project-provisioning
- Reads service definitions from syntaxis
- Provisions infrastructure
- Deploys services to remote infrastructure
- Manages secrets, monitoring, load balancing
- Handles multi-environment and high availability
Scenario 3: Discovering Available Services
# List all services
nu scripts/provisioning/service-catalog.nu list
# Get details about a specific service
nu scripts/provisioning/service-catalog.nu info syntaxis-api
# See how to use a service
nu scripts/provisioning/service-catalog.nu usage syntaxis-api
# View port mappings
nu scripts/provisioning/service-catalog.nu ports
# See deployment patterns
nu scripts/provisioning/service-catalog.nu patterns
Responsibility: syntaxis (service catalog)
- Maintains complete service metadata
- Provides discovery and documentation
- Shows examples and usage patterns
- Enables integration with project-provisioning
Integration Points
1. Service Definitions Contract
What project-provisioning reads from syntaxis:
configs/services-catalog.toml
├── Service metadata (name, description, type)
├── Network configuration (host, port, scheme)
├── Health checks (endpoint, method, status)
├── Dependencies (requires, conflicts)
├── Resource requirements (CPU, memory, disk)
├── Configuration locations
├── Usage examples
└── Deployment patterns
2. Preset Composition Contract
How presets define service combinations:
[preset.staging]
name = "Staging"
database_backend = "surrealdb"
[preset.staging.services]
syntaxis_cli = { enabled = false }
syntaxis_tui = { enabled = false }
syntaxis_api = { enabled = true, auto_start = true, port = 3000 }
surrealdb = { enabled = true, auto_start = true, port = 8000 }
nats = { enabled = true, auto_start = true, port = 4222 }
Project-provisioning reads this to understand:
- Which services to deploy
- Service dependencies and ordering
- Port assignments
- Auto-start behavior
3. Binary Distribution Contract
What project-provisioning receives from syntaxis:
Distribution bundles:
├── syntaxis-v0.1.0.tar.gz ← Contains all binaries
├── SHA256SUMS ← Integrity verification
└── manifest.toml ← Installation tracking
Project-provisioning:
- Verifies bundle integrity
- Extracts binaries
- Deploys to infrastructure
- Starts services per preset
4. provctl-bridge Contract
How project-provisioning calls syntaxis infrastructure code:
# project-provisioning calls provctl-bridge to:
provctl-bridge read-services \
--preset dev \
--from ~/Development/syntaxis/configs
provctl-bridge generate-deployment \
--preset staging \
--backend kubernetes \
--output kubernetes/manifest.yaml
provctl-bridge export-config \
--preset production \
--output terraform/variables.tfvars
Data Flow Examples
Example 1: User wants to deploy staging environment
Step 1: syntaxis provides service definitions
├─ User runs: nu service-catalog.nu preset staging
└─ Output: YAML/JSON with service list, ports, health checks
Step 2: User exports for project-provisioning
├─ User runs: nu service-catalog.nu export staging > /tmp/staging.yaml
└─ File contains: service names, ports, dependencies, examples
Step 3: project-provisioning reads service definitions
├─ Read: configs/services-catalog.toml
├─ Read: configs/installation.toml [preset.staging]
└─ Output: Infrastructure as Code (Terraform)
Step 4: project-provisioning deploys
├─ Provision VMs for each service
├─ Install syntaxis binaries
├─ Start services per preset
├─ Setup monitoring and health checks
└─ Configure load balancers and DNS
Step 5: User accesses deployed system
├─ curl https://api.staging.example.com/health
├─ open https://dashboard.staging.example.com
└─ View metrics in Grafana
Example 2: User adds a new service to syntaxis
Step 1: Define service in syntaxis
├─ Edit: configs/services-catalog.toml
├─ Add: [service.my-new-service]
└─ Specify: binary, port, health check, dependencies
Step 2: Add to preset
├─ Edit: configs/installation.toml
└─ Add to [preset.X.services]: my_new_service = { enabled = true }
Step 3: Build binary
├─ cargo build --release
└─ nu scripts/provisioning/pack.nu
Step 4: Test service discovery
├─ nu service-catalog.nu info my-new-service
├─ nu service-catalog.nu preset dev
└─ nu service-catalog.nu usage my-new-service
Step 5: project-provisioning auto-discovers
├─ Next deployment automatically includes new service
├─ Health checks configured automatically
├─ Port assignments automatic
└─ No changes needed to provisioning code!
Architecture Principles
1. Configuration Driven
Both systems use TOML configuration as the source of truth:
- No hardcoded service definitions
- Extensible without code changes
- Easy to audit and version control
2. Separation of Concerns
syntaxis: "What is available?"
- Binary distribution
- Service metadata
- Usage documentation
project-provisioning: "How to deploy it?"
- Infrastructure provisioning
- Multi-host orchestration
- Monitoring and observability
3. Delegation Pattern
When a request doesn't match a system's responsibility:
- syntaxis redirects to project-provisioning for remote deployments
- project-provisioning reads metadata from syntaxis
4. Contract-Based Integration
Systems communicate via:
- Configuration files (TOML)
- Exported data (YAML/JSON)
- Well-defined interfaces (provctl-bridge)
- No tight coupling or hardcoded paths
Future Extensions
For syntaxis:
-
Enhanced Service Discovery
- Expose service catalog via REST API
- Service availability check:
nu service-catalog.nu validate-local - Real-time service status monitoring
-
Advanced Usage Patterns
- Service dependency graphing
- Automatic startup ordering
- Service interaction examples
-
Configuration Generation
- Generate nginx/caddy configs from port definitions
- Generate docker-compose.yml from preset
- Generate systemd unit files
For project-provisioning integration:
-
Bidirectional Updates
- project-provisioning exports deployment status back to syntaxis
- Service health propagates from infrastructure to local
- Metrics flow back to developer environment
-
Plugin System
- Custom validators for service dependencies
- Custom deployment backends
- Custom health check definitions
-
Template Generation
- Helm charts from presets
- Terraform modules for each service
- Kubernetes manifests from presets
Implementation Status
Current (Implemented)
✅ Service catalog with complete metadata ✅ Preset composition system ✅ Service discovery tool (service-catalog.nu) ✅ Usage documentation and examples ✅ Port and networking specifications ✅ Dependency tracking
Planned
🔲 REST API for service catalog 🔲 Real-time service status monitoring 🔲 Advanced deployment patterns (canary, blue-green) 🔲 Automatic nginx/docker-compose generation 🔲 Bidirectional integration with project-provisioning
Quick Reference
For Developers (Local Setup)
# Discover what's available
nu scripts/provisioning/service-catalog.nu list
# See what's in a preset
nu scripts/provisioning/service-catalog.nu preset dev
# Install and setup locally
nu scripts/provisioning/install-with-presets.nu --preset dev
# Start services
syntaxis-api --bind 127.0.0.1:3000
For DevOps (Remote Deployment)
# Export preset for infrastructure
nu scripts/provisioning/service-catalog.nu export staging > /tmp/staging.yaml
# Use project-provisioning to deploy
cd /Users/Akasha/project-provisioning
provctl provision --preset staging --backend kubernetes
For Integration
# Read service metadata
cat configs/services-catalog.toml
# Check preset composition
cat configs/installation.toml | grep -A 20 '\[preset.production\]'
# Export for external systems
nu scripts/provisioning/service-catalog.nu export dev
Related Documentation
- INSTALLATION_CONTEXTS.md - User guide for LOCAL setup
- ADVANCED_INSTALLATION.md - Advanced scenarios and troubleshooting
- IMPLEMENTATION_SUMMARY.md - Complete file manifest
- CLAUDE.md - Development reference
- project-provisioning documentation - Infrastructure orchestration details
Document Version: 1.0.0 Last Updated: 2025-11-19 Architecture: syntaxis (distribution) + project-provisioning (orchestration)