Étude de cas : iolite-ifrit

1. Contexte et objectifs

Problématique

Portainer est trop lourd et pas assez auditable. Iolite-ifrit est un single binary Rust qui fait la même chose en ~4.3 MB de RAM. Extensible vers un Cloud OS complet.

Pourquoi remplacer Portainer ?

2. Architecture : 14 crates workspace

Le projet est structuré en un Cargo workspace de 14 crates, chacun responsable d'un domaine fonctionnel distinct :

crates/
├── core/          # Shared types, RFC 9457 errors, YAML config
├── docker/        # Docker SDK wrapper, compose runner
├── engine/        # Deploy orchestration (recreate + blue-green)
├── server/        # Main API server (Axum, routes)
├── auth/          # Bearer token bcrypt, scopes middleware
├── logging/       # Tracing JSON, audit log
├── metrics/       # Prometheus registry
├── proxy/         # Traefik dynamic config per app
├── database/      # PostgreSQL provisioning (age-encrypted)
├── gitops/        # app.yml compiler + webhook parsing
├── observability/ # Prometheus scrape targets + alert rules
├── identity/      # Authentik SSO provisioning
├── backup/        # Restic + WAL-G backup/verify/forget
└── static-sites/  # Caddyfile generation, tar.gz deploy

Vue d'ensemble

API Server (Axum)
├── Docker Engine  → Deploy (recreate/blue-green)
├── Proxy         → Traefik dynamic config
├── Database      → PostgreSQL provisioning
├── Identity      → Authentik SSO
├── Backup        → Restic + WAL-G
├── GitOps        → Webhook handlers
└── Observability → Prometheus targets

3. Blue-green deployment

Iolite-ifrit supporte deux stratégies de déploiement : recreate (stop old, start new) et blue-green (run both, swap when healthy). Le blue-green utilise 2 stacks avec swap des labels Traefik. Rollback automatique si le health check échoue.

// Deploy strategy enum
pub enum DeployStrategy {
    Recreate,     // Stop old, start new
    BlueGreen {   // Run both, swap when healthy
        health_timeout: Duration,
        rollback_on_failure: bool,
    },
}

4. Auth avec scopes glob

L'authentification utilise des Bearer tokens avec hashing bcrypt. Les scopes supportent les glob patterns pour un contrôle d'accès flexible :

• * — accès total
• prefix-* — toutes les apps commençant par "prefix-"
• exact-match — une app spécifique

5. RFC 9457 Problem Detail

Toutes les erreurs suivent le standard RFC 9457 (Problem Details for HTTP APIs). Chaque réponse d'erreur est structurée et parseable par les clients.

#[derive(Serialize)]
pub struct ProblemDetail {
    pub r#type: String,
    pub title: String,
    pub status: u16,
    pub detail: Option<String>,
    pub instance: Option<String>,
}

6. 24 routes API

L'API expose 24 routes couvrant l'ensemble des fonctionnalités du Cloud OS :

7. Roadmap : 8 phases

Le projet a suivi une roadmap en 8 phases. Chaque phase ajoutait un module (crate) au workspace. Toutes sont complétées sauf la Phase 6 (health removed as SPOF).

8. Métriques et résultats

Performance en production

9. Enseignements