2015-07-14 17 views
7

Attualmente stiamo lavorando su Dockerizing l'applicazione Ruby on Rails, che comprende anche il lavoro ritardato. Una domanda che ronza all'interno del nostro team di sviluppo è se e/o come Dockerizzare il componente del lavoro ritardato separatamente dall'applicazione.Dockerizing Delayed Job

Ciò consentirebbe al lavoro ritardato di avviare nuovi contenitori quando necessario per il traffico elevato all'interno della coda dei lavori. Inoltre, poiché differita Lavoro inizia effettivamente l'applicazione Rails ogni volta quando il primo avvio, abbiamo pensato che i seguenti vantaggi avrebbero seguito:

  1. Il contenitore di lavoro in ritardo potrebbe iniziare più velocemente
  2. Applicazione codice sarebbe start up a prescindere del tempo di avvio del contenitore Ritardo lavoro
+1

In realtà, il worker deve avere lo stack rails proprio come fa il contenitore dell'applicazione, con l'eccezione che il suo comando sarebbe il daemon del lavoro ritardato invece del server delle rotaie – DVG

+0

@DVG Esiste un vantaggio nell'esecuzione in un separato contenitore allora? Esiste naturalmente l'ideologia aggiunta di un singolo processo per contenitore, ma possiamo anche aumentare il processo di lavoro in ritardo a prescindere dallo stato effettivo dell'applicazione. – user2990654

+0

Certo, possono ancora essere scalati indipendentemente dall'applicazione, ma deve ancora avviare l'app per fare il suo lavoro – DVG

risposta

1

Quindi conosco un ragazzo responsabile di un'app di rotaie che utilizza lavori in ritardo. Quando è arrivato il momento di rendere disponibile l'app, ha ottenuto un contenitore per ciascuno. Entrambi i contenitori utilizzano lo stesso codice base, ma uno esegue il frontend e uno i lavori. Non è devops microservice-eriffic ma funziona.

Al di fuori della separazione logica tra i due, i contenitori docker devono avere solo un processo in esecuzione all'interno. Avrei potuto hackerarlo insieme ma sembrava sbagliato rompere un docker fondamentale fuori dal cancello.