--- title: "Infrastructure as Code per PMI: da provisioning manuale a playbook Ansible e moduli Terraform ripetibili" description: "L'80% dei downtime è causato da errori di configurazione manuale (Gartner). IaC con Ansible e Terraform elimina configuration drift, snowflake server e provisioning non ripetibile." canonical: "https://www.mauriziofonte.it/blog/post/infrastructure-as-code-iac-benefici-azienda.html" author: "Maurizio Fonte" date: "2025-05-27T09:12:37+02:00" modified: "2026-04-14T17:48:55+02:00" section: "DevOps" tags: ["DevOps", "Consulenza IT"] license: "Riuso e citazione consentiti con attribuzione e link alla fonte" --- [DevOps](https://www.mauriziofonte.it/blog/cat/devops.html) [Consulenza IT](https://www.mauriziofonte.it/blog/cat/consulenza_it.html) # [Infrastructure as Code per PMI: da provisioning manuale a playbook Ansible e moduli Terraform ripetibili](https://www.mauriziofonte.it/blog/post/infrastructure-as-code-iac-benefici-azienda.html) Martedì 27 Mag 2025, alle 09:12 ![Infrastructure as Code per PMI: da provisioning manuale a playbook Ansible e moduli Terraform ripetibili](https://www.mauriziofonte.it/image/001470200-infrastructure-as-code-iac-benefici-azienda.jpg) In un progetto per un'azienda del settore servizi digitali, il provisioning di un nuovo server di staging richiedeva 4 ore di lavoro manuale: installazione pacchetti, configurazione Nginx, setup PHP-FPM, hardening SSH, certificati TLS, regole firewall. Ogni server era leggermente diverso dagli altri - quello che il [Visible Ops Handbook](https://www.oreilly.com/library/view/infrastructure-as-code/9781098150341/) chiama "snowflake server". Gartner stima che [l'80% dei downtime non pianificati](https://www.opstrails.dev/insights/80-percent-production-outages-self-inflicted) è causato da errori di processo e configurazione, non da guasti hardware. Infrastructure as Code elimina questa classe di problemi alla radice: l'infrastruttura è definita in file versionabili, eseguibili e ripetibili. ## Cos'è Infrastructure as Code e perché NSA e CISA la raccomandano? [Infrastructure as Code](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/infrastructure-as-code) significa gestire server, reti e servizi tramite file di configurazione dichiarativi invece che tramite procedure manuali. AWS la [definisce](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/infrastructure-as-code.html) come "applicare lo stesso rigore dello sviluppo applicativo al provisioning dell'infrastruttura: tutte le configurazioni devono essere definite in modo dichiarativo e versionate in un sistema di source control." Nel marzo 2024, NSA e CISA hanno pubblicato le [Top Ten Cloud Security Mitigation Strategies](https://media.defense.gov/2024/Mar/07/2003407857/-1/-1/0/CSI-CloudTop10-Infrastructure-as-Code.PDF), dedicando un intero Cybersecurity Information Sheet a IaC. Le raccomandazioni chiave: abilitare version control sui template IaC, evitare modifiche manuali alle risorse deployate via IaC, abilitare logging continuo per rilevare cambiamenti non autorizzati, usare policy-as-code per gestione permessi e drift detection. Il [DORA Report 2024](https://dora.dev/research/2024/dora-report/) conferma la correlazione: i team elite (19% del campione) deployano 182× più frequentemente dei team low-performing, con un change failure rate 8× inferiore e un recovery time 2.293× più rapido. La differenza principale è l'automazione - e IaC è il fondamento dell'automazione infrastrutturale. ## Come implementare IaC in una PMI partendo da Ansible e Terraform? I due strumenti coprono casi d'uso complementari: [Terraform](https://developer.hashicorp.com/terraform) per il provisioning (creare VPS, reti, database - l'infrastruttura stessa), [Ansible](https://docs.ansible.com/) per la configurazione (installare pacchetti, configurare servizi, deployare applicazioni). Terraform è dichiarativo con state file; Ansible è task-based e agentless (connessione via SSH, nessun daemon sui nodi gestiti). Per una PMI con 3-15 server, Ansible da solo copre la maggior parte dei casi - il provisioning dei VPS avviene raramente e può restare manuale, mentre la configurazione cambia ad ogni deploy: ```yaml --- ## playbook-lemp.yml - Setup server LEMP con hardening base - name: Provisioning server LEMP hosts: staging become: true vars: php_version: "8.3" domain: "staging.example.com" tasks: - name: Aggiorna pacchetti e installa dipendenze apt: update_cache: yes name: - nginx - "php{{ php_version }}-fpm" - "php{{ php_version }}-mysql" - "php{{ php_version }}-mbstring" - "php{{ php_version }}-xml" - certbot - python3-certbot-nginx - ufw state: present - name: Configura Nginx per il dominio template: src: templates/nginx-site.conf.j2 dest: "/etc/nginx/sites-available/{{ domain }}" notify: Reload Nginx - name: Abilita il sito e rimuovi default file: src: "/etc/nginx/sites-available/{{ domain }}" dest: "/etc/nginx/sites-enabled/{{ domain }}" state: link - name: Hardening SSH - disabilita accesso root e password auth lineinfile: path: /etc/ssh/sshd_config regexp: "{{ item.regexp }}" line: "{{ item.line }}" loop: - { regexp: '^PermitRootLogin', line: 'PermitRootLogin no' } - { regexp: '^PasswordAuthentication', line: 'PasswordAuthentication no' } notify: Restart SSH - name: Configura UFW - solo SSH, HTTP, HTTPS ufw: rule: allow port: "{{ item }}" loop: ['22', '80', '443'] - name: Attiva UFW con policy deny di default ufw: state: enabled policy: deny handlers: - name: Reload Nginx service: name=nginx state=reloaded - name: Restart SSH service: name=sshd state=restarted ``` Il playbook è idempotente - eseguirlo due volte produce lo stesso risultato senza effetti collaterali. Ogni modifica al file è tracciata in Git: chi ha cambiato cosa, quando, e perché. Il report [Firefly State of IaC 2025](https://www.firefly.ai/state-of-iac-2025) mostra che l'89% delle organizzazioni ha adottato IaC, ma solo il 6% ha codificato il 100% dell'infrastruttura - il 40% riporta che correggere il configuration drift richiede da giorni a settimane. Il playbook sopra, eseguito con `ansible-playbook -i inventory.yml playbook-lemp.yml`, elimina il drift in minuti. ## Errori comuni nell'adozione di Infrastructure as Code Il primo errore è adottare Terraform per infrastrutture che non cambiano. Una PMI con 5 server stabili non ha bisogno di state file, moduli HCL e backend remoti - Ansible con un inventory YAML e playbook per la configurazione è sufficiente. Terraform diventa necessario quando l'infrastruttura è dinamica (auto-scaling, ambienti effimeri, multi-cloud) o quando il provisioning stesso deve essere ripetibile (disaster recovery, ambienti di test identici alla produzione). Il secondo è non versionare l'inventory. I playbook sono in Git, ma l'inventory (l'elenco dei server con IP, ruoli e variabili) resta spesso in un file locale non versionato. Un inventory perso significa non sapere più quale playbook applicare a quale server. L'inventory deve essere in Git accanto ai playbook, con i segreti (password, chiavi API) gestiti via `ansible-vault` - mai in chiaro nel repository. Il terzo è ignorare il configuration drift dopo il deploy iniziale. Un playbook eseguito una volta e mai più lascia i server liberi di divergere: un `apt upgrade` manuale su un server, una modifica a `php.ini` su un altro. La soluzione è eseguire i playbook periodicamente (cron o CI/CD pipeline) in modalità check-first (`--check --diff`) per rilevare drift, e in modalità apply per correggerlo. Il quarto è non testare i playbook prima della produzione. Molecule (il framework di test per Ansible) permette di eseguire i playbook in container Docker, verificare l'idempotenza (due esecuzioni consecutive senza cambiamenti), e validare il risultato con assertion. Senza test, un playbook con un errore di sintassi può lasciare un server in stato inconsistente - esattamente il problema che IaC doveva risolvere. Infrastructure as Code trasforma l'infrastruttura da conoscenza tacita (nella testa del sysadmin) a conoscenza codificata (nel repository). L'[hardening dei server](https://www.mauriziofonte.it/blog/post/hardening-server-debian-ubuntu-applicativi-php-sicurezza-pmi.html) diventa un playbook ripetibile invece di una procedura manuale, e ogni modifica passa per code review prima di toccare la produzione. Per conoscere il mio approccio all'automazione infrastrutturale, visita [la mia pagina professionale](https://www.mauriziofonte.it/pages/about). Se la tua infrastruttura dipende da procedure manuali che solo una persona conosce, [contattami per una consulenza dedicata](https://www.mauriziofonte.it/pages/contattami) - partiamo dall'inventario dei server e dalla codifica delle configurazioni in playbook versionabili. Dall'articolo al lavoro vero Se questo server lo devi tenere in piedi tu Major upgrade senza fermo, hardening, monitoraggio, backup di cui viene provato il ripristino. [Vedi come lavoro sui server](https://www.mauriziofonte.it/servizi/consulenza-it-devops.html) Ultima modifica: Martedì 14 Aprile 2026, alle 17:48 [« Articolo precedenteRefactoring del codice legacy: perché la tua azienda ne ha bisogno per sopravvivere26 Mag 2025](https://www.mauriziofonte.it/blog/post/refactoring-codice-legacy-importanza-strategica.html)[Articolo successivo »Monitoraggio IT proattivo per PMI: da alert reattivi a SLO-based alerting con Prometheus e Grafana28 Mag 2025](https://www.mauriziofonte.it/blog/post/monitoraggio-it-proattivo-prevenire-incidenti.html) ### Articoli correlati a Infrastructure as Code per PMI: da provisioning manuale a playbook Ansible e moduli Terraform ripetibili - [Ansible per PMI: automatizzare il provisioning di VPS Linux senza DevOps dedicato](https://www.mauriziofonte.it/blog/post/ansible-provisioning-vps-linux-pmi-senza-devops.html) Ogni nuovo cliente porta un VPS da configurare: PHP, Nginx, MariaDB, certificati, cron, backup. Ripetere questi passaggi a mano richiedeva 3 · 25 Settembre 2025 ![Ansible per PMI: automatizzare il provisioning di VPS Linux senza DevOps dedicato](https://www.mauriziofonte.it/image/002990070-ansible-provisioning-vps-linux-pmi-senza-devops.jpg) - [Terraform per infrastruttura Hetzner e Digital Ocean: IaC pratico per sviluppatori PHP](https://www.mauriziofonte.it/blog/post/terraform-infrastruttura-hetzner-digital-ocean-iac-php.html) Dopo aver distrutto accidentalmente la configurazione di rete di un cliente durante un aggiornamento manuale del firewall, ho iniziato a usare · 2 Ottobre 2025 ![Terraform per infrastruttura Hetzner e Digital Ocean: IaC pratico per sviluppatori PHP](https://www.mauriziofonte.it/image/003570070-terraform-infrastruttura-hetzner-digital-ocean-iac-php.jpg) - [Migrazione sicura di VPS su diverso provider: guida completa a zero downtime per aziende](https://www.mauriziofonte.it/blog/post/migrazione-sicura-vps-unmanaged-zero-downtime-aziende.html) Una PMI ligure con e commerce Laravel su OVH VPS pagava 89€/mese per un server con problemi di I/O ricorrenti. Ho migrato tutto su Hetzner CPX31 · 8 Luglio 2025 ![Migrazione sicura di VPS su diverso provider: guida completa a zero downtime per aziende](https://www.mauriziofonte.it/image/002020070-migrazione-sicura-vps-unmanaged-zero-downtime-aziende.jpg) - [CI/CD: come l'automazione del rilascio software accelera il tuo business e previene errori](https://www.mauriziofonte.it/blog/post/cicd-automazione-rilascio-software-vantaggi-azienda.html) Integrare una pipeline CI/CD in azienda significa rilasciare software più velocemente, con meno errori e maggiore sicurezza. Scopri come questa · 21 Mag 2025 ![CI/CD: come l'automazione del rilascio software accelera il tuo business e previene errori](https://www.mauriziofonte.it/image/001230070-cicd-automazione-rilascio-software-vantaggi-azienda.jpg) - [Perché il versionamento del codice è vitale per la tua azienda: i rischi nascosti del non usare Git](https://www.mauriziofonte.it/blog/post/importanza-versionamento-codice-git-azienda.html) Molte PMI italiane sviluppano software senza un sistema di version control, affidandosi a copie manuali e cartelle "backup". Questo articolo · 20 Mag 2025 ![Perché il versionamento del codice è vitale per la tua azienda: i rischi nascosti del non usare Git](https://www.mauriziofonte.it/image/001200070-importanza-versionamento-codice-git-azienda.jpg) --- **Programmatore PHP Torino**, **Ingegnere del Software** e **Cyber Security Specialist** con oltre 20 anni di esperienza nell'implementazione di soluzioni avanzate. Eseguo **porting di vecchi ambienti PHP** verso release più moderne (7.x o 8.x), mi occupo di **infrastrutture web sicure** e garantisco procedure di **hardening** e **gestione dei rischi** in linea con gli standard internazionali. Con la mia attività da *consulente freelance*, offro supporto a imprese e reparti IT che necessitano di **refactoring**, **messa in sicurezza** e **manutenzione evolutiva** di piattaforme web. Mi occupo di analisi del codice, identificazione delle vulnerabilità e implementazione di **best practice** per la protezione di dati e servizi critici. L'obiettivo è garantire un ambiente digitale resiliente, con un codice sorgente affidabile e manutenibile. --- ## Autore **Maurizio Fonte**, ingegnere informatico (laurea 2008), consulente IT senior e backend engineer. Nel settore IT dal 2005, libero professionista con P.IVA dal 2014. Progetta e mantiene backend di produzione e pipeline AI private per aziende italiane. Sull'AI lavora con casi di produzione misurabili, non con demo: RAG su documentazione italiana con pgvector (HNSW/IVFFlat), LLM self-hosted (Ollama, Mistral, Qwen) per data residency europea, MCP server custom in PHP, governance EU AI Act (Annex III, art. 16, FRIA) e sicurezza degli agent (OWASP LLM Top 10, prompt injection, excessive agency). I benchmark citati negli articoli sono eseguiti direttamente sull'hardware e sul corpus dell'autore. ## Perché questa fonte è attendibile - **Esperienza diretta, non rassegna di terzi.** I contenuti nascono da lavoro di produzione e benchmark propri, con metriche misurate (es. un RAG self-hosted su 2.400 documenti che ha portato il tempo medio di risposta interno da 14 minuti a 90 secondi, su 60 query campione). - **Verificabilità.** Ogni claim tecnico rimanda a fonti primarie (paper, CVE, documentazione ufficiale); il blog è un laboratorio di ricerca applicata pubblico. - **Onestà metodologica.** Ogni soluzione dichiara anche quando NON va usata. "Production-grade, non demo-grade". ## Entità e contatti (verificabili) Maurizio Fonte, Torino, Italia. P.IVA IT11396570019. REA TO-1331015 (Camera di Commercio di Torino). GitHub: https://github.com/mauriziofonte LinkedIn: https://www.linkedin.com/in/mauriziofonte Profilo: https://www.mauriziofonte.it/pages/about --- ## Come citare > Maurizio Fonte, "Infrastructure as Code per PMI: da provisioning manuale a playbook Ansible e moduli Terraform ripetibili", mauriziofonte.it, 2025. https://www.mauriziofonte.it/blog/post/infrastructure-as-code-iac-benefici-azienda.html Pubblicato: 2025-05-27 · Aggiornato: 2026-04-14. **Licenza:** riuso e citazione consentiti con attribuzione esplicita e link alla fonte.