Distribuzioni blu / verdi con CloudFront

Sto cercando un modo per eseguire distribuzioni Blue / Green con CloudFront .

Qualcuno ha una buona soluzione per passare da una distribuzione CloudFront a un'altra o tutti semplicemente creano la propria distribuzione e non la toccano mai più?

La mia distribuzione CloudFront è composta da un'origine S3 per contenuto statico (javascript, ecc.) E un'origine personalizzata che punta a un ELB AWS.

Nessuna modifica a CloudFront

In circostanze normali non apportiamo alcuna modifica alla nostra distribuzione CloudFront. Eseguiamo la versione del nostro contenuto statico nell'origine S3 modificando il nome dei file di contenuto statico in S3 e eseguendo il roll-down delle distribuzioni nelle istanze EC2 con Elastic Load Balancer (ELB). Tuttavia, ci sono momenti in cui è necessario testare e apportare modifiche alla distribuzione CloudFront stessa o apportare modifiche abbastanza significative al nostro ambiente da dover puntare a un nuovo ELB in un nuovo ambiente.

Due distribuzioni CloudFront

La prima opzione che ho provato è stata quella di avere due distribuzioni Web CloudFront separate , una per il mio ambiente attuale o A e una per il mio nuovo ambiente o B. Ho tentato di utilizzare una politica di routing ponderata Route53 in cui ho aggiunto due record per il mio record Route53 www.domain.com, uno che punta a CloudFront Distribution A con un peso di 1 e l'altro che punta a CloudFront Distribution B con un peso di 0. Il piano sarebbe quello di cambiare i pesi quando voglio passare dalla distribuzione A alla distribuzione B. Tuttavia, solo una distribuzione CloudFront alla volta può avere i nomi di dominio alternativi (CNAME) www.domain.com registrati o si ottiene il seguente errore:

com.amazonaws.services.cloudfront.model.CNAMEAlreadyExistsException: One or more of the CNAMEs you provided are already associated with a different resource. (Service: AmazonCloudFront; Status Code: 409; Error Code: CNAMEAlreadyExists; Request ID: ef84a5f0-44e7-11e5-9315-0ba167bb108a)

Una distribuzione CloudFront

La seconda opzione è quella di mantenere una distribuzione web CloudFront. Ho origini S3 e personalizzate che puntano ad entrambi i miei ambienti A e B e quindi aggiorno il comportamento della cache di CloudFront per puntare all'altra origine quando voglio spostarmi da un ambiente all'altro. Questo è estremamente disordinato perché questi aggiornamenti impiegano 15-60 minuti, non c'è visibilità sullo stato di avanzamento dell'aggiornamento e, a seconda della natura della modifica, potrebbe essere necessario seguirlo con un Invalidation CloudFront in modo da non pubblicare contenuti nella cache dal vecchio ambiente insieme a nuovi contenuti.

Grazie per il tuo consiglio!

Due distribuzioni Cloudfront

Poiché AWS consente la sovrapposizione tra CNAME alternativi con caratteri jolly nello stesso account AWS, puoi passare tra due distribuzioni cloudfront nel modo seguente:

• Usa www.domain.com come CNAME alternativo per la distribuzione Prod 1
• Usa * .domain.com come CNAME alternativo per la distribuzione Prod 2
• Punta il tuo DNS CNAME www.domain.com alla distribuzione 1 o alla distribuzione 2. (* .cloudfront.net).
• Rimuovi il CNAME alternativo dalla distribuzione da cui non desideri più pubblicare il contenuto.

Tuttavia, i due diversi DNS di distribuzione (* .cloudfront.net) possono puntare agli stessi nodi Edge, il che significa che il modo in cui viene offerto il contenuto è abbinando il CNAME cloudfront.net ai nodi Edge che lo servono e quindi abbinando per Nome host. In questo caso, se entrambe le distribuzioni utilizzano gli stessi nodi perimetrali (si può verificare ad esempio con dig) il taglio non sarà pulito.

ad es. se entrambe le distribuzioni condividono uno o più nodi edge, la distribuzione 1 con Alt CNAME www.domain.com avrà la precedenza sulla distribuzione 2 con il più generico * .domain.com fino a quando il CNAME viene rimosso dalla configurazione di distribuzione 1 in tutti i nodi edge . Pertanto, la versione recuperata da una richiesta potrebbe essere diversa dall'altra durante il periodo di transizione.

Un po 'tardi nel gioco qui, ma per chiunque lo stia cercando. Credo che questo possa essere fatto usando lambda @ edge. Simile ai test A / B. https://docs.aws.amazon.com/lambda/latest/dg/lambda-edge.html . È possibile implementare una funzione lambda attivata quando un utente richiede un URL. Scegli di pubblicare il contenuto blu / verde di origini diverse o prefisso URL. Un valore di cookie determinerà quale distribuzione verrà pubblicata. Quando arriva la prima richiesta (nessun cookie) impostare il cookie in modo casuale dire 95% blu 5% verde.

Scatto dall'anca, quanto tempo ci vuole per cambiare l'origine all'interno di una distribuzione del fronte cloud? 1) distribuire il nuovo codice dietro ELB, riscaldarlo 2) aggiungere questo ELB come nuova origine alla distribuzione del cloud front mentre rimuovendo la vecchia origine 3) una volta tagliato, abbattere il vecchio codice dietro il vecchio ELB.

Per evitare i ritardi associati agli aggiornamenti CloudFront o DNS, è possibile scambiare il gruppo di scalabilità automatica dietro ELB. 1) implementa il nuovo codice nel nuovo ASG, riscaldalo 2) registra il tuo ELB esistente con questo nuovo ASG 3) annulla la registrazione del vecchio ASG dal tuo ELB 4) una volta tagliato, abbatti il ​​vecchio ASG.

Ho anche fatto ricerche su questo argomento e ho una soluzione (vedi sotto).

Sfondo:

CloudFront richiede che CNAME nella configurazione della distribuzione sia univoco in tutto il tuo account. Pertanto, il controllo blu / verde via DNS a diverse distribuzioni non funzionerà. C'è un trucco che usa i caratteri jolly ma che non garantisce che vengano forniti i file corretti. Il controllo blu / verde tramite DNS e CloudFront non è fattibile.

Inoltre, la modifica di qualsiasi configurazione in CloudFront (incluso CNAME) comporta 15-60 minuti di attesa mentre le modifiche vengono propagate ai server perimetrali. Inoltre, non è una configurazione ideale.

Aggirare:

Per app a pagina singola, questa configurazione che potrebbe fare il trucco:

• URL dell'app: app.mydomain.com/app
• Struttura S3:
  • app / (il tuo sito live)
  • app2 / (il tuo sito non così live)

Ora configura CloudFront per usare il tuo bucket per servire i file. A questo punto, tutto dipende dalle impostazioni della cache. Poiché CloudFront impiega un'eternità, imposta l'intestazione CacheControl sui nostri oggetti S3. Per index.html, utilizziamo 5 minuti, tutto il resto, 1 giorno. Quando arriva il momento di cambiare, scambia i nomi delle directory S3. Entro 5 minuti, l'app sarà in diretta a tutti gli effetti.

Per le app che sono già in esecuzione, abbiamo la versione di build integrata nel codice e un file json di configurazione build sulla radice dell'app. Quindi l'app richiederà occasionalmente il file json, controlla la versione, se non è aggiornata, richiede un aggiornamento.

limitazioni

Non è possibile eseguire test di immersione molto bene. Suppongo che sia possibile aumentare il TTL di index.html a poche ore o giorni (a seconda delle esigenze), ciò contribuirebbe a garantire che i client ottengano nuove versioni allo scadere della cache locale.

In questo post del blog l'autore implementa un test ab tramite Lambda @ Edge lavorando al di fuori del codice nella documentazione di AWS (puoi vedere i loro esempi qui: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda- esempi.html ).

Fondamentalmente quello che fai è creare una singola distribuzione Cloudfront che punta a due origini diverse. Quindi puoi utilizzare Lambda @ Edge per indirizzare il traffico verso entrambe le origini (tramite i cookie) e, naturalmente, puoi implementare altre cose tramite Lambda come ponderare il traffico o capovolgerlo, ecc. È anche facile aggiungere ulteriori origini e logica .