Containerization for Kubernetes

Hi,

I’m a DevOps engineer asked to get a Bloomreach setup into Kubernetes.

Currently, when the system initializes it writes a JCR to local file storage. I’m wondering if it would be possible to create a dedicated container with the bloomreach code which can be reached by the 1-N scaled backend containers.

So ideally the backend could be scaled and they all can rely on 1 container with the initialized JCR, available via the JCR API interface. https://documentation.bloomreach.com/library/concepts/content-repository/jcr-interface.html

If the JCR files would be on a shared volume, one might get into trouble with open files, concurrent writes or some other conflict. So from a Operations point of view, it would be ideal to have that JCR reachable by via an API.

Is this a common scenario? Has anybody got some experience with this?

Thanks for your input!

1 Like

What you describe is not possible. Each member of the jcr cluster has to maintain its own lucene index (files in local storage) and own repository. They cannot share those.

I understand they can’t share the same volume. But when it’s reachable as an API in a separate container it would solve that issue. Then there would only 1 set of files for the JCR, reachable via rmi://$container_name:1099/$endpoint

That’s also not possible is what i meant to say. The cms and site webapps require repository to be present in the same jvm IIRC. That rmi connection is for remote connection for other apps, and i also heard some issues around using rmi (security etc.) .