2016-03-15 16 views
6

Attualmente sto migrando un sito Web Django dal mio server hostato che esegue Ubuntu in AWS Elastic Beanstalk.Impostazione di un processo pianificato/cron con Django su Elastic Beanstalk con un livello di lavoratore

Ho trovato il processo un po 'semplice, fino a quando non ho provato a impostare alcuni lavori programmati per la mia app. Da quello che posso raccogliere, voglio eseguire un cron job su un ambiente di lavoro utilizzando un file cron.yaml. Ho letto attraverso la documentazione: http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features-managing-env-tiers.html#worker-periodictasks

e leggere il post del blog: https://medium.com/@joelennon/running-cron-jobs-on-amazon-web-services-aws-elastic-beanstalk-a41d91d1c571#.mx7dq9ufo

E vari post StackOverflow, ma mi sento come mi manca ancora alcuni concetti fondamentali su ciò che rende effettivamente il mio operaio ambiente di livello. Sul mio server potevo semplicemente creare un cron job per soddisfare questa esigenza - quindi questo concetto è piuttosto nuovo per me. Ho anche alcune app di Django in esecuzione su Heroku che utilizzano dinamiche web e di lavoro, elaborazione asincrona, Redis e Celery e lavori programmati, ma non riesco a capire come tradurre questo nel mondo di Elastic Beanstalk.

In sostanza, i concetti che voglio capire sono:

  1. Ciò che rende in realtà il mio ambiente di livello dei lavoratori per quanto riguarda il codice va? Ovviamente più del semplice file cron.yaml. È questo un clone esatto della mia app Web, distribuito anche in questo ambiente? O può questo in qualche modo fare riferimento al codice dal mio ambiente web ed eseguire in questo modo?
  2. Oppure l'app worker è completamente nuova completamente? Devo creare un'app di Django/Flask in piena regola per farlo?
  3. In che modo l'app del mio operatore parla fisicamente alla mia app Web? In che modo i messaggi POST in cron.yaml sono effettivamente pensati per eseguire lavori nell'app Web? Se si tratta di un'app standalone, in che modo vengono effettivamente collegati gli ambienti utente e Web?

In sostanza, desidero pianificare alcuni comandi di gestione Django. Ho esposto i metodi come endpoint POST, ma non riesco a capire come ottenere l'ambiente di lavoro per parlare/eseguire i lavori sull'app Web.

Scusa la mia ingenuità, apprezzerei davvero ogni tipo di consiglio e direzione su come questo concetto si riunisce tutti.

risposta

3

Così ho finito per parlare con un amico che ha più familiarità con i servizi AWS. Ha spiegato i concetti e ho ottenuto i lavori pianificati in esecuzione impostando l'ambiente di lavoro come segue:

  • Creazione di un'applicazione autonoma separata per l'ambiente web. Ho creato un'app Django "worker" separata, ma questa poteva essere Flask o qualsiasi altra struttura o linguaggio
  • Creata un'app chiamata "cron" che aveva viste per gestire i messaggi POST a diversi endpoint, che sono essenzialmente i lavori programmati. voluto eseguire. Questi endpoint sono ciò che i lavori nel mio file cron.yaml sono diretti a
  • Poiché i miei lavori dovevano apportare modifiche al database per l'app Web, ho configurato l'app worker per utilizzare lo stesso database dell'app Web. Era semplice come aggiungere variabili di ambiente RDS alla mia configurazione dell'ambiente di lavoro. Per esempio. Set RDS_DB_NAME, RDS_HOSTNAME, RDS_USERNAME per puntare al database ambiente web

Et voilà, i processi pianificati eseguiti nei tempi previsti e apportare le modifiche del database come richiesto.

+1

Un'altra idea è di includere 1 endpoint di cron nell'app web/non-worker principale, che esegue la gestione di 'runcrons' [django-cron's] (http://django-cron.readthedocs.io/en/latest/) comando a livello di codice e crea 1 endpoint dell'app di lavoro che richiede l'endpoint dell'app Web. Una chiave arbitraria conosciuta da entrambi i server (inviata da worker, convalidata dall'app Web) impedirebbe agli utenti di attivare i tuoi crons. Il vantaggio non è la necessità di reinventare la ruota con modelli, connessioni database, ecc. Sul lavoratore. Tuttavia, se i crons sono a uso intensivo di risorse e/o frequenti, potrebbe trattarsi di un problema sul server web. – jmq

+0

@ jmq Mi piace molto la tua soluzione in realtà. La mia soluzione richiedeva la clonazione di tutti i miei modelli in un'app separata e il collegamento allo stesso database, che è un po 'disordinato. – benedwards44

+0

Dopo aver affrontato nuovamente questo problema e considerandolo di più, lo scenario migliore per me ora sembra essere quello di sviluppare il "cron.yaml" nel repository principale e inviare un duplicato del codice base al server worker. Anche se questo non si sente molto SECCO in un modo (che stai solo eseguendo il codice completo su 2 server e i loro scopi sono diversi), scarica il lavoro effettivo delle attività di cron sul livello di lavoro, che è il punto di AWS offre questo livello. Inoltre minimizza/elimina il nuovo codice dalla necessità di essere scritto (in contrasto con il mio primo commento sopra). – jmq

Problemi correlati