Contesto: Review sicurezza superata il 9 marzo. Via libera al pilota. Questo documento definisce l'architettura Docker per il deploy su server fisico Emisfera.
Partecipanti: Giobi (consulente architettura), Puddu (referente tecnico interno, root server).
Obiettivo: Validare le 8 decisioni architetturali e definire i prossimi step per la simulazione.
Principio guida
Tutto Docker. Niente mele e arance.
Brain admin, workspace, servizi: tutti container. Stack uniforme = manutenzione uniforme. Se tutto si gestisce uguale, tutto si mantiene uguale.
Sacrificabile. Se muore, si ricostruisce in secondi. Python, git, tool brain — tutto preconfigurato nell'immagine.
Insostituibile. File markdown su filesystem host, versionati con Git. Sopravvive a qualsiasi crash del container.
Le 8 decisioni
Tutto Docker
Ogni componente è un container. Brain admin = container privilegiato con Docker socket. Workspace = container isolati. Niente eccezioni bare metal.
Fasi rollout: Alpha → Beta → Prod
Container model
No servizi esterni
Integrazioni + WebSSH
Brain = dati su host
Brain data (wiki/, diary/, todo/, boot/) su filesystem host, versionati Git, montati nei container come volume. Container = ambiente sacrificabile.
Container isolati
Zero comunicazione tra workspace. Ogni container è una bolla. Shared/ montata read-only. API esterne whitelistate a livello di network policy Docker.
Image minimali
Base image leggera (Python, git, tool brain). Si scala per chi serve (Node, compilatori). Default = minimo vitale.
Cold start / auto-shutdown
Container on-demand: spin up quando l'utente si collega, shutdown dopo timeout inattività. Brain admin gestisce il lifecycle. Cold start ~2-3 secondi con image minimale.
Monitoring custom
Brain admin con health check loop: stato container, uptime, risorse. Dashboard HTML minimale. Alert via email/canale interno. Niente Zabbix/Nagios — overkill per 5-6 container.
Rolling update + rollback
Image Docker taggate semanticamente. Brain admin fa rolling update (un container alla volta, verifica, poi prossimo). Ultime 3 versioni sempre disponibili per rollback istantaneo.
Struttura target
Server Emisfera (on-premise, fisico)
│
├── /var/emibrain/brains/ # Brain data (host, git versioned)
│ ├── giobi/
│ ├── puddu/
│ ├── ricci/
│ ├── franzini/
│ ├── stagista/
│ └── shared/ # Knowledge base (fase Prod)
│
└── Docker containers:
├── emibrain-admin # Brain admin (privilegiato)
├── emibrain-ws-giobi # Workspace (on-demand)
├── emibrain-ws-puddu
├── emibrain-ws-ricci
├── emibrain-ws-franzini
├── emibrain-ws-stagista
└── emibrain-webssh # WebSSH proxy (fase Beta)
Utenti Alpha
| Giobi | Consulente esterno |
| Puddu | Referente tecnico + root |
| Ricci | PM |
| Paola Franzini | CFO |
| Stagista | TBD |
API & Connettività
- Claude Enterprise — gestione utenti/chiavi centralizzata
- Outbound — blindato, solo lettura siti web inizialmente
- Whitelisting — apertura graduale concordata con Puddu
- Billing — tracking per utente (per la CFO)
Container lifecycle
Cold start / auto-shutdown
Cold start ~2-3 sec con image minimale. Brain resta su host, intatto.
Rolling update
Rollback: emibrain rollback v1.1 — 10 secondi, ultime 3 versioni sempre disponibili.
Il Brain Admin
Container privilegiato con Docker socket. Gestisce tutto il lifecycle degli altri container.
Sicurezza
Container isolati
Zero comunicazione tra workspace. Ogni container è una bolla con network namespace separato.
Shared read-only
La cartella condivisa è montata read-only in ogni container. Solo il brain admin può scriverci.
Outbound blindato
Inizialmente solo lettura siti web. API whitelistate progressivamente. Solo Claude Enterprise come AI provider.
Audit trail
Brain admin logga ogni azione (creazione workspace, accesso, modifiche container). Git traccia ogni modifica ai brain data. Log indipendenti e ispezionabili.
Brain versionati su host
I dati non sono dentro i container. Backup con gli strumenti standard di Emisfera. Git per versioning. Il container può morire, il brain sopravvive.
Roadmap
Alpha — Infrastruttura
Siamo quiMarzo 2026
- • Definizione architettura Docker (questo talk)
- • Simulazione su server test
- • Dockerfile base + brain admin container
- • Primo workspace funzionante con SSH
Beta — Utenti con brain puro
Da completamento Alpha
- • 5 workspace attivi (Giobi, Puddu, Ricci, Franzini, stagista)
- • Solo brain, nessun servizio esterno
- • Accesso via SSH (power user) + WebSSH (se fixato)
- • Git auto-commit per versioning brain
Prod — Servizi e integrazioni
Da validazione Beta
- • Shared/ aperta con knowledge base aziendale
- • WebSSH stabile per utenti non-tecnici
- • Integrazioni whitelistate (email, documenti)
- • Packages installabili per workspace
Domande aperte per Puddu
Punti da discutere e decidere insieme prima della simulazione.
Specs del server fisico
Quale macchina? RAM, CPU, disco. Per 5-6 container con cold start servono risorse minime, ma meglio saperlo.
Connessione Efesto ↔ server Emisfera
SSH diretto? Tailscale? VPN site-to-site? Per la fase Alpha serve che Giobi possa accedere da remoto.
Brain admin: cosa vede degli altri brain?
Solo metadati (stato container, risorse, log) o anche contenuto workspace? Definire scope per audit trail.
Git: un repo per brain o mono-repo?
Repo separati scalano meglio. Mono-repo più semplice da backuppare. Chi fa commit? Automatico o manuale?
Onboarding utenti non-tecnici
Paola Franzini (CFO) non apre un terminale. Aspettiamo WebSSH per lei, o troviamo un'alternativa per la Beta?
Backup & disaster recovery
Git per versioning, ma il backup infrastrutturale si aggancia ai sistemi Emisfera esistenti. Quale sistema usate?