Che cosa sono gli stack di distribuzione?

Completato

Uno stack di distribuzione di Azure è un tipo di risorsa di Azure che consente di gestire il ciclo di vita di una raccolta di risorse di Azure come singola unità atomica, anche se si estendono su più gruppi di risorse o sottoscrizioni. Consente distribuzioni coerenti e ripetibili, semplifica la gestione e consente un ridimensionamento efficiente e l'aggiornamento delle risorse.

In questa unità vengono fornite informazioni sull'organizzazione delle risorse in Azure e su come gli stack di distribuzione consentano di gestire le risorse in modi che in passato non erano possibili.

Organizzazione delle risorse

Le risorse in Azure possono essere organizzate in vari modi. È possibile scegliere di organizzare le risorse in base a un ambiente (produzione, gestione temporanea, sviluppo), un ciclo di vita dell'applicazione o una funzione (ad esempio, connettività o risorse di calcolo). Fattori quali le dimensioni dell'organizzazione, il numero di applicazioni e la residenza dei dati influiscono su queste decisioni e, per ogni scenario, sono disponibili procedure consigliate generali.

Relativamente agli ambienti di distribuzione, è possibile separarli in sottoscrizioni o gruppi di gestione diversi. Tutti i componenti di un'applicazione possono essere contenuti in un singolo gruppo di risorse, in più gruppi di risorse o anche in più sottoscrizioni. In merito alle risorse di Azure, le procedure consigliate suggeriscono di organizzarle in gruppi di risorse in base al ciclo di vita e alla sicurezza.

Applicazione di un singolo gruppo di risorse

In alcuni casi è consigliabile usare un singolo gruppo di risorse per la propria applicazione. Se, ad esempio, non si ha molta familiarità con Azure e si sta usando per la prima volta un ambiente di sviluppo o se si sta distribuendo un'applicazione di produzione senza molte risorse, un singolo gruppo di risorse può essere una scelta appropriata.

In alcuni casi, un gruppo di risorse viene usato come limite di sicurezza per le autorizzazioni. Se i requisiti di sicurezza non sono rigorosi, infatti, è possibile gestire una singola assegnazione di controllo degli accessi in base al ruolo nell'ambito del gruppo di risorse.

Si supponga che l'applicazione sia costituita da un servizio app, da Application Insights e da un database SQL distribuito in un singolo gruppo di risorse e che l'organizzazione disponga di team separati per la gestione delle risorse di calcolo, delle applicazioni Web e dei database. Se i criteri di sicurezza dell'organizzazione richiedono un controllo degli accessi in base al ruolo di tipo granulare, è necessario gestire le autorizzazioni nell'ambito di una risorsa anziché di un gruppo di risorse.

Nel corso del tempo, è possibile che nello stesso gruppo di risorse vengano distribuite anche risorse non correlate all'applicazione. Si supponga, ad esempio, che un collega distribuisca una nuova sessione di Azure Key Vault e scelga accidentalmente il gruppo di risorse sbagliato al momento della distribuzione. In questo scenario, può essere difficile determinare quali risorse appartengono all'applicazione e, pertanto, possono verificarsi problemi come l'eliminazione accidentale di una risorsa critica.

Applicazione di più gruppi di risorse

Cosa accade quando l'applicazione raggiunge nuove dimensioni e richiede quindi una modifica? Potrebbe essere necessario suddividere l’applicazione in più parti e assegnarle a gruppi di risorse separati per semplificare i controlli di sicurezza. Ad esempio, è possibile inserire tutte le risorse di calcolo nel gruppo delle risorse di calcolo, le risorse dell'applicazione nel gruppo di risorse dell'applicazione e tutti i database nel gruppo di risorse dei database.

Questo modello consente di gestire le autorizzazioni nell’ambito delle risorse di calcolo e i team dedicati all’applicazione e ai database nell’ambito dei gruppi di risorse appropriati. Se da un lato questa procedura può risolvere un problema, dall’altro introduce una gestione decentralizzata. Poiché in Azure l’ambito della maggior parte delle distribuzioni è il gruppo di risorse, non è più possibile gestire le risorse come singola unità.

Se, infatti, le risorse dell'applicazione vengono distribuite in gruppi di risorse separati, può essere difficile identificare le risorse che fanno parte dell'applicazione. È possibile usare i tag di Azure per facilitare l’identificazione delle risorse in un'applicazione ma esiste comunque la possibilità che alcune risorse non siano contrassegnate correttamente.

Nel modello di applicazione di più gruppi di risorse, è possibile che le operazioni di distribuzione debbano essere eseguite più volte. Quando si distribuisce una risorsa, infatti, a seconda del metodo di distribuzione potrebbe essere necessario eseguire più comandi di distribuzione. Poiché in Azure l’ambito della maggior parte delle distribuzioni è il gruppo di risorse, sarebbe necessario distribuire prima le risorse di rete, quindi le risorse dell'applicazione. Questo principio deve essere seguito anche per le operazioni di eliminazione. Se, ad esempio, devono essere rimossi tutti i gruppi di risorse correlati all'applicazione, potrebbe essere necessario eseguire più operazioni di eliminazione.

Inserimento degli stack di distribuzione

Gli stack di distribuzione cambiano il modo di pensare all'organizzazione delle risorse su più gruppi di risorse e sottoscrizioni. Uno stack di distribuzione consente di raggruppare tutte le risorse che costituiscono l'applicazione, indipendentemente dal posto che occupano nella gerarchia organizzativa delle risorse di Azure. È possibile gestirle come singola unità. Con gli stack di distribuzione, è possibile eseguire operazioni del ciclo di vita sulla raccolta di risorse che costituiscono lo stack.

Si considerino gli stack di distribuzione come una serie di puntatori che raggruppano le risorse dell'applicazione in una singola unità. Gli stack di distribuzione possono essere creati in ambiti diversi, ad esempio gruppi di risorse, sottoscrizioni e gruppi di gestione.

Si consideri l'esempio precedente. Avendo distribuito l'applicazione e le relative risorse con un singolo stack, con ambito a livello di sottoscrizione e tra gruppi di risorse, è ora possibile gestire l'applicazione come singola unità. Ogni gruppo di risorse e le relative risorse vengono quindi gestiti dallo stack.

Uso di stack di distribuzione

Quali operazioni possono essere eseguite su uno stack di distribuzione? È possibile creare, elencare, aggiornare ed eliminare uno stack di distribuzione. In merito alle risorse, è possibile visualizzare le risorse nello stack, aggiungere e rimuovere risorse dallo stack e proteggere lo stack e le relative risorse dall'eliminazione.

Le procedure di creazione e distribuzione di uno stack di distribuzione e delle relative risorse sono pressoché identiche a quelle di una distribuzione standard di Azure e usano gli stessi modelli JSON ARM, file Bicep o specifiche di modello a cui si è abituati. Ad esempio:

Il comando dell'interfaccia della riga di comando di Azure per distribuire un file Bicep in un gruppo di risorse è:

az deployment group create \
    --resource-group rg-depositsApplication \
    --template-file ./main.bicep

Il comando dell'interfaccia della riga di comando di Azure per creare uno stack di distribuzione nell'ambito del gruppo di risorse è:

az stack group create \
    --name stack-deposits \
    --resource-group rg-depositsApplication \
    --template-file ./main.bicep \
    --action-on-unmanage detachAll \
    --deny-settings-mode none

Gli stack di distribuzione consentono anche una pulizia efficiente dell'ambiente. Gli stack di distribuzione consentono di eliminare lo stack e tutte le relative risorse tramite una singola chiamata API, senza dover essere a conoscenza delle dipendenze. Questa funzionalità consente di rimuovere le risorse in modo semplice, rapido e affidabile. Ad esempio:

Il comando dell'interfaccia della riga di comando di Azure per eliminare uno stack di distribuzione e relative risorse nell'ambito del gruppo di risorse è:

az stack group delete \
    --name stack-deposits \
    --resource-group rg-depositsApplication \
    --action-on-unmanage detachAll

Nota

È possibile che si stia già usando distribuzioni in modalità completa come parte di una strategia di distribuzione esistente. In questo caso, considerare gli stack di distribuzione come successiva evoluzione, nonché come un'opzione più sicura.

Risorse gestite

Quando si invia un file Bicep, un modello JSON ARM o una specifica di modello a uno stack di distribuzione, quest’ultimo diventa responsabile della gestione delle risorse descritte nel file. Le risorse gestite dallo stack vengono definite risorse gestite, ma vengono comunque modificate tramite i file del modello originale.

Se una risorsa non deve più essere gestita dallo stack di distribuzione, è possibile modificare lo stack in modo che non includa più la risorsa. L'azione sul comportamento non gestito di uno stack di distribuzione determina cosa accade a una risorsa rimossa dalla definizione dello stack di distribuzione. Questo comportamento, illustrato più avanti nell'unità, stabilisce ad esempio se una risorsa, un gruppo di risorse o gruppi di gestione vengono scollegati o eliminati dallo stack.

Impostazione di negazione

È inoltre possibile configurare nello stack e nelle relative risorse un'impostazione di negazione che impedisca modifiche non autorizzate. Queste assegnazioni di negazione sono personalizzabili. È possibile impostare la modalità su “nessun flag”, “nega eliminazione” o “nega scrittura ed elimina”, che possono risultare simili ai blocchi di Azure. È possibile anche escludere dalle assegnazioni di negazione azioni o entità servizio specifiche. Le impostazioni di negazione devono essere considerate come un ulteriore livello di protezione da modifiche ed eliminazioni accidentali.