Come implementare l'individuazione del servizio per i client Swarm Docker esterni

Question

Come implementare l'individuazione del servizio per i client Swarm Docker esterni

#1 da (2 voti)

4

Ho una domanda riguardante un caso specifico con il nostro prodotto.

Diciamo che ho due servizi; Service A e Service B . (Il numero di servizi varia da un'installazione all'altra). Sono schierati nel nostro Docker Swarm. Non pubblicano alcuna porta, il che significa che non sono raggiungibili al di fuori del nostro cluster Swarm. E ho un contenitore Nginx, che pubblica una porta all'esterno di Swarm e che usiamo come proxy inverso.

Service A e Service B fanno cose molto simili, che chiameremo dipende dalle preferenze del nostro cliente. Vorremmo che i nostri clienti usassero lo stesso endpoint (diciamo HTTP POST /some-event ) per accedere a quei servizi, ma anche selezionare un servizio ( Service A o Service B ) fornendo qualcosa in più con il contesto della richiesta.

Ad esempio, abbiamo pensato di implementare un altro server con accesso a Service A e Service B , creando chiavi di accesso per entrambi i servizi, scrivendoli nel database e fornendo ai nostri clienti le chiavi di accesso. Questo nuovo server sarà l'unico destinatario di HTTP POST /some-event e instraderà la richiesta a Service A o Service B a seconda della chiave di accesso fornita con il contesto della richiesta (ad esempio nell'intestazione, ecc.) Ma questo sembrava reinventare la ruota.

Sto anche esaminando Netflix Zuul, ma questa soluzione implica la scrittura di una configurazione Zuul ogni volta che distribuiamo il nostro prodotto (a seconda del numero di servizi che distribuiamo con ogni installazione).

Quindi la domanda è; quali potrebbero essere i modi alternativi per ottenere il routing dinamico con le intestazioni per le richieste fatte alla stessa risorsa / servizio? Grazie!

design architecture microservices docker

posta Hasan Can Saral 30.10.2016 - 20:56

fonte

1 risposta

Leggi altre domande sui tag design architecture microservices docker

Riscrivi eventi in EventStore Paradigmi di registrazione, DI / IoC, gerarchie di oggetti

score 2 · Accepted Answer

Faccio qualcosa di simile a ciò che descrivi nel mio design. Anche se l'ho risolto tramite il routing sul nome di dominio. No, i diversi servizi dovrebbero essere distribuiti sotto domini / sotto-domini diversi.

Tuttavia, se si imposta l'uso delle intestazioni per il routing, è possibile fare qualcosa di simile:

upstream service1 { server 127.0.1.1:65535; }
upstream service2 { server 127.0.1.2:65535; }

map $http_x_access_key $access_key 
{
  123 "service1";
  456 "service2";
}

server 
{
  listen 80;
  server_name example.com;
  location / 
  {
     proxy_pass http://$access_key;
     # proxy settings
     # ...
  }
}

link

Se hai bisogno di accedere a un livello db per risolvere la richiesta, ti suggerisco di scrivere il tuo proxy inverso per risolvere questo problema. Dovresti riuscire a farlo in poche righe e, se necessario, potrai estendere ulteriormente la funzionalità.