In the previous step, we have started the consul server locally, now let’s start the light-oauth2 services as they are part of the portal. We will start more services later on, but here we use the light-oauth2 services to demo the process.
We cannot use the docker-compose-oauth2-mysql.yml in light-docker as the configuration there is not using the consul registry. In order to use the consul registry and discovery, all services should be bound to the host network instead of the docker network.
To use the consul registry, I have created another folder in the light-config-test repository. The docker-compose file and configuration files are copied from the light-docker.
docker-compose up -d
If this is the first time you start the docker-compose, it will take a while to download all images. Once all service is up, go to the consul UI again to check if all services are registered.
You should find seven services registered on the consul, and they are all healthy.
The light-oauth2/local-consul config files are copied from the light-docker/light-oauth2/mysql with the following modifications.
Add client.yml, client.keystore, and client.truststore to the config folder so that the client module can be used to connect to the local consul server.
There is no need to add these files as we are not using TLS to connect to consul; however, it is always a good idea to add these files just in case we move to the official test environment with a Consul cluster only offer HTTP/S connection.
If you are using light-4j version 1.6.x with Java 8, then we need to add the consulToken that matches the master token used in the consul container.
If you are using light-4j version 2.0.x and above with Java 11, then you need to add this line to the consul.yml file below.
In this config file, we need to change the enableRegistry to true. Since all light-oauth2 services have their port numbers allocated, we don’t need dynamicPort to be enabled.
We need to add the section for the registry, load balance, and cluster support at the beginning of the file.
We also need to create a new file to specify the parameters for ConsulClient.
# Consul URL for accessing APIs
# number of requests before reset the shared connection.
# deregister the service after the amount of time after health check failed.
# health check interval for TCP or HTTP check. Or it will be the TTL for TTL check. Every 10 seconds,
# TCP or HTTP check request will be sent. Or if there is no heart beat request from service after 10 seconds,
# then mark the service is critical.
# One of the following health check approach will be selected. Two passive (TCP and HTTP) and one active (TTL)
# enable health check TCP. Ping the IP/port to ensure that the service is up. This should be used for most of
# the services with simple dependencies. If the port is open on the address, it indicates that the service is up.
# enable health check HTTP. A http get request will be sent to the service to ensure that 200 response status is
# coming back. This is suitable for service that depending on database or other infrastructure services. You should
# implement a customized health check handler that checks dependencies. i.e. if db is down, return status 400.
# enable health check TTL. When this is enabled, Consul won't actively check your service to ensure it is healthy,
# but your service will call check endpoint with heart beat to indicate it is alive. This requires that the service
# is built on top of light-4j and the above options are not available. For example, your service is behind NAT.
# endpoints that support blocking will also honor a wait parameter specifying a maximum duration for the blocking request.
# This is limited to 10 minutes.This value can be specified in the form of "10s" or "5m" (i.e., 10 seconds or 5 minutes,
Here you can see that we are using lightapi.net as the hostname in the consulUrl and httpCheck is set to true.
We need to update the copied docker-compose.yml to switch to the host network.