Best practice: gestione e distribuzione di app e libri di ricette

Importante

Il AWS OpsWorks Stacks servizio ha raggiunto la fine del ciclo di vita il 26 maggio 2024 ed è stato disabilitato sia per i clienti nuovi che per quelli esistenti. Consigliamo vivamente ai clienti di migrare i propri carichi di lavoro verso altre soluzioni il prima possibile. Se hai domande sulla migrazione, contatta il AWS Support Team su AWS re:post o tramite Premium AWS Support.

AWS OpsWorks Stacks distribuisce app e libri di cucina su ogni nuova istanza da un repository remoto. Durante il ciclo di vita di un'istanza, spesso è necessario aggiornare le app o i libri di ricette sulle istanze online dello stack per aggiungere caratteristiche, risolvere i bug e così via. Ci sono vari modi per gestire le app e i libri di ricette di uno stack, ma l'approccio utilizzato deve soddisfare i seguenti requisiti generali:

• Tutte le istanze dello stack di produzione devono avere lo stesso codice di applicazione e libro di ricette personalizzato, con eccezioni limitate come il test A/B.

• La distribuzione di un aggiornamento non deve interrompere il funzionamento del sito, anche in caso di problemi.

Questa sezione descrive le prassi raccomandate per la gestione e la distribuzione di app e libri di ricette.

Mantenimento della coerenza

In generale, è necessario mantenere uno stretto controllo sul codice dell'app o del libro di ricette in esecuzione sullo stack di produzione. Di solito, tutte le istanze devono eseguire la versione attualmente approvata del codice. Le eccezioni si verificano quando si aggiornano le app o i libri di ricette, come descritto in seguito, e in casi particolari, come l'esecuzione di test A/B.

Il codice dell'app e del libro di ricette viene distribuito da un repository di origine specificato sulle tue istanze dello stack in due modi:

• Quando avvii un'istanza, AWS OpsWorks Stacks distribuisce automaticamente l'app corrente e il codice del ricettario sull'istanza.

• Per le istanze online, è necessario distribuire manualmente il codice corrente dell'app e del libro di ricette eseguendo un comando Deploy (per le app) o un comando Update Custom Cookbooks (per i libri di ricette).

Poiché sono previsti due meccanismi di distribuzione, è fondamentale gestire il tuo codice sorgente attentamente per evitare di eseguire per errore un codice diverso su altre istanze. Ad esempio, se distribuisci app o libri di cucina da un ramo principale di Git, AWS OpsWorks Stacks distribuisce ciò che si trova in quel ramo in quel momento. Se aggiorni il codice nel ramo principale e quindi avvii una nuova istanza, quest'ultima disporrà di una versione più recente del codice rispetto alle istanze precedenti. La versione più recente potrebbe anche non essere approvata per la produzione.

Raccomandazione: Amazon S3 Archives

Per assicurarti che tutte le tue istanze abbiano la versione di codice approvata, ti consigliamo di distribuire app e libri di cucina da un archivio Amazon Simple Storage Service (Amazon S3) Simple Storage Service (Amazon S3). Ciò garantisce che il codice sia un elemento statico, un file.zip o un altro file di archivio, che deve essere aggiornato in modo esplicito. Inoltre, Amazon S3 è altamente affidabile, quindi raramente, se non mai, non sarai in grado di accedere all'archivio. Per garantire ulteriormente la coerenza, modifica in modo esplicito ogni file di archivio utilizzando una convenzione di denominazione o utilizzando il controllo delle versioni di Amazon S3, che fornisce un audit trail e un modo semplice per ripristinare una versione precedente.

Ad esempio, puoi creare una pipeline di distribuzione utilizzando uno strumento come Jenkins. Dopo aver eseguito il commit e il test del codice che desideri distribuire, crea un file di archivio e caricalo su Amazon S3. Tutte le distribuzioni delle app o gli aggiornamenti dei libri di ricette determinano l'installazione del codice in quel file di archivio e ogni istanza avrà lo stesso codice.

Raccomandazione: repository Git o Subversion

Se preferisci utilizzare un repository Git o Subversion, non distribuire dal ramo principale. Al contrario, aggiungi un tag alla versione approvata e specifica che tale versione è l'origine dell'app o del libro di ricette.

Distribuzione del codice alle istanze online

AWS OpsWorks Stacks non distribuisce automaticamente il codice aggiornato nelle istanze online. È necessario eseguire questa operazione manualmente, il che comporta le seguenti sfide:

• Distribuire l'aggiornamento in modo efficiente senza compromettere la capacità del sito di gestire le richieste dei clienti durante il processo di distribuzione.

• Gestire una distribuzione non riuscita a causa di problemi con l'app o il libro di ricette da distribuire o di anomalie associate al processo di distribuzione stesso.

L'approccio più semplice consiste nell'esecuzione di un comando Deploy predefinito (per le app) o un comando Update Custom Cookbooks (per i libri di ricette), che distribuisce l'aggiornamento in ogni istanza simultaneamente. Questo approccio è semplice e veloce, ma non vi è alcun margine di errore. Se la distribuzione ha esito negativo o il codice aggiornato genera problemi, ogni istanza nello stack di produzione potrebbe esserne interessata e pertanto il sito potrebbe potenzialmente non funzionare o venire disabilitato fino alla risoluzione del problema o al ritorno alla versione precedente.

Raccomandazione: utilizza una solida strategia di distribuzione, che permetta alle istanze che eseguono la versione del codice precedente di continuare a gestire le richieste fino alla conferma dell'avvenuta distribuzione e fino al trasferimento in totale sicurezza di tutto il traffico in entrata verso la nuova versione.

Le seguenti sezioni forniscono due esempi di strategie di distribuzione solide, seguite da una discussione su come gestire un database back-end durante la distribuzione. Per brevità, vengono descritti gli aggiornamenti delle app, ma è possibile utilizzare strategie simili per i libri di ricette.

Argomenti

• Utilizzo di una distribuzione in sequenza
• Utilizzo di stack separati
• Gestione di un database back-end

Utilizzo di una distribuzione in sequenza

Una distribuzione in sequenza aggiorna un'applicazione su istanze di server applicazioni online di uno stack in più fasi. In ciascuna fase, aggiorni un sottoinsieme di istanze online e verifichi che l'aggiornamento abbia esito positivo prima di avviare la fase successiva. In caso di anomalie, le istanze che ancora eseguono la versione dell'app precedente possono continuare a gestire il traffico in entrata finché non avrai risolto i problemi.

L'esempio seguente presuppone tu stia utilizzando la prassi raccomandata che prevede di distribuire le istanze di server applicazioni dello stack tra più zone di disponibilità.

Per eseguire una distribuzione in sequenza

1. Nella pagina di distribuzione delle app, scegliere Advanced (Avanzate), quindi scegliere una singola istanza del server applicazioni e distribuire l'app sull'istanza.

   Per cautela, è possibile rimuovere l'istanza dal sistema di bilanciamento del carico prima di distribuire l'app. In questo modo gli utenti rileveranno l'applicazione aggiornata solo dopo la verifica del suo corretto funzionamento. Se utilizzi Elastic Load Balancing, rimuovi l'istanza dal load balancer utilizzando la console Elastic Load Balancing, la CLI o un SDK.

2. Verificare che l'app aggiornata funzioni correttamente e che l'istanza presenti parametri di prestazione accettabili.

   Se hai rimosso l'istanza da un sistema di bilanciamento del carico Elastic Load Balancing, utilizza la console Elastic Load Balancing, la CLI o un SDK per ripristinarla. La versione dell'app aggiornata gestisce ora le richieste degli utenti.

3. Distribuire l'aggiornamento al resto delle istanze nella zona di disponibilità e verificare che funzionino correttamente e presentino parametri accettabili.

4. Ripetere la fase 3 per le altre zone di disponibilità dello stack, una zona alla volta. Se vuoi essere particolarmente cauto, ripeti i passaggi da 1 a 3.

Nota

Se utilizzi un sistema di bilanciamento del carico Elastic Load Balancing, puoi utilizzare il relativo controllo dello stato per verificare che la distribuzione sia andata a buon fine. Tuttavia, imposta il percorso ping verso un'applicazione che controlla le dipendenze e verifica che tutto funzioni correttamente, non verso un file statico che si limita a confermare che il server applicazioni è in esecuzione.

Utilizzo di stack separati

Un altro approccio alla gestione delle applicazioni consiste nell'utilizzo di uno stack separato per ogni fase del ciclo di vita dell'applicazione. I diversi stack vengono talvolta definiti ambienti. Questa organizzazione ti consente di realizzare sviluppo e test su stack che non sono accessibili pubblicamente. Quando sei pronto a distribuire un aggiornamento, trasferisci il traffico degli utenti dallo stack che ospita la versione dell'applicazione attuale allo stack che ospita la versione aggiornata.

Argomenti

• Utilizzo di stack di sviluppo, gestione temporanea e produzione
• Utilizzo di una strategia di sviluppo blu-verde

Utilizzo di stack di sviluppo, gestione temporanea e produzione

L'approccio più comune usa gli stack seguenti.

Stack di sviluppo

Utilizza uno stack di sviluppo per attività quali l'implementazione di nuove caratteristiche o la correzione di bug. Uno stack di sviluppo è essenzialmente un prototipo dello stack di produzione, con gli stessi livelli, app, risorse e così via, che sono inclusi nel tuo stack di produzione. Poiché lo stack di sviluppo non deve in genere gestire lo stesso carico dello stack di produzione, puoi di solito utilizzare meno istanze o istanze più piccole.

Gli stack di sviluppo non sono pubblici e ne controlli l'accesso nel modo seguente:

• Limitando l'accesso alla rete tramite la configurazione delle regole in entrata del gruppo di sicurezza del server applicazioni o del sistema di bilanciamento del carico in modo da accettare solo le richieste in entrata da parte di indirizzi IP o intervalli di indirizzi specificati.

  Ad esempio, puoi limitare l'accesso HTTP, HTTPS e SSH a indirizzi del tuo intervallo di indirizzi aziendali.

• Controlla l'accesso alla funzionalità di gestione AWS OpsWorks dello stack di Stacks utilizzando la pagina Autorizzazioni dello stack.

  Ad esempio, puoi concedere un livello di autorizzazione Gestione al team di sviluppo e Mostra a tutti gli altri dipendenti.

Stack di gestione temporanea

Utilizza uno stack di gestione temporanea per verificare e finalizzare i candidati per uno stack di produzione aggiornato. +Una volta completato lo sviluppo, crea uno stack di gestione temporanea tramite clonazione dello stack di sviluppo. Quindi esegui la suite di test sullo stack di gestione temporanea e distribuisci gli aggiornamenti su tale stack per risolvere i problemi che si verificano.

Gli stack di gestione temporanea, inoltre, non sono pubblici; puoi controllare l'accesso alla rete e allo stack in modo analogo allo stack di sviluppo. Tieni presente che quando cloni uno stack di sviluppo per creare uno stack di staging, puoi clonare le autorizzazioni concesse dalla gestione delle autorizzazioni di Stacks. AWS OpsWorks Tuttavia, la clonazione non influenza le autorizzazioni concesse dalle policy IAM degli utenti. È necessario utilizzare la console IAM, l'interfaccia a riga di comando o un SDK per modificare tali autorizzazioni. Per ulteriori informazioni, consulta Gestione delle autorizzazioni utente.

Stack di produzione

Lo stack di produzione è lo stack pubblico che supporta la tua applicazione corrente. Quando lo stack di gestione temporanea ha superato i test, lo promuovi a stack di produzione ed elimini il vecchio stack di produzione. Per un esempio su come Eseguire questa operazione, consulta Utilizzo di una strategia di sviluppo blu-verde.

Nota

Invece di usare la console AWS OpsWorks Stacks per creare gli stack manualmente, crea un modello per ogni stack. AWS CloudFormation Questo approccio presenta i vantaggi seguenti:

• Velocità e praticità: all'avvio del modello, crea AWS CloudFormation automaticamente lo stack, incluse tutte le istanze richieste.

• Coerenza: archivia il modello per ogni stack nel tuo repository di origine per garantire che gli sviluppatori utilizzino lo stesso stack per lo stesso scopo.

Utilizzo di una strategia di sviluppo blu-verde

Una strategia di distribuzione blu-verde è un modo comune per utilizzare in modo efficiente gli stack separati per distribuire un aggiornamento dell'applicazione in produzione.

• L'ambiente blu è lo stack di produzione, che ospita l'applicazione corrente.

• L'ambiente verde è lo stack di gestione temporanea, che ospita l'applicazione aggiornata.

Quando sei pronto a distribuire l'app aggiornata in produzione, trasferisci il traffico degli utenti dallo stack blu a quello verde, che diventa il nuovo stack di produzione. Quindi ritira il vecchio stack blu.

L'esempio seguente descrive come eseguire una distribuzione blu-verde con AWS OpsWorks stack Stacks, insieme a Route 53 e un pool di sistemi di bilanciamento del carico Elastic Load Balancing. Prima di effettuare il passaggio, è necessario verificare quanto segue:

• L'aggiornamento dell'applicazione sullo stack verde ha superato il test ed è pronto per la produzione.

• Lo stack verde è identico a quello blu tranne per il fatto che include l'app aggiornata e non è pubblico.

  Entrambi gli stack dispongono delle stesse autorizzazioni, dello stesso numero e tipo di istanze in ciascun livello, della stessa configurazione basata sul tempo e basata sul carico e così via.

• Tutte le istanze 24 ore su 24, 7 giorni su 7, dello stack verde e le istanze basate sul tempo pianificate sono online.

• Disponi di un pool di sistemi di bilanciamento del carico Elastic Load Balancing che possono essere collegati dinamicamente a un layer in entrambi gli stack e possono essere preriscaldati per gestire il volume di traffico previsto.

• Hai utilizzato la funzionalità di routing ponderato di Route 53 per creare un set di record in una zona ospitata che include i sistemi di bilanciamento del carico in pool.

• Hai assegnato un peso diverso da zero al sistema di bilanciamento del carico collegato al livello del server applicazioni dello stack blu e un peso pari a zero ai sistemi di bilanciamento del carico non utilizzati. In questo modo il sistema di bilanciamento del carico dello stack blu gestisce tutto il traffico in entrata.

Per trasferire gli utenti allo stack verde

1. Collegare uno dei sistemi di bilanciamento del carico inutilizzati del pool al livello del server applicazioni dello stack verde. In alcuni casi, ad esempio quando si prevede traffico flash, oppure se non è possibile configurare un test di carico per aumentare progressivamente il traffico, inizializzare il sistema di bilanciamento del carico per gestire il traffico previsto.

2. Dopo che tutte le istanze dello stack verde hanno superato il controllo di integrità di Elastic Load Balancing, modifica i pesi nel set di record della Route 53 in modo che il load balancer dello stack verde abbia un peso diverso da zero e il load balancer dello stack blu abbia un peso corrispondente ridotto. È consigliabile iniziare facendo gestire una piccola percentuale di richieste allo stack verde, magari il 5%, lasciando gestire tutto il resto allo stack blu. Sono ora disponibili due stack di produzione: il verde che gestisce alcune delle richieste in entrata e il blu che gestisce il resto.

3. Monitorare i parametri di prestazione dello stack verde. Se sono accettabili, aumentare il peso dello stack verde in modo che possa gestire magari il 10% del traffico in entrata.

4. Ripetere la fase 3 finché lo stack verde non gestisce circa metà del traffico in entrata. A questo punto dovrebbero essere emersi tutti i potenziali problemi, pertanto se lo stack verde funziona in modo accettabile, è possibile completare il processo riducendo il peso dello stack blu a zero. Lo stack verde è ora il nuovo stack blu e gestisce tutto il traffico in entrata.

5. Scollegare il sistema di bilanciamento del carico dal livello del server applicazioni del vecchio stack blu e restituirlo al pool.

6. Anche se il vecchio stack blu non gestisce più le richieste degli utenti, consigliamo di conservarlo per un po' in caso di problemi con il nuovo stack blu. In questo caso, è possibile eseguire il roll back dell'aggiornamento invertendo la procedura per indirizzare il traffico in entrata al vecchio stack blu. Quando si è certi che il nuovo stack blu stia funzionando in modo accettabile, arrestare il vecchio stack blu.

Gestione di un database back-end

Se l'applicazione dipende da un database di backend, sarà necessario passare dalla vecchia applicazione alla nuova. AWS OpsWorks Stacks supporta le seguenti opzioni di database.

Livello Amazon RDS

Con un livello Amazon Relational Database Service (Amazon RDS), crei l'istanza DB RDS separatamente e poi la registri nel tuo stack. Puoi registrare un'istanza database RDS con un solo stack alla volta, ma è possibile trasferire un'istanza database RDS da uno stack a un altro.

AWS OpsWorks Stacks installa un file con i dati di connessione sui server delle applicazioni in un formato che può essere facilmente utilizzato dall'applicazione. AWS OpsWorks Stacks aggiunge inoltre le informazioni di connessione al database agli attributi di configurazione e distribuzione dello stack, a cui è possibile accedere tramite ricette. Puoi inoltre utilizzare JSON per fornire i dati di connessione alle applicazioni. Per ulteriori informazioni, consulta Connessione a un database.

L'aggiornamento di un'applicazione che dipende da un database pone due sfide fondamentali:

• Garantire che ogni transazione venga correttamente registrata durante la transizione evitando race condition tra le nuove e le vecchie versioni dell'applicazione.

• Eseguire la transizione in un modo che limiti l'impatto sulle prestazioni del sito e riduca al minimo o elimini tempi di inattività.

Quando utilizzi le strategie di distribuzione descritte in questo argomento, non potrai semplicemente scollegare il database dalla vecchia applicazione e ricollegarlo alla nuova. Entrambe le versioni dell'applicazione vengono eseguite in parallelo durante la transizione e devono disporre dell'accesso agli stessi dati. Di seguito vengono descritti due approcci alla gestione della transizione, entrambi con vantaggi e sfide.

Approccio 1: entrambe le applicazioni si connettono allo stesso database

Vantaggi

• Non si verificano tempi di inattività durante la transizione.

  Un'applicazione interrompe gradualmente l'accesso al database, mentre l'altra assume gradualmente il controllo.

• Non è necessario sincronizzare i dati tra i due database.

Sfide

• Entrambe le applicazioni accedono allo stesso database, quindi è necessario gestire l'accesso per evitare la perdita o il danneggiamento dei dati.

• Se è necessario eseguire la migrazione a un nuovo schema del database, la vecchia versione dell'applicazione deve essere in grado di utilizzarlo.

Se utilizzi stack separati, questo approccio è probabilmente più adatto ad Amazon RDS perché l'istanza non è legata in modo permanente a uno stack particolare ed è accessibile da applicazioni in esecuzione su stack diversi. Tuttavia, non potrai registrare un'istanza database RDS con più di uno stack alla volta, pertanto è necessario fornire i dati di connessione a entrambe le applicazioni, per esempio utilizzando JSON. Per ulteriori informazioni, consulta Utilizzo di una ricetta personalizzata.

Se utilizzi un aggiornamento progressivo, la vecchia e la nuova versione dell'applicazione sono ospitate sullo stesso stack, quindi puoi utilizzare un livello Amazon RDS o MySQL.

Approccio 2: fornire a ciascuna versione dell'applicazione il proprio database

Vantaggi

• Ogni versione dispone del proprio database, in modo che gli schemi non debbano essere compatibili.

Sfide

• Sincronizzare i dati tra i due database durante la transizione senza perdere o danneggiare dati.

• Garantire che la tua procedura di sincronizzazione non provochi notevoli tempi di inattività o peggiori in modo significativo le prestazioni del sito.

Se stai usando stack separati, ognuno ha il proprio database. Se stai usando una distribuzione in sequenza, puoi collegare due database allo stack, uno per ogni applicazione. Se la vecchia applicazione e quella aggiornata non dispongono di schemi di database compatibili, questo approccio è migliore.

Raccomandazione: in generale, consigliamo di utilizzare un livello Amazon RDS come database di backend dell'applicazione perché è più flessibile e può essere utilizzato per qualsiasi scenario di transizione. Per ulteriori informazioni su come gestire le transizioni, consulta la Amazon RDS User Guide.