Gestire gli ambienti di sviluppo di applicazioni nelle zone di destinazione di Azure
Questo articolo descrive come i team della piattaforma cloud possono implementare protezioni per gestire gli ambienti dell'applicazione nelle zone di destinazione di Azure. Viene inoltre illustrato come allineare i vari ambienti di sviluppo di applicazioni al framework. Un aspetto chiave nella creazione dell'ambiente appropriato consiste nel inserire le sottoscrizioni nei gruppi di gestione appropriati.
Impostare le basi
I team di sviluppo richiedono la possibilità di scorrere rapidamente e i team di governance e piattaforma cloud devono gestire i rischi, la conformità e la sicurezza dell'organizzazione su larga scala. È possibile gestire correttamente gli ambienti applicazioni concentrandosi su due principi chiave di progettazione della zona di destinazione di Azure: governance basata su criteri e democratizzazione delle sottoscrizioni. Questi principi forniscono protezioni fondamentali e descrivono come delegare i controlli ai team dell'applicazione. I team dell'applicazione usano le linee guida di Azure Well-Architected Framework per progettare il carico di lavoro. Distribuiscono e gestiscono le proprie risorse della zona di destinazione e il team della piattaforma controlla le risorse assegnando criteri di Azure.
È importante fornire risorse sandbox per le risorse semi-regolamentate , in modo che i team dell'applicazione possano sperimentare tecnologie e funzionalità.
Quando i proprietari di applicazioni usano vendita di abbonamenti o altri processi di creazione di sottoscrizioni, devono sapere come richiedere sottoscrizioni per più ambienti di sviluppo.
Questo articolo descrive la zona di destinazione di Azure, inclusi i gruppi di gestione, i criteri e l'architettura della piattaforma condivisa e il carico di lavoro o l'area di destinazione dell'applicazione.
Nota
Le linee guida contenute in questo articolo sono destinate solo alle zone di destinazione del carico di lavoro o dell'applicazione. Per i test e la separazione dell'ambiente per la piattaforma della zona di destinazione di Azure stessa, vedere Approccio di test per le zone di destinazione di Azure, che descrive l'approccio canary.
In pratica, è possibile usare qualsiasi numero e tipo di ambiente in più fasi. Questo articolo fa riferimento agli ambienti in più fasi seguenti.
| Environment | Descrizione | Gruppo di gestione |
|---|---|---|
| Sandbox | Ambiente usato per l'innovazione rapida dei prototipi, ma non configurazioni associate alla produzione | Gruppo di gestione sandbox |
| Sviluppo | Ambiente usato per compilare potenziali candidati di rilascio | Gruppo di gestione archetipo, ad esempio corp o online |
| Test | Ambiente usato per eseguire test, tra cui unit test, test di accettazione utente e test di controllo della qualità | Gruppo di gestione archetipo, ad esempio corp o online |
| Produzione | Ambiente usato per offrire valore ai clienti | Gruppo di gestione archetipo, ad esempio corp o online |
Per altre informazioni, vedere i video Gestione degli ambienti di sviluppo, test e produzione per i carichi di lavoro delle applicazioni e Quante sottoscrizioni è consigliabile usare in Azure?
Ambienti, sottoscrizioni e gruppi di gestione
Come prerequisito per questa sezione, vedere Area di progettazione dell'organizzazione delle risorse.
È necessario organizzare correttamente le sottoscrizioni quando si adottano le procedure per la zona di destinazione di Azure. Idealmente, ogni ambiente dell'applicazione deve avere una propria sottoscrizione. Questo metodo fornisce controlli di sicurezza e criteri che mantengono isolati gli ambienti. Contiene potenziali problemi per un ambiente.
Le sottoscrizioni separate hanno gli stessi criteri a livello di archetipo. Se necessario, i proprietari delle applicazioni possono assegnare criteri specifici della sottoscrizione per applicare il comportamento specifico dell'applicazione e dell'ambiente.
Alcune architetture di applicazioni richiedono che i servizi siano condivisi tra gli ambienti. In questo caso, è possibile usare una singola sottoscrizione per più ambienti. È consigliabile che i proprietari del carico di lavoro lavorino con i team della piattaforma cloud per determinare se è necessaria una singola sottoscrizione per più ambienti.
Usare una singola sottoscrizione per più ambienti applicazione se:
Gli ambienti non possono essere isolati nelle proprie sottoscrizioni.
Gli ambienti hanno gli stessi team assegnati ai ruoli funzionali, ad esempio gli operatori di rete.
Gli ambienti possono usare gli stessi criteri.
Se un carico di lavoro dell'applicazione o del servizio deve trovarsi in una singola sottoscrizione ed è necessario apportare modifiche ai criteri applicabili a ogni ambiente, è possibile:
Creare un nuovo gruppo di gestione allineato all'archetipo sotto il gruppo di gestione delle zone di destinazione. Per altre informazioni, vedere Gerarchia dei gruppi di gestione in questo articolo.
Usare le sottoscrizioni di ambiente sandbox per le attività di sviluppo. Per gli ambienti sandbox è impostato un set di criteri meno restrittivo.
Usare i criteri applicati a livello di sottoscrizione anziché a livello di gruppo di gestione. È possibile aggiungere tag nelle definizioni dei criteri per filtrare e applicare criteri all'ambiente corretto. È anche possibile assegnare o escludere i criteri da gruppi di risorse specifici.
È possibile assegnare criteri durante il processo di creazione della sottoscrizione come parte di vendita di abbonamenti.
Per i criteri implementati per controllare i costi, applicare la definizione dei criteri a livello di sottoscrizione, se necessario. In alternativa, è possibile rendere il proprietario della zona di destinazione responsabile dei costi, che fornisce una vera autonomia. Per altre informazioni, vedere Automazione della piattaforma e DevOps.
Avviso
A differenza dei criteri e dei controlli a livello di gruppo di gestione, i criteri e i tag basati su sottoscrizione possono essere modificati da utenti con autorizzazioni elevate per la sottoscrizione. Amministrazione istrator con ruoli appropriati possono ignorare questi controlli escludendo i criteri, modificando i criteri o modificando i tag nelle risorse.
Di conseguenza, non è consigliabile applicare tag nelle definizioni dei criteri incentrati sulla sicurezza. Inoltre, non assegnare le autorizzazioni come sempre attive per le azioni seguenti:
Microsoft.Authorization/policyAssignments/*Microsoft.Authorization/policyDefinitions/*Microsoft.Authorization/policyExemptions/*Microsoft.Authorization/policySetDefinitions/*
È possibile controllare queste azioni usando Privileged Identity Management (PIM).
Gerarchia dei gruppi di gestione
Evitare gerarchie complesse del gruppo di gestione. Possono richiedere modifiche frequenti, ridimensionare in modo inefficiente e mancanza di valore. Per evitare questi potenziali problemi, i gruppi di gestione delle zone di destinazione di Azure sono allineati all'archetipo del carico di lavoro. Per altre informazioni, vedere Organizzazione dei gruppi di gestione e delle sottoscrizioni.
Archetype-aligned significa che i gruppi di gestione vengono creati solo per archetipi di carico di lavoro specifici. Nell'architettura concettuale, ad esempio, il gruppo di gestione delle zone di destinazione dispone di gruppi di gestione figlio online e aziendale. Questi gruppi di gestione figlio sono allineati a modelli archetipi distinti per i carichi di lavoro che contengono. I gruppi di gestione figlio si concentrano sui requisiti di connettività ibrida (VPN/Azure ExpressRoute), ad esempio solo interni e applicazioni e servizi pubblici.
Escludendo gli ambienti sandbox, vari ambienti dell'applicazione devono usare lo stesso archetipo per la distribuzione. Anche se gli ambienti sono divisi tra più sottoscrizioni, vengono mantenuti all'interno dello stesso gruppo di gestione (corp o online), in base all'archetipo del gruppo di gestione e ai requisiti.
È possibile usare sottoscrizioni sandbox per lo sviluppo non strutturato, ad esempio lab personali o per un carico di lavoro che non ha un archetipo. Un team del carico di lavoro di applicazioni o servizi usa un gruppo di gestione sandbox per testare vari servizi di Azure per determinare il funzionamento migliore per i requisiti. Dopo aver deciso i servizi, è possibile effettuare il provisioning di una zona di destinazione (nel gruppo di gestione allineato all'archetipo del carico di lavoro corretto nella gerarchia dei gruppi di gestione delle zone di destinazione) per il team.
Gli ambienti sandbox possono essere usati per applicazioni specifiche oppure un team del carico di lavoro può usarli per la sperimentazione.
Per altre informazioni, vedi:
- Gruppi di gestione.
- Area di progettazione dell'organizzazione delle risorse.
- Personalizzare l'architettura della zona di destinazione di Azure per soddisfare i requisiti.
Problemi del gruppo di gestione basato sull'ambiente
I gruppi di gestione per gli ambienti all'interno di archetipi possono aggiungere overhead di gestione e fornire un valore minimo.
Il gruppo di gestione delle zone di destinazione deve avere criteri universali che applicano protezioni sia per i gruppi di gestione figlio aziendali che per i gruppi di gestione figlio online. Corp e online hanno criteri univoci che applicano le linee guida aziendali correlate ai carichi di lavoro pubblici e privati.
Molte organizzazioni creano gruppi di gestione separati per gli ambienti SDLC (Workload Software Development Lifecycle) per assegnare criteri e controlli ambientali. In pratica, questo metodo crea più sfide per i team del carico di lavoro rispetto a quanto risolve. Gli ambienti SDLC non devono avere criteri diversi, quindi non è consigliabile separare i gruppi di gestione.
I proprietari di applicazioni possono modificare la topologia o la configurazione delle risorse di un carico di lavoro in modo da allinearsi ai criteri in più ambienti SDLC promossi tramite. Questo metodo aumenta il rischio. Le regole specifiche di ogni ambiente possono comportare un'esperienza di sviluppo insufficiente per i team di sviluppo e controllo della qualità. I problemi possono verificarsi anche se un'applicazione ha un set di criteri di protezione che funzionano in un ambiente e l'applicazione viene esposta a un set diverso di criteri più avanti nel ciclo di promozione. Potrebbe essere necessario apportare modifiche a un'applicazione se i controlli cambiano.
Per evitare questo lavoro aggiuntivo, creare criteri coerenti per tutta la promozione del codice negli ambienti SDLC. Non è consigliabile creare criteri per ogni ambiente, ma fornire un set coerente per tutti gli ambienti di sviluppo, esclusi gli ambienti sandbox.
Si supponga, ad esempio, che un'organizzazione definisca un criterio che richiede la configurazione degli account di archiviazione con regole firewall specifiche per impedire l'ingresso da reti pubbliche. Gli account di archiviazione usano invece endpoint privati all'interno delle reti della zona di destinazione di Azure per la comunicazione. Se l'ambiente di sviluppo non ha criteri di questo tipo, il test del carico di lavoro non rileva una configurazione errata dell'account di archiviazione che consente l'accesso pubblico. Le distribuzioni di test funzionano nell'ambiente di sviluppo e vengono iterate su . Quando la soluzione viene alzata di livello a un altro ambiente con i criteri dell'account di archiviazione, la distribuzione ha esito negativo a causa dei criteri applicati.
Di conseguenza, il team di sviluppo di applicazioni deve rielaborare la distribuzione e l'architettura, dopo aver già investito un impegno significativo. In questo esempio viene illustrato il modo in cui i diversi criteri in vari ambienti possono creare problemi.
Nota
L'equazione seguente illustra perché un gruppo di gestione separato per ogni ambiente o carico di lavoro non viene ridimensionato correttamente: N carichi di lavoro x gruppi di gestione Z = gruppi di gestione totali.
Se un'organizzazione dispone di 30 carichi di lavoro che richiedono un gruppo di gestione e un gruppo di gestione figlio per ambienti di sviluppo, test e produzione, l'organizzazione rimane con:
N = numero di carichi di lavoro/app = 30
Z = numero di gruppi di gestione per il carico di lavoro e gli ambienti (1 per il carico di lavoro + 3 per gli ambienti) = 4
N (30) x Z (4) = 120 gruppi di gestione totali
I proprietari di applicazioni potrebbero dover applicare criteri in modo diverso a più ambienti. Ad esempio, i proprietari di applicazioni potrebbero richiedere configurazioni di backup per gli ambienti di produzione, ma non per altri ambienti.
Alcuni criteri possono essere abilitati come criteri di controllo a livello di gruppo di gestione. I team delle applicazioni determinano come implementare il controllo. Questo metodo non impedisce le distribuzioni, ma crea consapevolezza e consente ai team delle applicazioni di gestire le proprie esigenze specifiche. Possono quindi creare criteri di livello superiore o incorporarli nei moduli di distribuzione IaC (Infrastructure as Code).
In questo modello di responsabilità condivisa, le procedure di controllo del team della piattaforma e il team dell'applicazione gestisce l'implementazione. Questo modello può migliorare l'agilità delle distribuzioni.
Gli operatori della piattaforma devono collaborare con ogni team del carico di lavoro dell'applicazione o del servizio (proprietari della zona di destinazione) per comprendere i requisiti. Gli operatori della piattaforma possono fornire sottoscrizioni in base ai requisiti e ai piani dell'applicazione. Gli operatori della piattaforma possono anche decidere di designare linee di prodotto per vari tipi di carichi di lavoro in modo che possano creare processi di creazione delle sottoscrizioni e strumenti in base ai requisiti comuni dei team del carico di lavoro delle applicazioni o dei servizi.
Scenario: carichi di lavoro basati su macchine virtuali
I carichi di lavoro iniziali nelle zone di destinazione di Azure sono spesso costituiti da macchine virtuali di Azure. È possibile distribuire questi carichi di lavoro in Azure o eseguirne la migrazione da data center esistenti.
Anziché distribuire macchine virtuali in più ambienti in una singola sottoscrizione, è possibile:
Stabilire sottoscrizioni per ogni ambiente dell'applicazione e inserirle tutte nello stesso gruppo di gestione archetipo.
Distribuire una rete virtuale per ogni ambiente applicazione nella sottoscrizione appropriata. È possibile determinare le dimensioni della rete virtuale in base alle dimensioni dell'ambiente dell'applicazione.
Distribuire le macchine virtuali nella sottoscrizione appropriata. Le macchine virtuali possono usare SKU diversi e configurazioni di disponibilità diverse per ogni ambiente, se appropriato.
Varie risorse dell'ambiente dell'applicazione sono protette da diversi controlli di accesso. Di conseguenza, quando gli sviluppatori di applicazioni configurano pipeline di distribuzione, l'identità di ogni pipeline può essere limitata all'ambiente. Questa configurazione consente di proteggere gli ambienti da distribuzioni accidentali.
Scenario: servizio app Azure
Un carico di lavoro con sottoscrizioni ambientali che usano servizio app può creare problemi. Per gli sviluppatori di applicazioni, una procedura consigliata servizio app consiste nell'usare gli slot di distribuzione per gestire le modifiche e gli aggiornamenti a un'app Web.
Tuttavia, questa funzionalità può essere usata solo con l'app presente nel piano servizio app, che può essere usata solo all'interno di una singola sottoscrizione. Se gli operatori della piattaforma impongono ai proprietari delle applicazioni di usare sottoscrizioni separate per ambienti di sviluppo, test e produzione, il ciclo di vita della distribuzione delle applicazioni potrebbe essere più difficile da gestire.
Per questo esempio, l'opzione migliore è una singola sottoscrizione per il carico di lavoro dell'applicazione o del servizio. I proprietari di applicazioni possono usare il controllo degli accessi in base al ruolo di Azure con PIM a livello di gruppo di risorse per una maggiore sicurezza.