Vi propongo di familiarizzare con la trascrizione della relazione di Aleksandr Sigacev sul Service Discovery nei sistemi distribuiti, utilizzando come esempio Consul.
Il Service Discovery è stato creato per consentire di collegare una nuova applicazione al nostro ambiente esistente con il minimo sforzo. Utilizzando il Service Discovery, possiamo massimizzare la separazione tra un contenitore, come Docker, o un servizio virtuale e l'ambiente in cui è in esecuzione.
Salve a tutti! Sono Aleksandr Sigacev, lavoro per l'azienda Inventos. Oggi vi presenterò un concetto chiamato Service Discovery. Esamineremo il Service Discovery utilizzando Consul come esempio.
Quali problemi risolve il Service Discovery? È stato creato per consentire di collegare una nuova applicazione al nostro ambiente esistente con il minimo sforzo. Utilizzando il Service Discovery, possiamo massimizzare la separazione tra un contenitore, come Docker, o un servizio virtuale e l'ambiente in cui è in esecuzione.
Come si presenta? In un classico esempio web: è un frontend che riceve la richiesta dell'utente. Successivamente esegue la route verso il backend. In questo esempio, il load-balancer bilancia tra due backend.
Qui vediamo che stiamo avviando una terza istanza dell'applicazione. Quando l'applicazione si avvia, effettua la registrazione nel Service Discovery. Il Service Discovery informa il load-balancer. Il load-balancer modifica automaticamente la propria configurazione e il nuovo backend inizia a lavorare. In questo modo è possibile aggiungere backend o, al contrario, escluderli dal lavoro.
Quali altre operazioni è conveniente eseguire tramite il Service Discovery? Può memorizzare le configurazioni di nginx, i certificati e l'elenco dei server backend attivi.
Inoltre, il Service Discovery consente di rilevare guasti e malfunzionamenti. Quali sono le possibili modalità di rilevamento dei guasti?
- Questa applicazione che abbiamo sviluppato informa autonomamente il Service Discovery che è ancora operativa.
- Il Service Discovery, dal suo canto, interroga l'applicazione per verificare la sua disponibilità.
- Oppure si può utilizzare uno script o un'applicazione esterna che verifica la disponibilità della nostra applicazione e informa il Service Discovery che tutto va bene e si può procedere o, al contrario, che ci sono problemi e che è necessario escludere questa istanza dell'applicazione dal bilanciamento.
Ogni schema può essere applicato a seconda del software che utilizziamo. Ad esempio, se abbiamo appena iniziato a sviluppare un nuovo progetto, possiamo facilmente implementare uno schema in cui la nostra applicazione avvisa il Service Discovery. Oppure possiamo collegarci perché il Service Discovery esegue il controllo.
Se l'applicazione ci è stata lasciata in eredità o è stata sviluppata da un terzo, allora si applica la terza opzione, in cui scriviamo un gestore e tutto ciò si integra automaticamente nel nostro lavoro.
Questo è un esempio. Il bilanciatore di carico in forma di nginx si riavvia. È un'utilità aggiuntiva fornita insieme a Consul. Questo è consul-template. Descriviamo una regola. Diciamo che utilizziamo un modello (Template Engine Golang). Quando si verificano eventi, con notifiche riguardanti modifiche, viene rigenerato e al Service Discovery viene inviata la comando "reload". Un esempio semplice, quando a seguito di un evento nginx viene riconfigurato e riavviato.
Che cos'è Consul?
Prima di tutto, è un Service Discovery.
Ha un meccanismo di verifica della disponibilità - Health Checking.
Possiede anche un KV Store.
E alla base ha la possibilità di utilizzare Multi Datacenter.
A cosa serve tutto questo? Nel KV Store possiamo memorizzare esempi di configurazioni. Possiamo eseguire controlli del servizio locale e avvisare tramite Health Checking. Il Multi Datacenter è utilizzato per costruire una mappa dei servizi. Ad esempio, Amazon ha diverse zone e instrada il traffico in modo ottimale, affinché non ci siano richieste superflue tra i data center, che vengono tariffate separatamente rispetto al traffico locale, e quindi hanno una latenza minore.
Analizziamo un po' i termini utilizzati in Consul.
- Consul è un servizio scritto in Go. Uno dei vantaggi dei programmi scritti in Go è che si tratta di un unico file binario che puoi scaricare. Puoi avviarlo da qualsiasi posizione senza alcuna dipendenza.
- Successivamente, utilizzando le chiavi, possiamo avviare questo servizio sia in modalità client che in modalità server.
- Inoltre, l'attributo "datacenter" consente di contrassegnare a quale data center appartiene questo server.
- Il consenso si basa sul protocollo raft. Se qualcuno è interessato, può leggere di più sul sito di Consul. Questo è un protocollo che consente di designare un leader e stabilire quali dati considerare validi e accessibili.
- Gossip è un protocollo che consente l'interazione tra i nodi. Inoltre, questo sistema è decentralizzato. All'interno di un unico data center, tutti i nodi comunicano con i vicini. Di conseguenza, le informazioni sullo stato attuale vengono scambiate tra di loro. Si può dire che si tratta di pettegolezzi tra vicini.
- LAN Gossip è lo scambio locale di dati tra i 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 attraverso il client su un server.
Descrizione di RPC. Supponiamo che su una macchina virtuale o su un server fisico sia in esecuzione Consul come client. Ci si rivolge localmente a esso. Successivamente, il client locale richiede informazioni al server e si sincronizza. Le informazioni, a seconda delle impostazioni, possono essere fornite dalla cache locale o possono essere sincronizzate con il leader, il master del server.
Questi due schemi hanno sia vantaggi che svantaggi. Se lavoriamo con la cache locale, è veloce. Se lavoriamo con i dati memorizzati sul server, è più lento, ma otteniamo informazioni più aggiornate.
Se si rappresenta graficamente, ecco un'immagine del sito. Possiamo vedere che sono attivi tre master. Uno è contrassegnato con una stella come leader. In questo esempio, ci sono tre client che scambiano informazioni localmente tramite UDP/TCP. Le informazioni tra i data center vengono trasferite tra i server. Qui i client interagiscono tra loro localmente.
Quale API fornisce Consul? Per ottenere informazioni, ci sono due tipi di API in Consul.
Questa è l'API DNS. Per impostazione predefinita, Consul viene avviato sulla porta 8600. Possiamo configurare il proxy delle richieste e garantire l'accesso tramite risoluzione locale, tramite DNS locale. Possiamo effettuare una richiesta tramite dominio e ricevere in risposta informazioni sull'indirizzo IP.
HTTP API – oppure possiamo richiedere localmente sulla porta 8500 informazioni su un servizio specifico e ottenere una risposta JSON che indica quale IP ha il server, quale host, quale porta è registrata. Informazioni aggiuntive possono essere trasmesse tramite token.
Cosa serve per avviare Consul?
Nella prima opzione, in modalità sviluppatore indichiamo il flag che si tratta della modalità sviluppatore. L'Agent si avvia come server e svolge già autonomamente tutte le funzioni su una sola macchina. Pratico, veloce e praticamente non sono necessari ulteriori settaggi per il primo avvio.
La seconda modalità è l’avvio in production. Qui l'avvio si complica un po’. Se non abbiamo alcuna versione del consule, dobbiamo portare nel bootstrap la prima macchina, cioè questa macchina assumerà le responsabilità di leader. La solleviamo, quindi solleviamo un secondo esempio di server, passando le informazioni su dove si trova il master. Solleviamo il terzo. Dopo che sono state sollevate tre macchine, sulla prima macchina dal bootstrap avviato, la riavviamo in modalità normale. I dati si sincronizzano e il cluster iniziale è già attivo.
Si raccomanda di avviare da tre a sette esempi in modalità server. Questo è dovuto al fatto che se il numero dei server cresce, aumenta il tempo necessario per la sincronizzazione delle informazioni tra di loro. Il numero di nodi deve essere dispari per garantire il quorum.
Come si garantiscono i controlli di salute? Nella directory per la configurazione di Consul scriviamo in formato Json una regola di verifica. La prima opzione è la disponibilità, in questo esempio, del dominio google.com. E indichiamo che ogni 30 secondi deve essere eseguita questa verifica. In questo modo controlliamo che il nostro nodo abbia accesso alla rete esterna.
La seconda opzione è il controllo di se stesso. Effettuiamo una chiamata curl a localhost sulla porta specificata con un intervallo di 10 secondi.
Queste verifiche vengono sommate e inviate al Service Discovery. Sulla base della disponibilità, questi nodi vengono esclusi o appariranno nell'elenco delle macchine disponibili e funzionanti correttamente.
Inoltre, Consul offre un'interfaccia UI che può essere avviata con un flag separato e sarà disponibile sulla macchina. Questo consente di visualizzare informazioni e apportare alcune modifiche.
In questo esempio, è aperta la scheda 'Servizio'. Si mostra che sono stati avviati tre servizi, uno dei quali è Consul. La quantità di controlli eseguiti e ci sono tre data center in cui si trovano le macchine.
Questo è un esempio di scheda «Nodes». Possiamo vedere che hanno nomi composti che coinvolgono i data center. Qui viene anche mostrato quali servizi sono attivi, ovvero vediamo che i tag non sono stati assegnati. In questi tag aggiuntivi è possibile specificare alcune informazioni che il sviluppatore può utilizzare per indicare parametri extra.
È possibile anche inviare informazioni a Consul sullo stato dei dischi e sul carico medio.
Domande
Domanda: Abbiamo un container Docker, come possiamo usarlo con Consul?
Risposta: Ci sono diversi approcci per un container Docker. Uno dei più comuni è utilizzare un container Docker esterno responsabile della registrazione. Al momento dell'avvio, gli viene passato il socket di Docker. Tutti gli eventi di registrazione e de-registrazione del container vengono registrati in Consul.
Domanda: Quindi Consul avvia autonomamente il container Docker?
Risposta: No. Siamo noi a lanciare il container Docker. E nella configurazione specifichiamo – ascolta su questo socket. È simile a come funziona con il certificato, quando passiamo informazioni su dove e cosa abbiamo.
Domanda: Quindi, dentro il container Docker che stiamo cercando di collegare a Service Discovery, deve esserci una logica che sa come fornire i dati a Consul?
Risposta: Non proprio. Quando parte, passiamo variabili attraverso l'ambiente. Ad esempio, nome del servizio, porta del servizio. Nel registro ascolta queste informazioni e le inserisce in Consul.
Domanda: Ho ancora una domanda sull'interfaccia utente. Abbiamo distribuito l'UI, ad esempio, su un server di produzione. Cosa dire della sicurezza? Dove vengono memorizzati i dati? È possibile in qualche modo accumulare dati?
Risposta: Nell'UI ci sono proprio i dati dal database e da Service Discovery. Le password le impostiamo nelle impostazioni noi stessi.
Domanda: È possibile pubblicarlo su Internet?
Risposta: Per impostazione predefinita, Consul si avvia su localhost. Per pubblicarlo su Internet, sarà necessario impostare un proxy. Ci occupiamo noi delle regole di sicurezza.
Domanda: Fornisce dati storici immediatamente? È interessante vedere le statistiche sui controlli di stato. È possibile diagnosticare problemi se il server si interrompe frequentemente.
Risposta: Non sono sicuro che ci siano dettagli sui controlli.
Domanda: Non è tanto importante lo stato attuale, quanto è importante la dinamica.
Risposta: Per l'analisi – sì.
Domanda: Non è meglio non utilizzare Consul per Service Discovery per Docker?
Risposta: Non lo consiglierei. Lo scopo della relazione è presentare il concetto. Storicamente ha fatto un percorso, a mio avviso, fino alla prima versione. Ora ci sono soluzioni più complete, come Kubernetes, che ha tutto questo sotto il cofano. Nel contesto di Kubernetes, Service Discovery è inferiore a Etcd. Ma non sono così esperto di quest'ultimo come di Consul. Pertanto, ho deciso di illustrare Service Discovery con un esempio di Consul.
Domanda: Lo schema con il server leader non rallenta l'avvio dell'applicazione nel complesso? 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 è un server completo, ma gestisce un determinato ambito. Di solito finisce con service.consul. E poi seguiamo la logica. Non usiamo nei production nomi di dominio, ma piuttosto infrastrutture interne, che di solito sono nascoste dietro la cache del server, se lavoriamo tramite DNS.
Domanda: Cioè, se vogliamo accedere al database, dovremo comunque chiamare Consul per prima cosa per trovare quel database, corretto?
Risposta: Sì. Se lavoriamo tramite DNS, funziona come senza Consul, quando usiamo nomi DNS. Solitamente le applicazioni moderne non interrogano ogni volta il nome di dominio, poiché abbiamo stabilito la connessione e tutto funziona; nel prossimo futuro non lo usiamo praticamente mai. Se la connessione si interrompe, allora sì, chiediamo di nuovo dove si trova il nostro database e ci dirigiamo verso di esso.
— Chat degli utenti Hashicorp: Consul, Nomad, Terraform
P.S. Riguardo ai controlli di stato. In Consul, come in Kubernetes, viene utilizzato lo stesso sistema di verifica dello stato di salute del servizio basato sul codice di stato.
200 OK per sano
503 Servizio non disponibile per malatoFonti:
Fonte: habr.com
