Distribuzione sicura
 Raggiungere lo stato desiderato della distribuzione con prevedibilità. |
|---|
Creare una supply chain del carico di lavoro che consente di raggiungere in modo coerente l'obiettivo di prevedibilità in tutti gli ambienti, tra le piattaforme di hosting, le applicazioni, i dati e le risorse di configurazione del carico di lavoro. Il meccanismo di distribuzione deve essere in grado di automazione, test, monitoraggio e controllo delle versioni. Deve essere modularizzato e pronto per l'esecuzione su richiesta. Non deve essere rappresentato come un processo end-to-end monolitico. La supply chain non è necessariamente per un'esecuzione più rapida, ma per ottenere coerenza e auto-documentazione su più iterazioni.
Il team del carico di lavoro è responsabile della catena di fornitura in relazione al proprio carico di lavoro.
Scenario di esempio
Contoso Manufacturing ha sviluppato un'applicazione basata su Java usata per monitorare e ottimizzare i processi di produzione. Il carico di lavoro è stato migrato di recente in Azure ed è ora in esecuzione in Azure Spring Apps, Database di Azure per MySQL e hub IoT di Azure.
Distribuire l'infrastruttura tramite codice
Usare Infrastructure as Code (IaC) per definire gli aspetti ripetibili della supply chain pronti per la produzione. Preferisce approcci dichiarativi rispetto ai metodi imperativi.
Le tecnologie IaC dichiarative sono progettate tenendo conto dell'automazione e della riutilizzabilità. È possibile eseguire l'offload delle distribuzioni dell'infrastruttura da singoli utenti agli strumenti e ottenere una qualità coerente.
Dal punto di vista dell'infrastruttura, la presenza di un minor numero di scelte tecnologiche elimina la varianza degli strumenti e semplifica il rilevamento della deviazione della configurazione. Anche la manutenzione sarà più semplice. Se si allineano le scelte con il set di competenze esistente del team, il team può facilmente adottarli.
Sfida di Contoso
- La versione locale del carico di lavoro usava una combinazione di script e passaggi manuali per compilare l'infrastruttura e distribuire l'applicazione in ambienti diversi. All'inizio del processo di migrazione di Azure, il team ha apportato modifiche agli script imperativi esistenti per la nuova piattaforma in modo da poter riutilizzare la maggior parte possibile della codebase di automazione esistente. Questo approccio è stato adottato anche a causa della mancanza di esperienza con le tecnologie Azure e IaC come Bicep.
- Con l'avanzamento della migrazione e il team è diventato più familiare con la piattaforma, è diventato convinto che l'uso di un approccio IaC con Bicep fosse una soluzione migliore a lungo termine.
Applicazione dell'approccio e dei risultati
- In assenza di conoscenze interne, il team ha contratto il lavoro per eseguire la migrazione e estendere gli script di automazione della distribuzione per il carico di lavoro a terzisti esperti, che hanno lavorato incorporato con il team di sviluppo durante le fasi iniziali del progetto, fornendo al contempo il trasferimento delle conoscenze al resto del team.
- L'implementazione basata su Bicep risultante offre un modo più affidabile, gestibile ed efficiente per effettuare il provisioning dell'infrastruttura in Azure. Il codice è ora più leggibile e gestibile, con un ottimo supporto degli strumenti in VSCode. È anche completamente idempotente e semplifica la gestione dello stato, che non sono mai stati in grado di eseguire completamente con la versione precedente/imperativa.
Considerare l'IaC come il codice dell'applicazione
Seguire le raccomandazioni software per lo sviluppo e la manutenzione IaC: modularizzare in moderazione, evitare astrazioni personalizzate o a basso valore e seguire un approccio a più livelli per riflettere i diversi cicli di vita. Form foundational layer in cui i livelli inferiori rimangono costanti e i livelli superiori cambiano in base alle esigenze.
Gli artefatti della distribuzione, ad esempio i file binari dell'applicazione, i modelli IaC e i parametri, fanno parte della superficie di attacco. Applicare garanzie, ad esempio la gestione dei segreti, il controllo di accesso e altri principi del pilastro Sicurezza.
Gli artefatti sperimentano lo stesso livello di rigore tecnico del codice dell'applicazione. I controlli qualitativi tramite verifiche e test peer offrono fiducia nella distribuzione.
Un approccio a più livelli semplifica la manutenzione e crea limiti che stabiliscono linee chiare di responsabilità.
L'aggiunta di controlli di sicurezza agli artefatti consente di rafforzare il sistema durante il processo di distribuzione.
Sfida di Contoso
- Il team di progetto aveva un budget generoso all'inizio dello sforzo di migrazione, quindi hanno assunto collaboratori molto esperti che hanno fornito con alta qualità e in un breve periodo di tempo. I terzisti hanno usato un repository separato per lo sviluppo e tale repository non è stato regolarmente controllato per la sicurezza, mentre il repository del codice dell'applicazione principale è.
- Il team è pronto a rilasciare una riprogettazione principale della soluzione e il codice di distribuzione necessita di modifiche significative. A causa di una scarsità di risorse di sviluppo, il batch più recente di modifiche viene apportato da due interns. Quando uno degli sviluppatori senior del team viene chiamato per aiutare gli utenti, nota più commit nel repository che non sono alla pari con gli standard di sviluppo del team, inclusa la presenza di segreti dell'applicazione come chiavi API hardcoded nella codebase.
Applicazione dell'approccio e dei risultati
- Il team decide di spostare la codebase di compilazione e distribuzione nello stesso repository usato per il codice dell'applicazione e di iniziare ad applicare lo stesso livello di rigore di progettazione di altre aree della codebase. Il codice viene portato agli standard del team prima del primo commit, i segreti dell'applicazione vengono rimossi e tutti gli altri standard e strumenti di qualità del team vengono applicati.
- Di conseguenza, il team ha protetto questa sezione della codebase aumentando al contempo la qualità del codice. In futuro, le modifiche apportate a questa area della codebase seguiranno gli stessi standard e useranno gli stessi strumenti usati per la codebase dell'applicazione principale, incluse le revisioni del codice peer e l'analisi automatizzata del codice con strumenti di qualità e sicurezza.
Standardizzare le distribuzioni in un singolo manifesto
Sviluppare un manifesto di distribuzione comune usato in tutti gli ambienti. Usare tale manifesto come meccanismo predefinito per i progetti greenfield, gli aggiornamenti incrementali del carico di lavoro o il ripristino di emergenza.
L'applicazione di questo approccio consentirà di rimuovere il sovraccarico di gestione di più asset.
In caso di emergenza, il ripristino sarà rapido e affidabile perché è possibile distribuire un manifesto provato e testato invece di creare un ambiente improvvisato.
Sfida di Contoso
- Contoso Manufacturing usa una pipeline completamente automatizzata per distribuire l'infrastruttura, il codice dell'applicazione e le modifiche di configurazione all'ambiente di sviluppo e produzione. L'applicazione è configurata per essere a disponibilità elevata in una singola area. La maggior parte dei componenti dell'applicazione è senza stato, ad eccezione del database MySQL. Il backup del database viene eseguito in base al valore RTO/RPO stabilito e il backup viene replicato in un'area secondaria.
- Se si verifica un errore grave o irreversibile nell'area primaria, il team prevede di creare un nuovo ambiente per ospitare l'applicazione nell'area secondaria. Durante un'esercitazione pianificata per testare le procedure di ripristino di emergenza, gli script di distribuzione hanno esito negativo quando si tenta di ricreare l'ambiente nell'area secondaria a causa della mancanza di disponibilità di diverse risorse e altre limitazioni del servizio.
Applicazione dell'approccio e dei risultati
- Il team riduce i problemi riscontrati quando si tenta di effettuare il provisioning nell'area secondaria sostituendo l'uso di alcune risorse con SKU equivalenti disponibili in entrambe le aree e rendendo configurabili alcune opzioni in modo diverso, ma valido, il valore può essere usato nel database secondario.
- L'esercizio ha aumentato la fiducia del team nella capacità di recuperare da errori principali dell'infrastruttura.