On Tue, Jan 10, 2023 at 3:11 PM Christopher Schultz
<ch...@christopherschultz.net> wrote:
>
> 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!The KubernetesMembershipProvider is the cleanest way to access the Kube namespace. Then you can use it to list the pods (as here) or pretty much anything else. There's a problem though: it needs the token to connect to the service account (= configuration !) *and* configure the appropriate permissions in Kube to allow the desired access (= annoying configuration !). I liked it because once it works it is predictable and reliable. DNSMembershipProvider is an equivalent to get the list of pods with far less configuration. However it uses DNS which is prone to "issues". So basically yeah, you would need to write a PropertySource that does somewhat the connection and json parsing that KubernetesMembershipProvider does. I don't see how the processing can be generic for everything that is in the Kube namespace, so it would allow access to some specific values. The problem then is that security configuration (in Kube) will still be horrible. But it could work eventually. In KubernetesMembershipProvider, the connection with the token to the service account is generic. The URL used in the Kube namespace is hardcoded. And the json parsing is obviously specific to processing the list of (running) pods in the cluster. Rémy > Thanks, > -chris > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
