Questo articolo fornisce indicazioni sull'implementazione per vendita di abbonamenti automazione. La distribuzione di sottoscrizioni standardizza il processo di richiesta, distribuzione e governance delle sottoscrizioni in modo che i team delle applicazioni possano distribuire i carichi di lavoro più velocemente.
Figura 1. Implementazione vendita di abbonamenti in un ambiente di Azure di esempio.
Sono stati creati vendita di abbonamenti moduli Bicep e Terraform da usare come punto di partenza. È necessario modificare i modelli in base alle esigenze di implementazione. Per altre informazioni sul processo di vendita di abbonamenti, vedere Panoramica del distributore di sottoscrizioni.
Architettura
È consigliabile progettare l'automazione vendita di abbonamenti per eseguire tre attività principali. L'automazione della distribuzione automatica delle sottoscrizioni deve (1) raccogliere i dati delle richieste di sottoscrizione, (2) avviare l'automazione della piattaforma e (3) creare la sottoscrizione usando infrastructure-as-code. Esistono diversi approcci per implementare vendita di abbonamenti automazione per eseguire queste tre attività. L'implementazione di esempio (figura 2) mostra un approccio che usa un flusso Git. La progettazione di Gitflow è allineata all'approccio dichiarativo usato da molti team della piattaforma per gestire la piattaforma.
Figura 2. Implementazione di esempio dell'automazione vendita di abbonamenti.
Nell'implementazione di esempio (figura 2) lo strumento di raccolta dati raccoglie i dati della richiesta di sottoscrizione. Quando la richiesta di sottoscrizione riceve l'approvazione, avvia l'automazione della piattaforma. L'automazione della piattaforma è costituita dalla pipeline di richiesta, dal controllo del codice sorgente e dalla pipeline di distribuzione. La pipeline di richiesta crea un file di parametri di sottoscrizione JSON o YAML con i dati dello strumento di raccolta dati. La pipeline di richiesta crea anche un nuovo ramo, esegue il commit del file dei parametri di sottoscrizione e apre una richiesta pull nel controllo del codice sorgente. Il nuovo ramo viene unito al ramo principale nel controllo del codice sorgente. L'unione attiva la pipeline di distribuzione per creare la sottoscrizione con i moduli infrastructure-as-code.
La distribuzione deve inserire la sottoscrizione nel gruppo di gestione corretto in base ai requisiti di governance (vedere la figura 1). La distribuzione crea un budget di sottoscrizione preliminare come base per la gestione dei costi. In base alle esigenze del carico di lavoro, la distribuzione potrebbe creare una rete virtuale vuota e configurare il peering in un hub a livello di area. Il team della piattaforma deve distribuire la sottoscrizione al team dell'applicazione dopo la creazione e la configurazione. Il team dell'applicazione deve aggiornare il budget della sottoscrizione e creare le risorse del carico di lavoro.
Raccogliere dati
L'obiettivo della raccolta dei dati è ricevere l'approvazione aziendale e definire i valori del file di parametri di sottoscrizione JSON/YAML. È consigliabile usare uno strumento di raccolta dati per raccogliere i dati necessari quando il team dell'applicazione invia la richiesta di sottoscrizione. Lo strumento di raccolta dati deve interfacciarsi con altri sistemi nel flusso di lavoro vendita di abbonamenti per avviare l'automazione della piattaforma.
Usare uno strumento di raccolta dati. È possibile usare uno strumento di gestione dei servizi IT (ITSM) per raccogliere i dati o creare un portale clienti con uno strumento con poco codice o senza codice, ad esempio Microsoft PowerApps. Lo strumento di raccolta dati deve fornire la logica di business per approvare o negare la richiesta di sottoscrizione.
Raccogliere i dati necessari. È necessario raccogliere dati sufficienti per definire i valori del parametro di sottoscrizione JSON/YAML in modo da automatizzare la distribuzione. I valori specifici raccolti dipendono dalle esigenze. È necessario acquisire il richiedente autorizzato, il centro di costo e i requisiti di rete (connettività Internet o locale). Può essere utile chiedere al team dell'applicazione i componenti del carico di lavoro previsti (piattaforma applicativa, requisiti di dati), la riservatezza dei dati e il numero di ambienti (sviluppo, test, preproduzione, produzione).
Convalidare i dati. È consigliabile convalidare i dati durante il processo di raccolta dati. È più difficile risolvere i problemi più avanti nelle fasi di automazione della piattaforma.
Creare una richiesta rilevabile. Lo strumento di raccolta dati deve creare una richiesta registrata e rilevabile per una nuova sottoscrizione, ad esempio un ticket in uno strumento ITSM. La richiesta deve contenere tutti i dati necessari per soddisfare i requisiti di tale sottoscrizione. È consigliabile associare la logica di business e il rilevamento delle autorizzazioni alla richiesta.
Interfaccia con altri sistemi interni. Se necessario, lo strumento di raccolta dati deve interfacciarsi con altri strumenti o sistemi nell'organizzazione. L'obiettivo è arricchire la richiesta con i dati di altri sistemi. Per eseguire l'automazione, potrebbe essere necessaria l'identità, la finanza, la sicurezza e i dati di rete. Ad esempio, l'automazione potrebbe interfacciarsi con uno strumento di gestione degli indirizzi IP per riservare lo spazio degli indirizzi IP corretto.
Creare un trigger. Quando la richiesta di sottoscrizione riceve l'approvazione, il trasferimento dei dati deve attivare l'automazione della piattaforma. È consigliabile creare una notifica push con i dati necessari dallo strumento di raccolta dati. Potrebbe essere necessario un livello middleware, ad esempio Funzioni di Azure o App per la logica di Azure, per avviare il processo.
Avviare l'automazione della piattaforma
La notifica e i dati dello strumento di raccolta dati devono attivare l'automazione della piattaforma. L'obiettivo dell'automazione della piattaforma è creare un file di parametri di sottoscrizione JSON/YAML, unire il file nel ramo main e distribuirlo con i moduli infrastructure-as-code per creare la sottoscrizione. Il team della piattaforma deve possedere e gestire l'automazione della piattaforma. L'automazione della piattaforma nell'implementazione di esempio è costituita dalla pipeline di richiesta, dal controllo del codice sorgente e dalla pipeline di distribuzione (vedere la figura 2).
Usare file JSON o YAML. È consigliabile usare file di dati strutturati (JSON o YAML) per archiviare i dati per creare una sottoscrizione. È consigliabile documentare la struttura del file e renderla estendibile per supportare le esigenze future. Ad esempio, il frammento di codice JSON seguente definisce i valori dei parametri di sottoscrizione per uno dei moduli Bicep in GitHub.
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentParameters.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"subscriptionDisplayName": {
"value": "sub-bicep-lz-vending-example-001"
},
"subscriptionAliasName": {
"value": "sub-bicep-lz-vending-example-001"
},
"subscriptionBillingScope": {
"value": "providers/Microsoft.Billing/billingAccounts/1234567/enrollmentAccounts/123456"
},
// Insert more parameters here
}
}
Vedere l'intero file. Per altri esempi, vedere Esempi di Bicep ed esempi di Terraform
Usare un file per ogni richiesta di sottoscrizione. La sottoscrizione è l'unità di distribuzione nel processo di vendita di abbonamenti, quindi ogni richiesta di sottoscrizione deve avere un file di parametri di sottoscrizione dedicato.
Usare un sistema di richieste pull. Il processo Gitflow che crea il file dei parametri di sottoscrizione deve automatizzare i passaggi seguenti:
- Creare un nuovo ramo per ogni richiesta di sottoscrizione.
- Usare i dati raccolti per creare un singolo file di parametri di sottoscrizione YAML/JSON per la nuova sottoscrizione nel ramo .
- Creare una richiesta pull dal ramo in
main. - Aggiornare lo strumento di raccolta dati con una modifica dello stato e un riferimento a questa richiesta pull.
La pipeline di richiesta nell'implementazione di esempio esegue questi passaggi (vedere la figura 2). È anche possibile usare una soluzione basata su codice ospitata in Azure se il flusso di lavoro è complesso.
Convalidare il file dei parametri della sottoscrizione. La richiesta pull deve attivare un processo di linting per convalidare i dati della richiesta. L'obiettivo è garantire che la distribuzione sia riuscita. Deve convalidare il file di parametri di sottoscrizione YAML/JSON. Potrebbe anche verificare che l'intervallo di indirizzi IP sia ancora disponibile. È anche possibile aggiungere un controllo di revisione manuale con l'intervento umano. Possono eseguire la revisione finale e apportare modifiche al file dei parametri della sottoscrizione. L'output deve essere un file di parametri di sottoscrizione JSON/YAML con tutti i dati per creare una sottoscrizione.
Attivare la pipeline di distribuzione. Quando la richiesta pull viene unione nel main ramo, l'unione deve attivare la pipeline di distribuzione.
Creare una sottoscrizione
L'ultima attività dell'automazione vendita di abbonamenti consiste nel creare e configurare la nuova sottoscrizione. L'implementazione di esempio usa la pipeline di distribuzione per distribuire il modulo infrastructure-as-code con il file di parametri di sottoscrizione JSON/YAML (vedere la figura 2).
Usare l'infrastruttura come codice. La distribuzione deve usare l'infrastruttura come codice per creare la sottoscrizione. Il team della piattaforma deve creare e gestire questi modelli per garantire una governance appropriata. È consigliabile usare i moduli vendita di abbonamenti Bicep e Terraform e modificarli in base alle esigenze di implementazione.
Usare una pipeline di distribuzione. La pipeline di distribuzione orchestra la creazione e la configurazione della nuova sottoscrizione. La pipeline deve eseguire le attività seguenti:
| Categoria attività | Attività pipeline |
|---|---|
| Identità | • Creare o aggiornare le risorse di Microsoft Entra per rappresentare la proprietà della sottoscrizione. • Configurare le identità del carico di lavoro con privilegi per le distribuzioni del team del carico di lavoro. |
| Governance | • Posizionare nella gerarchia dei gruppi di gestione. • Assegnare il proprietario della sottoscrizione. • Configurare controlli degli accessi in base al ruolo (RBAC) a livello di sottoscrizione per i gruppi di sicurezza configurati. • Assegnare Criteri di Azure a livello di sottoscrizione. • Configurare la registrazione Microsoft Defender per il cloud. |
| Rete | • Distribuire reti virtuali. • Configurare il peering di rete virtuale per le risorse della piattaforma (hub a livello di area). |
| Budget | • Creare budget per i proprietari delle sottoscrizioni usando i dati raccolti. |
| Creazione di report | • Aggiornare sistemi esterni, ad esempio Gestione indirizzi IP, per eseguire il commit nelle prenotazioni IP. • Aggiornare la richiesta dello strumento di raccolta dati con il nome finale della sottoscrizione e l'identificatore univoco globale (GUID). • Notificare al team dell'applicazione che la sottoscrizione è pronta. |
È necessario un contratto commerciale per creare una sottoscrizione a livello di codice. Se non si ha un contratto commerciale, è necessario introdurre un processo manuale per creare la sottoscrizione, ma è comunque possibile automatizzare tutti gli altri aspetti della configurazione della sottoscrizione.
Stabilire un'identità del carico di lavoro. La pipeline di distribuzione richiede l'autorizzazione per eseguire queste operazioni con tutti i sistemi con cui si interfaccia. È consigliabile usare l'identità gestita o OpenID Connect (OIDC) per eseguire l'autenticazione in Azure.
Post-distribuzione
L'automazione vendita di abbonamenti termina con la creazione e la configurazione della sottoscrizione. Il team della piattaforma deve distribuire la nuova sottoscrizione al team dell'applicazione dopo la creazione. Il team dell'applicazione deve aggiornare il budget della sottoscrizione, creare le risorse del carico di lavoro e distribuire il carico di lavoro. Il team della piattaforma controlla la governance della sottoscrizione e gestisce le modifiche alla governance delle sottoscrizioni nel tempo.
Applicare la gestione dei costi. I budget delle sottoscrizioni forniscono notifiche fondamentali per la gestione dei costi. La distribuzione deve creare un budget preliminare per la sottoscrizione in base ai dati della richiesta di sottoscrizione. Il team dell'applicazione riceve la sottoscrizione. Devono aggiornare il budget per soddisfare le esigenze del carico di lavoro. Per altre informazioni, vedi:
- Creare e gestire i budget
- Gestire i costi con i budget di Azure
- Allocazione costi
- Tenere traccia dei costi tra business unit, ambienti o progetti
Gestire la governance delle sottoscrizioni. È consigliabile aggiornare la sottoscrizione man mano che cambiano i requisiti di governance del carico di lavoro. Ad esempio, potrebbe essere necessario spostare una sottoscrizione in un gruppo di gestione diverso. È consigliabile creare l'automazione per alcune di queste operazioni di routine. Per altre informazioni, vedi:
- Spostamento di gruppi di gestione e sottoscrizione
- Mantenere aggiornati i criteri e le iniziative politiche
- Assegnazione di tag alle risorse
- Personalizzare l'architettura della zona di destinazione di Azure per soddisfare i requisiti
Passaggi successivi
La distribuzione automatica delle sottoscrizioni semplifica e standardizza il processo di creazione della sottoscrizione e lo inserisce nella governance dell'organizzazione. È consigliabile implementare vendita di abbonamenti automazione per consentire ai team dell'applicazione di accedere alle zone di destinazione delle applicazioni più rapidamente ed eseguire l'onboarding dei carichi di lavoro. Per altre informazioni, vedi: