Avvio EC2 nei tempi previsti

Devo avviare un’istanza EC2 alle (diciamo) 6am ogni giorno. I limiti sono che vorrei evitare di avere un computer in esecuzione tutto il giorno per eseguire l’avvio o utilizzare una soluzione a pagamento come ylastic.

La soluzione ad alestic, è la più vicina finora. Il lato negativo di questa soluzione è che il tempo di avvio è elevato a causa del tempo necessario per installare software personalizzato e per spostarsi tra i dati.

C’è un modo per avviare semplicemente un’istanza invece di creare una nuova istanza ogni volta, come mostrato in questo esempio ?

Dati i vostri vincoli, la funzionalità desiderata purtroppo non è coperta dai due meccanismi di automazione dedicati disponibili come prodotti e servizi AWS in questo momento:

  • Scalabilità automatica : è un servizio Web progettato per l’ avvio o la chiusura automatica delle istanze Amazon Elastic Compute Cloud (Amazon EC2) in base a criteri definiti dall’utente, pianificazioni e controlli dello stato.
  • AWS CloudFormation : offre agli sviluppatori e agli amministratori di sistema un modo semplice per creare e gestire una raccolta di risorse AWS correlate, eseguirne il provisioning e aggiornarle in modo ordinato e prevedibile.

Mentre l’avvio / arresto / riavvio concettualmente di un’istanza rientra nella categoria di gestione di quest’ultimo, non è disponibile in questo modo (che è anche la ragione per cui forniamo un’attività separata specificamente per questa funzionalità all’interno del deprecato Bamboo AWS Plugin e del suo successore Task Per AWS ).

Di conseguenza, gli approcci delineati nella mia risposta a Come triggersre / distriggersre le istanze cloud durante l’orario di ufficio sono ancora applicabili, sebbene con il vincolo aggiuntivo che è necessario trovare gratuitamente un provider che ospita lo script o la soluzione di integrazione continua:

  • Gli script di hosting sono, ad esempio, possibili già da un po ‘di tempo per mezzo di quei fornitori di cron job.

  • Data l’attuale esplosione delle soluzioni di Platform as a Service (PaaS) ci sono alcuni provider che ti permetteranno di fare script host e / o soluzioni di integrazione continua in un modo o nell’altro.

Ovviamente è necessario verificare se l’utilizzo dei livelli gratuiti disponibili per scopi come questo è accettabile in base ai rispettivi Termini di utilizzo di un provider in questione.

Ora puoi farlo con Amazon OpsWorks . Dopo aver impostato le cose principali, basta creare una nuova istanza e impostare il tipo di ridimensionamento su “time-based” (non è ansible modificarlo per qualche motivo una volta che l’istanza è stata effettuata):

inserisci la descrizione dell'immagine qui

Ora, fai clic sulla categoria “Istanze> Basato sul tempo” e imposta il programma:

inserisci la descrizione dell'immagine qui

C’è un altro strumento di pianificazione EC2 basato su Java che può aiutarti a risolvere questo problema. Per quanto mi riguarda, ho voluto rendere disponibile un server alla mia squadra durante gli orari di ufficio, anche se non è utilizzato da nessuno. Questa applicazione mi ha aiutato a raggiungere questo objective. Spero che questo faccia bene anche a te.

Suggerirei di programmare l’avvio EC2 usando AWS Lambda .

Raccomandazione :
Controlla il suggerimento di D. Svanlund , utente con Ace: 2000+ pts, su questo thread del forum AWS .

Vantaggio :
Non hai bisogno di nulla più di una piccola sceneggiatura o due che hai pianificato. Nessuna istanza da avviare, solo un’invocazione rapida dello script che hai creato. Scegli il linguaggio di programmazione che preferisci e usa l’SDK AWS per eseguire operazioni di istanza. Una soluzione abbastanza leggera,

Costo stimato :
L’attività eseguita due volte al giorno per un tempo inferiore a 3 secondi con un consumo di memoria fino a 128 MB costa in genere meno di $ 0,0004 USD / mese (Vedi riferimento )

programmazione
A gennaio 2016 gli eventi programmati di AWS Lambda sono stati trasformati in eventi AWS CloudWatch . Gli eventi CloudWatch hanno le stesse funzionalità di pianificazione degli eventi schedulati di Lambda. La limitazione degli eventi programmati di AWS Lambda di 5 eventi programmati per regione è stata revocata a 50 regole CloudWatch Events.

Metodo
Impostare i tipi di EC2 adatti alla Pianificazione Avvia / Arresta . Raccomando di usare EC2-VPC / EBS . Crea politica e ruolo IAM. Relazione di fiducia del ruolo appena creato (Vedi riferimento ).
Configura il trigger di eventi CloudWatch per Lambda tramite Function Trigger come mostrato di seguito.

Eventi CloudWatch - Programma

Ecco il codice della funzione start-server che Runtime è impostato su Node.js.
Cambia YOUR_REGION e YOUR_INSTANCE_ID al tuo da Instance Console .

var AWS = require('aws-sdk'); exports.handler = function(event, context) { var ec2 = new AWS.EC2({region: 'YOUR_REGION'}); ec2.startInstances({InstanceIds : ['YOUR_INSTANCE_ID'] },function (err, data) { if (err) console.log(err, err.stack); // an error occurred else console.log(data); // successful response context.done(err,data); }); }; 

Nota: nel caso in cui sia necessaria la funzione stop-server, è sufficiente modificare ec2.startInstances in ec2.stopInstances . Potresti persino non aver bisogno della funzione di arresto quando utilizzi Arresto automatico per avvio EC2

Registrazione
Se il ruolo IAM viene creato con le autorizzazioni necessarie, la funzione Lambda creerà AWS CloudWatch Log Stream per ciascuna delle sue esecuzioni.

AWS CloudWatch Log Stream

Ho appena affrontato lo stesso problema e l’ho risolto usando la scalabilità automatica proprio come molte delle risposte qui menzionate. L’unica cosa di cui hai bisogno è l’immagine AMI che vuoi eseguire e gli strumenti da riga di comando dell’API di scalabilità automatica .

Dopo aver scaricato gli strumenti, seguire le istruzioni nel file readme per impostare le variabili ambientali e aggiungere le credenziali AWS. Quindi inserire i seguenti comandi in un file batch (questo esempio è per Windows):

 as-create-launch-config --key "MYLAUNCHCONFIGNAME" --instance-type t1.micro --image-id MYAMI-IMAGEID --launch-config "MYLAUNCHCONFIGNAME" as-create-auto-scaling-group --auto-scaling-group "MYSCALINGGROUPNAME" --launch-configuration "MYLAUNCHCONFIGNAME" --availability-zones "us-east-1a,us-east-1b,us-east-1c,us-east-1d" --min-size 0 --max-size 0 rem Don't restart instance after shutdown as-suspend-processes "MYSCALINGGROUPNAME" --processes ReplaceUnhealthy rem Start instance at 22:15 as-put-scheduled-update-group-action --name "startMyInstance" --auto-scaling-group "MYSCALINGGROUPNAME" --min-size 1 --max-size 1 --recurrence "15 22 * * *" rem Stop instance at 23:05 as-put-scheduled-update-group-action --name "stopMyInstance" --auto-scaling-group "MYSCALINGGROUPNAME" --min-size 0 --max-size 0 --recurrence "05 23 * * *" 

Sostituisci i nomi in maiuscolo con alcuni di tua scelta e imposta l’AMI-ID corretto per la tua immagine AMI. Una nuova istanza basata sulla tua immagine AMI inizierà alle 22:15 e terminerà alle 23:05. Ovviamente è anche ansible modificare il tipo di istanza e le zone di disponibilità.

IMHO aggiungendo una pianificazione a un gruppo di ridimensionamento automatico è il migliore approccio “simile al cloud”, come accennato in precedenza.

Ma nel caso in cui non puoi terminare le tue istanze e usarne di nuove, ad esempio se hai IP elastici associati a ecc.

È ansible creare uno script Ruby per avviare e arrestare le istanze in base a un intervallo di date.

 #!/usr/bin/env ruby # based on https://github.com/phstc/amazon_start_stop require 'fog' require 'tzinfo' START_HOUR = 6 # Start 6AM STOP_HOUR = 0 # Stop 0AM (midnight) conn = Fog::Compute::AWS.new(aws_access_key_id: ENV['AWS_ACCESS_KEY_ID'], aws_secret_access_key: ENV['AWS_SECRET_ACCESS_KEY']) server = conn.servers.get('instance-id') tz = TZInfo::Timezone.get('America/Sao_Paulo') now = tz.now stopped_range = (now.hour >= STOP_HOUR && now.hour < START_HOUR) running_range = !stopped_range if stopped_range && server.state != 'stopped' server.stop end if running_range && server.state != 'running' server.start # if you need an Elastic IP # (everytime you stop an instance Amazon dissociates Elastic IPs) # # server.wait_for { state == 'running' } # conn.associate_address server.id, 127.0.0.0 end 

Dai un'occhiata a amazon_start_stop per creare uno scheduler gratuitamente usando Heroku Scheduler .

AWS Data Pipeline è particolarmente adatto a questo compito. Data Pipeline utilizza le tecnologie AWS e può essere configurato per eseguire comandi CLS AWS su una pianificazione impostata senza dipendenze esterne. Data Pipeline può scrivere registri su S3 ed eseguire nel contesto di un ruolo IAM, che elimina i requisiti di gestione delle chiavi. La pipeline di dati è anche economica; ad esempio, il livello gratuito Pipeline dati può essere utilizzato per arrestare e avviare istanze una volta al giorno.

https://aws.amazon.com/premiumsupport/knowledge-center/stop-start-ec2-instances/

La scalabilità automatica sembra la soluzione migliore per il tuo problema e AWS offre tale funzionalità. Se stai cercando una soluzione di terze parti come ylastic, ma non vuoi pagare per questo, l’unica alternativa che conosco è Scalr, dove lavoro. Scalr è open-source, quindi devi solo scaricare il codice sorgente e installarlo da solo.

Altre alternative includono RightScale e enStratus. A mio avviso, l’account gratuito di RightScale non include il ridimensionamento automatico, mentre il piano “gratuito” di enStratus addebita la scalabilità automatica su una base di $ 0.20 / server ora.

Il miglior metodo gratuito che conosco è http://www.exostack.com. Lo uso per pianificare l’triggerszione o la distriggerszione delle istanze a orari prestabiliti, utilizzandolo ora per oltre 400 istanze e funziona perfettamente. Inoltre hanno uno scheduler per istantanee e AMI che uso anche per DR. Hanno anche un tracker di costo ec2 piuttosto elegante – sembra darti una ripartizione mensile e annuale dei costi. IMO abbastanza preciso.

Amazon ora ha istanze riservate pianificate

Istanze riservate pianificate : queste istanze sono disponibili per l’avvio nelle windows temporali prenotate. Questa opzione consente di abbinare la prenotazione della capacità a una pianificazione ricorrente prevedibile che richiede solo una frazione di un giorno, una settimana o un mese. Ad esempio, se si dispone di un carico di lavoro prevedibile come un’analisi del rischio finanziario mensile, è ansible programmarlo per l’esecuzione nei primi cinque giorni del mese. Un altro esempio potrebbe essere la pianificazione dell’elaborazione delle bollette notturne dalle 4 pm alle 12:00 ogni giorno della settimana.

ma anche

Termine : le istanze riservate programmate hanno un impegno di un anno.

Opzione di pagamento : le istanze riservate pianificate accumulano tariffe orarie, fatturate con incrementi mensili nel corso del termine.

Per saperne di più https://aws.amazon.com/ec2/purchasing-options/reserved-instances/

  • Anch’io! Sconcertato di vedere Amazon non fornisce un modo integrato per programmare semplicemente l’EC2 per l’avvio e l’arresto in un determinato momento. (Beh, non è scioccato perché probabilmente non vogliono che tu sia in grado di spegnerlo, giusto? 🙂

  • RISPOSTA : Ho trovato il metodo Auto-Scaling il modo migliore per automatizzare questo e gratuitamente, senza la necessità di app di terze parti o di un server separato in esecuzione 24/7. Qui è necessaria una buona conoscenza di AS, AMI e EC2.

    Vai al link URL qui sotto per vedere come puoi aggiungere “AZIONI SCHEDULATE” ai tuoi gruppi di ridimensionamento automatico. Funziona alla grande!

    Ora posso far girare il mio server EC2 a mezzogiorno e girare (in realtà finisce) alle 8PM. Molto bello In bocca al lupo!

  • Di seguito è riportato uno screenshot delle mie impostazioni. Queste impostazioni creeranno e lanciano un EC2 ogni giorno per un’ora al giorno. SALUTI!

http://docs.aws.amazon.com/autoscaling/latest/userguide/schedule_time.html#sch-actions_rules

Azioni pianificate con scalabilità automatica:

Amazon ha recentemente annunciato due nuove funzionalità per ottenere questo risultato senza implementazioni personalizzate direttamente come configurazione dalla sezione AW2 Web Console EC2.

  • Utilizzo del ridimensionamento pianificato per scaling automatico delle applicazioni (Dopo aver creato un gruppo di scalabilità automatica, è disponibile una scheda in cui è ansible aggiungere ulteriori regole di autoscaling basate sul tempo) inserisci la descrizione dell'immagine qui

  • Prenotazione di istanze EC2 programmate (nella console EC2, in Istanze, esiste l’opzione di riservare istanze EC2 pianificate) inserisci la descrizione dell'immagine qui