Así que tenemos microservicios de Java escritos con Spring-Boot, usando Consul para el descubrimiento de servicios y la gestión de configuración y ejecutándose en contenedores Docker. Todo funciona, pero cuando un contenedor muere o un servicio se reinicia, la identificación del servicio anterior nunca desaparece en Consul y el servicio para siempre se muestra como "Error" en la interfaz de usuario de Consul, aunque el nuevo contenedor se ha registrado y muestra todo. Verde.
No estamos usando el latido del corazón, pero no puedo encontrar mucha documentación sobre cuál es la diferencia entre el latido del corazón y el control de salud para Consul.
Aquí está mi bootstrp.yml
spring: application: name: my-service cloud: config: enabled: false consul: host: ${discovery.host:localhost} port: ${discovery.port:8500} config: watch: wait-time: 30 delay: 10000 profile-separator: "-" format: FILES discovery: prefer-ip-address: true instanceId: ${spring.application.name}:${spring.application.instance_id:${random.value}}Hay otras configuraciones para habilitar el latido del corazón, pero los documentos dicen algo sobre esto que pone más estrés en el clúster de Consul.
¿Alguien ha logrado que los servicios de Consul y Spring Boot/Docker se den de baja automáticamente? En realidad, no causa ningún problema real, pero hace que la interfaz de usuario de Consul sea bastante inútil para monitorear los servicios arriba/abajo.
Ha mencionado que está utilizando un contenedor docker para ejecutar el microservicio. ¿Está atrapando el SIGTERM en su secuencia de comandos de punto de entrada en el contenedor docker? Si se envía un SIGTERM, la aplicación de arranque lo obtendrá y verá el siguiente registro que muestra que el microservicio se está cancelando con Consul.
2017-04-27 09:20:19.854 INFO 6852 --- [on(6)-127.0.0.1] inMXBeanRegistrar$SpringApplicationAdmin : Application shutdown requested. 2017-04-27 09:20:19.857 INFO 6852 --- [on(6)-127.0.0.1] ationConfigEmbeddedWebApplicationContext : Closing org.springframework.boot.context.embedded.AnnotationConfigEmbeddedWebApplicationContext@afb5821: startup date [Thu Apr 27 09:20:00 EDT 2017]; parent: org.springframework.context.annotation.AnnotationConfigApplicationContext@130c12b7 2017-04-27 09:20:19.859 INFO 6852 --- [on(6)-127.0.0.1] oscsupport.DefaultLifecycleProcessor : Stopping beans in phase 2147483647 2017-04-27 09:20:19.863 INFO 6852 --- [on(6)-127.0.0.1] oscsupport.DefaultLifecycleProcessor : Stopping beans in phase 0 2017-04-27 09:20:19.863 INFO 6852 --- [on(6)-127.0.0.1] osccsConsulServiceRegistry : Deregistering service with consul: xxxxxxxxxxxxxConsul no cancela automáticamente los servicios.
Consultehttps://groups.google.com/forum/#!topic/consul-tool/slV5xfWRpEE para obtener una pista sobre la misma pregunta. De acuerdo con ese hilo, debe actualizar la configuración o realizar una llamada a la API del agente . Dado que el agente es la fuente de la verdad, no debe intentar actualizar a través de la API del catálogo. Ver GitHub para más detalles. También mencionan en el grupo de Google que no necesariamente tiene que cancelar el registro de los servicios si el nodo se cae correctamente, pero ese no parece ser su caso de uso.
Eche un vistazo a Consul not deregistering zombie services para obtener sugerencias sobre cómo automatizar la cancelación del servicio utilizando la API o herramientas como el registrador .