Pagina “scusa, sito inattivo” di AWS ELB

Ho un sito ELB v2 di base. Nessun cluster o altro ancora. Sono abbastanza inesperto con AWS.

Il mio stack è nginx / uwsgi / django + altri servizi.

Mi chiedevo se qualcuno avesse pensato di fare una "scusa, il sito Web è attualmente inattivo ..." - pagina di stile (il testo personalizzato che posso aggiornare i tempi di inattività pianificati è un bonus!) Ogni volta che ci sono tempi di inattività per qualsiasi motivo e la salute di l'istanza è rossa. Non sembra che Amazon offra questa funzionalità: mi sto perdendo qualcosa? C'è un modo per creare un'istanza separata, minuscola, che viene servita SOLO se quella principale è rossa o qualcosa del genere?

Grazie!

La soluzione semplice e interessante è quella di mettere il tuo ELB dietro CloudFront.

Se il server di origine (in questo caso l'ELB) genera un errore 5XX (o 4XX se lo desideri), CloudFront può restituire una pagina di errore personalizzata , che puoi configurare CloudFront per recuperare da un bucket S3 creando una seconda origine che punta al bucket e creazione di un routing del comportamento della cache (ad es.) /errors/static/*al bucket.

Funziona meglio del failover di Route 53 per un motivo importante ... un errore fatale, se vuoi ... i browser sono terribili nel memorizzare nella cache le ricerche DNS per molto più tempo del previsto. Il DNS TTL non è pertinente.

In sostanza, una volta che un browser ha una voce DNS in mano, continua a provare a usarla ... in genere, fino a quando tutte le finestre del browser sono chiuse.

Quindi, se il tuo sito non funziona per un visitatore che era già sul sito, è improbabile che vedano il sito alternativo.

Peggio ancora, se un visitatore colpisce il tuo sito per la prima volta mentre è inattivo, si "attaccherà" sulla pagina di manutenzione finché non chiuderà tutte le finestre del browser.

Se si utilizza il DNS di failover, ciò è davvero utile solo se la destinazione di failover è ancora l'applicazione, forse solo più lontano.

Puoi disattivare la memorizzazione nella cache di CloudFront se non ti serve.

Puoi anche configurare l'errore di CloudFront che memorizza nella cache TTL su un valore diverso da zero se vuoi che smetta di martellare il tuo sito mentre è inattivo e cerca di ripristinarlo. Per una determinata pagina che genera un errore, continuerà a mostrare la pagina di errore e non disturberà il server con ulteriori richieste per quella pagina fino alla scadenza dell'errore CachingTTL.

Utilizzare DNS Route53 e routing di failover . Dovresti essere in grado di ottenere un bucket S3 che ospita un sito Web statico a pagina singola. Non credo che tu possa farlo con solo ELB.

Amazon ha un post sul blog che ti dice come farlo qui .

Aggiornamento: come dice Michael, c'è un inconveniente nella cache DNS del browser, vedi la sua risposta per ulteriori informazioni. Route 53 è probabilmente un'opzione più semplice di CloudFront, ma CF ha altri vantaggi, prestazioni e in alcuni casi d'uso può ridurre i costi.

Sono già state menzionate diverse soluzioni, tra cui CloudFront e Route53. CloudFront è un'ottima soluzione e nella mia esperienza non ha affatto rallentato le cose, ma comporta costi aggiuntivi. E Route53 ha già menzionato i problemi di cache DNS.

Fino a quando ALB non supporta le pagine di errore personalizzate (che possono o non possono accadere), esiste potenzialmente una nuova soluzione dopo il recente annuncio di risposte fisse ALB , ma non è point and click: è possibile impostare una funzione Lambda che aggiunge temporaneamente una regola per il bilanciamento del carico, fornendo una risposta fissa con i contenuti della "pagina di errore".

Oltre a scrivere Lambda, dovrai trovare un modo per attivarlo 'on' e 'off', che potrebbe essere tramite un controllo dello stato Route53 o un controllo dello stato del gruppo target del bilanciamento del carico (probabilmente tramite l'allarme CloudWatch -> SNS - > Lambda).

Non è esattamente semplice, ma probabilmente funzionerebbe bene una volta installato!

Come scritto da @Tim e @Micheal, puoi scegliere di utilizzare Route53 DNS e routing di failover o CloudFront con pagine di errore personalizzate . Entrambi i metodi hanno i loro pro e contro.

Se non stai già utilizzando Cloudfront, penso che Route53 sia una soluzione più semplice. Consulta il post di blog aggiornato di AWS (che ora include un metodo più semplice per l'integrazione ELB).

CloudFront è molto più complicato da configurare e ci vorranno circa 15 minuti per ogni aggiornamento. Cloudfront memorizza anche nella cache (come prevedibile), quindi non è chiaro se la risposta del DNS sarà più lenta rispetto ai problemi della cache DNS con Route 53.

Nota che se il tuo sito web ELB risponde solo a SSL, non puoi utilizzare la semplice soluzione S3 come descritto nel blog di AWS 3 . In tal caso dovrai aggiungere Cloudfront davanti al bucket S3 per aggiungere SSL, rendendo più complicata la soluzione di routing degli errori DNS.