Guarire automaticamente un'istanza EC2 con un gruppo di scala automatica?

Sto provando a configurare un'istanza EC2 di autocalorizzazione utilizzando un gruppo di scala automatica e uno script di avvio dati utente. Se il server corrente ha un problema in cui non è più raggiungibile, l'istanza dovrebbe terminare e un nuovo deve sostituirsi. Questo è abbastanza facile, ma un requisito si dimostra difficile.

Ho bisogno del server di sostituzione di avere lo stesso IP privato del server precedente. Il mio pensiero è di avere un IP privato secondario (questo è all'interno di un VPC) assegnato al server originale e quindi riassegnarlo al nuovo server.

  1. Suppongo di poter utilizzare l'aws-cli installato durante lo script di avvio dati utente per riassegnare l'IP privato, ma come faccio a sapere quale server viene sostituito e re-assegnare l'IP da esso (ad esempio se nel futuro la piscina di server è più grande e 2 accadono di scendere contemporaneamente).

  2. Se il server originale viene terminato, potrei riuscire a assegnare nuovamente l'IP privato?

  • Come si va a elencare istanze utilizzando cli in alcuni VPC con il nome del tag, l'indirizzo IP privato dell'istanza e dell'istanza di istanza?
  • Esiste un command per elencare le istanze AWS che comportno una breve output?
  • AWS CLI lancia l'istanza Host name & Elastic IP
  • Scaricare il certificato SSL da gestore certificati aws
  • C'è un modo per recuperare tutti i contenuti da un bucket Amazon S3 in versione aggiornata a partire da un determinato data-time
  • Aggiornamento di AWS CLI su Ubuntu 14.04
  • Problemi che utilizzano gli strumenti della row di command EC2 in una delle istanze
  • Come eseguire le istruzioni descrittive di aws ec2 per account diversi
  • 2 Solutions collect form web for “Guarire automaticamente un'istanza EC2 con un gruppo di scala automatica?”

    Dopo molte ricerche e prove / errori, ecco cosa abbiamo finito per fare:

    1. Abbiamo messo each tipo di server nel proprio gruppo di scala automatica con uno script di shell utente per configurare completamente i server.
    2. Abbiamo utilizzato tag per tenere traccia delle risorse sui server che volevamo trasferire (IP privato, IP elastico, EBS, ecc.).
    3. Al momento dell'avvio di un'istanza di sostituzione, il nostro script di dati utente interroga l'AWS CLI per get un'istanza terminata dello stesso tipo con i tag di risorse disponibili.
    4. Utilizziamo i dati in tali tag e l'AWS CLI per assegnare tali risorse al server di sostituzione e quindi rimuovere i tag dal vecchio server.
    5. Poiché questo è tutto in un VPC, l'IP privato è ancora disponibile per noi perché viene rilasciato nuovamente alla VPC alla fine dell'istanza.

    Abbiamo funzionato per alcuni giorni e sembra funzionare abbastanza bene (anche se rimane da vedere quando un'istanza in realtà fallisce per qualcosa di diverso da noi che lo chiude direttamente per il test).

    AWS ha recentemente annunciato la funzionalità "Auto-Recovery for EC2 Instances". Per quanto lo capisco, questo funziona sostanzialmente come un gruppo di scala automatica, ma conserva IP e volumi di istanza ecc.

    Al momento questa funzionalità è disponibile solo per i casi più recenti e solo nella regione del sud-est.

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.