Le sugiero que lea la transcripción del informe Descubrimiento de servicios en sistemas distribuidos de Alexander Sigachev usando Consul como ejemplo.
Service Discovery fue creado para que a un costo mínimo pueda conectar una nueva aplicación a nuestro entorno existente. Al utilizar Service Discovery, podemos separar al máximo un contenedor acoplable o un servicio virtual del entorno en el que se ejecuta.
¡Doy la bienvenida a todos! Soy Alexander Sigachev, trabajo en Inventos. Y hoy les presentaré un concepto como Service Discovery. Veamos Service Discovery usando Consul como ejemplo.
¿Qué problemas resuelve Service Discovery? Service Discovery fue creado para que a un costo mínimo pueda conectar una nueva aplicación a nuestro entorno existente. Al utilizar Service Discovery, podemos separar al máximo un contenedor acoplable o un servicio virtual del entorno en el que se ejecuta.
Cómo se ve? En un ejemplo clásico de la web, esta es la interfaz que acepta la solicitud del usuario. Luego lo enruta al backend. En este ejemplo, este equilibrador de carga equilibra dos backends.
Aquí vemos que estamos lanzando una tercera instancia de la aplicación. En consecuencia, cuando se inicia la aplicación, se registra en Service Discovery. Service Discovery notifica al equilibrador de carga. Load-balancer cambia su configuración automáticamente y el nuevo backend se pone en funcionamiento. De esta forma, se pueden agregar backends o, por el contrario, excluirlos del trabajo.
¿Qué más es conveniente hacer con Service Discovery? Service Discovery puede almacenar configuraciones de nginx, certificados y una lista de servidores backend activos.
Service Discovery también le permite detectar fallas y detectar fallas. ¿Cuáles son los posibles esquemas para detectar fallas?
- Esta aplicación que desarrollamos notifica automáticamente a Service Discovery que aún está funcional.
- Service Discovery, por su parte, sondea la disponibilidad de la aplicación.
- O utilizamos un script o una aplicación de terceros que verifica la disponibilidad de nuestra aplicación y notifica a Service Discovery que todo está bien y puede funcionar o, por el contrario, que todo está mal y esta instancia de la aplicación debe excluirse del equilibrio.
Cada uno de los esquemas se puede utilizar dependiendo de qué software utilicemos. Por ejemplo, acabamos de comenzar a desarrollar un nuevo proyecto y luego podemos proporcionar fácilmente un esquema cuando nuestra aplicación notifica Service Discovery. O podemos conectar que Service Discovery está verificando.
Si heredamos la aplicación o la desarrolló otra persona, entonces la tercera opción es adecuada cuando escribimos un controlador, y todo esto entra en nuestro trabajo automáticamente.
Éste es un ejemplo. Se reinicia el equilibrador de carga en forma de nginx. Esta es una utilidad opcional que se proporciona con Consul. Esta es la plantilla de cónsul. Describimos la regla. Decimos que estamos usando una plantilla (Golang Template Engine). Cuando ocurren eventos, cuando se notifica que se han producido cambios, se regenera y el comando "recargar" se envía a Service Discovery. El ejemplo más simple es cuando nginx se reconfigura por un evento y se reinicia.
¿Qué es Cónsul?
-
En primer lugar, esto es el descubrimiento de servicios.
-
Tiene un mecanismo de verificación de disponibilidad: Comprobación de estado.
-
También cuenta con una Tienda KV.
-
Y se basa en la capacidad de utilizar Multi Datacenter.
¿Para qué se puede utilizar todo esto? En KV Store podemos almacenar configuraciones de ejemplo. Comprobación de salud podemos comprobar el servicio local y notificar. Se utiliza Multi Datacenter para poder construir un mapa de servicios. Por ejemplo, Amazon tiene varias zonas y enruta el tráfico de la forma más óptima para que no haya solicitudes innecesarias entre centros de datos, que se cobran por separado del tráfico local y, en consecuencia, tienen menos latencia.
Entendamos un poco sobre los términos que se utilizan en Consul.
- Cónsul es un servicio escrito en Go. Una de las ventajas de un programa Go es 1 archivo binario que simplemente descargas. Se inicia desde cualquier lugar y no tiene dependencias.
- Luego, mediante las teclas podremos iniciar este servicio ya sea en modo cliente o en modo servidor.
- Además, el atributo "centro de datos" le permite establecer un indicador a qué centro de datos pertenece este servidor.
- Consenso – basado en el protocolo de la balsa. Si alguien está interesado, puede leer más sobre esto en el sitio web del Cónsul. Este es un protocolo que le permite determinar el líder y determinar qué dinero se considera válido y accesible.
- Gossip es un protocolo que permite la interacción entre nodos. Además, este sistema está descentralizado. Dentro de un centro de datos, todos los nodos se comunican con sus vecinos. Y, en consecuencia, la información sobre el estado actual se transmite entre sí. Podemos decir que esto es un chisme entre vecinos.
- LAN Gossip: intercambio de datos local entre vecinos dentro del mismo centro de datos.
- WAN Gossip: se utiliza cuando necesitamos sincronizar información entre dos centros de datos. La información fluye entre nodos que están marcados como servidor.
- RPC: le permite ejecutar solicitudes a través de un cliente en un servidor.
Descripción de RPC. Digamos que Consul se ejecuta como cliente en una máquina virtual o servidor físico. Lo contactamos localmente. Y luego el cliente local solicita información al servidor y se sincroniza. Dependiendo de la configuración, la información se puede recuperar del caché local o se puede sincronizar con el líder, con el servidor maestro.
Estos dos esquemas tienen ventajas y desventajas. Si trabajamos con un caché local, entonces es rápido. Si trabajamos con datos que están almacenados en el servidor, tardamos más, pero obtenemos información más relevante.
Si representa esto gráficamente, entonces esta es la imagen del sitio. Vemos que tenemos tres maestros en ejecución. Uno está marcado con un asterisco como líder. En este ejemplo, hay tres clientes que intercambian información localmente entre sí a través de UDP/TCP. Y la información entre centros de datos se transfiere entre servidores. Aquí los clientes interactúan entre sí localmente.
¿Qué API proporciona Consul? Para poder obtener información, Consul cuenta con dos tipos de API.
Esta es la API de DNS. De forma predeterminada, Consul se ejecuta en el puerto 8600. Podemos configurar el proxy de solicitud y proporcionar acceso mediante resolución local, mediante DNS local. Podemos realizar consultas por dominio y recibir información de la dirección IP como respuesta.
API HTTP: o podemos solicitar localmente información sobre un servicio específico en el puerto 8500 y recibir una respuesta JSON, qué IP tiene el servidor, qué host, qué puerto está registrado. Y se puede transmitir información adicional mediante token.
¿Qué necesitas para ejecutar Consul?
En la primera opción, en modo desarrollador indicamos la bandera de que este es el modo desarrollador. El agente comienza como un servidor. Y realiza toda la función de forma independiente en una sola máquina. Cómodo, rápido y prácticamente no se requieren ajustes adicionales para el primer inicio.
El segundo modo es el lanzamiento en producción. Aquí es donde la puesta en marcha se complica un poco. Si no tenemos ninguna versión del cónsul, entonces debemos poner en arranque la primera máquina, es decir, esta máquina, que asumirá las responsabilidades del líder. Lo levantamos, luego levantamos la segunda instancia del servidor, pasándole información sobre dónde se encuentra nuestro maestro. Levantamos el tercero. Después de tener tres máquinas en funcionamiento, lo reiniciamos en modo normal en la primera máquina desde el arranque en ejecución. Los datos están sincronizados y el clúster inicial ya está activo.
Se recomienda ejecutar de tres a siete instancias en modo servidor. Esto se debe al hecho de que si aumenta el número de servidores, aumenta el tiempo para sincronizar la información entre ellos. El número de nodos debe ser impar para garantizar el quórum.
¿Cómo se realizan los controles de salud? Escribimos una regla de verificación en forma de Json en el directorio de configuración de Consul. La primera opción es la disponibilidad del dominio google.com en este ejemplo. Y decimos que esta comprobación debe realizarse a intervalos de 30 segundos. De esta forma comprobamos que nuestro nodo tiene acceso a la red externa.
La segunda opción es comprobarlo usted mismo. Usamos curl normal para llamar a localhost en el puerto especificado a intervalos de 10 segundos.
Estas comprobaciones se resumen y se envían a Service Discovery. Según la disponibilidad, estos nodos se excluyen o aparecen en la lista de máquinas disponibles y que funcionan correctamente.
Consul también proporciona una interfaz UI, que se inicia con una bandera separada y estará disponible en la máquina. Esto le permite ver información y también puede realizar algunos cambios.
En este ejemplo, la pestaña "Servicio" está abierta. Se muestra que se están ejecutando tres servicios, uno de ellos es Cónsul. Número de controles realizados. Y hay tres centros de datos en los que se encuentran las máquinas.
Este es un ejemplo de la pestaña Nodos. Vemos que tienen nombres compuestos que involucran centros de datos. También muestra qué servicios se están ejecutando, es decir, vemos que no se han establecido etiquetas. Estas etiquetas adicionales pueden proporcionar información que el desarrollador puede utilizar para especificar parámetros adicionales.
También puede transmitir información al Consul sobre el estado de los discos y la carga promedio.
preguntas
Pregunta: Tenemos un contenedor acoplable, ¿cómo usarlo con Consul?
Respuesta: Existen varios enfoques para el contenedor acoplable. Uno de los más comunes es utilizar un contenedor acoplable de terceros responsable del registro. Al inicio, se le pasa un socket acoplable. Todos los eventos de registro y baja de contenedores se registran en Consul.
Pregunta: ¿Entonces el propio Consul inicia el contenedor acoplable?
Respuesta: No. Estamos ejecutando un contenedor acoplable. Y al configurar indicamos: escuche tal o cual enchufe. Esto es aproximadamente lo mismo que trabajamos con un certificado, cuando cargamos información sobre dónde y qué tenemos.
Pregunta: ¿Resulta que dentro del contenedor Docker que estamos intentando conectar a Service Discovery debería haber algún tipo de lógica que pueda enviar datos a Consul?
Respuesta: En realidad no. Cuando comienza, pasamos variables a través de la variable de entorno. Digamos nombre del servicio, puerto de servicio. El registro escucha esta información y la ingresa en Consul.
Pregunta: Tengo otra pregunta sobre la interfaz de usuario. Implementamos la interfaz de usuario, por ejemplo, en un servidor de producción. ¿Qué pasa con la seguridad? ¿Dónde se almacenan los datos? ¿Es posible acumular datos de alguna manera?
Respuesta: En la interfaz de usuario hay datos de la base de datos y de Service Discovery. Nosotros mismos configuramos las contraseñas en la configuración.
Pregunta: ¿Se puede publicar esto en Internet?
Respuesta: De forma predeterminada, Consul se inicia en localhost. Para publicar en Internet, necesitarás instalar algún tipo de proxy. Somos responsables de nuestras propias normas de seguridad.
Pregunta: ¿Proporciona datos históricos listos para usar? Es interesante observar las estadísticas sobre controles de salud. También puede diagnosticar problemas si el servidor falla con frecuencia.
Respuesta: No estoy seguro de que haya detalles de los cheques allí.
Pregunta: El estado actual no es tan importante como la dinámica.
Respuesta: Para análisis, sí.
Pregunta: ¿Es mejor no utilizar Service Discovery para Consul Docker?
Respuesta: No recomendaría usarlo. El objetivo del informe es presentar qué concepto existe. Históricamente, en mi opinión, llegó a la 1ª versión. Ahora hay soluciones más completas, por ejemplo Kubernetes, que tiene todo esto bajo el capó. Como parte de Kubernetes, Service Discovery es inferior a Etcd. Pero no estoy tan familiarizado con él como con Consul. Por lo tanto, decidí hacer Service Discovery usando Consul como ejemplo.
Pregunta: ¿El esquema con un servidor líder no ralentiza el inicio de la aplicación en su conjunto? ¿Y cómo determina el Cónsul un nuevo líder si éste miente?
Respuesta: Tienen todo un protocolo descrito. Si estás interesado, puedes leerlo.
Pregunta: ¿Consul actúa como un servidor completo para nosotros y todas las solicitudes pasan por él?
Respuesta: No actúa como un servidor completo, sino que se hace cargo de una zona específica. Generalmente termina con service.consul. Y luego seguimos adelante lógicamente. No utilizamos nombres de dominio en producción, sino la infraestructura interna, que suele estar oculta detrás del almacenamiento en caché del servidor si trabajamos usando DNS.
Pregunta: Es decir, si queremos acceder a una base de datos, en cualquier caso recurriremos a Consul para encontrar esta base de datos primero, ¿verdad?
Respuesta: Sí. Si trabajamos usando DNS, entonces funciona igual que sin Consul cuando usamos nombres DNS. Por lo general, las aplicaciones modernas no obtienen el nombre de dominio en cada solicitud, porque instalamos Connect, todo funciona y en un futuro próximo prácticamente no lo usaremos. Si la conexión se interrumpe, entonces sí, volvemos a preguntar dónde está nuestra base y nos dirigimos a ella.
— Chat de usuario de Hashicorp: Cónsul, Nomad, Terraform
PD: En cuanto a los controles sanitarios. Consul, al igual que Kubernetes, utiliza el mismo sistema para verificar el estado de supervivencia de un servicio según el estado del código.
200 OK for healthy
503 Service Unavailable for unhealthyFuentes:
Fuente: habr.com