config.portal-registry.yml Maven / Gradle / Ivy

Go to download
Show more of this group Show more artifacts with this name
Show all versions of portal-registry Show documentation
A registry and discovery client that integrates with light-portal
There is a newer version: 2.1.38
# Portal URL for accessing controller API. Default to lightapi.net public portal, and it can be pointed to a standalone
# light-controller instance for testing in the same Kubernetes cluster or docker-compose.
portalUrl: ${portalRegistry.portalUrl:https://lightapi.net}
# Bootstrap jwt token to access the light-controller. In most case, the pipeline will get the token from OAuth 2.0
# provider during the deployment. And then pass the token to the container with an environment variable. The other
# option is to use the light-4j encyptor to encrypt token and put it into the values.yml in the config server. In
# that case, you can use portalRegistry.portalToken as the key instead of the environment variable.
portalToken: ${portal.authorization:}
# number of requests before resetting the shared connection to work around HTTP/2 limitation
maxReqPerConn: ${portalRegistry.maxReqPerConn:1000000}
# De-register the service after the amount of time with health check failed. Once a health check is failed, the
# service will be put into a critical state. After the deregisterAfter, the service will be removed from discovery.
# the value is an integer in milliseconds. 1000 means 1 second and default to 2 minutes
deregisterAfter: ${portalRegistry.deregisterAfter:120000}
# health check interval for HTTP check. Or it will be the TTL for TTL check. Every 10 seconds, an HTTP check
# request will be sent from the light-portal controller. Or if there is no heartbeat TTL request from service
# after 10 seconds, then mark the service is critical. The value is an integer in milliseconds
checkInterval: ${portalRegistry.checkInterval:10000}
# enable health check HTTP. An 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 the 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. This
# is the recommended configuration that allows the light-portal controller to poll the health info from each service.
httpCheck: ${portalRegistry.httpCheck:false}
# enable health check TTL. When this is enabled, The light-portal controller won't actively check your service to
# ensure it is healthy, but your service will call check endpoint with a heartbeat to indicate it is alive. This
# requires that the service is built on top of light-4j, and the HTTP check is not available. For example, your service
# is behind NAT. If you are running the service within your internal network and using the SaaS lightapi.net portal,
# this is the only option as our portal controller cannot access your internal service to perform a health check.
# We recommend deploying light-portal internally if you are running services within an internal network for efficiency.
ttlCheck: ${portalRegistry.ttlCheck:true}
# The health check path implemented on the server. In most of the cases, it would be /health/ plus the serviceId;
# however, on a kubernetes cluster, it might be /health/liveness/ in order to differentiate from the /health/readiness/
# Note that we need to provide the leading and trailing slash in the path definition.
healthPath: ${portalRegistry.healthPath:/health/}