Vi invitiamo a dare un'occhiata alla trascrizione della relazione di Aleksandr Sigachev su Service Discovery nei sistemi distribuiti, utilizzando Consul come esempio.
Service Discovery è stato creato per facilitare la connessione di una nuova applicazione al nostro ambiente esistente con il minimo sforzo. Utilizzando Service Discovery, possiamo separare al massimo un contenitore in forma di Docker o un servizio virtuale dall'ambiente in cui è in esecuzione.
Salve a tutti! Sono Aleksandr Sigachev e lavoro per l'azienda Inventos. Oggi vi presenterò il concetto di Service Discovery, esaminando questo tema attraverso l'esempio di Consul.
Quali problemi risolve Service Discovery? È stato progettato per facilitare l'aggiunta di nuove applicazioni al nostro ambiente esistente senza complicazioni. Con Service Discovery, possiamo separare al meglio un contenitore in forma di Docker o un servizio virtuale dall'ambiente in cui è eseguito.
Come appare il tutto? In un classico esempio web si ha il frontend che gestisce la richiesta dell'utente, quindi svolge il compito di instradamento verso il backend. In questo caso, un load-balancer distribuisce il carico su due backend.
Qui vediamo il lancio di una terza istanza dell'applicazione. Quando l'applicazione viene avviata, essa si registra in Service Discovery. Questo notifica il load-balancer, che aggiorna automaticamente la sua configurazione per integrare il nuovo backend. In questo modo, backend possono essere aggiunti o rimossi dal servizio.
Cosa possiamo fare comodamente tramite Service Discovery? Può contenere le configurazioni di nginx, certificati e un elenco di backend attivi.
Inoltre, Service Discovery è in grado di rilevare guasti e malfunzionamenti. Quali schemi possono essere adottati per individuare errori?
- Questa applicazione, una volta sviluppata, informa Service Discovery che è ancora operativa.
- D'altra parte, Service Discovery interroga l'applicazione per verificare la disponibilità.
- Oppure si può utilizzare uno script o un'applicazione esterna per controllare la disponibilità della nostra applicazione e informare Service Discovery riguardo alla situazione: se tutto funziona correttamente o se è necessario escludere quell'istanza dal bilanciamento.
Ogni schema potrebbe essere applicato a seconda del software utilizzato. Ad esempio, se stiamo avviando un nuovo progetto, possiamo facilmente implementare una configurazione in cui la nostra applicazione notifica Service Discovery. In alternativa, possiamo configurare Service Discovery per eseguire controlli.
Se invece l'applicazione ci è stata ceduta o sviluppata da terzi, allora è opportuno utilizzare il terzo schema, in cui scriviamo un gestore e tutto si integra automaticamente nel nostro flusso di lavoro.
Questo è un esempio. Il load-balancer in forma di nginx si riavvia. Si utilizza un'utilità aggiuntiva, fornita insieme a Consul, chiamata consul-template. Definiamo una regola, specificando che utilizziamo un modello (scritto in Golang). In caso di eventi o notifiche riguardo a cambiamenti, il modello si rigenera e Service Discovery riceve un comando di "reload". Un semplice esempio è quando, a seguito di un evento, si riconfigura nginx e si riavvia.
Che cos'è Consul?
Prima di tutto, è un Service Discovery.
Possiede un meccanismo di controllo della disponibilità – Health Checking.
Dispone anche di un KV Store.
Inoltre, è progettato per uso Multi Datacenter.
A cosa serve tutto questo? Nel KV Store possiamo conservare esempi di configurazioni. Il Health Checking ci consente di monitorare un servizio locale e notificare eventuali problemi. Il Multi Datacenter è utilizzato per creare una mappa dei servizi. Ad esempio, Amazon ha diverse zone e instrada il traffico in modo ottimale, evitando richieste superflue tra i data center che comportano costi aggiuntivi, mentre il traffico locale ha una latenza inferiore.
Esaminiamo alcuni dei termini usati in Consul.
- Consul è un servizio scritto in Go. Uno dei vantaggi del software Go è che si tratta di un singolo file binario, che puoi scaricare e avviare da qualsiasi posizione senza dipendenze.
- Successivamente, tramite chiavi, possiamo avviare questo servizio in modalità client o server.
- L'attributo "datacenter" consente di etichettare a quale data center appartiene il server.
- Il consensus si basa sul protocollo raft. Se qualcuno è interessato, può leggerne di più sul sito di Consul. Questo protocollo consente di determinare un leader e stabilire quali dati considerare validi e disponibili.
- Gossip – è un protocollo che consente l'interazione tra nodi. Questa sistema è decentralizzato. All'interno di un data center, tutti i nodi comunicano con i vicini, scambiandosi le informazioni sullo stato attuale. Si può dire che si tratta di 'gossip' tra vicini.
- LAN Gossip – scambio locale di dati tra vicini all'interno di un singolo data center.
- WAN Gossip – viene utilizzato quando è necessario sincronizzare le informazioni tra due data center. Le informazioni vengono trasferite tra nodi contrassegnati come server.
- RPC – consente di effettuare richieste tramite un client su un server.
Descrizione di RPC. Supponiamo che su una macchina virtuale o un server fisico sia in esecuzione Consul come client. Viene effettuata una richiesta locale. Successivamente, il client locale richiede informazioni al server e si sincronizza. A seconda delle impostazioni, le informazioni possono provenire dalla cache locale oppure possono essere sincronizzate con il leader o il master del server.
Questi due schemi hanno sia vantaggi che svantaggi. Se lavoriamo con la cache locale, sarà veloce. Se lavoriamo con i dati memorizzati sul server, ci vorrà più tempo, ma otterremo informazioni più aggiornate.
Se lo rappresentiamo graficamente, avremo un'immagine del sito. Possiamo vedere che sono attivi tre master. Uno di essi è contrassegnato come leader. In questo esempio, tre client si scambiano informazioni tra loro localmente tramite UDP/TCP. Le informazioni tra i data center vengono trasferite tra server. Qui i client interagiscono localmente tra loro.
Quale API fornisce Consul? Per ottenere informazioni, Consul offre due tipi di API.
Questa è l'API DNS. Per impostazione predefinita, Consul viene avviato sulla porta 8600. Possiamo configurare il proxy di richiesta e garantire l'accesso tramite risoluzione locale, utilizzando DNS locale. Possiamo effettuare richieste tramite dominio e ricevere come risposta l'informazione sull'indirizzo IP.
HTTP API – oppure possiamo richiedere informazioni su un servizio specifico localmente sulla porta 8500 e ricevere una risposta JSON che indica quale IP ha il server, quale host e quale porta è registrata. Ulteriori informazioni possono essere fornite tramite un token.
Cosa serve per avviare Consul?
Nel primo caso, avviamo in modalità sviluppatore specificando il flag per indicare che siamo in modalità sviluppatore. L'agent parte come server, e svolge autonomamente tutte le funzioni su un'unica macchina. È conveniente, veloce e non richiede praticamente configurazioni aggiuntive per il primo avvio.
La seconda modalità è l'esecuzione in produzione. Qui il lancio è un po' più complicato. Se non abbiamo alcuna versione di Consul, dobbiamo portare il primo nodo in bootstrap, cioè la macchina che assumerà le funzioni di leader. La avviamo, poi avviamo un secondo server passando le informazioni su dove si trova il master. Ne avviamo un terzo. Dopo aver avviato tre macchine, sulla prima macchina già avviata in bootstrap, la riavviamo in modalità normale. I dati vengono sincronizzati e il cluster iniziale è già avviato.
Si consiglia di avviare da tre a sette istanze in modalità server. Questo è dovuto al fatto che se il numero di server aumenta, aumenta anche il tempo necessario per la sincronizzazione delle informazioni tra di essi. Il numero di nodi deve essere dispari per garantire un quorum.
Come vengono eseguiti i controlli di salute? Nella directory di configurazione di Consul scriviamo una regola di verifica in formato JSON. Il primo caso è la disponibilità, in questo caso del dominio google.com. Diciamo che dobbiamo eseguire questo controllo a intervalli di 30 secondi. In questo modo verifichiamo se il nostro nodo ha accesso alla rete esterna.
Il secondo caso è il controllo di se stesso. Utilizziamo un semplice curl per contattare localhost sulla porta specificata con un intervallo di 10 secondi.
Questi controlli vengono sommati e vanno al Service Discovery. In base alla disponibilità, questi nodi vengono esclusi o aggiunti all'elenco delle macchine disponibili e funzionanti correttamente.
Consul fornisce anche un'interfaccia UI, che può essere avviata con un flag specifico e sarà accessibile sulla macchina. Questo permette di visualizzare le informazioni e di apportare alcune modifiche.
In questo esempio è aperta la scheda 'Servizio'. Viene mostrato che sono attivi tre servizi, uno dei quali è Consul. Il numero di controlli eseguiti e sono presenti tre data center in cui si trovano le macchine.
Questo è un esempio della scheda 'Nodi'. Possiamo vedere che hanno nomi compositi legati ai data center. Qui viene mostrato anche quali servizi sono attivi, cioè possiamo notare che i tag non sono stati definiti. In questi tag aggiuntivi si possono fornire ulteriori informazioni che lo sviluppatore può utilizzare per specificare parametri aggiuntivi.
È possibile anche trasmettere informazioni a Consul sullo stato dei dischi e sul carico medio.
Domande
Domanda: Abbiamo un container Docker, come possiamo utilizzarlo con Consul?
Risposta: Per un container Docker ci sono vari approcci. Uno dei più comuni è utilizzare un container Docker di terze parti per la registrazione. Quando viene avviato, riceve il socket di Docker. Tutti gli eventi di registrazione e deregistrazione del container vengono registrati in Consul.
Domanda: Cioè, Consul avvia autonomamente il container Docker?
Risposta: No. Siamo noi a avviare il container Docker. E nella configurazione specifichiamo – ascolta su questo socket. Funziona più o meno come quando gestiamo un certificato, quando divulghiamo le informazioni su dove e cosa abbiamo.
Domanda: Quindi, all'interno del container Docker che stiamo cercando di connettere al Service Discovery deve esserci una logica in grado di fornire i dati a Consul?
Risposta: Non proprio. Quando si avvia, trasmettiamo variabili tramite l'ambiente. Ad esempio, il nome del servizio, la porta del servizio. Il registro ascolta queste informazioni e le inserisce in Consul.
Domanda: Ho anche una domanda sull'UI. Abbiamo distribuito l'UI, ad esempio, su un server di produzione. Che succede con la sicurezza? Dove vengono archiviati i dati? È possibile in qualche modo accumulare i dati?
Risposta: Nell'UI ci sono esattamente i dati dal database e da Service Discovery. Le password le impostiamo noi stessi nelle impostazioni.
Domanda: È possibile pubblicarlo su internet?
Risposta: Di default, Consul si avvia su localhost. Per pubblicarlo su internet, è necessario impostare un proxy. Noi ci assumiamo la responsabilità delle regole di sicurezza.
Domanda: Fornisce dati storici di default? È interessante vedere le statistiche sui Health Checks. Possiamo diagnosticare problemi se il server si guasta frequentemente.
Risposta: Non sono sicuro che ci siano dettagli sui controlli.
Domanda: Non è tanto importante lo stato attuale, quanto la dinamica.
Risposta: Per l'analisi – sì.
Domanda: È meglio non utilizzare Consul per il Service Discovery di Docker?
Risposta: Non lo consiglierei. L'obiettivo della presentazione è introdurre il concetto. Storicamente ha fatto un percorso, mi pare, fino alla versione 1. Ora ci sono soluzioni più complete, ad esempio Kubernetes, che ha tutto questo incorporato. Nel contesto di Kubernetes, il Service Discovery è inferiore a Etcd. Ma non lo conosco così bene come Consul. Quindi ho deciso di illustrare il Service Discovery usando Consul.
Domanda: Lo schema con il server leader non rallenta l'avvio dell'applicazione in generale? E come fa Consul a determinare un nuovo leader se quello attuale è inattivo?
Risposta: Hanno descritto un intero protocollo. Se sei interessato, puoi leggere.
Domanda: Consul funge da server completo e tutte le richieste passano attraverso di esso?
Risposta: Non funge da server completo, ma si occupa di una zona specifica. Essa di solito termina con service.consul. E poi procediamo secondo la logica. Non utilizziamo nomi di dominio in produzione, ma proprio la nostra infrastruttura interna, che di solito è nascosta dietro il server di caching, se operiamo con DNS.
Domanda: Cioè, se vogliamo accedere a un database, dobbiamo comunque chiedere a Consul di trovare prima questo database, giusto?
Risposta: Sì. Se operiamo con DNS, funziona come senza Consul quando utilizziamo nomi DNS. Di solito, le applicazioni moderne non interrogano il nome di dominio per ogni richiesta, perché abbiamo stabilito una connessione, tutto funziona e nel prossimo periodo non lo usiamo quasi. Se la connessione si interrompe, allora – sì, chiediamo di nuovo dove si trova il nostro database e andiamo a cercarlo.
— Chat degli utenti Hashicorp: Consul, Nomad, Terraform
P.S. Per quanto riguarda i controlli di salute. In Consul, così come in Kubernetes, viene utilizzato lo stesso sistema di monitoraggio dello stato di vitalità del servizio basato sul codice di stato.
200 OK per sano
503 Servizio non disponibile per malatoFonti:
Fonte: habr.com
