[Suggestion] - Support single-node deployments

[konrad-garus]

Suggestion

It would be nice if the Confluence chart supported single-node deployments. You don't always need the hassle and additional costs of additional volumes, processes (Synchrony) etc.

1. Make "shared home" optional. When it's disabled, don't create the shared home volume, its corresponding volume mount, or the ATL_PRODUCT_HOME_SHARED env var.
2. Support using in-process Synchrony. We don't need the extra pod with its own heap etc. Let us just have a service that points to 8091 on Confluence.

Product

Confluence

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

[bianchi2]

@konrad-garus thanks for your questions. I am afraid we can't get rid of shared home as such but what I think is possible is either:

• use RWO volume for it (like EBS)
• or use one volume for both shared and local home - you can redefine shared home path with an additional env var

I haven't tried it myself though but happy to verify it if it's something that somehow addresses the raised issue.

[konrad-garus]

Why not get rid of shared home? Confluence is perfectly happy without it, as long as it's a single-node deployment. Which is what I'm asking for here.

In fact, we've recently talked about it for Bitbucket: https://github.com/atlassian/data-center-helm-charts/issues/379.

Right now I'm using Kustomize for it and it works just fine. What I'm suggesting here is to make it a part of the official chart, to support single-node deployments.

My Kustomize patches look like this:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: confluence
spec:
  template:
    spec:
      containers:
        - name: confluence
          env:
          - $patch: delete
            name: ATL_PRODUCT_HOME_SHARED
          volumeMounts:
          - $patch: replace
          - name: local-home
            mountPath: /var/atlassian/application-data/confluence
      volumes:
      - $patch: delete

# By replacing additional_jvm_args, this update does two things:
# 
# 1. It removes the config params that configure standalone Synchrony
# 2. It tweaks Confluence configuration to have better behavior around job purge (causing excessive DB load)
#
# The default args (as of 1.5.1) are:
# -Dconfluence.cluster.hazelcast.listenPort=5701
# -Dsynchrony.btf.disabled=true
# -Dsynchrony.by.default.enable.collab.editing.if.manually.managed=true
# -Dconfluence.clusterNodeName.useHostname=true
# -Datlassian.logging.cloud.enabled=false
# -XX:ActiveProcessorCount=1
apiVersion: v1
kind: ConfigMap
metadata:
  name: confluence-jvm-config
data:
  additional_jvm_args: -Djobs.limit.per.purge=50000 -Dall.jobs.ttl.hours=168

apiVersion: v1
kind: Service
metadata:
  name: confluence
spec:
  ports:
  - name: synchrony
    port: 8091
    targetPort: 8091
    protocol: TCP

[bianchi2]

Hi @konrad-garus sorry for not getting back to you earlier. Your Kustomize now makes sense to me. One question though - what's local-home volumeMount is replaced with?

I guess, we may add a few conditions to drop shared home env var and shared home volumeMount and volume altogether.

As to the synchrony, as far as I understand you may control everything in values.yaml through additional jvm args?

[bordenit]

Maybe get rid of local home instead. If you do not customize the deployment there are probably just a few files needed to be persistent in local home, as the important stuff goes into shared home. If possible to accommodate those few files perhaps make shared home read-write-once if single node to improve performance, and read-write-many only if multi-node. Also, since synchrony statefulset is the same image reducing the pods does seem ideal. Sometimes getting all 4 pods to boot is quite painful.

[mdraheim]

as for synchrony: it is possible to deploy managed synchrony with the data center chart. Meaning no synchrony statefulset at all, just the managed synchrony in each confluence pod. No changes to the chart or image nexessary, only creative overrides.

[bianchi2]

@bordenit it is possible to have a custom volume for shared-home and make it RWO (of course if you do not plan to scale StatefulSet). Local home is optional, it is emptyDir by default and the downside of not persisting local-home is the necessity to recover indexes each time the pod restarts.

[bianchi2]

We won't be implementing it at this time as Helm charts target deployments at scale. It is still possible to use a custom RWO volume for shared home.