Cómo utilizar Consul para construir una plataforma PaaS elástica y escalable
Du Wei es un programador que se dedica a la investigación y el desarrollo y la operación y mantenimiento de Internet durante casi diez años. Es coautor de "Estudios de casos del sistema Linux". Actualmente trabajo en Liangfeng Technology, enfocándome en DevOps, computación en la nube, big data y otros campos relacionados.
Antecedentes de la aplicación
HiAR es una plataforma de desarrollo de realidad aumentada (AR) de nueva generación creada por Liangfeng Technology, que proporciona servicios de AR multiplataforma potentes y fáciles de usar. Permite a los desarrolladores utilizar fácilmente la tecnología de visión por computadora y la tecnología de gráficos por computadora más avanzadas para crear rápidamente aplicaciones AR personalizadas.
El servicio en la nube es una infraestructura importante de la plataforma HiAR. Ya sea alta disponibilidad o escalabilidad, el descubrimiento de servicios juega un papel integral. Antes de usar el descubrimiento de servicios, encontramos varios puntos débiles:
◆ Para agregar nodos de servicio al sistema, necesitamos modificar manualmente el archivo de configuración Nginx/LVS y modificar los registros DNS.
◆ Cuando el servicio de la aplicación lanza una nueva versión, aún necesitamos modificar manualmente el archivo de configuración de Nginx, desconectar el nodo, esperar a que el lanzamiento sea exitoso y luego modificar el archivo de configuración de Nginx nuevamente para poner el servicio en línea.
◆ Aunque luego mejoramos la operación y el mantenimiento de las dos situaciones anteriores escribiendo scripts y mejoramos este proceso a un método semiautomático y semimanual, sigue siendo inconveniente y no está relacionado con el servicio. Se puede lograr una automatización completa y combinada.
◆ El DNS de la intranet falla y necesitamos mantener el servicio DNS.
◆ No existe registro de servicio, lo que limita el uso de Docker como máquina virtual liviana.
Ahora, con el descubrimiento de servicios, todo es fácil y divertido. Agregar o restar nodos de servicio actualiza automáticamente los archivos de configuración de Nginx/LVS; ¡DNS lo olvida! Simplemente use una IP; acceda a Mesos Docker y juegue con el escalado elástico.
Por qué elegir Consul
Ha habido muchos artículos que comparan Zookeeper, etcd y Consul, así que no repetiré la analogía. Con bajos costos de funcionamiento y mantenimiento, implementación simple, facilidad de uso y todo lo que necesita, Consul debería ser rentable para equipos pequeños y medianos.
Antes de adentrarnos en el mundo real, echemos un vistazo a lo que Consul tiene para ofrecer.
◆ Alta del servicio. Notifique al registro de servicios que se ha agregado un nuevo servicio a través de HTTP API o DNS.
◆ Descubrimiento de servicios. Conozca la dirección y el puerto del servicio de destino a través de HTTP API o DNS.
◆ Chequeo de salud. Admite múltiples métodos y monitoreo personalizado de scripts HTTP, TCP, Docker y Shell.
◆ Configurar plantillas. Consul Template es responsable de obtener periódicamente información del registro de servicios, actualizar automáticamente el archivo de configuración y recargar el archivo de configuración cuando se producen cambios.
Los cuatro puntos anteriores han satisfecho las necesidades de muchas organizaciones. Por supuesto, esto no es todo. Consul también tiene muchas funciones adicionales, como: interfaz web visual y soporte para múltiples centros de datos.
Experiencia práctica
Nuestro uso de Consul se puede resumir en cuatro aspectos: implementación, aplicación, gestión y actualización.
Implementación
El clúster Consul tiene dos roles, servidor y cliente. Suele haber de 3 a 5 servidores, que es la recomendación oficial. El cliente Consul es el nodo que necesita registro o descubrimiento de servicios.
La implementación de Consul es muy simple. Funciona desde el primer momento. Es solo un archivo ejecutable de Consul sin dependencias complicadas.
Descargue el archivo ejecutable compilado del agente Consul del sitio web oficial y cárguelo en todos los nodos en las funciones de servidor y cliente, luego podrá iniciar el agente Consul.
Veamos cómo iniciar un clúster Consul (3 servidores, 1 cliente).
Entorno experimental:
server01 192.168.1.11
server02 192.168.1.12
server03 192.168.1.13
client01 192.168.1.21
Inicia sesión por separado. Inicie sesión en Server01, Server02 y Server03 e inicie los agentes.
[worker@server01 ~]$ agente cónsul -server -bootstrap-expect 2 -data-dir /tmp/consul -bind= 192.168.1.11 -node=server01
[worker @servidor02 ~]$ agente cónsul -servidor -bootstrap-expect 2 -data-dir /tmp/consul -bind=192.168.1.12 - nodo=servidor02
[worker@server03 ~]$ agente cónsul -servidor -bootstrap-expect 2 -data-dir /tmp/consul -bind=192.168.1.13 -node=server03
Inicie sesión en Server03 en una nueva ventana y únase a los clústeres de Server01 y Server02.
[worker@server03 ~]$ consul join 192.168.1.11 192.168.1.12
Los pasos anteriores son para inicializar el nodo del servidor. Posteriormente puede usar el parámetro -rejoin para iniciarlo. y volver a unirlo.
[worker@server01 ~]$ agente cónsul -servidor -bootstrap-expect 2 -data-dir /tmp/consul -bind=192.168.1.11 -node=server01 -rejoin
[ trabajador@servidor02 ~]$ agente cónsul -servidor -bootstrap-expect 2 -data-dir /tmp/consul -bind=192.168.1.12 -node=servidor02 -rejoin
[trabajador@servidor03 ~]$ agente cónsul -server -bootstrap-expect 2 -data-dir /tmp/consul -bind=192.168.1.13 -node=server03 -rejoin
¡Se han implementado tres nodos de servidor! A continuación, implemente los nodos del cliente. Los nodos cliente se implementan a continuación y, al igual que los nodos servidores, hay tres pasos: inicio inicial, unión manual y reincorporación al clúster.
[worker@client01 ~]$ consul agent -data-dir /tmp/consul -bind=192.168.1.21 -node=client01
En Client01, puede abrir un nuevo inicio de sesión y únase al clúster Server01.
[worker@client01 ~]$ consul join 192.168.1.11
Vuelva a unirse al nodo del cliente 01 para mantenimiento futuro iniciándolo con el parámetro -rejoin.
[worker@client01 ~]$ consul agent -data-dir /tmp/consul -bind=192.168.1.21 -node=client01 -rejoin
Hasta ahora, hemos creado Creado un grupo de cónsules. Pero, ¿cómo realizar el registro y el descubrimiento de servicios? Esto debe estar estrechamente alineado con los requisitos prácticos y se explica con más detalle en las siguientes subsecciones.
Aplicaciones
Consul no existe de forma aislada. Para aprovechar Consul al máximo, puedes combinarlo con herramientas como Nginx, LVS, Docker y más.
Nginx y LVS son los componentes básicos del sistema, mientras que RecoService, FeatureService y SearchService son servicios internos basados en SOA. El primero descubre servicios para el clúster Consul y el segundo registra servicios para el clúster Consul. Consul es el pegamento y el interruptor que hace funcionar todo el sistema, lo que permite una expansión elástica de bajo costo.
La capa de acceso Nginx es responsable del proxy inverso y el equilibrio de carga. El nodo Nginx ejecuta dos servicios relacionados con Consul. Uno es Consul Agent, que es un cliente de Consul; el otro es Consul Template, que es un servicio de actualización de configuración y descubrimiento de servicios. Consul Template es responsable de consultar periódicamente al Consul Agent local y, si cambia la información de registro de los servicios relacionados; Se actualizará el archivo de configuración de Nginx y se recargará el servicio Nginx.
Ejecutar la plantilla Consul es un paso clave para habilitar el escalado elástico:
$ consul-template -consul 127.0.0.1:8500 -template "/etc/nginx/conf/vhosts/ test.ctmpl:/etc/nginx/conf/vhosts/test.conf:nginx -s reload"
En el comando anterior, test.conf es el archivo de configuración del host virtual de Nginx y test.ctmpl. es el archivo de configuración relacionado con La plantilla correspondiente al archivo. El siguiente es un fragmento de código de la plantilla de equilibrio de carga:
upstream test-cluster {
ip_hash; {{range service "test"}}
servidor; {{. Address}}: {{.Port}}; {{end}}
}
Capa lógica, cluster de servicios interno basado en SOA. La comunicación entre diferentes grupos de servicios internos requiere el descubrimiento de servicios, y aquí se presenta LVS para el descubrimiento de servicios. La ventaja de esto es que no es necesario implementar el descubrimiento de servicios en el código del servicio interno y, en escalas mayores, también es necesario equilibrar la carga.
Similar a Nginx en la capa de acceso, LVS también usa Consul Template para consultar periódicamente al Consul Agent local, actualizar los archivos de configuración relevantes y luego recargar el servicio.
¿Cómo se registran los servicios internos en el centro de servicio? Hay dos formas: una es registrar la API HTTP a través del servicio de Consul y llamar a la API para registrarse después de que se inicia el servicio. La otra es registrarse definiendo el servicio en el archivo de configuración. Se recomienda utilizar este último método para el registro del servicio. ¿Cómo funciona? Continúe leyendo :)
Agregue un archivo de configuración consul.json al proyecto, especifique el nombre del servicio y el puerto del servicio y agregue una verificación de estado de la siguiente manera:
{
"servicio":
{
"nombre": "prueba",
"puerto": 9999,
"comprobar":
{
"tcp": "127.0.0.1:9999",
"intervalo": "10s"
}
}
}
El último paso para registrar el servicio es especificar el archivo de configuración cuando se inicia el agente Consul. El método específico es. de la siguiente manera:
$ consul agent -data-dir /tmp/consul -node=test -bind=192.168.1.21 -config-dir=/tmp/consul.json
Administración
El primero es la gestión de nodos, es decir, la gestión del proceso Cónsul. Dado que la disponibilidad del Consul Agent en sí no es alta, es necesario que nos hagamos cargo del proceso Consul. Utilizamos Systemd. También puede elegir herramientas de gestión de procesos como Supervisord o Upstart.
El segundo es la gestión de clústeres. Consul proporciona una interfaz de gestión visual. Puede ver todos los servicios y nodos, junto con sus pruebas de salud y su estado actual.
Actualizar
Dado que Consul está relacionado con el funcionamiento normal de todo el sistema, aún debes tener mucho cuidado al actualizar. Es una buena idea probar el sistema varias veces en un entorno de prueba antes de actualizarlo a producción. Las situaciones de actualización se pueden dividir en los tres tipos siguientes y estos problemas deben resolverse antes de realizar la actualización.
◆ Actualización profesional. Consulte las páginas específicas de la actualización para ver si hay instrucciones especiales para la versión de actualización actual. Por ejemplo, si está actualizando desde una versión anterior a la 0.5.1 a la 0.6, necesitará migrar sus datos con la ayuda de la herramienta cónsul-migrate.
◆ Actualizaciones incompatibles. Utilice cónsul -v para verificar el número de versión del protocolo de compatibilidad con versiones anteriores para una nueva versión. Cuando no es compatible con la versión actual, se requiere una actualización de dos pasos. Primero, actualice todo el clúster una vez con el parámetro -protocal= el número de versión del protocolo anterior, luego elimine el parámetro -protocal del comando de inicio y reinicie todos los nodos.
◆ Actualización estándar. Si nada de lo anterior es cierto, felicidades, todo lo que necesita hacer es una simple actualización estándar. Es decir, detener la versión anterior del agente e iniciar la nueva versión del agente.
En realidad, se trata de una actualización estándar en la mayoría de los casos.
El orden recomendado para actualizar los nodos es actualizar primero el nodo Seguidor del servidor, luego actualizar el nodo Líder del servidor y finalmente actualizar todos los nodos Cliente.
Conclusión
La introducción del registro y descubrimiento de servicios en el sistema es un cambio que afecta a todo el sistema, pero toda la arquitectura del sistema se beneficiará, especialmente la arquitectura moderna de microservicios.
Creo que muchos sistemas están equipados con equilibrio de carga, verificación de estado, detección de latidos y otras funciones. Naturalmente, aprovechar el descubrimiento de servicios, la expansión elástica, la alta disponibilidad y el lanzamiento de servicios en escala de grises es algo natural.