Ansible: Server On-Premise Automatizzati in 20 Minuti
Installare RAG Enterprise su un server del cliente significava 2 giorni di configurazione manuale. Oggi con i nostri playbook Ansible tutto è pronto in 20 minuti: sistema operativo blindato, servizi configurati, monitoraggio attivo. Ecco come abbiamo reso ogni deploy riproducibile.
Da 2 Giorni a 20 Minuti: Perché Ansible
Il nostro primo deploy on-premise di RAG Enterprise è stato un incubo. Due ingegneri, due giorni, un documento Google Docs di 47 passaggi. Installare dipendenze, configurare UFW, creare utenti di sistema, impostare systemd, configurare Nginx, installare Certbot, deployare il codice, configurare Qdrant, caricare i modelli di embedding. Alla fine funzionava, ma il secondo deploy ha rivelato che ci eravamo dimenticati tre passaggi e il documento era già obsoleto. Abbiamo valutato tre opzioni: Terraform, Puppet e Ansible. Terraform è eccellente per il cloud (provisioning di VM, reti, storage su AWS/GCP), ma i nostri server on-premise sono già fisicamente lì — non serve provisioning infrastrutturale. Puppet richiede un agent installato su ogni server e un master server centralizzato, una complessità eccessiva per i nostri 20-30 deploy. Ansible è agentless: si connette via SSH, esegue i task, e se ne va. Nessun software da mantenere sui server dei clienti. Il primo playbook Ansible ci ha richiesto una settimana di lavoro. Ma dal secondo deploy in poi, ogni installazione è passata da 2 giorni a 20 minuti. Un comando (ansible-playbook -i inventory.yml site.yml) e il server è pronto. Riproducibile, documentato, versionato su Git.
Playbook di Hardening e Provisioning
I nostri playbook sono organizzati in ruoli Ansible riutilizzabili. Il ruolo "base-hardening" è il primo che viene eseguito su ogni server: aggiorna il sistema, configura UFW con policy deny-all, installa e configura fail2ban, disabilita il login root via SSH, imposta l'autenticazione solo via chiave, configura unattended-upgrades per le patch di sicurezza automatiche. Questo ruolo è identico per tutti i deploy, indipendentemente dal prodotto. Il ruolo "rag-enterprise" installa tutto lo stack applicativo: Python 3.12 con virtualenv, Qdrant come servizio systemd, i modelli di embedding (che vengono scaricati da un nostro mirror privato per evitare dipendenza da HuggingFace in produzione), il backend FastAPI con Gunicorn e 4 workers, e il frontend React come file statici serviti da Nginx. Ogni componente ha il suo template Jinja2 per la configurazione — le porte, i path, i limiti di memoria sono variabili che cambiano per ogni cliente. Abbiamo anche un ruolo "monitoring" che installa node_exporter per Prometheus, configura i timer systemd per i check di salute, e imposta gli alert su Slack. L'intero stack di monitoraggio viene attivato con un singolo tag: ansible-playbook site.yml --tags monitoring. Se un cliente non vuole il monitoraggio esterno, lo escludiamo senza toccare nient'altro.
Orchestrazione Multi-Server e Aggiornamenti
Alcuni clienti enterprise hanno installazioni RAG Enterprise su più server: un server per il backend API, uno per Qdrant con più RAM, e uno per i modelli LLM locali con GPU dedicata. Ansible gestisce questa orchestrazione con un inventory file che definisce i gruppi di host. Il playbook esegue i ruoli nell'ordine corretto: prima il database Qdrant (deve essere pronto prima del backend), poi il servizio di embedding, infine il backend API che si connette a entrambi. Gli aggiornamenti dei deploy esistenti sono dove Ansible brilla di più. Quando rilasciamo una nuova versione di RAG Enterprise, il playbook di aggiornamento fa backup del database, ferma i servizi, aggiorna il codice dal nostro repository privato, esegue le migrazioni del database se necessarie, e riavvia tutto. L'idempotenza di Ansible ci garantisce che eseguire il playbook due volte non rompe nulla — se un task è già nello stato desiderato, viene saltato. Abbiamo un inventario centrale di tutti i server dei clienti (ovviamente criptato con ansible-vault). Con un singolo comando possiamo verificare lo stato di tutti i deploy: ansible all -m ping ci dice in 5 secondi quali server sono raggiungibili. Per gli aggiornamenti di sicurezza urgenti, possiamo patchare tutti i server contemporaneamente con ansible all -m apt -a "name=openssl state=latest". Questo livello di controllo centralizzato sarebbe impossibile senza automazione.
Servizi Correlati
Scopri come applichiamo queste tecnologie nei nostri progetti enterprise.
Interessato?
Contattaci per ricevere un preventivo personalizzato.
Securvita S.r.l. — i3k.eu