Come condividere il lavoratore tra due diverse applicazioni su heroku?

Question

Ho due applicazioni separate in esecuzione su heroku e che puntano allo stesso database, il primo responsabile per user interface e il secondo per admin interface, sto usando sidekiq con redis per l'elaborazione dei processi in background, ho aggiunto un worker e sono in grado di condividere ' redis-server 'impostando la variabile di ambiente che punta allo stesso Redis che fornisce Addon, Ora desidero condividere anche il lavoratore, perché l'aggiunta del lavoratore extra avrà un costo doppio.

Si prega di suggerire, se questo è anche possibile o no?

Answer 1

Se entrambe le app utilizzano lo stesso URL Redis e lo stesso spazio dei nomi, è possibile avviare un utente con la stessa configurazione Redis e verrà condiviso da entrambi.

Si noti che il processo Sidekiq avvierà un'app o l'altra. Il codice per i tuoi lavoratori deve essere in quella app. L'altra applicazione non sarà in grado di fare riferimento al codice, ma può spingere i lavori utilizzando:

Sidekiq::Client.push('class' => 'SomeWorker', 'args' => [1,2,3]) 

nota che 'classe' è una stringa in modo SomeWorker può effettivamente essere definito nel altra applicazione.

Answer 2

Che ne dici di utilizzare 3 diverse app di heroku?

1. User Interface App (repository ui)
   • web: raggruppamento di server rotaie exec
2. Interfaccia di amministrazione App (repository di amministrazione)
   • web: server di fascio binari exec
3. Worker (repository admin)
   • lavoratore: fascio sidekiq exec (documentation)

Anche se 2 e 3 l'uso la stessa base di codice, è possibile avere 2 applicazioni diverse Heroku. Uno che avvia l'amministratore, uno che avvia effettivamente sidekiq. Questo risolverebbe il tuo problema?

Answer 3

La risposta di Mike è ancora una scommessa sicura, anche se dover includere tutte le opzioni sidekiq pertinenti in linea ovunque si accoda questa classe è un po 'grave.

Ecco un post sul blog che va in modo più dettagliato, e offre un secondo approccio:

http://coderascal.com/ruby/using-sidekiq-across-different-applications/

In sostanza l'alternativa è quella di avere una classe "proxy" sull'applicazione enqueueing che controlla il comportamento sidekiq (coda, tentativi, ecc.). Quindi ci sarebbe un nome di classe corrispondente nell'applicazione di ricezione/disaccoppiamento.

L'autore del post del blog ignora alcune logiche standard Sidekiq per il reindirizzamento dalla classe proxy alla classe non proxy sul lato ricevente. Ignorare il comportamento della gemma è un po 'rischioso e applica una convenzione extra sulla denominazione della classe. Ma potresti essere in grado di cavartela senza fare quella parte.