-
Suggestion
-
Resolution: Fixed
-
None
-
3
-
5
-
Enterprise customers using Red Hat OpenShift and Kubernetes want the ability to dockerize Confluence Data Center nodes for quick and easy deployment. This would also benefit client running Confluence Data Center in AWS that wish to automate deployment (outside of using the AWS quick-start CloudFormation templates) and thus need to define static IP's in the confluence.cfg.xml config.
Due to the way this cloud works and/or security restrictions, they need the ability to use the Hazelcast SPI discovery instead of Multicast or Unicast.
Hazelcast 3.6+ is required to do this, but 3.8+ is preferred. Currently we use the following versions:
- Confluence 5.10.8 uses Hazelcast 3.4.2
- Confluence 6.0 through 6.6.5 uses Hazelcast 3.5.2
- Confluence 6.6.6+ uses Hazelcast 3.8.6:
CONFSERVER-55867
Updated the above two lines to reflect changes in 6.6.x - Note that while Hazelcast was upgraded, this does not necessarily mean SPI is supported in Confluence yet.
Upgrading hazelcast to 3.8 would allow enterprise admins to more easily deploy Confluence Data Center nodes on the fly.
[CONFSERVER-52568] Include the ability to utilize Hazelcast's SPI discovery in Confluence Data Center
you can leave questions here https://community.atlassian.com/t5/Atlassian-Data-Center-on/gh-p/DC_Kubernetes
Hi Dipesh,
You can install Data Center in Kubernetes with the TCP/ip option, and make it work when new nodes are added or removed.
We have described it here with videos and blogposts if you are interested :
https://www.praqma.com/services/ask/
The video is a bit old. Today we use Helm for all deployments.
Let me know if you have questions.
I recently attempted to get Confluence Data Centre running on Google Kubernetes Engine (GKE); and found this same limitation with multicast discovery of cluster nodes.
As far as I'm aware, GKE does not support multicast; however there are some CNI plugins such as Weave Net that do. Unfortunately, even with Weave installed, multicast discovery of DC nodes still does not work.
I was successful in getting 2 cluster nodes working, but only by switching to TCP/IP discovery mode, and then during the first-run setup, entering the IP address of the first pod. After completing the setup of the single node and scaling to a second node (kubectl scale --replicas=2 statefulset confluence), the second node was able to join the cluster successfully.
Unfortunately, continuing to scale beyond two nodes was problematic. When a third node was added, the second node (that was until then working flawlessly) immediately died and restarted.
Once the second node restarted, the third node then died and restarted...and this flapping between second and third nodes continued indefinitely. I can only assume that this was because the 2nd/3rd nodes did not have their IPs listed in the confluence.cluster.peers configuration setting.
With the introduction of the Data Center Approved Apps program, and the need for app vendors to have access to an appropriately sized/scaled DC cluster for testing their apps; having the ability to easily provision a cluster in Kubernetes would greatly simplify the process for vendors looking to complete the performance & scale testing required by the approved apps program.
I was recently attempting to get Confluence Data Center running on Google Kubernetes Engine (GKE); and discovered this limitation (unable to use multicast for node discovery).
As far as I'm aware, GKE doesn't support multicast; however there are some CNI plugins such as Weave Net that do. Unfortunately, even with Weave Net installed, when scaling up the pod replica count, additional DC nodes are unable to find each other over multicast.
I was, successful in getting two DC nodes working; but only by using TCP/IP discovery mode and during the first-run setup of the initial node, entering its IP address. A second DC node (kubectl scale --replicas=2 statefulset confluence) was able to discover the first node and successfully join the cluster.
However, continuing to scale beyond 2 replicas was problematic: when a third node starts; the second node (that was previously working flawlessly) immediately dies and restarts.
Once the second node comes back after restarting, the third node then immediately dies & restarts...and this flapping between the second and third nodes continues indefinitely. Presumably this is because neither the 2nd or 3rd nodes have their IP addresses listed in the `confluence.cluster.peers` config setting.
With the introduction of the Data Center Approved Apps program, and the need for app vendors to have access to an appropriately sized/scaled DC cluster for testing their apps; the ability to easily deploy to Kubernetes would greatly simplify the process for app vendors looking to get DC approved.
At Deutsche Bank we are looking to deploy Confluence onto RedHat Openshift
If we were able to use Hazelcast's Discovery API we would be able to configure Hazelcast to cluster by using the OpenShift environment variables - e.g. Service.
At the moment Confluence forces us to use Multicast or Unicast via the Confluence Web UI - and in the OpenShift world we do not have any concept of fixed IPs - whether they be unicast or multicast.
We already deploy Hazelcast on OpenShift using our own implementation of the Discovery SPI - we would just like to have the ability to do the same with the embedded Hazelcast in Confluence.
The Atlassian Data Center product team has built docker image and helm charts that support fully dockerised deployment environments. https://atlassian.github.io/data-center-helm-charts/