Distribuire in tutta sicurezza

Completato 200 XP
Raggiungere lo stato desiderato della distribuzione con prevedibilità.

Creare una catena di approvvigionamento 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 automatizzare, testare, monitorare ed eseguire il controllo delle versioni. Dovrebbe essere modularizzato e pronto per l'esecuzione on-demand. Non dovrebbe essere rappresentato come un processo end-to-end monolitico. La catena di approvvigionamento non è necessariamente destinata a un'esecuzione più rapida, ma per ottenere coerenza e auto-documentazione in iterazioni multiple.

Il team del carico di lavoro è responsabile della catena di approvvigionamento relativa al proprio carico di lavoro.

Scenario di esempio

Contoso Manufacturing ha sviluppato un'applicazione basata su Java che viene usata per monitorare e ottimizzare i processi di produzione. Il carico di lavoro è stato recentemente migrato in Azure ed è ora in esecuzione in Azure Spring Apps, nel Database di Azure per MySQL e nell'Hub IoT di Azure.

Distribuire l'infrastruttura tramite codice

Usare Infrastructure as Code (IaC) per definire gli aspetti ripetibili della catena di approvvigionamento pronti per la produzione. Preferire 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 deriva della configurazione. Anche la manutenzione sarà più semplice. Se si allineano le scelte con il set di competenze esistente del team, quest'ultimo potrà adottarle facilmente.

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 puntare alla 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 il team ha acquisito maggiore dimestichezza con la piattaforma e ha compreso che l'uso di un approccio IaC con Bicep fosse una soluzione migliore a più lungo termine.

Applicazione dell'approccio e risultati

  • In assenza di conoscenze interne, il team ha appaltato 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 insieme al team di sviluppo durante le fasi iniziali del progetto, eseguendo 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 pienamente idempotent e semplifica la gestione dello stato, cosa che non era mai stato in grado di fare completamente con la versione precedente/imperativa.

Considerare l'IaC uguale al codice dell'applicazione

Seguire le raccomandazioni software per lo sviluppo e la manutenzione IaC: Modularizzare con moderazione, evitare astrazioni personalizzate o a basso valore e seguire un approccio a livelli per riflettere cicli di vita diversi. Creare livelli fondamentali in cui quelli inferiori rimangono costanti e quelli 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 livelli semplifica la manutenzione e crea limiti che stabiliscono linee di responsabilità chiare.

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 della migrazione, per cui ha assunto collaboratori molto esperti che hanno fornito risultati di alta qualità e in un breve periodo di tempo. I terzisti hanno usato un repository separato per lo sviluppo, il quale non è stato sottoposto a verifiche regolare per la sicurezza, mentre il repository del codice dell'applicazione principale sì.
  • Il team si sta preparando a rilasciare un redesign importante 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 sta venendo eseguito da due tirocinanti. Quando uno degli sviluppatori senior del team viene chiamato per aiutare i tirocinanti, nota diversi commit nel repository che non sono alla pari con gli standard di sviluppo del team, tra cui la presenza di segreti dell'applicazione come chiavi API hardcoded nella codebase.

Applicazione dell'approccio e 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 al codice.
  • Il team ha così protetto questa sezione della codebase migliorando 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, comprese le revisioni del codice peer e la scansione 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 correlato alla gestione di vari asset.

In caso di emergenza, il ripristino sarà rapido e affidabile perché si è in grado di 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 falliscono 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 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 da poter usare un valore diverso, ma valido, nel database secondario.
  • L'esercizio ha aumentato la fiducia del team nella capacità di recuperare da errori principali dell'infrastruttura.

Verificare le conoscenze

1.

In che modo la distribuzione dell'infrastruttura come codice consente di distribuire in tutta sicurezza?

2.

In che modo lo spostamento del codice IaC nello stesso repository del codice dell'applicazione aiuta il team Contoso a distribuire in tutta sicurezza?

3.

Quale dei seguenti elementi può contribuire a garantire che la distribuzione di un ambiente di ripristino di emergenza sarà svolta in modo efficiente?


Unità successiva: Automatizzare per l'efficienza

Indietro Prossima