Alcune note pratiche di DSC

Nel post di ieri ho spiegato cosa è e come funziona a grandi linee PowerShell DSC, oggi volevo completare il quadro con un paio di considerazioni, fatte dopo avere speso del tempo a creare uno script per deployare un sito in una situazione reale.

La prima è che attualmente ancora ci sono purtroppo pochi package stabili, molte risorse sono disponibili nei Resource Kit Wave X, dove X è ora arrivata al 4 (DSC Resource Kit Wave 4 is Live). Purtroppo queste risorse sono ancora in fase “preview”, non sono decisamente complete ed alcune, come quelle per deployare un file .dacpac, sono veramente poco utilizzabili. Nel caso dei .DacPac ho dovuto fare qualche patch al volo per poter completare il mio scenario.

Questo non significa assolutamente che DSC non sia una tecnica valida ed usabile, solamente che a data odierna non dovete attendervi di trovare Out-of-the-box tutto quello che vi potrebbe servire per realizzare i vostri deploy. Il vantaggio di usare DSC è innegabile, e vorrei puntualizzare alcuni fattori chiave che mi fanno propendere per DSC rispetto ad altre soluzioni di deploy.

La configurazione rappresenta lo stato finale desiderato, e quindi “si legge da sola” costituendo non solamente uno script operativo che è in grado di portare il sistema target allo stato desiderato, ma è anche nel contempo documentazione su cosa “si aspetta l’applicazione”.

Facciamo un esempio.

[sourcecode language="powershell" padlinenumbers="true"]
    xFirewall Firewall
    {
        Name                  = "TailpinToys Dev"
        DisplayName           = "Firewall Rule for TailpinToys Dev"
        DisplayGroup          = "Tailspin"
        Ensure                = "Present"
        Access                = "Allow"
        State                 = "Enabled"
        Profile               = ("Domain")
        Direction             = "InBound"
        LocalPort             = ("11000")         
        Protocol              = "TCP"
        Description           = "Firewall Rule for TailpinToys Dev"  
    }
[/sourcecode]

Con la risorsa xFirewall sto specificando che vorrei la porta 11000 aperta in InBound per il profilo “Domain”. In questo modo sto dichiarando che la mia applicazione necessità di avere delle particolari richieste al sistema, come ad esempio l’avere la porta 11000 aperta. Qualcuno potrà dire che facendo un deploy manuale, se vi viene detto di mettere il sito in porta 11000 è banale che si dovrà contestualmente aprire la corrispondente porta del firewall, ma pensiamo ad una applicazione più complessa, magari una app desktop che hosta un servizio WCF, in questo caso un deploy con DSC costituisce una chiara documentazione di cosa si attende la applicazione (ad esempio alcune porte aperte nel firewall).

Ma andiamo avanti facendo un altro esempio

[sourcecode language="powershell"]

    NTFSPermission AppDataSecurity
    {
        Ensure = "Present"
        Account = "IIS AppPool\DefaultAppPool"
        Access = "Allow"
        Path = "C:\inetpub\dev\tailspintoys\app_data"
        Rights = "FullControl"
    } 
[/sourcecode]

In questo caso sto dichiarando che la mia app web si aspetta di poter scrivere nella cartella app_data, dove in questo caso risiede il database locale di Elmah. Ora ripensate a quante volte nella vostra vita è capitato di effettuare il rilascio di un sito, avere problemi di permessi e sentire la risposta dai dev:

“Dai a tutta la cartella del sito permessi everyone – full access”.

Poi andatevi a vedere questo link di DevOps reactions, e capirete a cosa si riferisce. Il problema negli scenari reali si presenta perché ogni applicazione potrebbe avere bisogno di un particolare permesso per una particolare cartella, ma essendo la documentazione di deploy scarsa e scadente, si ricade nell’errore di dare permessi su tutto o addirittura di far girare le app web come Administrator (ORRORE!!!!!!).

Se gli sviluppatori sono spinti fin dall’inizio alla creazione di un file DSC per effettuare il deploy, si ottiene il vantaggio di avere automatizzato il deploy, ma anche di avere creato una dettagliata documentazione dello stato dell’ambiente dove l’applicazione si attende di essere eseguita.

Quindi, anche se ancora molte risorse sono in Beta, DSC è una validissima scelta, soprattutto perché è facile scrivere le proprie risorse se si conosce un poco di Powershell ed è sempre possibile includere degli script da eseguire nel sistema target, come ultima risorsa, es:

[sourcecode language="powershell"]
Script ChangeConnectionString 
    {
        SetScript =
        {    
            $path = "C:\inetpub\dev\tailspintoys\Web.Config"
            [xml]$xml = Get-Content $path 

            $node = $xml.SelectSingleNode("//connectionStrings/add[@name='TailspinConnectionString']")
            $node.Attributes["connectionString"].Value = "Data Source=localhost;Initial Catalog=TailspinToys;User=sa;pwd=xxxxx;Max Pool Size=1000"
            $xml.Save($path)
        }
        TestScript = 
        {
            return $false
        }
        GetScript = 
        {
            return @{
                GetScript = $GetScript
                SetScript = $SetScript
                TestScript = $TestScript
                Result = false
            }
        } 
    }
[/sourcecode]

In questo caso ho usato la risorsa Script, usata per eseguire degli script nel sistema target. Il TestScript viene chiamato per capire se lo script SetScript deve essere eseguito o meno. Nel mio caso viene sempre restituito $false ad indicare che lo stato non è mai soddisfatto e quindi il mio script verrà eseguito ad ogni Start-DscConfiguration. Lo script sopra ad esempio effettua un cambiamento di configurazione al web.config usando PowerShell ed XPath, nulla di più semplice. Per evitare di scrivere la parte test e verificare se la connection string sia o meno già nello stato desiderato, è più semplice eseguire sempre il Set, perchè in questo caso siamo idempotenti.

In conclusione, spero di avervi incuriosito riguardo PowerShell DSC, e PowerShell in generale.

Gian Maria.

One Response to Alcune note pratiche di DSC

  1.