Mark,
On 1/10/23 03:22, Mark Thomas wrote:
On 09/01/2023 22:17, Christopher Schultz wrote:
All,
I'm aware that there is a k8s manager for clustering
(CloudMembershipService) but I was wondering if / how that could be
extended in order to provide any other types of automated
configuration information for a Tomcat installation.
For example, I'd love to be able to deploy a Tomcat node and have it
grab its primary database connection information from k8s.
I spent like 5 minutes reading through the CloudMembershipService and
KubernetesMembershipProvider classes and it seems to be all bundled
together and very geared toward fetching cluster information.
It seems that most of the KubernetesMembershipProvider.start method
could be moved into a separate support class which just manages k8s
connection information (e.g. fetching from the environment, building
URLs to various interesting paths, wrapping fethcing-and-JSON-parsing,
etc.) and that could be re-used for a parameter-resolver for XML
config files like we can do for system properties like
<Connector jvmRoute="${foo}">
It occurs to be that we should be able to do something like this:
<Connector jvmRoute="${k8s:jvmRoute}">
... and write a resolver that fetches that value on the fly.
(Hopefully it would cache stuff, so that a dozen different
environmental references don't have to be resolved separately.)
Isn't this why ServiceBindingPropertySource was contributed? I only
dabble with k8s very occasionally but my understanding is that this is
the 'proper' way to pick up config in a k8s environment.
Yeah, I think you are right. I hadn't noticed that class before, and it
looks like it doesn't interact with k8s (or similar) in any way: it just
assumes that the orchestration framework has already dropped a cache of
useful configuration files onto the system before the service is launched.
It looks like the KubernetesMembershipProvider needs to be separate from
that because it actually has to communicate directly with k8s for, well,
membership services. It's not just reading configuration values.
So, I guess... nothing to see here!
Thanks,
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
