REL08-BP04 Implementazione utilizzando un'infrastruttura immutabile - AWS Well-Architected Framework

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

REL08-BP04 Implementazione utilizzando un'infrastruttura immutabile

L'infrastruttura immutabile è un modello che richiede che non vengano applicati aggiornamenti, patch di sicurezza o modifiche di configurazione sui carichi di lavoro di produzione. Quando è necessaria una modifica, l'architettura viene costruita su una nuova infrastruttura e distribuita alla produzione.

Segui una strategia di implementazione dell'infrastruttura immutabile per aumentare l'affidabilità, la coerenza e la riproducibilità nelle implementazioni dei carichi di lavoro.

Risultato desiderato: con un'infrastruttura immutabile, non sono consentite modifiche locali (in-place) per l'esecuzione delle risorse dell'infrastruttura all'interno di un carico di lavoro. Invece, quando è necessaria una modifica, un nuovo set di risorse infrastrutturali aggiornate contenente tutte le modifiche necessarie viene implementato in parallelo alle risorse esistenti. Questa implementazione viene convalidata automaticamente e, in caso di successo, il traffico viene gradualmente trasferito al nuovo set di risorse.

Questa strategia di implementazione si applica, ad esempio, agli aggiornamenti software, alle patch di sicurezza, alle modifiche apportate all'infrastruttura, agli aggiornamenti della configurazione e agli aggiornamenti delle applicazioni.

Anti-pattern comuni:

  • Implementazione locale (in-place) di modifiche alle risorse dell'infrastruttura in esecuzione.

Vantaggi dell'adozione di questa best practice:

  • Maggiore coerenza tra gli ambienti: l'assenza di differenze nelle risorse dell'infrastruttura tra ambienti garantisce l'aumento della coerenza e la semplificazione dei test.

  • Riduzione delle deviazioni di configurazione: sostituendo le risorse dell'infrastruttura con una configurazione nota e controllata dalla versione, l'infrastruttura viene impostata a uno stato noto, testato e affidabile, evitando deviazioni di configurazione.

  • Implementazioni atomiche affidabili: il completamento delle implementazioni avviene con successo o non cambia nulla, così da aumentare coerenza e affidabilità del processo di implementazione.

  • Implementazioni semplificate: le implementazioni sono semplificate poiché non devono supportare gli aggiornamenti. Gli aggiornamenti sono solo nuove implementazioni.

  • Implementazioni più sicure con processi di rollback e ripristino rapidi: le implementazioni sono più sicure poiché la versione funzionante precedente non viene modificata. Puoi eseguire il rollback se vengono rilevati errori.

  • Livello di sicurezza migliorato: non consentendo modifiche all'infrastruttura, i meccanismi di accesso remoto (ad esempio) possono essere disabilitati. SSH Questo riduce il vettore di attacco, migliorando il profilo di sicurezza dell'organizzazione.

Livello di rischio associato se questa best practice non fosse adottata: medio

Guida all'implementazione

Automazione

Nel definire una strategia di implementazione dell'infrastruttura immutabile, si consiglia di utilizzare il più possibile l'automazione per aumentare la riproducibilità e ridurre al minimo i potenziali errori umani. Per maggiori dettagli, consulta REL08-BP05 Implementare le modifiche con l'automazione e Automatizzare distribuzioni sicure e pratiche.

Con il modello Infrastructure as code (IaC), le fasi di provisioning, orchestrazione e implementazione dell'infrastruttura sono definite in modo programmatico, descrittivo e dichiarativo e archiviate in un sistema di controllo del codice sorgente. L'utilizzo del modello Infrastructure as code (IaC) semplifica l'automazione dell'implementazione dell'infrastruttura e aiuta a raggiungere l'immutabilità dell'infrastruttura.

Modelli di implementazione

Quando è richiesta una modifica del carico di lavoro, la strategia di implementazione immutabile dell'infrastruttura impone l'implementazione di un nuovo set di risorse dell'infrastruttura, comprese tutte le modifiche necessarie. È importante che questo nuovo set di risorse si basi su un modello di implementazione che riduca al minimo l'impatto sugli utenti. Esistono due strategie principali per questa implementazione:

Distribuzione canary: è la pratica di indirizzare un piccolo numero di clienti alla nuova versione, in genere in esecuzione su una singola istanza di servizio (la release canary). Quindi analizzerai in modo approfondito le modifiche di comportamento o gli errori generati. Puoi rimuovere il traffico dalla release canary in caso di problemi critici e reindirizzare gli utenti alla versione precedente. Se l'implementazione ha esito positivo, puoi continuare a implementare alla velocità desiderata, monitorando al contempo le modifiche per individuare eventuali errori, fino al completamento dell'implementazione. AWS CodeDeploy può essere configurato con una configurazione di distribuzione che consenta una distribuzione canaria.

Implementazione blu/verde: simile alla distribuzione canary, tranne per il fatto che un intero parco dell'applicazione è implementato in parallelo. Puoi alternare le implementazioni tra i due stack (blu e verde). Ancora una volta, puoi inviare il traffico alla nuova versione e tornare alla versione precedente in caso di problemi con l'implementazione. Di solito tutto il traffico viene trasferito contemporaneamente, tuttavia puoi anche utilizzare frazioni del traffico verso ciascuna versione per accelerare l'adozione della nuova versione utilizzando le DNS funzionalità di routing ponderato di Amazon Route 53. AWS CodeDeploy e AWS Elastic Beanstalkpuò essere configurato con una configurazione di distribuzione che consente una distribuzione blu/verde.

Diagramma che mostra l'implementazione blu/verde con AWS Elastic Beanstalk e Amazon Route 53

Figura 8: Implementazione blu/verde con AWS Elastic Beanstalk e Amazon Route 53

Rilevamento delle deviazioni

Per deviazione si intende qualsiasi modifica che causa uno stato o una configurazione di una risorsa dell'infrastruttura diversi da quelli previsti. Qualsiasi tipo di modifica non gestita della configurazione è contraria al concetto di infrastruttura immutabile e tale modifica dovrebbe essere individuata e corretta per implementare con successo l'infrastruttura immutabile.

Passaggi dell'implementazione

  • Non autorizzare la modifica locale (in-place) delle risorse dell'infrastruttura in esecuzione.

    • È possibile utilizzare AWS Identity and Access Management (IAM) per specificare chi o cosa può accedere a servizi e risorse AWS, gestire centralmente le autorizzazioni dettagliate e analizzare l'accesso per perfezionare le autorizzazioni in tutto il mondo. AWS

  • Automatizza l'implementazione delle risorse dell'infrastruttura per aumentare la riproducibilità e ridurre al minimo i potenziali errori umani.

    • Come descritto nel AWS white paper Introduzione a DevOps on, l'automazione è un elemento fondamentale per i servizi ed è supportata internamente in tutti AWS i servizi, le funzionalità e le offerte.

    • La prepreparazione di Amazon Machine Image (AMI) può velocizzare i tempi di avvio. EC2Image Builder è un AWS servizio completamente gestito che consente di automatizzare la creazione, la manutenzione, la convalida, la condivisione e l'implementazione di applicazioni personalizzate, sicure e personalizzate per up-to-date Linux o Windows. AMI

    • Alcuni dei servizi che supportano l'automazione sono:

      • AWS Elastic Beanstalkè un servizio per distribuire e scalare rapidamente applicazioni web sviluppate con Java,. NET, Node.jsPHP, Python, Ruby, Go e Docker su server familiari come Apache, NGINX Passenger e. IIS

      • AWS Protonaiuta i team della piattaforma a connettere e coordinare tutti i diversi strumenti necessari ai team di sviluppo per il provisioning dell'infrastruttura, la distribuzione del codice, il monitoraggio e gli aggiornamenti. AWS Proton abilita l'infrastruttura automatizzata come il provisioning del codice e la distribuzione di applicazioni serverless e basate su container.

    • L'utilizzo dell'infrastruttura come codice semplifica l'automazione dell'implementazione dell'infrastruttura e aiuta a raggiungere l'immutabilità dell'infrastruttura. AWS fornisce servizi che consentono la creazione, l'implementazione e la manutenzione dell'infrastruttura in modo programmatico, descrittivo e dichiarativo.

      • AWS CloudFormationaiuta gli sviluppatori a creare AWS risorse in modo ordinato e prevedibile. Le risorse sono scritte in file di testo utilizzando il formato JSON oYAML. I modelli richiedono una sintassi e una struttura specifiche che dipendono dai tipi di risorse create e gestite. È possibile creare le risorse in JSON o YAML con qualsiasi editor di codice AWS Cloud9, ad esempio archiviarle in un sistema di controllo delle versioni e quindi CloudFormation creare i servizi specificati in modo sicuro e ripetibile.

      • AWS Serverless Application Model (AWS SAM) è un framework open source su cui è possibile creare applicazioni serverless. AWS AWS SAM si integra con altri AWS servizi ed è un'estensione di. AWS CloudFormation

      • AWS Cloud Development Kit (AWS CDK) è un framework di sviluppo software open source per modellare ed eseguire il provisioning delle risorse delle applicazioni cloud utilizzando linguaggi di programmazione familiari. È possibile utilizzare AWS CDK per modellare l'infrastruttura delle applicazioni utilizzando TypeScript Python, Java e. NET. AWS CDK utilizza AWS CloudFormation in background per fornire risorse in modo sicuro e ripetibile.

      • AWS Cloud Control APIintroduce un set comune di Create, Read, Update, Delete e List (CRUDL) APIs per aiutare gli sviluppatori a gestire la propria infrastruttura cloud in modo semplice e coerente. Cloud Control API Common APIs consente agli sviluppatori di gestire in modo uniforme il ciclo di vita dei servizi e di AWS terze parti.

  • Applica modelli di implementazione che riducano al minimo l'impatto sugli utenti.

  • Rileva le deviazioni a livello di configurazione o stato. Per ulteriori informazioni, consulta Detecting unmanaged configuration changes to stacks and resources.

Risorse

Best practice correlate:

Documenti correlati:

Video correlati: