Ti suggerisco di leggere la trascrizione del rapporto Service Discovery di Alexander Sigachev nei sistemi distribuiti utilizzando Consul come esempio.
Service Discovery è stato creato in modo che a un costo minimo sia possibile connettere una nuova applicazione al nostro ambiente esistente. Utilizzando Service Discovery, possiamo separare al massimo un contenitore docker o un servizio virtuale dall'ambiente in cui è in esecuzione.
Do il benvenuto a tutti! Mi chiamo Alexander Sigachev, lavoro presso Inventos. E oggi ti presenterò un concetto come Service Discovery. Diamo un'occhiata a Service Discovery utilizzando Consul come esempio.
Quali problemi risolve Service Discovery? Service Discovery è stato creato in modo che a un costo minimo sia possibile connettere una nuova applicazione al nostro ambiente esistente. Utilizzando Service Discovery, possiamo separare al massimo un contenitore docker o un servizio virtuale dall'ambiente in cui è in esecuzione.
Che cosa sembra? In un classico esempio sul web, questo è il front-end che accetta la richiesta dell’utente. Quindi lo instrada al backend. In questo esempio, questo bilanciatore del carico bilancia due backend.
Qui vediamo che stiamo lanciando una terza istanza dell'applicazione. Di conseguenza, all'avvio dell'applicazione, viene registrata con Service Discovery. Service Discovery invia una notifica al bilanciatore del carico. Il bilanciatore del carico cambia automaticamente la sua configurazione e il nuovo backend viene messo in funzione. In questo modo è possibile aggiungere dei backend o, al contrario, escluderli dal lavoro.
Cos'altro è conveniente fare con Service Discovery? Service Discovery può archiviare configurazioni nginx, certificati e un elenco di server backend attivi.
Service Discovery consente inoltre di rilevare errori e rilevare guasti. Quali sono i possibili schemi per rilevare i guasti?
- Questa applicazione che abbiamo sviluppato notifica automaticamente a Service Discovery che è ancora funzionante.
- Service Discovery, da parte sua, esegue il polling della disponibilità dell'applicazione.
- Oppure utilizziamo uno script o un'applicazione di terze parti che verifica la disponibilità della nostra applicazione e avvisa Service Discovery che tutto va bene e può funzionare o, al contrario, che tutto va male e questa istanza dell'applicazione deve essere esclusa dal bilanciamento.
Ciascuno degli schemi può essere utilizzato a seconda del software che utilizziamo. Ad esempio, abbiamo appena iniziato a sviluppare un nuovo progetto, quindi possiamo facilmente fornire uno schema quando la nostra applicazione notifica Service Discovery. Oppure possiamo connetterci affinché Service Discovery stia controllando.
Se abbiamo ereditato l'applicazione o è stata sviluppata da qualcun altro, la terza opzione è adatta quando scriviamo un gestore e tutto ciò entra automaticamente nel nostro lavoro.
Questo è un esempio. Il bilanciatore del carico sotto forma di nginx viene riavviato. Si tratta di un'utilità opzionale fornita con Consul. Questo è il modello di console. Descriviamo la regola. Diciamo che stiamo utilizzando un template (Golang Template Engine). Quando si verificano eventi, quando si sono verificate notifiche di modifiche, viene rigenerato e il comando "ricarica" viene inviato a Service Discovery. L'esempio più semplice è quando nginx viene riconfigurato da un evento e riavviato.
Cos'è Console?
-
Prima di tutto, questo è Service Discovery.
-
Ha un meccanismo di controllo della disponibilità: controllo dello stato.
-
Ha anche un negozio KV.
-
E si basa sulla possibilità di utilizzare Multi Datacenter.
A cosa può servire tutto questo? Nel KV Store possiamo memorizzare configurazioni di esempio. Controllo sanitario possiamo controllare il servizio locale e avvisare. Multi Datacenter viene utilizzato in modo da poter costruire una mappa dei servizi. Ad esempio, Amazon dispone di diverse zone e instrada il traffico nel modo più ottimale in modo che non vi siano richieste inutili tra i data center, che vengono addebitati separatamente dal traffico locale e, di conseguenza, hanno una latenza inferiore.
Comprendiamo un po' i termini utilizzati in Consul.
- Consul è un servizio scritto in Go. Uno dei vantaggi di un programma Go è 1 file binario che devi solo scaricare. Lanciato da qualsiasi luogo e non hai dipendenze.
- Quindi, utilizzando le chiavi, possiamo avviare questo servizio sia in modalità client che in modalità server.
- Inoltre, l'attributo "datacenter" consente di impostare un flag a quale data center appartiene questo server.
- Consenso – basato sul protocollo della zattera. Se qualcuno è interessato, può leggere di più a riguardo sul sito del Console. Questo è un protocollo che consente di determinare il leader e determinare quale denaro è considerato valido e accessibile.
- Gossip è un protocollo che consente l'interazione tra i nodi. Inoltre, questo sistema è decentralizzato. All'interno di un data center, tutti i nodi comunicano con i vicini. E, di conseguenza, le informazioni sullo stato attuale vengono trasmesse reciprocamente. Possiamo dire che si tratta di pettegolezzi tra vicini.
- LAN Gossip: scambio locale di dati tra vicini all'interno dello stesso data center.
- WAN Gossip: utilizzato quando è necessario sincronizzare le informazioni tra due data center. Le informazioni fluiscono tra i nodi contrassegnati come server.
- RPC – consente di eseguire richieste tramite un client su un server.
Descrizione dell'RPC. Supponiamo che Consul sia in esecuzione come client su una macchina virtuale o un server fisico. Lo contattiamo localmente. E poi il client locale richiede informazioni dal server e viene sincronizzato. A seconda delle impostazioni, le informazioni possono essere recuperate dalla cache locale, oppure possono essere sincronizzate con il leader, con il server master.
Questi due schemi hanno sia vantaggi che svantaggi. Se lavoriamo con una cache locale, allora è veloce. Se lavoriamo con i dati archiviati sul server, ci vorrà più tempo, ma otteniamo informazioni più rilevanti.
Se lo rappresenti graficamente, questa è l'immagine del sito. Vediamo che abbiamo tre master in esecuzione. Uno è contrassegnato da un asterisco come leader. In questo esempio ci sono tre client che scambiano informazioni localmente tra loro tramite UDP/TCP. E le informazioni tra data center vengono trasferite tra server. Qui i client interagiscono tra loro a livello locale.
Quali API fornisce Consul? Per ottenere informazioni, Consul dispone di due tipi di API.
Questa è l'API DNS. Per impostazione predefinita, Consul viene eseguito sulla porta 8600. Possiamo configurare il proxy delle richieste e fornire l'accesso tramite risoluzione locale, tramite DNS locale. Possiamo interrogare per dominio e ricevere informazioni sull'indirizzo IP in risposta.
API HTTP - oppure possiamo richiedere localmente informazioni su un servizio specifico sulla porta 8500 e ricevere una risposta JSON, quale IP ha il server, quale host, quale porta è registrata. E ulteriori informazioni possono essere trasmesse tramite token.
Di cosa hai bisogno per gestire Console?
Nella prima opzione, in modalità sviluppatore indichiamo il flag che questa è la modalità sviluppatore. L'agente viene avviato come server. Ed esegue l'intera funzione in modo indipendente su una macchina. Per il primo avvio è comodo, veloce e praticamente non richiede alcuna impostazione aggiuntiva.
La seconda modalità è il lancio in produzione. È qui che l'avvio diventa un po' complicato. Se non disponiamo di alcuna versione del console, allora dobbiamo portare in bootstrap la prima macchina, ovvero questa macchina, che assumerà le responsabilità del leader. Lo solleviamo, quindi creiamo la seconda istanza del server, passandogli le informazioni su dove si trova il nostro master. Alziamo il terzo. Dopo aver attivato tre macchine, riavviamo il sistema in modalità normale sulla prima macchina dal bootstrap in esecuzione. I dati sono sincronizzati e il cluster iniziale è già attivo.
Si consiglia di eseguire da tre a sette istanze in modalità server. Ciò è dovuto al fatto che se il numero di server cresce, aumenta il tempo per sincronizzare le informazioni tra di loro. Il numero di nodi deve essere dispari per garantire il quorum.
Come vengono forniti i controlli sanitari? Scriviamo una regola di verifica sotto forma di Json nella directory di configurazione di Console. La prima opzione è la disponibilità del dominio google.com in questo esempio. E diciamo che questo controllo va effettuato ad intervalli di 30 secondi. In questo modo controlliamo che il nostro nodo abbia accesso alla rete esterna.
La seconda opzione è controllare te stesso. Usiamo l'arricciatura regolare per chiamare localhost sulla porta specificata a intervalli di 10 secondi.
Questi controlli vengono riepilogati e inviati a Service Discovery. In base alla disponibilità questi nodi vengono esclusi oppure compaiono nell'elenco delle macchine disponibili e correttamente funzionanti.
Consul fornisce anche un'interfaccia utente, che viene avviata con un flag separato e sarà disponibile sulla macchina. Ciò ti consente di visualizzare le informazioni e puoi anche apportare alcune modifiche.
In questo esempio è aperta la scheda “Servizio”. È dimostrato che sono in funzione tre servizi, uno dei quali è Console. Numero di controlli eseguiti. E sono tre i data center in cui si trovano le macchine.
Questo è un esempio della scheda Nodi. Vediamo che hanno nomi composti che coinvolgono data center. Mostra anche quali servizi sono in esecuzione, cioè vediamo che non sono stati impostati tag. Questi tag aggiuntivi possono fornire alcune informazioni che lo sviluppatore può utilizzare per specificare parametri aggiuntivi.
Puoi anche trasmettere informazioni a Console sullo stato dei dischi e sul carico medio.
domande
Domanda: abbiamo un contenitore docker, come usarlo con Consul?
Risposta: esistono diversi approcci per il contenitore docker. Uno dei più comuni è utilizzare un contenitore docker di terze parti responsabile della registrazione. All'avvio gli viene passato un socket docker. Tutti gli eventi di registrazione e de-pubblicazione dei contenitori vengono registrati in Consul.
Domanda: Quindi Console stesso avvia il contenitore docker?
Risposta: no. Stiamo eseguendo un contenitore docker. E durante la configurazione indichiamo: ascolta questo o quel socket. Questo è più o meno lo stesso di come lavoriamo con un certificato, quando carichiamo informazioni su dove e cosa abbiamo.
Domanda: risulta che all'interno del contenitore Docker che stiamo tentando di connettere a Service Discovery dovrebbe esserci un qualche tipo di logica in grado di inviare dati a Consul?
Risposta: Non proprio. All'avvio, passiamo le variabili attraverso la variabile d'ambiente. Diciamo nome del servizio, porta del servizio. Il registro ascolta queste informazioni e le inserisce in Consul.
Domanda: ho un'altra domanda sull'interfaccia utente. Abbiamo distribuito l'interfaccia utente, ad esempio, su un server di produzione. E la sicurezza? Dove vengono archiviati i dati? È possibile in qualche modo accumulare dati?
Risposta: nell'interfaccia utente sono presenti dati dal database e da Service Discovery. Impostiamo noi stessi le password nelle impostazioni.
Domanda: è possibile pubblicarlo su Internet?
Risposta: per impostazione predefinita, Consul viene avviato su localhost. Per pubblicare su Internet, dovrai installare una sorta di proxy. Siamo responsabili delle nostre regole di sicurezza.
Domanda: Fornisce dati storici pronti all'uso? È interessante osservare le statistiche sui controlli sanitari. È inoltre possibile diagnosticare i problemi se il server si guasta spesso.
Risposta: non sono sicuro che ci siano i dettagli dei controlli lì.
Domanda: Lo stato attuale non è così importante quanto la dinamica.
Risposta: Per analisi – sì.
Domanda: è meglio non utilizzare Service Discovery per la finestra mobile Consul?
Risposta: non ne consiglierei l'uso. Lo scopo della relazione è quello di introdurre ciò che esiste tale concetto. Storicamente, secondo me, è arrivato alla prima versione. Ora esistono già soluzioni più complete, ad esempio Kubernetes, che hanno tutto questo sotto il cofano. Come parte di Kubernetes Service Discovery è inferiore a Etcd. Ma non lo conosco così bene come lo ho con Console. Pertanto, ho deciso di realizzare Service Discovery utilizzando Consul come esempio.
Domanda: Lo schema con un server leader non rallenta l'avvio dell'applicazione nel suo insieme? E come fa il Console a determinare un nuovo leader se questo mente?
Risposta: Hanno descritto un intero protocollo. Se sei interessato, puoi leggerlo.
Domanda: Consul funge da server a tutti gli effetti per noi e tutte le richieste passano attraverso di esso?
Risposta: non funziona come un server a tutti gli effetti, ma occupa una zona specifica. Di solito termina con service.consul. E poi andiamo avanti logicamente. Nella produzione non utilizziamo nomi di dominio, bensì l'infrastruttura interna, che di solito è nascosta dietro il caching del server se lavoriamo con DNS.
Domanda: Cioè, se vogliamo accedere a un database, in ogni caso chiederemo a Consul di trovare prima questo database, giusto?
Risposta: sì. Se lavoriamo utilizzando DNS, funzionerà come senza Console quando utilizziamo nomi DNS. Di solito, le applicazioni moderne non estraggono il nome di dominio in ogni richiesta, perché abbiamo installato Connect, tutto funziona e nel prossimo futuro praticamente non lo utilizzeremo. Se la connessione è interrotta, allora sì, chiediamo di nuovo dov'è la nostra base e ci andiamo.
— Chat utente Hashicorp: Console, Nomad, Terraform
PS Per quanto riguarda i controlli sanitari. Consul, come Kubernetes, utilizza lo stesso sistema per verificare lo stato di sopravvivenza di un servizio in base allo stato del codice.
200 OK for healthy
503 Service Unavailable for unhealthyFonti:
Fonte: habr.com