Una delle tecnologie molto promettenti nell’ambito DevOps in Windows è senza dubbio Powershell, un linguaggio di scripting potente che permette di sfruttare tutta la potenza degli oggetti .NET, ma nel contempo utilizzare paradigmi tipici delle shell avanzate di Unix/Linux come il piping dei comandi etc.

In powershell, recentemente sta prendendo forma una particolare tecnologia chiamata DSC ovvero Desired State Configuration, che permetterà di ridurre molto la frizione che accade tra Dev ed Ops per quanto riguarda il deploy.

Non è questa la sede per fare una descrizione dettagliata su DSC, visto che vi sono molte risorse a disposizione nei vari blog Microsoft, ma vorrei soffermarmi sugli aspetti più interessanti che la rendono molto appetibile come tecnologia su cui basare i propri script di Deploy.

Di base uno script DSC definisce una funzione con una keyword specifica chiamata Configuration la quale permette appunto di specificare una configurazione che si vuole avere su uno o più macchine (nodi) targets. A questo punto nello script si indicano alcune configurazioni finali desiderate per i vari nodi su cui lo script dovrà operare. ES:

[sourcecode language='powershell'  padlinenumbers='true']
Configuration ContosoWebsite 
{ 
  param ($MachineName)

  Node $MachineName 
  { 
    #Install the IIS Role 
    WindowsFeature IIS 
    { 
      Ensure = “Present” 
      Name = “Web-Server” 
    } 
[/sourcecode]

In questo caso la funzione ContosoWebSite, la quale accetta come parametro il nome di una singola macchina target, dichiara che la macchina target dovrà avere presente la WindowsFeature chiamata Web-Server (ovvero IIS). Ai fini di Powershell, ContosoWebsite è a tutti gli effetti una funzione, ed all’interno utilizza la keyword Node introdotta da DSC, la quale permette di identificare un nodo target per il quale verranno dichiarate delle configurazioni. All’interno del nodo troviamo quindi una serie di dichiarazioni sugli stati desiderati della macchina, in questo caso si necessita solamente che la Windows Feature Web-Server sia nello stato Present.

Una volta eseguito lo script DSC la funzione ContosoWebSite è disponibile nella sessione powershell e può essere invocata con i parametri desiderati, es:

[sourcecode language='powershell' ]
ContosoWebsite -MachineName "WebTest2"
[/sourcecode]

Questa chiamata produce una cartella chiamata ContosoWebSite con all’interno un file con estensione Mof, specifica di DSC. Abbiamo concluso quella che è chiamata la Authoring Phase ovvero la fase in cui noi stiamo definendo la configurazione e la istanziamo con dei parametri definiti (il file mof).

Nella seconda fase queste configurazioni debbono essere rese disponibili per gli ambienti, e quindi si può utilizzare il metodo Pull, in cui le configurazioni sono memorizzate in un server centrale e poi recuperate dalle macchine target, oppure il metodo Push in cui le configurazioni vengono direttamente inviate alle macchine target. Il metodo Push è il più interessante a mio avviso, ma ha la controindicazione di dovere preventivamente avere copiato ogni modulo DSC custom che si è utilizzato nella macchina target.

La fase finale è detta Make It So, ovvero si chiede al motore DSC di assicurarsi che le macchine siano nello stato desiderato. Ad esempio usando il metodo Push, dalla propria macchina, si potrebbe semplicemente chiedere di eseguire il file mof creato precedentemente con l’istruzione.

[sourcecode language='powershell' ]
Start-DscConfiguration -Path .\ContosoWebsite -Wait -Verbose
[/sourcecode]

Cosi facendo il motore DSC va a verificare se nella macchina WebTest2 sia effettivamente presente la windows feature Web-Server (IIS) e qualora questa non fosse presente la installa in maniera automatica. Questa operazione viene fatta da appositi Providers il cui scopo è appunto gestire differenti funzionalità del nodo target. Avete una lista dei provider attualmente disponibili a questo link. Per quanto riguarda l’autenticazione valgono le regole per le sessioni remote di Powershell, mentre i parametri –Wait e –Verbose servono rispettivametne per attendere che il comando sia finito e per avere una diagnostica maggiore. Senza l’opzione –Wait vi verrà restituito un job.

Per quale ragione ritengo DSC una tecnologia veramente interessante e che vale la pena tenere sotto occhio?

1) E’ basata su Powershell, un linguaggio di scripting di cui chiunque sviluppi in Windows dovrebbe avere una conoscenza base
2) Permette la configurazione di sistemi ed il deploy da remoto (push model) senza necessità di avere agent nelle macchine target (powershell nativamente supporta il concetto di sessioni remote)
3) Permette di definire in maniera chiara ed efficace lo stato in cui debbono essere le macchine di un ambiente per poter eseguire il proprio software.
4) Automatizzano il deploy permettendo inoltre di installare in maniera automatica i vari prerequisiti che servono nelle macchine target.
4) E’ idempotente, ovvero potete eseguire lo script quante volte volete, ma per ogni configurazione viene prima verificato che lo stato non sia quello voluto, e solo in questo caso viene applicata la configurazione. Es Nel caso precedente IIS viene installato solamente se non è effettivamente già presente.

P.S. Recentemente è anche stato annunciato un supporto per Powershell DSC anche per macchine Linux, come potete leggere in questo articolo. Questo rende DSC ancora più appetibile per ambienti eterogenei.

Spero di avervi incuriosito

Gian Maria.