Automatic Consul Registration for Quarkus Applications

[aureamunoz]

Enhance the integration with Consul to enable applications to automatically register themselves during startup, even if the application doesn't explicitly know its IP address. Consul will handle the communication, minimizing configuration effort.

When a Quarkus application starts, if the stork-service-registration-consul is present, it should automatically register with Consul, including its IP address, public port, and other metadata. To provide flexibility, we will introduce the following new configuration options:

1. Public IP / Name: Optional. If not provided, Consul will use its detected IP.
2. Public Port: Optional. Defaults to quarkus.http.port.
3. Service Name: Optional. Defaults to quarkus.application.name.
4. Service ID: Optional. Consul-specific. Defaults to a generated UUID (quarkus.uuid or similar).
5. Health Check URL: Optional. If a health check is configured, use the liveness endpoint. Note that it may run on a separate management interface, with a different public IP and port, so manual configuration may be needed.

For full Docker mode, this will work assuming the private port is exposed on the network.

Consul Failure Management

That would be a request for enhancement for the Vert.x consul client.
Another critical aspect is how the client manages Consul failures. Currently, even in distributed mode, the Consul client is unaware of all Consul instances and doesn't switch to a new leader when a failure occurs.

Proposed solution:

• On client creation, query Consul for its nodes and store them.
• In case of a failure:
  1. Query any available Consul server ($ANY_CONSUL_SERVER/v1/status/leader) to find the new leader.
  2. Create a new client and retry the request with the new leader.

To optimize performance, clients should be reused instead of being created every time.

Additional Considerations

• Handling scenarios where the health check is on a different IP/port than the application itself.

cc @cescoffier @melloware @FranckD-Zenika @@FranckDemeyer

[melloware]

Another feature for your list is we should accept a List<String> of tags and a Map<String,String> of metadata.

        client.registerService(
                new ServiceOptions()
                .setPort(port)
                .setAddress(address)
                .setName(name)
                .setId("greeting-service")
                .setTags(List.of("v1"))
                .setMeta(Map.of("version", "v1")));

[aureamunoz]

I've been working a bit on this today again.
There is a problem when consul returns an empty address. The problem is in StorkClientRequestFilter line 50 :

      String host = instance.getHost() == null ? "localhost" : instance.getHost();

I'm creating a PR soon for fixing it.
Anyway, we still have a problem about auto-registration. Consul is not able to detect the public IP of the application sending the request. It just uses the agent's address If not provided, and for some reason when the agent's address is registered it returns an empty address when a discovery request is sent.

So, we can do automatic registration in quarkus when de dependency is present but need the public ip and public port to register via the configuration. For the service name we can default to the application name if not provided.