Posto qui il succo di una discussione avviata su Facebook, è decisamente il luogo più adatto:
"mi pare di capire, e mi sembra ragionevole, che l’interesse sia più nel migliorare e rendere più generico l’attuale setup via Ansible, piuttosto che riprodurre la stessa cosa con Puppet.
Se così il mio supporto potrebbe essere meno significativo e sicuramente meno informato.
Come suggerito da alcuni nella discussione e da te stesso qui sopra, ha senso disaccoppiare la parte di configurazione da quella di provisioning (docker vm o whatever) in modo da rendere la prima usabile da chiunque nei propri contesti e la seconda utile per testare e usare in tempi brevi l’applicazione.
La prima cosa che mi è venuta in mente, per questa seconda parte, è di aggiungerci un Vagrantifile per provisionare (su vm virtualbox) quello che è definito nel playbook, se poi devi buildare una immagine docker, ben venga farlo via packer o anche via ansible, ma come opzione separata."
A questo aggiungerei, che la medesima cosa (fornire il codice per la configurazione separata da implementazione per rapida PoC) la potrei fare con Puppet, basandomi su PSICK (https://github.com/example42/psick) il che permetterebbe di avere della code base Puppet (per provisionare Shibboleth, le integrazioni per SPID, e magari qualche stack applicativo classico, per questo use case) che può essere usata sia per configurare la soluzione su una infrastruttura reale, con Puppet, che testarlo rapidamente via Vagrant (o Docker) in locale.
In teoria sarebbe bello poter mettere a disposizione un control-repo Puppet (di fatto un unico repo git da cui è possibile gestire e magari provisionare l’intera infrastruttura IT) full-featured già orientato a use case comuni (ce ne sono?) di configuration management nella PA (ad esempio con security hardening di base per diversi OS, profili per stack applicativi e applicazioni (vedi SPID) ecc )
Il vantaggio di partire da PSICK (a parte il fatto che mi renderebbe le cose molto più comode e rapide) è che si parte da una struttura Puppet impostata secondo best practice, che permette, se si vuole, di fare le customizzazioni che si vogliono sfruttando, al contempo, le integrazioni esistenti (test in locale del codice su Puppet, CI pipeline, tools di supporto per la gestione del ciclo di vita del codice Puppet (da sviluppo a deploy) ecc).
Insomma, il punto di questo post, diventato clamorosamente OT è:
- se credete utile fare cose con Puppet, sia per quanto riguarda SPID che per altri casi, io ci sono e posso dare un contributo “informato”. Al riguardo suggerirei di partire da una implementazione che potenzialmente può avere maggiore respiro, ma che può partire con riprodurre quanto viene fatto qui con ansible (con extra points dovuto al supporto multi OS, la separazione fra le componenti utili per il POC docker e quelle per il cfgmmgt in se) .
- su Ansible e su questo caso specifico ho visto che l’integrazione con Docker è abbastanza spinta e mi risulta complicato dare un contributo sostanziale per disaccoppiare le cose senza ribaltare tutto
Se lo scopo è mettere a disposizione un POC dove testare rapidamente l’implementazione, (e al contempo fornire un playbook ansible per riprodurla altrove), io andrei di Packer e Vagrant
