syntaxis/docs/provisioning-architecture.md
Jesús Pérez 9cef9b8d57 refactor: consolidate configuration directories
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)
2025-12-26 18:36:23 +00:00

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:

  1. Build and package binaries for multiple platforms
  2. Define what services are available (configs/services-catalog.toml)
  3. Show how to use each service (examples, ports, health checks)
  4. Manage local installation and setup
  5. 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:

  1. Read service definitions from syntaxis
  2. Provision infrastructure (Terraform, CloudFormation, etc.)
  3. Deploy services to multiple hosts
  4. Manage service registry and discovery
  5. Setup secrets and configuration management
  6. Configure monitoring and observability
  7. Implement deployment workflows (rolling, canary, blue-green)
  8. Handle multi-environment management
  9. 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:

  1. What services syntaxis provides
  2. How to use each service
  3. Service dependencies and compatibility
  4. Networking requirements (ports, protocols)
  5. Resource requirements (CPU, memory, disk)
  6. 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:

  1. Verifies bundle integrity
  2. Extracts binaries
  3. Deploys to infrastructure
  4. 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:

  1. Enhanced Service Discovery

    • Expose service catalog via REST API
    • Service availability check: nu service-catalog.nu validate-local
    • Real-time service status monitoring
  2. Advanced Usage Patterns

    • Service dependency graphing
    • Automatic startup ordering
    • Service interaction examples
  3. Configuration Generation

    • Generate nginx/caddy configs from port definitions
    • Generate docker-compose.yml from preset
    • Generate systemd unit files

For project-provisioning integration:

  1. Bidirectional Updates

    • project-provisioning exports deployment status back to syntaxis
    • Service health propagates from infrastructure to local
    • Metrics flow back to developer environment
  2. Plugin System

    • Custom validators for service dependencies
    • Custom deployment backends
    • Custom health check definitions
  3. 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


Document Version: 1.0.0 Last Updated: 2025-11-19 Architecture: syntaxis (distribution) + project-provisioning (orchestration)