Suxiro que lea a transcrición do informe de Alexander Sigachev Service Discovery in distributed systems usando Consul como exemplo.
Service Discovery creouse para que cun custo mínimo poida conectar unha nova aplicación ao noso contorno existente. Usando Service Discovery, podemos separar ao máximo un contedor docker ou un servizo virtual do ambiente no que se está a executar.
Benvido a todos! Son Alexander Sigachev, traballo en Inventos. E hoxe presentareivos un concepto como Service Discovery. Vexamos Service Discovery usando Consul como exemplo.
Que problemas soluciona Service Discovery? Service Discovery creouse para que cun custo mínimo poida conectar unha nova aplicación ao noso contorno existente. Usando Service Discovery, podemos separar ao máximo un contedor docker ou un servizo virtual do ambiente no que se está a executar.
Que aspecto ten? Nun exemplo clásico na web, esta é a interface que acepta a solicitude do usuario. Despois envíao ao backend. Neste exemplo, este equilibrador de carga equilibra dous backends.
Aquí vemos que estamos a lanzar unha terceira instancia da aplicación. En consecuencia, cando se inicia a aplicación, rexístrase en Service Discovery. Service Discovery notifica ao equilibrador de carga. Load-balancer cambia a súa configuración automaticamente e o novo backend ponse en funcionamento. Deste xeito, pódense engadir backends ou, pola contra, excluírse do traballo.
Que máis é conveniente facer con Service Discovery? Service Discovery pode almacenar configuracións de nginx, certificados e unha lista de servidores backend activos.
Service Discovery tamén permite detectar fallos e detectar fallos. Cales son os esquemas posibles para detectar fallos?
- Esta aplicación que desenvolvemos notifica automaticamente a Service Discovery que aínda está funcionando.
- Service Discovery, pola súa banda, investiga a dispoñibilidade da aplicación.
- Ou utilizamos un script ou unha aplicación de terceiros que comproba a dispoñibilidade da nosa aplicación e notifica a Service Discovery que todo está ben e pode funcionar ou, pola contra, que todo está mal e que esta instancia da aplicación debe ser excluída do equilibrio.
Cada un dos esquemas pódese utilizar dependendo do software que usemos. Por exemplo, acabamos de comezar a desenvolver un novo proxecto, entón podemos proporcionar facilmente un esquema cando a nosa aplicación notifique Service Discovery. Ou podemos conectar que Service Discovery está comprobando.
Se herdamos a aplicación ou foi desenvolvida por outra persoa, entón a terceira opción é adecuada cando escribimos un controlador, e todo isto entra no noso traballo automaticamente.
Este é un exemplo. O equilibrador de carga en forma de nginx reinicia. Esta é unha utilidade opcional que se proporciona con Consul. Este é o modelo cónsul. Describimos a regra. Dicimos que estamos a usar un modelo (Golang Template Engine). Cando se producen eventos, cando se producen notificacións de cambios, rexenérase e o comando "recargar" envíase a Service Discovery. O exemplo máis sinxelo é cando nginx é reconfigurado por un evento e reiniciado.
Que é Cónsul?
-
En primeiro lugar, trátase de Service Discovery.
-
Ten un mecanismo de comprobación de dispoñibilidade: comprobación de saúde.
-
Tamén ten unha tenda KV.
-
E baséase na capacidade de usar Multi Datacenter.
Para que pode servir todo isto? Na tenda KV podemos gardar exemplos de configuración. Revisión de saúde podemos consultar o servizo local e avisar. Utilízase Multi Datacenter para que se poida construír un mapa de servizos. Por exemplo, Amazon dispón de varias zonas e encamiña o tráfico da forma máis óptima para que non haxa solicitudes innecesarias entre centros de datos, que se cobran por separado do tráfico local e, en consecuencia, teñen menos latencia.
Imos entender un pouco os termos que se usan en Cónsul.
- Consul é un servizo escrito en Go. Unha das vantaxes dun programa Go é 1 ficheiro binario que acaba de descargar. Lanzado desde calquera lugar e non tes ningunha dependencia.
- Despois, mediante as teclas, podemos iniciar este servizo ben en modo cliente ou en modo servidor.
- Ademais, o atributo "centro de datos" permítelle establecer unha bandeira a que centro de datos pertence este servidor.
- Consenso - baseado no protocolo de balsa. Se alguén está interesado, pode ler máis sobre isto na páxina web do Cónsul. Este é un protocolo que permite determinar o líder e determinar que diñeiro se considera válido e accesible.
- Gossip é un protocolo que permite a interacción entre nodos. Ademais, este sistema está descentralizado. Dentro dun centro de datos, todos os nodos comunícanse cos seus veciños. E, en consecuencia, a información sobre o estado actual transmítese entre si. Podemos dicir que isto é un chisme entre veciños.
- LAN Gossip: intercambio de datos local entre veciños dentro do mesmo centro de datos.
- WAN Gossip: úsase cando necesitamos sincronizar información entre dous centros de datos. A información flúe entre os nós que están marcados como servidor.
- RPC: permítelle executar solicitudes a través dun cliente nun servidor.
Descrición do RPC. Digamos que Consul está a executarse como cliente nunha máquina virtual ou nun servidor físico. Contactámonos con el localmente. E entón o cliente local solicita información do servidor e sincronízase. Dependendo da configuración, a información pódese recuperar da caché local ou sincronizarse co líder, co servidor mestre.
Estes dous esquemas teñen pros e contras. Se traballamos cunha caché local, entón é rápido. Se traballamos con datos que se almacenan no servidor, leva máis tempo, pero obtemos información máis relevante.
Se representas isto graficamente, esta é a imaxe do sitio. Vemos que temos tres mestres en execución. Un está marcado cun asterisco como líder. Neste exemplo, hai tres clientes que intercambian información localmente entre si a través de UDP/TCP. E a información entre centros de datos transfírese entre servidores. Aquí os clientes interactúan entre eles localmente.
Que API proporciona Consul? Para obter información, Consul conta con dous tipos de API.
Esta é a API de DNS. Por defecto, Consul execútase no porto 8600. Podemos configurar o proxy de solicitudes e proporcionar acceso mediante resolución local, mediante DNS local. Podemos consultar por dominio e recibir información do enderezo IP como resposta.
API HTTP - ou podemos solicitar localmente información sobre un servizo específico no porto 8500 e recibir unha resposta JSON, que IP ten o servidor, que host, que porto está rexistrado. E información adicional pódese transmitir mediante token.
Que necesitas para dirixir Cónsul?
Na primeira opción, no modo de desenvolvedor indicamos a bandeira de que se trata do modo de desenvolvedor. O axente comeza como servidor. E realiza toda a función de forma independente nunha máquina. Cómodo, rápido e practicamente non se precisan configuracións adicionais para o primeiro inicio.
O segundo modo é o lanzamento en produción. Aquí é onde a posta en marcha se complica un pouco. Se non temos ningunha versión do cónsul, entón debemos levar a primeira máquina ao arranque, é dicir, esta máquina, que asumirá as responsabilidades do líder. Levantámolo, despois levantamos a segunda instancia do servidor, pasándolle información onde se atopa o noso mestre. Levantamos o terceiro. Despois de ter tres máquinas activas, reiniciámola en modo normal na primeira máquina desde o arranque en execución. Os datos están sincronizados e o clúster inicial xa está activado.
Recoméndase executar de tres a sete instancias en modo servidor. Isto débese a que, se o número de servidores crece, aumenta o tempo de sincronización da información entre eles. O número de nós debe ser impar para garantir o quórum.
Como se proporcionan os controis de saúde? Escribimos unha regra de verificación en forma de Json no directorio de configuración de Consul. A primeira opción é a dispoñibilidade do dominio google.com neste exemplo. E dicimos que esta comprobación debe realizarse a intervalos de 30 segundos. Deste xeito comprobamos que o noso nodo ten acceso á rede externa.
A segunda opción é comprobar a si mesmo. Usamos curl regular para chamar localhost no porto especificado a intervalos de 10 segundos.
Estas comprobacións son resumidas e enviadas a Service Discovery. En función da dispoñibilidade, estes nós quedan excluídos ou aparecen na lista de máquinas dispoñibles e que funcionan correctamente.
Consul tamén ofrece unha interface de IU, que se inicia cunha bandeira separada e estará dispoñible na máquina. Isto permítelle ver información e tamén pode facer algúns cambios.
Neste exemplo, a pestana "Servizo" está aberta. Está demostrado que funcionan tres servizos, un deles é Cónsul. Número de comprobacións realizadas. E hai tres centros de datos nos que se atopan as máquinas.
Este é un exemplo da pestana Nodos. Vemos que teñen nomes compostos que inclúen centros de datos. Tamén mostra que servizos están en execución, é dicir, vemos que non se estableceu ningunha etiqueta. Estas etiquetas adicionais poden proporcionar información que o desenvolvedor pode usar para especificar parámetros adicionais.
Tamén pode transmitir información a Consul sobre o estado dos discos e a carga media.
preguntas
Pregunta: Temos un contedor docker, como usalo con Consul?
Resposta: hai varios enfoques para o contenedor docker. Unha das máis comúns é utilizar un contedor docker de terceiros responsable do rexistro. No inicio, pásase a el un socket docker. Todos os eventos de rexistro e retirada de contedores están rexistrados en Consul.
Pregunta: entón o propio Consul inicia o contedor docker?
Resposta: Non. Estamos a executar un contedor docker. E ao configurar indicamos: escoita tal ou tal toma. Isto é aproximadamente o mesmo que traballamos cun certificado, cando cargamos información sobre onde e que temos.
Pregunta: Resulta que dentro do contedor Docker que estamos tentando conectar a Service Discovery debería haber algún tipo de lóxica que poida enviar datos a Consul?
Resposta: non realmente. Cando comeza, pasamos variables pola variable de ambiente. Digamos o nome do servizo, o porto do servizo. O rexistro escoita esta información e introdúcea en Cónsul.
Pregunta: teño outra pregunta sobre a IU. Implementamos a IU, por exemplo, nun servidor de produción. Que pasa coa seguridade? Onde se almacenan os datos? É posible acumular datos dalgún xeito?
Resposta: na IU hai datos da base de datos e do Service Discovery. Nós mesmos establecemos contrasinais na configuración.
Pregunta: Pódese publicar isto en Internet?
Resposta: Por defecto, Consul comeza en localhost. Para publicar en Internet, terás que instalar algún tipo de proxy. Somos responsables das nosas propias normas de seguridade.
Pregunta: Proporciona datos históricos fóra da caixa? É interesante ver as estatísticas sobre os controis de saúde. Tamén pode diagnosticar problemas se o servidor falla a miúdo.
Resposta: Non estou seguro de que haxa detalles das comprobacións alí.
Pregunta: o estado actual non é tan importante como a dinámica.
Resposta: Para análise - si.
Pregunta: é mellor non usar Service Discovery para Consul docker?
Resposta: non recomendaría usalo. O obxectivo do informe é introducir o que existe tal concepto. Historicamente, pasou, na miña opinión, á 1a versión. Agora hai solucións máis completas, por exemplo, Kubernetes, que ten todo isto baixo o capó. Como parte de Kubernetes Service Discovery é inferior a Etcd. Pero non estou tan familiarizado con iso como o estou co Cónsul. Polo tanto, decidín facer Service Discovery usando Consul como exemplo.
Pregunta: o esquema cun servidor líder non ralentiza o inicio da aplicación no seu conxunto? E como determina o Cónsul un novo líder se este minte?
Resposta: Teñen todo un protocolo descrito. Se estás interesado, podes lelo.
Pregunta: Consul actúa como un servidor completo para nós e todas as solicitudes pasan por el?
Resposta: non actúa como un servidor completo, senón que se fai cargo dunha zona específica. Normalmente remata con servizo.cónsul. E despois seguimos loxicamente. Non usamos nomes de dominio na produción, senón a infraestrutura interna, que adoita estar oculta detrás do caché do servidor se traballamos con DNS.
Pregunta: É dicir, se queremos acceder a unha base de datos, en calquera caso tiraremos de Consul para atopar esta base de datos primeiro, non?
Resposta: Si. Se traballamos usando DNS, entón funciona igual que sen Consul cando usamos nomes DNS. Normalmente, as aplicacións modernas non tiran do nome de dominio en cada solicitude, porque instalamos connect, todo funciona e nun futuro próximo practicamente non o usamos. Se a conexión está rota, entón si, volvemos preguntar onde está a nosa base e imos a ela.
— Chat de usuarios de Hashicorp: Consul, Nomad, Terraform
PD No tocante aos controis de saúde. Consul, como Kubernetes, usa o mesmo sistema para comprobar o estado de supervivencia dun servizo en función do estado do código.
200 OK for healthy
503 Service Unavailable for unhealthyFontes:
Fonte: www.habr.com