Yevhen Atlassian Team

You can declare an additional configmap and mount a custom file. See: https://github.com/atlassian/data-center-helm-charts/blob/main/src/main/charts/confluence/values.yaml#L1726

https://atlassian.github.io/data-center-helm-charts/userguide/CONFIGURATION/#ingress all you need is to create an ingress, ie enable it in your helm values.

There are no official recommendations on the LB and session affinity. You could implement it the way it makes sense in your infrastructure, as long as requests from the same client go to the same Jira pod. Official documentation mentions nginx ingress controller, so it's safe to use it.

I'd say, Azure LB needs to use sticky cookies and send requests to the same backend Jira pods.

If you have nginx ingress controller, and you dpeloy using official Helm charts, then it should work out of the box.

You need to configure session affinity aka sticky sessions on your LoadBalancer which is pre-requisite of running datacenter apps (not only on kube)

@Luboss command and args can't be overridden. What you can do, however, is declare additionalInitContainer that mounts shared home (or shared and local home if necessary) with some sleep infinity command: additionalInitContainers: - name: debug image: ubuntu command: ["/bin/bash"] args: ["-c", "sleep infinity"]…

@Eric Chen no, unfortunately, datacenter container images aren't signed.

@Richard Adler thanks for the update. We'll fix this in a new version. This should not be a fatal error so we just log it instead of throwing an exception.

@Richard Adler do you mind sharing the entire stacktrace?

@Corey Perkins sadly, only logs can help identify the issue. It'd be great if you can share both Tomcat (catalina.out) and application (atlassian-confluence.log) full logs.

@C_Faysal _CFcon_ you need to make sure that synchrony is accessible from within the Confluence pod and in your browser as well. Synchrony url should be in the jvm configmap in the namespace.

Of course, you need to enable clustering to be able to scale Confluence. What you need to do is: * scale down to 1 replica * set forceConfigUpdate to true * set clustering.enabled to true * run helm upgrade * ensure you have got clustering props in cfg.xml in shared and local home * scale up

Can you share it (just replace license and any sensitive info). Also please share confluence.cfg.xml from local home.

Do you see confluence.cfg.xml in shared-home?

Shared storage is something you need to take care of in your K8S cluster. Atlassian Helm charts don't configure infrastructure for you. NFS, EFS, Azure files, Google File storage - it all depends on the K8S vendor and cloud you use.

Most likely you don't have shared home configured and the second Confluence pod thinks it's a fresh installation.

You need to create a secret with the cert and reference it in https://github.com/atlassian/data-center-helm-charts/blob/main/src/main/charts/confluence/values.yaml#L1064

You need to fix DNS resolution problem in your cluster. Both server and client (UI) use the same synchrony URL.

> as you know Jira and Confluence needs shared-home between them That is not true. Deploying each datacenter product to a different namespace is a common practice but not a requirement, so it's up to you.

additionalConfigMaps will create a ConfigMap for you. You just need to define server.xml content that you want.

There's no documentation but what you can do is: * copy existing server.xml from the pod * generate keystore and create a secret in jira namespace * use additionalFiles feature to mount the secret * use addtionalConfigMaps to mount your custom server.xml * change service and container ports to 8443 * in your ingress use…

@Ankit Masaram it depends on what ingress controller you use. Without ingress controller details I am afraid nobody can help you. 1. Were you able to run Jira on a secure port? 2. What is your ingress controller?

@D M I personally don't see anything wrong with deploying Atlassian DC products to the same cluster provided that each product has its own nodegroup and you do a good job with setting reasonable resources requests/limits, use affinity/anti-affinity rules, tolerations etc. Atlassian DC products and DC Helm charts do not…

That's the default version (the latest LTS typically).

@Gerard Pa you can deploy any Jira Software version by overriding image.tag in Helm values. Helm charts are Jira version agnostic.

I am pretty sure OpenShift creates a Route for each ingress and I am not certain nginx annotations have any effect here unless you indeed use Nginx ingress controller. You may want to annotate your route with haproxy.router.openshift.io/timeout=120 to see if it makes any difference.

@Alok Deo do you create OpenShift routes? If so, you may need to increase timeouts via annotations.

You need to get pod events to see why scheduler in your EKS cluster can't find a suitable node for jira pod.

@Brian Murray Jira serviceAccount has nothing to do with how you authenticate to a Kubernetes cluster in your Terraform. You need to properly configure your kubernetes provider in Terraform.