Che cos'è il servizio State Configuration di Automazione di Azure?
Il servizio State Configuration di Automazione di Azure può essere usato per assicurare che le macchine virtuali (VM) nell'area di un cluster si trovino in uno stato coerente, con lo stesso software installato e le stesse configurazioni.
In questa unità vengono illustrate le funzionalità di Automazione di Azure, viene esaminato il modello dichiarativo di PowerShell Desired State Configuration (DSC) e vengono esplorati i relativi vantaggi.
State Configuration di Automazione di Azure è un servizio di Azure basato su PowerShell. Consente di distribuire in modo coerente, monitorare in modo affidabile e aggiornare automaticamente lo stato desiderato di tutte le risorse. Automazione di Azure offre gli strumenti per definire le configurazioni e applicarle ai computer, reali e virtuali.
Perché usare il servizio State Configuration di Automazione di Azure?
Gestire manualmente una configurazione corretta e coerente per i server che eseguono i servizi può essere un processo difficile e soggetto a errori. State Configuration di Automazione di Azure usa PowerShell DSC per risolvere questi problemi. Gestisce centralmente gli artefatti e il processo DSC.
Il servizio State Configuration di Automazione di Azure include un server di pull incorporato. È possibile specificare che i nodi ricevano automaticamente le configurazioni da questo server di pull, conformemente allo stato desiderato, e segnalino la propria conformità. È possibile avere come destinazione macchine virtuali o computer fisici Windows o Linux, nel cloud o locali.
È possibile usare i log di Monitoraggio di Azure per verificare la conformità dei nodi configurando il servizio State Configuration di Automazione di Azure per l'invio di questi dati.
Che cos'è PowerShell DSC?
PowerShell DSC è una piattaforma di gestione dichiarativa usata dal servizio State Configuration di Automazione di Azure per la configurazione, la distribuzione e il controllo dei sistemi. Un linguaggio di programmazione dichiarativo separa la finalità, ovvero cosa si vuole fare, dall'esecuzione, ovvero come si vuole procedere. Si specifica quale deve essere lo stato desiderato e DSC provvede a eseguire le operazioni necessarie. Non è necessario saper implementare o distribuire una funzionalità quando è disponibile una risorsa DSC. Ci si può concentrare invece sulla struttura della distribuzione.
Se si sta già usando PowerShell, ci si potrebbe chiedere perché sia necessario il modello DSC. Si consideri l'esempio seguente.
Quando si vuole creare una condivisione in un server Windows, è possibile usare il comando di PowerShell seguente:
# Create a file share
New-SmbShare -Name MyFileShare -Path C:\Shared -FullAccess User1 -ReadAccess User2
Questo script è semplice e facile da comprendere. Tuttavia, se si usa questo script nell'ambiente di produzione, si riscontrano diversi problemi. Si consideri cosa potrebbe accadere se lo script venisse eseguito più volte o se l'utente User2
avesse già l'accesso completo anziché l'accesso in sola lettura.
Questo approccio non è idempotente. L'idempotenza descrive un'operazione che ha lo stesso effetto sia che venga eseguita una sola volta che 10.001 volte. Per ottenere l'idempotenza in PowerShell, è necessario aggiungere la logica e la gestione degli errori. Se la condivisione file non esiste, è necessario crearla. Se la condivisione esiste, non è necessario crearla. Se User2
esiste ma non ha l'accesso in lettura, è necessario aggiunger l'accesso in lettura.
Lo script di PowerShell sarà simile al seguente:
$shareExists = $false
$smbShare = Get-SmbShare -Name $Name -ErrorAction SilentlyContinue
if($smbShare -ne $null)
{
Write-Verbose -Message "Share with name $Name exists"
$shareExists = $true
}
if ($shareExists -eq $false)
{
Write-Verbose "Creating share $Name to ensure it is Present"
New-SmbShare @psboundparameters
}
else
{
# Need to call either Set-SmbShare or *ShareAccess cmdlets
if ($psboundparameters.ContainsKey("ChangeAccess"))
{
#...etc., etc., etc
}
}
Altri casi speciali che non sono stati presi in considerazione potrebbero occorrere solo quando si verificano problemi. DSC gestisce automaticamente i casi imprevisti. Con DSC viene descritto il risultato anziché il processo da eseguire per ottenerlo.
Il frammento di codice DSC seguente illustra un esempio:
Configuration Create_Share
{
Import-DscResource -Module xSmbShare
# A node describes the VM to be configured
Node $NodeName
{
# A node definition contains one or more resource blocks
# A resource block describes the resource to be configured on the node
xSmbShare MySMBShare
{
Ensure = "Present"
Name = "MyFileShare"
Path = "C:\Shared"
ReadAccess = "User1"
FullAccess = "User2"
Description = "This is an updated description for this share"
}
}
}
Nell'esempio precedente viene usato il modulo xSmbShare
che indica a DSC come controllare lo stato di una condivisione file. Il Resource Kit di DSC contiene più di 100 moduli di risorse, incluso un modulo per l'installazione di un sito IIS. È possibile trovare un collegamento al Resource Kit di DSC nell'unità Riepilogo alla fine di questo modulo.
Nell'unità successiva si apprenderanno altre informazioni sulla struttura del codice di PowerShell DSC.
Che cos'è Gestione configurazione locale?
Gestione configurazione locale è un componente di Windows Management Framework disponibile in un sistema operativo Windows. Gestione configurazione locale è responsabile dell'aggiornamento dello stato di un nodo, come una VM, in modo che corrisponda allo stato desiderato. Ogni volta che si esegue Gestione configurazione locale, vengono completati i passaggi seguenti:
- Get: ottiene lo stato corrente del nodo.
- Test: confronta lo stato corrente di un nodo con lo stato desiderato usando uno script DSC compilato (file con estensione mof).
- Set: aggiorna il nodo in modo che corrisponda allo stato desiderato descritto nel file con estensione mof.
Gestione configurazione locale verrà configurato quando si registra una VM con Automazione di Azure.
Architetture push e pull in DSC
Gestione configurazione locale in ogni nodo può operare in due modalità.
Modalità push: un amministratore invia manualmente le configurazioni a uno o più nodi, ovvero ne esegue il push. Gestione configurazione locale verifica che lo stato di ogni nodo corrisponda a quello specificato dalla configurazione.
Modalità pull: un server di pull contiene le informazioni di configurazione. L'istanza di Gestione configurazione locale in ogni nodo esegue il polling del server di pull a intervalli regolari, per impostazione predefinita ogni 15 minuti, per ottenere i dettagli di configurazione più recenti. Queste richieste sono indicate come Passaggio 1 nel diagramma seguente. Nel Passaggio 2 il server di pull invia nuovamente i dettagli di tutte le modifiche apportate alla configurazione a ogni nodo.
In modalità pull ogni nodo deve essere registrato con il servizio di pull.
Entrambe le modalità presentano dei vantaggi:
- La modalità push è facile da configurare. Non necessita di una propria infrastruttura dedicata e può essere eseguita su un portatile. La modalità push è utile per testare la funzionalità di DSC. È anche possibile usare la modalità push per ottenere un nuovo computer da un'immagine nello stato desiderato di base.
- La modalità pull è utile in una distribuzione aziendale che si estende su un numero elevato di computer. Gestione configurazione locale esegue regolarmente il polling del server di pull e verifica che i nodi si trovino nello stato desiderato. In uno strumento esterno o in un team applica gli aggiornamenti rapidi che comportino una deviazione di configurazione in singoli computer che vengono rapidamente riallineati alla configurazione impostata. Questo processo consente di ottenere uno stato di conformità continua per gli obblighi normativi e relativi alla sicurezza.
Piattaforme e sistemi operativi supportati
Automation DSC per Azure è supportato da Servizi cloud di Azure e da altri provider di servizi cloud, dall'infrastruttura locale o da una combinazione ibrida che comprende tutti questi ambienti.
Automation DSC per Azure supporta i sistemi operativi seguenti:
- Windows
- Server 2022
- Server 2019
- Server 2016
- Server 2012 R2
- Server 2012
- Server 2008 R2 SP1
- 11
- 10
- 8.1
- 7
- Linux
- L'estensione DSC Linux supporta tutte le distribuzioni Linux elencate nella documentazione di PowerShell DSC.
PowerShell DSC è installato in tutti i computer Linux supportati da Automation DSC per Azure.
Requisiti DSC per Windows
Per i computer Windows, l'estensione VM di DSC (Desired State Configuration) per Azure usa WMF per gestire versioni delle funzionalità di Windows come Windows PowerShell DSC e Gestione remota Windows (WinRM). Azure DSC supporta WMF 4.0 e versioni successive, di conseguenza i computer Windows devono eseguire Windows Server 2008 R2 SP1, Windows 7 o versioni successive.
La prima volta che si chiama l'estensione DSC di Azure, viene installata una versione compatibile del sistema operativo di WMF in tutte le versioni di Windows, ad eccezione di Windows Server 2016 e versioni successive. In Windows Server 2016 e versioni successive è già installata la versione più recente di WMF. Dopo l'installazione di WMF, è richiesto il riavvio del computer.
WinRM è abilitato nei nodi dei computer che eseguono Windows Server 2012 o versioni successive e Windows 7 o versioni successive.
Il supporto del proxy per l'agente DSC è disponibile nelle build di Windows 1809 e versioni successive. Il supporto del proxy non è disponibile in DSC per le versioni precedenti di Windows.
Altri requisiti per DSC
Se i nodi si trovano in una rete privata, per consentire la comunicazione tra DSC e il servizio Automazione di Azure sono necessari la porta e gli URL seguenti:
- Porta: è necessaria solo la porta TCP 443 per l'accesso a Internet in uscita
- URL globale: *.azure-automation.net
- URL globale di US Gov Virginia: *.azure-automation.us
- Servizio agente: https://
<workspaceId>
.agentsvc.azure-automation.net