Launch template e configurazione ASG

Un Launch Template è un modello versionato che indica agli Auto Scaling Group (e direttamente a EC2) come avviare le istanze. Contiene l'ID AMI, il tipo di istanza, la coppia di chiavi, i gruppi di sicurezza e gli eventuali user data in un unico documento riutilizzabile. A differenza della precedente Launch Configuration, un Launch Template supporta più versioni e può essere aggiornato senza sostituire l'ASG.

Potete creare un Launch Template con AWS CLI utilizzando create-launch-template. Il parametro --launch-template-data accetta un oggetto JSON che definisce tutte le impostazioni dell'istanza. Il versionamento consente di apportare modifiche al template senza influire sulle istanze in esecuzione finché non siete pronti per il deployment.

Ogni Launch Template inizia dalla versione 1. Quando create una nuova versione, potete sovrascrivere solo i campi modificati; tutte le altre impostazioni vengono ereditate dalla versione di origine. Potete configurare l'ASG in modo che utilizzi una versione $Latest (sempre la più recente) o una versione $Default (designata esplicitamente). L'utilizzo di $Default consente rollout controllati, mentre $Latest è pratico negli ambienti di sviluppo.

Un Auto Scaling Group (ASG) gestisce un insieme di istanze EC2 entro limiti definiti: minimo (soglia inferiore), massimo (soglia superiore) e capacità desiderata (numero target in ogni momento). Quando le istanze non superano i controlli dello stato o si attiva una policy di scaling, l'ASG avvia o termina automaticamente le istanze per mantenere il numero desiderato, tra il minimo e il massimo.

Quando si crea un ASG, si fa riferimento a un Launch Template (non direttamente a una AMI specifica). Occorre inoltre specificare le sottoreti VPC in cui verranno avviate le istanze. Distribuire le istanze su più sottoreti (una per AZ) offre ridondanza multi-AZ integrata: se un'AZ si guasta, l'ASG avvia automaticamente istanze sostitutive nelle AZ rimanenti.

Per impostazione predefinita, un ASG utilizza i controlli dello stato EC2, che contrassegnano un'istanza come non integra solo se è arrestata, terminata o se l'hypervisor segnala un errore. Quando si collega un load balancer, è consigliabile passare ai controlli dello stato ELB, in modo che l'ASG sostituisca le istanze in esecuzione che restituiscono errori HTTP 5xx. Questa è una domanda frequente negli esami: quando nell'architettura è presente un load balancer, scegliere sempre i controlli dello stato ELB.

Impostare correttamente i limiti della capacità è fondamentale. Il minimo garantisce che l'applicazione possa sempre gestire il traffico (non si scende mai al di sotto di questo valore). Il massimo impedisce uno scaling incontrollato che potrebbe esaurire i limiti del servizio o il budget. La capacità desiderata è il target iniziale; le policy di scaling la modificano dinamicamente. Se min=max=desired, l'ASG funziona come un gruppo di dimensioni fisse, utile per i deployment tramite Launch Template o per una capacità vincolata.

Per le applicazioni del web tier, collegare l'ASG a un target group di Application Load Balancer. Ogni nuova istanza avviata dall'ASG viene registrata automaticamente nel target group e le istanze terminate vengono rimosse automaticamente dalla registrazione. In questo modo il traffico viene instradato solo verso istanze integre e in esecuzione. È inoltre necessario impostare il tipo di controllo dello stato su ELB, affinché l'ASG rilevi i guasti a livello di load balancer.

Gli User data sono uno script shell (codificato in Base64) che viene eseguito una volta al primo avvio di un'istanza. In un Launch Template rappresentano il posto giusto per installare pacchetti, configurare agenti (CloudWatch, SSM) e recuperare il codice dell'applicazione. Mantenere gli User data idempotenti: gli script che possono essere eseguiti più volte senza problemi evitano inconvenienti durante l'instance refresh. Per configurazioni complesse, richiamare AWS Systems Manager o uno strumento di gestione della configurazione invece di incorporare script di grandi dimensioni.

Un Warm Pool pre-inizializza un insieme di istanze EC2 arrestate (o in esecuzione) in uno stato pronto, all'esterno dell'ASG. Quando l'ASG deve eseguire uno scale-out, utilizza le istanze del warm pool invece di avviare istanze da zero, riducendo drasticamente il tempo necessario per aggiungere capacità. Le istanze nel warm pool comportano costi dello stato arrestato (solo EBS, senza costi per la CPU), risultando molto più economiche rispetto al mantenimento di istanze di riserva completamente in esecuzione.

Quando l'ASG esegue uno scale-in, deve decidere quali istanze terminare. La policy di terminazione predefinita seleziona prima l'AZ con il maggior numero di istanze (per riequilibrare la distribuzione), poi l'istanza associata al Launch Template più vecchio e infine l'istanza più vicina all'ora di fatturazione successiva. È possibile personalizzare quest'ordine: ad esempio, scegliere OldestLaunchTemplate per rimuovere prima le istanze che eseguono configurazioni obsolete. L'ASG esegue inoltre automaticamente il riequilibrio tra le AZ dopo che una sottorete diventa disponibile o in seguito a modifiche manuali.

Verifichi la comprensione dei concetti di AWS Solutions Architect (SAA-C03) trattati in questa lezione.

In questa lezione ha appreso che i Launch Template forniscono un blueprint versionato e riutilizzabile per le istanze, che supporta più versioni e i puntatori di versione $Latest/$Default; i limiti della capacità dell'ASG (minimo/massimo/desiderato) determinano le dimensioni del gruppo, con distribuzione automatica multi-AZ tra le sottoreti; e i controlli dello stato ELB devono essere abilitati quando un ASG si trova dietro un load balancer, affinché i guasti a livello applicativo attivino la sostituzione. Nella prossima lezione verranno esaminate le policy di scaling, tra cui target tracking e step scaling.