XWiki Helm Chart

Last modified by Guilherme Sautner on 2024/04/18 20:19

cogProvide a helm chart to install and configure XWiki in a Kubernetes environment
TypeOther
CategoryOther
Developed by

xwiki:XWiki.ashish, Ludovic Dubost, Guilherme Sautner, Arsène Fougerouse

Rating
0 Votes
LicenseGNU Lesser General Public License 2.1

Description

This contrib extension provides Helm Chart aiming to ease the deployment in both Local and Highly Available setups.

TL/DR

helm repo add xwiki-helm https://xwiki-contrib.github.io/xwiki-helm
# Use --devel install most recent released (beta/alpha) version
helm upgrade -i xwiki xwiki-helm/xwiki

XWiki <1.0.0 Install from source.

Complete guide to see Requirements/Install instructions. 

Know Limitations

Follow features are available but are considered as experimental/incomplete:

  • Enable HA (Cluster/Autoscale Settings)
  • Custom internal Solr instance
  • Prometheus Metrics

Parameters

XWiki

NameDescriptionValue
image.nameXWiki docker image namexwiki
image.tagXWiki docker image taglts-mysql-tomcat
image.pullPolicyXWiki docker image pull policyIfNotPresent
workloadStatefulXWiki 1.0.0+ Define if workload will be (true) StatefulSet or Deploymenttrue
customConfigs.xwiki.cfgXWiki 1.0.0+ Key/Value preferences to be replaced or inserted on xwiki.cfg file[]
customConfigs.xwiki.propertiesXWiki 1.0.0+ Key/Value preferences to be replaced or inserted on xwiki.properties file[]
propertiesXWiki 1.0.0+ Key/Value preferences to be passed to Java process with -D parameters using JAVA_OPTS[]
javaOptsXWiki 1.0.0+ Custom JVM parameters[]
extraEnvVarsXWiki 1.0.0+ Array with extra environment variables[]
nodeSelectorXWiki 1.0.0+ Node labels for XWiki pods assignment{}
tolerationsXWiki 1.0.0+ Tolerations for XWiki pods assignment[]
affinityXWiki 1.0.0+ Affinity for XWiki pods assignment{}
resources.limitsThe resources limits for XWiki{}
resources.requestsThe requested resources for XWiki{}
securityContext.enabledXWiki 1.2.0+ Enable XWiki pods security contextfalse
securityContext.fsGroupXWiki 1.2.0+ Set XWiki pods FS user group101
containerSecurityContext.enabledXWiki 1.2.0+ Enable XWiki container security contextfalse
containerSecurityContext.runAsUserXWiki 1.2.0+ Set XWiki container user to use on run100
containerSecurityContext.runAsNonRootXWiki 1.2.0+ Set XWiki container to run as non-root usertrue
infinispan.enabledXWiki 1.3.0+ Enable the provision of custom settings for the infinispan configuration file.false
infinispan.customConfigXWiki 1.3.0+ Use custom settings for the infinispan configuration file.""
infinispan.defaultMemoryMaxCountXWiki 1.3.0+ Use custom memory maximum count from the default infinispan configuration file. 10000

Persistence

NameDescriptionValue
persistence.enabledXWiki 1.0.0+ Enable XWiki data persistence using PVCtrue
persistence.existingClaimXWiki 1.0.0+ Name of an existing PVC to use""
persistence.storageClassXWiki 1.0.0+ PVC Storage Class for XWiki data volume""
persistence.accessModesXWiki 1.0.0+ PVC Access Mode for XWiki data volume["ReadWriteOnce"]
persistence.sizeXWiki 1.0.0+ PVC Storage Request for XWiki data volume500Mi
persistence.annotationsXWiki 1.0.0+ Annotations for the PVC{}
persistence.labelsXWiki 1.0.0+ Labels for the PVC{}
persistence.selectorXWiki 1.0.0+ Selector to match an existing Persistent Volume{}
persistence.dataSourceXWiki 1.0.0+ Custom PVC data source{}

Traffic

NameDescriptionValue
ingress.enabledEnable ingress rule that makes XWiki service accessiblefalse
ingress.classNameIngressClass that implement the Ingress""
ingress.annotationsAdditional annotations for the Ingress.{}
ingress.hosts[0].hostXWiki 1.0.0+ Host for the ingress""
ingress.hosts[0].paths[0].pathXWiki 1.0.0+ Path for the ingress"/"
ingress.hosts[0].paths[0].pathTypeXWiki 1.0.0+ Path Type fo the ingress"ImplementationSpecific"
ingress.tlsXWiki 1.0.0+ TLS configuration[]
service.portNamePort name of service'node'
service.nameName of service'http'
service.typeKubernetes service type'ClusterIP'
service.externalPortExternal port80
service.internalPortInternal/Container port8080 
service.externalIPsAn array of externalIPs[]
service.sessionAffinitySpecific Session AffinityClientIP
istio.enabledEnable istio virtual servicefalse 
istio.hostHost to configured on istio virtual service"*"
istio.httpCookie.nameXWiki 1.1.0+ Name of cookie used for sticksession"xistio"
istio.httpCookie.pathXWiki 1.1.0+ Path of cookie used for sticksession"/"
istio.httpCookie.ttlXWiki 1.1.0+ Time to live of cookie used for sticksession"1800s"
istio.externalGatewayNameXWiki 1.1.0+ Use custom gateway name""
istio.gateway.enabledXWiki 1.1.0+ Enable creating gateway"false"
istio.gateway.selectorIstioXWiki 1.1.0+ Selector for istio gateway, some cases the default selector is "ingressgateway"."ingress"
istio.tls.enabledXWiki 1.1.0+ Enable TLS usage"false"
istio.tls.httpsRedirectXWiki 1.1.0+ Force redirect to https on http 'service'"false"
istio.tls.secretNameXWiki 1.1.0+ Use custom secret/certificate""
istio.tls.minProtocolVersionXWiki 1.1.0+ Minimal TLS protocol to be used"TLSV1_2"
istio.tls.modeXWiki 1.1.0+ Minimal TLS protocol to be used"TLSV1_2"
istio.tls.certificate.enabledXWiki 1.1.0+ Enable certificate creation to be issued (using certmanager) on same namespace of istio ingress"false"
istio.tls.certificate.namespaceXWiki 1.1.0+ Namespace of istio ingress is located"istio-ingress"
istio.tls.certificate.issuerRefXWiki 1.1.0+ Certmanager issuer reference{}

Database

In case deploy a database with xwiki chart, the database options are PostgreSQL, XWiki 1.0.0+ MariaDB and MySQL provided by bitnami.

NameDescriptionValue
externalDB.hostHost to external/existing database instance to use''
externalDB.databaseDatabase to use''
externalDB.userUser to use''
externalDB.passwordPassword for the above user''
externalDB.custommKeyRef.enableXWiki 1.2.4+ Enable usage of external secret with database password.false
externalDB.custommKeyRef.nameXWiki 1.2.4+ Secret name that contains password''
externalDB.custommKeyRef.keyXWiki 1.2.4+ Key for password''
mysql.enableWhether to deploy new MySQL servertrue
mysql.auth.rootPasswordPassword for the MySQL 'root' userxwiki
mysql.auth.usernameDatabase user to createxwiki
mysql.auth.passwordDatabase password for username abovexwiki
mysql.auth.databaseDatabase name to createxwiki
mariadb.enableXWiki 1.0.0+ Whether to deploy new MySQL serverfalse
mariadb.auth.rootPasswordXWiki 1.0.0+ Password for the MySQL 'root' userxwiki
mariadb.auth.usernameXWiki 1.0.0+ Database user to createxwiki
mariadb.auth.passwordXWiki 1.0.0+ Database password for username abovexwiki
mariadb.auth.databaseXWiki 1.0.0+ Database name to createxwiki
postgresql.enableWhether to deploy new PostgreSQL serverfalse
postgresql.auth.postgresPasswordPassword for the 'postgres' userxwiki
postgresql.auth.usernameDatabase user to createxwiki
postgresql.auth.passwordDatabase password for username abovexwiki
postgresql.auth.databaseDatabase name to createxwiki

For MySQL and MariaDB a initilization script and custom config are made in order to grant permission and use correct character set.

Cluster

XWiki 1.2.0+ The cluster setup is in a beta/experimental version. It needs a version of XWiki 15.0+ XWiki.

NameDescriptionValue
cluster.enabledEnable usage of Glowroot agentfalse
cluster.replicasNumber of XWiki instances1
cluster.jgroups.portJgroups TCP port to be used7800
cluster.jgroups.kube_ping.versionKubernetes Ping extension version to be used"2.0.1.Final"
cluster.jgroups.kube_ping.urlUse custom external URL to download kube_ping JAR file""
autoscaling.enabledEnable the HorizontalPodScalerfalse
autoscaling.minReplicasMinimium number of replicas1
autoscaling.maxReplicasMaximum number of replicas3
autoscaling.metricsCustom metrics to trigger the Autoscaling{}
autoscaling.statusDefine custom grain tuned metrics{}

Monitoring

NameDescriptionValue
glowroot.enabledXWiki 1.1.0+ Enable usage of Glowroot agentfalse
glowroot.propertiesXWiki 1.1.0+ Custom properties. Ex.: use custom central collector{}
glowroot.urlXWiki 1.2.0+ Use custom external URL to download Glowroot dist. file""
logback.enabledXWiki 1.2.0+ Enable to use custom values on logback file configurations.false
logback.customConfigurationXWiki 1.2.0+ Use custom entire configuration inside logback xml file.""
logback.extraConfigurationXWiki 1.2.0+ Add on end of logback xml file extra elements.""
prometheus.javaagent.enabledXWiki 1.3.0+ Enable usage of Prometheus Java Agent to expose prometheus metrics from JMX.false
prometheus.javaagent.portXWiki 1.3.0+ Port used to expose prometheus metrics12345
prometheus.javaagent.versionXWiki 1.3.0+ Agent version"0.20.0"
prometheus.javaagent.urlXWiki 1.3.0+ URL that is used to download agent JAR file. ""...""
prometheus.javaagent.configXWiki 1.3.0+ Custom Prometheus Java Agent configurationsrules:
      - pattern: ".*"
prometheus.javaagent.podmonitor.enabledXWiki 1.3.0+ Enable creation of PodMonitor resourcetrue
prometheus.javaagent.podmonitor.labelsXWiki 1.3.0+ Labels used on PodMonitor resource{}

Probes

XWiki 1.2.3+ Options configure liveness and readiness probes.

Depending on the number of pages or other characteristics of the environment, certain times and quantities will need to be adjusted.

probes.startup.enabledXWiki 1.2.4+ Enable startup probes. If this probe fails, the container will be recreated.true
probes.startup.httpGet.enabledXWiki 1.2.4+ Use http GET request to check probe. If false, test will be made with TCP socketfalse
probes.startup.httpGet.pathXWiki 1.2.4+ If httpGet enabled, witch path will be used./
probes.startup.initialDelaySecondsXWiki 1.2.4+ Seconds wait for the container startup.120
probes.startup.timeoutSecondsXWiki 1.2.4+ Seconds for probe times out.60
probes.startup.periodSecondsXWiki 1.2.4+ Time in seconds between checks.30
probes.startup.failureThresholdXWiki 1.2.4+ Quantity of failures check before restart container.5
probes.startup.successThresholdXWiki 1.2.4+ Quantity of successful check to reset failure threshold.1
probes.liveness.enabledEnable liveness probes. If this probe fails, the container will be restarted.true
probes.liveness.httpGet.enabledXWiki 1.2.4+ Use http GET request to check probe. If false, test will be made with TCP sockettrue
probes.liveness.httpGet.pathXWiki 1.2.4+ If httpGet enabled, witch path will be used./rest
probes.liveness.initialDelaySecondsSeconds wait for the container startup.30
probes.liveness.timeoutSecondsSeconds for probe times out.3
probes.liveness.periodSecondsTime in seconds between checks.30
probes.liveness.failureThresholdQuantity of failures check before restart container.10
probes.liveness.successThresholdQuantity of successful check to reset failure threshold.1
probes.readiness.enabledEnable readiness probes. If this probe fails, no traffic will be routed to the container.true
probes.readiness.httpGet.enabledXWiki 1.2.4+ Use http GET request to check probe. If false, test will be made with TCP sockettrue
probes.readiness.httpGet.pathXWiki 1.2.4+ If httpGet enabled, witch path will be used./rest/wikis/xwiki/spaces
probes.readiness.initialDelaySecondsSeconds wait for the container startup.30
probes.readiness.timeoutSecondsSeconds for probe times out.3
probes.readiness.periodSecondsTime in seconds between checks.30
probes.readiness.failureThresholdQuantity of failures check before stop send traffic.10
probes.readiness.successThresholdQuantity of successful check return to send traffic.1

Solr

When enabled, deploy an internal Solr instance.
This feature is available since XWiki 1.2.0+ 

 version 

NameDescriptionValue
solr.enabledDeploy a Solr instance. By default, use an internal instance"false"
solr.replicaCountNumber of replica1
solr.imageThe name of the Solr Docker image"gridexx/xwiki:solr8"
solr.extraEnvVarsXWiki 1.2.4+ Mapping extra ENV variables[]
solr.resources.limitsThe resources limits for Solr{}
solr.resources.requestsThe requested resources for Solr{}
solr.service.portNamePort name of service'solr-node'
solr.service.nameName of service'http'
solr.service.typeKubernetes service type'ClusterIP'
solr.service.externalPortExternal port8983
solr.service.internalPortInternal/Container port8983 
solr.persistence.enabledEnable Solr data persistence using PVC"true"
solr.persistence.existingClaimName of an existing PVC to use""
solr.persistence.storageClassPVC Storage Class for Solr data volume""
solr.persistence.accessModesPVC Access Mode for Solr data volume["ReadWriteOnce"]
solr.persistence.sizePVC Storage Request for Solr data volume500Mi
solr.persistence.annotationsAnnotations for the PVC{}
solr.persistence.labelsLabels for the PVC{}
solr.persistence.selectorSelector to match an existing Persistent Volume{}
solr.persistence.dataSourceCustom PVC data source{}

Examples

Custom Properties


# Custom configuration files for xwiki 
customConfigs:
 # Properties key that exists, replace in line is done with value here defined. 
 # If key don't exists, this key and value will be appended in that specific file. 
 # This files are list of key: value that are translated as key=value in that file.
 xwiki.cfg:
   xwiki.superadminpassword: "s3cr3t"
 # Extension repository should be writed as items of the array value extension.repositories
 xwiki.properties:
   extension.repositories:
      - "xwiki-extensions-xxx:maven:http://172.25.128.67:8081/repository/xwiki/"
      - store.xwiki.com:xwiki:https://store.xwiki.com/xwiki/rest/

# Properties to be passed to Java process with -D parameters using JAVA_OPTS 
properties:
 http.proxyHost: "proxy.mycompany.com"
 http.proxyPort: 7777
 https.proxyHost: "proxy.mycompany.com"
 https.proxyPort: 7777

As part of project XWiki for OpenDesk, it's possible to use System Property Updater extension, that's enable to change object properties or attachment references using helm chart properties. 

Example that changes logo to a new logo and some preferences on XWiki settings page: 


# Properties to be passed to Java process with -D parameters using JAVA_OPTS 
properties:
 "attachment:xwiki:[email protected]": "data:image/svg+xml;base64,AAA....=="
 "property:xwiki:XWiki.XWikiPreferences^XWiki.XWikiPreferences.colorTheme": "FlamingoThemes.Iceberg"
 "property:xwiki:XWiki.XWikiPreferences^XWiki.XWikiPreferences.timezone": "Europe/Berlin"
 "property:xwiki:XWiki.XWikiPreferences^XWiki.XWikiPreferences.default_language": "de"
 "property:xwiki:XWiki.XWikiPreferences^XWiki.XWikiPreferences.languages": "de"

Cluster

XWiki 1.2.0+ The cluster setup is in a beta/experimental version. It needs a version of XWiki 15.0+ XWiki.

To have a single XWiki data volume shared with all replicas, on this example we use NSF Ganesha server Provisioner

To discover all pods, it is required that the service account (is created automatically) used if cluster is enabled have pod permission to "get", "list" and "watch" inside the namespace that release was installed. It's recommended to use a dedicated namespace if you want to isolate some XWiki cluster from other workloads -n namespace --create-namespace

helm repo add nfs-ganesha-server-provisioner https://kubernetes-sigs.github.io/nfs-ganesha-server-and-external-provisioner/
helm install nfs-server-provisioner nfs-ganesha-server-provisioner/nfs-server-provisioner --set persistence.enabled=true 

Minimal values to enable cluster settings: 

image:
 tag: 15-mysql-tomcat

cluster:
 enabled: true
 replicas: 1

persistence:
 enabled: true
 storageClass: "nfs"
 accessModes:
    - ReadWriteMany

solr:
 enabled: true
 persistence:
   enabled: true

Monitoring

 

There is a preconfigured Glowroot on this chart that can be used for tracing, error log and reporting system. To enable, set XWiki 1.1.0+ glowroot.enabled to true

Follow one example of how to access service/dashboard using port forward:
kubectl port-forward xwiki-0 4000:4000

To see more details about other tools to monitoring XWiki, check Administrator Guide/Monitoring page. 

Logging

 
To change the logging settings of XWiki, it's possible to override the entire logback config file or simply add extra elements at the end of the configuration. To see more details about XWiki logging system, check Administrator Guide/Logging page. 

logback:
 enabled: true
 extraConfiguration: |
   <logger name="org.xwiki" level="debug"/>
   <logger name="com.xwiki" level="debug"/>
# Example to override all other configs elements, you can use: 
#  customConfiguration: |
#    <appender name="stdout" class="ch.qos.logback.core.ConsoleAppender">
#      <!-- Direct log messages to stdout -->
#      <Target>System.out</Target>
#      <encoder>
#        <pattern>%d [%t] %-5p %-30.30c{2} - %m %n</pattern>
#      </encoder>
#    </appender>

Backup

There are some tools that can manage the backups on k8s workloads. We can suggest Velero, as we already used on some internal clusters.

XWiki backup needs to be viewed to see all paths/components that needs to be saved.

Important volumes/paths to be considered:

  • xwiki volume, or /usr/local/xwiki/data path.
  • Database volume/Database dump. If PostgreSQL, there is some backup parameters that can be used.
  • If using an external solr: xwiki-solr-data volume, or another volume if using a custom external solr instance.

Sizing

Check XWiki Performance guide that contains more detailed options and settings related to sizes and performance. 

Recommended initial resources are equivalent to 1 CPU unit and 2G of memory. These values may vary depending on the XWiki use case.  

The default (chart) persistence size (XWiki Data) is low, it's recommended to give more space if usage will be with large pages/attachments. 

Events that needs to be monitored to sizing changes: 

  • In case of any “Out of Memory” error, proper increase on memory needs to be done. Important note that in some cases this error can be released with memory leeks or other issues. And the huge Java memory heap, requires more CPU unit to proper run without pressure on GC. 
  • Long processing time (Waiting long time for page to load/save), can be released with lack of CPU units or pressure on Memory. If memory is low and CPU is high, maybe only CPU unit increase is required. If memory usage is height, maybe there are height GC activities and sometimes more memory can help. 
  • Error save page, or add new attachments. Can be out of space problem, check Database avaliable size and XWiki data volume. 

 version 

NameDescriptionValue
solr.enabledDeploy a Solr instance. By default, use an internal instance"false"
solr.replicaCountNumber of replica1
solr.imageThe name of the Solr Docker image"gridexx/xwiki:solr8"
solr.extraEnvVarsXWiki 1.2.4+ Mapping extra ENV variables[]
solr.resources.limitsThe resources limits for Solr{}
solr.resources.requestsThe requested resources for Solr{}
solr.service.portNamePort name of service'solr-node'
solr.service.nameName of service'http'
solr.service.typeKubernetes service type'ClusterIP'
solr.service.externalPortExternal port8983
solr.service.internalPortInternal/Container port8983 
solr.persistence.enabledEnable Solr data persistence using PVC"true"
solr.persistence.existingClaimName of an existing PVC to use""
solr.persistence.storageClassPVC Storage Class for Solr data volume""
solr.persistence.accessModesPVC Access Mode for Solr data volume["ReadWriteOnce"]
solr.persistence.sizePVC Storage Request for Solr data volume500Mi
solr.persistence.annotationsAnnotations for the PVC{}
solr.persistence.labelsLabels for the PVC{}
solr.persistence.selectorSelector to match an existing Persistent Volume{}
solr.persistence.dataSourceCustom PVC data source{}

Examples

Custom Properties


# Custom configuration files for xwiki 
customConfigs:
 # Properties key that exists, replace in line is done with value here defined. 
 # If key don't exists, this key and value will be appended in that specific file. 
 # This files are list of key: value that are translated as key=value in that file.
 xwiki.cfg:
   xwiki.superadminpassword: "s3cr3t"
 # Extension repository should be writed as items of the array value extension.repositories
 xwiki.properties:
   extension.repositories:
      - "xwiki-extensions-xxx:maven:http://172.25.128.67:8081/repository/xwiki/"
      - store.xwiki.com:xwiki:https://store.xwiki.com/xwiki/rest/

# Properties to be passed to Java process with -D parameters using JAVA_OPTS 
properties:
 http.proxyHost: "proxy.mycompany.com"
 http.proxyPort: 7777
 https.proxyHost: "proxy.mycompany.com"
 https.proxyPort: 7777

As part of project XWiki for OpenDesk, it's possible to use System Property Updater extension, that's enable to change object properties or attachment references using helm chart properties. 

Example that changes logo to a new logo and some preferences on XWiki settings page: 


# Properties to be passed to Java process with -D parameters using JAVA_OPTS 
properties:
 "attachment:xwiki:[email protected]": "data:image/svg+xml;base64,AAA....=="
 "property:xwiki:XWiki.XWikiPreferences^XWiki.XWikiPreferences.colorTheme": "FlamingoThemes.Iceberg"
 "property:xwiki:XWiki.XWikiPreferences^XWiki.XWikiPreferences.timezone": "Europe/Berlin"
 "property:xwiki:XWiki.XWikiPreferences^XWiki.XWikiPreferences.default_language": "de"
 "property:xwiki:XWiki.XWikiPreferences^XWiki.XWikiPreferences.languages": "de"

Cluster

XWiki 1.2.0+ The cluster setup is in a beta/experimental version. It needs a version of XWiki 15.0+ XWiki.

To have a single XWiki data volume shared with all replicas, on this example we use NSF Ganesha server Provisioner

To discover all pods, it is required that the service account (is created automatically) used if cluster is enabled have pod permission to "get", "list" and "watch" inside the namespace that release was installed. It's recommended to use a dedicated namespace if you want to isolate some XWiki cluster from other workloads -n namespace --create-namespace

helm repo add nfs-ganesha-server-provisioner https://kubernetes-sigs.github.io/nfs-ganesha-server-and-external-provisioner/
helm install nfs-server-provisioner nfs-ganesha-server-provisioner/nfs-server-provisioner --set persistence.enabled=true 

Minimal values to enable cluster settings: 

image:
 tag: 15-mysql-tomcat

cluster:
 enabled: true
 replicas: 1

persistence:
 enabled: true
 storageClass: "nfs"
 accessModes:
    - ReadWriteMany

solr:
 enabled: true
 persistence:
   enabled: true

Monitoring

There is a preconfigured Glowroot on this chart that can be used for tracing, error log and reporting system. To enable, set XWiki 1.1.0+ glowroot.enabled to true

Follow one example of how to access service/dashboard using port forward:
kubectl port-forward xwiki-0 4000:4000

To see more details about other tools to monitoring XWiki, check Administrator Guide/Monitoring page. 

Logging

 
To change the logging settings of XWiki, it's possible to override the entire logback config file or simply add extra elements at the end of the configuration. To see more details about XWiki logging system, check Administrator Guide/Logging page. 

logback:
 enabled: true
 extraConfiguration: |
   <logger name="org.xwiki" level="debug"/>
   <logger name="com.xwiki" level="debug"/>
# Example to override all other configs elements, you can use: 
#  customConfiguration: |
#    <appender name="stdout" class="ch.qos.logback.core.ConsoleAppender">
#      <!-- Direct log messages to stdout -->
#      <Target>System.out</Target>
#      <encoder>
#        <pattern>%d [%t] %-5p %-30.30c{2} - %m %n</pattern>
#      </encoder>
#    </appender>

Backup

There are some tools that can manage the backups on k8s workloads. We can suggest Velero, as we already used on some internal clusters.

XWiki backup needs to be viewed to see all paths/components that needs to be saved.

Important volumes/paths to be considered:

  • xwiki volume, or /usr/local/xwiki/data path.
  • Database volume/Database dump. If PostgreSQL, there is some backup parameters that can be used.
  • If using an external solr: xwiki-solr-data volume, or another volume if using a custom external solr instance.

Sizing

Check XWiki Performance guide that contains more detailed options and settings related to sizes and performance. 

Recommended initial resources are equivalent to 1 CPU unit and 2G of memory. These values may vary depending on the XWiki use case.  

The default (chart) persistence size (XWiki Data) is low, it's recommended to give more space if usage will be with large pages/attachments. 

Events that needs to be monitored to sizing changes: 

  • In case of any “Out of Memory” error, proper increase on memory needs to be done. Important note that in some cases this error can be released with memory leeks or other issues. And the huge Java memory heap, requires more CPU unit to proper run without pressure on GC. 
  • Long processing time (Waiting long time for page to load/save), can be released with lack of CPU units or pressure on Memory. If memory is low and CPU is high, maybe only CPU unit increase is required. If memory usage is height, maybe there are height GC activities and sometimes more memory can help. 
  • Error save page, or add new attachments. Can be out of space problem, check Database avaliable size and XWiki data volume. 

 version 

NameDescriptionValue
solr.enabledDeploy a Solr instance. By default, use an internal instance"false"
solr.replicaCountNumber of replica1
solr.imageThe name of the Solr Docker image"gridexx/xwiki:solr8"
solr.extraEnvVarsXWiki 1.2.4+ Mapping extra ENV variables[]
solr.resources.limitsThe resources limits for Solr{}
solr.resources.requestsThe requested resources for Solr{}
solr.service.portNamePort name of service'solr-node'
solr.service.nameName of service'http'
solr.service.typeKubernetes service type'ClusterIP'
solr.service.externalPortExternal port8983
solr.service.internalPortInternal/Container port8983 
solr.persistence.enabledEnable Solr data persistence using PVC"true"
solr.persistence.existingClaimName of an existing PVC to use""
solr.persistence.storageClassPVC Storage Class for Solr data volume""
solr.persistence.accessModesPVC Access Mode for Solr data volume["ReadWriteOnce"]
solr.persistence.sizePVC Storage Request for Solr data volume500Mi
solr.persistence.annotationsAnnotations for the PVC{}
solr.persistence.labelsLabels for the PVC{}
solr.persistence.selectorSelector to match an existing Persistent Volume{}
solr.persistence.dataSourceCustom PVC data source{}

Examples

Custom Properties


# Custom configuration files for xwiki 
customConfigs:
 # Properties key that exists, replace in line is done with value here defined. 
 # If key don't exists, this key and value will be appended in that specific file. 
 # This files are list of key: value that are translated as key=value in that file.
 xwiki.cfg:
   xwiki.superadminpassword: "s3cr3t"
 # Extension repository should be writed as items of the array value extension.repositories
 xwiki.properties:
   extension.repositories:
      - "xwiki-extensions-xxx:maven:http://172.25.128.67:8081/repository/xwiki/"
      - store.xwiki.com:xwiki:https://store.xwiki.com/xwiki/rest/

# Properties to be passed to Java process with -D parameters using JAVA_OPTS 
properties:
 http.proxyHost: "proxy.mycompany.com"
 http.proxyPort: 7777
 https.proxyHost: "proxy.mycompany.com"
 https.proxyPort: 7777

As part of project XWiki for OpenDesk, it's possible to use System Property Updater extension, that's enable to change object properties or attachment references using helm chart properties. 

Example that changes logo to a new logo and some preferences on XWiki settings page: 


# Properties to be passed to Java process with -D parameters using JAVA_OPTS 
properties:
 "attachment:xwiki:[email protected]": "data:image/svg+xml;base64,AAA....=="
 "property:xwiki:XWiki.XWikiPreferences^XWiki.XWikiPreferences.colorTheme": "FlamingoThemes.Iceberg"
 "property:xwiki:XWiki.XWikiPreferences^XWiki.XWikiPreferences.timezone": "Europe/Berlin"
 "property:xwiki:XWiki.XWikiPreferences^XWiki.XWikiPreferences.default_language": "de"
 "property:xwiki:XWiki.XWikiPreferences^XWiki.XWikiPreferences.languages": "de"

Cluster

XWiki 1.2.0+ The cluster setup is in a beta/experimental version. It needs a version of XWiki 15.0+ XWiki.

To have a single XWiki data volume shared with all replicas, on this example we use NSF Ganesha server Provisioner

To discover all pods, it is required that the service account (is created automatically) used if cluster is enabled have pod permission to "get", "list" and "watch" inside the namespace that release was installed. It's recommended to use a dedicated namespace if you want to isolate some XWiki cluster from other workloads -n namespace --create-namespace

helm repo add nfs-ganesha-server-provisioner https://kubernetes-sigs.github.io/nfs-ganesha-server-and-external-provisioner/
helm install nfs-server-provisioner nfs-ganesha-server-provisioner/nfs-server-provisioner --set persistence.enabled=true 

Minimal values to enable cluster settings: 

image:
 tag: 15-mysql-tomcat

cluster:
 enabled: true
 replicas: 1

persistence:
 enabled: true
 storageClass: "nfs"
 accessModes:
    - ReadWriteMany

solr:
 enabled: true
 persistence:
   enabled: true

Monitoring

There is a preconfigured Glowroot on this chart that can be used for tracing, error log and reporting system. To enable, set XWiki 1.1.0+ glowroot.enabled to true

Follow one example of how to access service/dashboard using port forward:
kubectl port-forward xwiki-0 4000:4000

To see more details about other tools to monitoring XWiki, check Administrator Guide/Monitoring page. 

Logging

 
To change the logging settings of XWiki, it's possible to override the entire logback config file or simply add extra elements at the end of the configuration. To see more details about XWiki logging system, check Administrator Guide/Logging page. 

logback:
 enabled: true
 extraConfiguration: |
   <logger name="org.xwiki" level="debug"/>
   <logger name="com.xwiki" level="debug"/>
# Example to override all other configs elements, you can use: 
#  customConfiguration: |
#    <appender name="stdout" class="ch.qos.logback.core.ConsoleAppender">
#      <!-- Direct log messages to stdout -->
#      <Target>System.out</Target>
#      <encoder>
#        <pattern>%d [%t] %-5p %-30.30c{2} - %m %n</pattern>
#      </encoder>
#    </appender>

Backup

There are some tools that can manage the backups on k8s workloads. We can suggest Velero, as we already used on some internal clusters.

XWiki backup needs to be viewed to see all paths/components that needs to be saved.

Important volumes/paths to be considered:

  • xwiki volume, or /usr/local/xwiki/data path.
  • Database volume/Database dump. If PostgreSQL, there is some backup parameters that can be used.
  • If using an external solr: xwiki-solr-data volume, or another volume if using a custom external solr instance.

Sizing

Check XWiki Performance guide that contains more detailed options and settings related to sizes and performance. 

Recommended initial resources are equivalent to 1 CPU unit and 2G of memory. These values may vary depending on the XWiki use case.  

The default (chart) persistence size (XWiki Data) is low, it's recommended to give more space if usage will be with large pages/attachments. 

Events that needs to be monitored to sizing changes: 

  • In case of any “Out of Memory” error, proper increase on memory needs to be done. Important note that in some cases this error can be released with memory leeks or other issues. And the huge Java memory heap, requires more CPU unit to proper run without pressure on GC. 
  • Long processing time (Waiting long time for page to load/save), can be released with lack of CPU units or pressure on Memory. If memory is low and CPU is high, maybe only CPU unit increase is required. If memory usage is height, maybe there are height GC activities and sometimes more memory can help. 
  • Error save page, or add new attachments. Can be out of space problem, check Database avaliable size and XWiki data volume. 

 version 

NameDescriptionValue
solr.enabledDeploy a Solr instance. By default, use an internal instance"false"
solr.replicaCountNumber of replica1
solr.imageThe name of the Solr Docker image"gridexx/xwiki:solr8"
solr.extraEnvVarsXWiki 1.2.4+ Mapping extra ENV variables[]
solr.resources.limitsThe resources limits for Solr{}
solr.resources.requestsThe requested resources for Solr{}
solr.service.portNamePort name of service'solr-node'
solr.service.nameName of service'http'
solr.service.typeKubernetes service type'ClusterIP'
solr.service.externalPortExternal port8983
solr.service.internalPortInternal/Container port8983 
solr.persistence.enabledEnable Solr data persistence using PVC"true"
solr.persistence.existingClaimName of an existing PVC to use""
solr.persistence.storageClassPVC Storage Class for Solr data volume""
solr.persistence.accessModesPVC Access Mode for Solr data volume["ReadWriteOnce"]
solr.persistence.sizePVC Storage Request for Solr data volume500Mi
solr.persistence.annotationsAnnotations for the PVC{}
solr.persistence.labelsLabels for the PVC{}
solr.persistence.selectorSelector to match an existing Persistent Volume{}
solr.persistence.dataSourceCustom PVC data source{}

Examples

Custom Properties


# Custom configuration files for xwiki 
customConfigs:
 # Properties key that exists, replace in line is done with value here defined. 
 # If key don't exists, this key and value will be appended in that specific file. 
 # This files are list of key: value that are translated as key=value in that file.
 xwiki.cfg:
   xwiki.superadminpassword: "s3cr3t"
 # Extension repository should be writed as items of the array value extension.repositories
 xwiki.properties:
   extension.repositories:
      - "xwiki-extensions-xxx:maven:http://172.25.128.67:8081/repository/xwiki/"
      - store.xwiki.com:xwiki:https://store.xwiki.com/xwiki/rest/

# Properties to be passed to Java process with -D parameters using JAVA_OPTS 
properties:
 http.proxyHost: "proxy.mycompany.com"
 http.proxyPort: 7777
 https.proxyHost: "proxy.mycompany.com"
 https.proxyPort: 7777

As part of project XWiki for OpenDesk, it's possible to use System Property Updater extension, that's enable to change object properties or attachment references using helm chart properties. 

Example that changes logo to a new logo and some preferences on XWiki settings page: 


# Properties to be passed to Java process with -D parameters using JAVA_OPTS 
properties:
 "attachment:xwiki:[email protected]": "data:image/svg+xml;base64,AAA....=="
 "property:xwiki:XWiki.XWikiPreferences^XWiki.XWikiPreferences.colorTheme": "FlamingoThemes.Iceberg"
 "property:xwiki:XWiki.XWikiPreferences^XWiki.XWikiPreferences.timezone": "Europe/Berlin"
 "property:xwiki:XWiki.XWikiPreferences^XWiki.XWikiPreferences.default_language": "de"
 "property:xwiki:XWiki.XWikiPreferences^XWiki.XWikiPreferences.languages": "de"

Cluster

XWiki 1.2.0+ The cluster setup is in a beta/experimental version. It needs a version of XWiki 15.0+ XWiki.

To have a single XWiki data volume shared with all replicas, on this example we use NSF Ganesha server Provisioner

To discover all pods, it is required that the service account (is created automatically) used if cluster is enabled have pod permission to "get", "list" and "watch" inside the namespace that release was installed. It's recommended to use a dedicated namespace if you want to isolate some XWiki cluster from other workloads -n namespace --create-namespace

helm repo add nfs-ganesha-server-provisioner https://kubernetes-sigs.github.io/nfs-ganesha-server-and-external-provisioner/
helm install nfs-server-provisioner nfs-ganesha-server-provisioner/nfs-server-provisioner --set persistence.enabled=true 

Minimal values to enable cluster settings: 

image:
 tag: 15-mysql-tomcat

cluster:
 enabled: true
 replicas: 1

persistence:
 enabled: true
 storageClass: "nfs"
 accessModes:
    - ReadWriteMany

solr:
 enabled: true
 persistence:
   enabled: true

Monitoring

There is a preconfigured Glowroot on this chart that can be used for tracing, error log and reporting system. To enable, set XWiki 1.1.0+ glowroot.enabled to true

Follow one example of how to access service/dashboard using port forward:
kubectl port-forward xwiki-0 4000:4000

To see more details about other tools to monitoring XWiki, check Administrator Guide/Monitoring page. 

Logging

 
To change the logging settings of XWiki, it's possible to override the entire logback config file or simply add extra elements at the end of the configuration. To see more details about XWiki logging system, check Administrator Guide/Logging page. 

logback:
 enabled: true
 extraConfiguration: |
   <logger name="org.xwiki" level="debug"/>
   <logger name="com.xwiki" level="debug"/>
# Example to override all other configs elements, you can use: 
#  customConfiguration: |
#    <appender name="stdout" class="ch.qos.logback.core.ConsoleAppender">
#      <!-- Direct log messages to stdout -->
#      <Target>System.out</Target>
#      <encoder>
#        <pattern>%d [%t] %-5p %-30.30c{2} - %m %n</pattern>
#      </encoder>
#    </appender>

Backup

There are some tools that can manage the backups on k8s workloads. We can suggest Velero, as we already used on some internal clusters.

XWiki backup needs to be viewed to see all paths/components that needs to be saved.

Important volumes/paths to be considered:

  • xwiki volume, or /usr/local/xwiki/data path.
  • Database volume/Database dump. If PostgreSQL, there is some backup parameters that can be used.
  • If using an external solr: xwiki-solr-data volume, or another volume if using a custom external solr instance.

Sizing

Check XWiki Performance guide that contains more detailed options and settings related to sizes and performance. 

Recommended initial resources are equivalent to 1 CPU unit and 2G of memory. These values may vary depending on the XWiki use case.  

The default (chart) persistence size (XWiki Data) is low, it's recommended to give more space if usage will be with large pages/attachments. 

Events that needs to be monitored to sizing changes: 

  • In case of any “Out of Memory” error, proper increase on memory needs to be done. Important note that in some cases this error can be released with memory leeks or other issues. And the huge Java memory heap, requires more CPU unit to proper run without pressure on GC. 
  • Long processing time (Waiting long time for page to load/save), can be released with lack of CPU units or pressure on Memory. If memory is low and CPU is high, maybe only CPU unit increase is required. If memory usage is height, maybe there are height GC activities and sometimes more memory can help. 
  • Error save page, or add new attachments. Can be out of space problem, check Database avaliable size and XWiki data volume. 

 version 

NameDescriptionValue
solr.enabledDeploy a Solr instance. By default, use an internal instance"false"
solr.replicaCountNumber of replica1
solr.imageThe name of the Solr Docker image"gridexx/xwiki:solr8"
solr.extraEnvVarsXWiki 1.2.4+ Mapping extra ENV variables[]
solr.resources.limitsThe resources limits for Solr{}
solr.resources.requestsThe requested resources for Solr{}
solr.service.portNamePort name of service'solr-node'
solr.service.nameName of service'http'
solr.service.typeKubernetes service type'ClusterIP'
solr.service.externalPortExternal port8983
solr.service.internalPortInternal/Container port8983 
solr.persistence.enabledEnable Solr data persistence using PVC"true"
solr.persistence.existingClaimName of an existing PVC to use""
solr.persistence.storageClassPVC Storage Class for Solr data volume""
solr.persistence.accessModesPVC Access Mode for Solr data volume["ReadWriteOnce"]
solr.persistence.sizePVC Storage Request for Solr data volume500Mi
solr.persistence.annotationsAnnotations for the PVC{}
solr.persistence.labelsLabels for the PVC{}
solr.persistence.selectorSelector to match an existing Persistent Volume{}
solr.persistence.dataSourceCustom PVC data source{}

Examples

Custom Properties


# Custom configuration files for xwiki 
customConfigs:
 # Properties key that exists, replace in line is done with value here defined. 
 # If key don't exists, this key and value will be appended in that specific file. 
 # This files are list of key: value that are translated as key=value in that file.
 xwiki.cfg:
   xwiki.superadminpassword: "s3cr3t"
 # Extension repository should be writed as items of the array value extension.repositories
 xwiki.properties:
   extension.repositories:
      - "xwiki-extensions-xxx:maven:http://172.25.128.67:8081/repository/xwiki/"
      - store.xwiki.com:xwiki:https://store.xwiki.com/xwiki/rest/

# Properties to be passed to Java process with -D parameters using JAVA_OPTS 
properties:
 http.proxyHost: "proxy.mycompany.com"
 http.proxyPort: 7777
 https.proxyHost: "proxy.mycompany.com"
 https.proxyPort: 7777

As part of project XWiki for OpenDesk, it's possible to use System Property Updater extension, that's enable to change object properties or attachment references using helm chart properties. 

Example that changes logo to a new logo and some preferences on XWiki settings page: 


# Properties to be passed to Java process with -D parameters using JAVA_OPTS 
properties:
 "attachment:xwiki:[email protected]": "data:image/svg+xml;base64,AAA....=="
 "property:xwiki:XWiki.XWikiPreferences^XWiki.XWikiPreferences.colorTheme": "FlamingoThemes.Iceberg"
 "property:xwiki:XWiki.XWikiPreferences^XWiki.XWikiPreferences.timezone": "Europe/Berlin"
 "property:xwiki:XWiki.XWikiPreferences^XWiki.XWikiPreferences.default_language": "de"
 "property:xwiki:XWiki.XWikiPreferences^XWiki.XWikiPreferences.languages": "de"

Cluster

XWiki 1.2.0+ The cluster setup is in a beta/experimental version. It needs a version of XWiki 15.0+ XWiki.

To have a single XWiki data volume shared with all replicas, on this example we use NSF Ganesha server Provisioner

To discover all pods, it is required that the service account (is created automatically) used if cluster is enabled have pod permission to "get", "list" and "watch" inside the namespace that release was installed. It's recommended to use a dedicated namespace if you want to isolate some XWiki cluster from other workloads -n namespace --create-namespace

helm repo add nfs-ganesha-server-provisioner https://kubernetes-sigs.github.io/nfs-ganesha-server-and-external-provisioner/
helm install nfs-server-provisioner nfs-ganesha-server-provisioner/nfs-server-provisioner --set persistence.enabled=true 

Minimal values to enable cluster settings: 

image:
 tag: 15-mysql-tomcat

cluster:
 enabled: true
 replicas: 1

persistence:
 enabled: true
 storageClass: "nfs"
 accessModes:
    - ReadWriteMany

solr:
 enabled: true
 persistence:
   enabled: true

Monitoring

There is a preconfigured Glowroot on this chart that can be used for tracing, error log and reporting system. To enable, set XWiki 1.1.0+ glowroot.enabled to true

Follow one example of how to access service/dashboard using port forward:
kubectl port-forward xwiki-0 4000:4000

To see more details about other tools to monitoring XWiki, check Administrator Guide/Monitoring page. 

Logging

 
To change the logging settings of XWiki, it's possible to override the entire logback config file or simply add extra elements at the end of the configuration. To see more details about XWiki logging system, check Administrator Guide/Logging page. 

logback:
 enabled: true
 extraConfiguration: |
   <logger name="org.xwiki" level="debug"/>
   <logger name="com.xwiki" level="debug"/>
# Example to override all other configs elements, you can use: 
#  customConfiguration: |
#    <appender name="stdout" class="ch.qos.logback.core.ConsoleAppender">
#      <!-- Direct log messages to stdout -->
#      <Target>System.out</Target>
#      <encoder>
#        <pattern>%d [%t] %-5p %-30.30c{2} - %m %n</pattern>
#      </encoder>
#    </appender>

Backup

There are some tools that can manage the backups on k8s workloads. We can suggest Velero, as we already used on some internal clusters.

XWiki backup needs to be viewed to see all paths/components that needs to be saved.

Important volumes/paths to be considered:

  • xwiki volume, or /usr/local/xwiki/data path.
  • Database volume/Database dump. If PostgreSQL, there is some backup parameters that can be used.
  • If using an external solr: xwiki-solr-data volume, or another volume if using a custom external solr instance.

Sizing

Check XWiki Performance guide that contains more detailed options and settings related to sizes and performance. 

Recommended initial resources are equivalent to 1 CPU unit and 2G of memory. These values may vary depending on the XWiki use case.  

The default (chart) persistence size (XWiki Data) is low, it's recommended to give more space if usage will be with large pages/attachments. 

Events that needs to be monitored to sizing changes: 

  • In case of any “Out of Memory” error, proper increase on memory needs to be done. Important note that in some cases this error can be released with memory leeks or other issues. And the huge Java memory heap, requires more CPU unit to proper run without pressure on GC. 
  • Long processing time (Waiting long time for page to load/save), can be released with lack of CPU units or pressure on Memory. If memory is low and CPU is high, maybe only CPU unit increase is required. If memory usage is height, maybe there are height GC activities and sometimes more memory can help. 
  • Error save page, or add new attachments. Can be out of space problem, check Database avaliable size and XWiki data volume. 

 version 

NameDescriptionValue
solr.enabledDeploy a Solr instance. By default, use an internal instance"false"
solr.replicaCountNumber of replica1
solr.imageThe name of the Solr Docker image"gridexx/xwiki:solr8"
solr.extraEnvVarsXWiki 1.2.4+ Mapping extra ENV variables[]
solr.resources.limitsThe resources limits for Solr{}
solr.resources.requestsThe requested resources for Solr{}
solr.service.portNamePort name of service'solr-node'
solr.service.nameName of service'http'
solr.service.typeKubernetes service type'ClusterIP'
solr.service.externalPortExternal port8983
solr.service.internalPortInternal/Container port8983 
solr.persistence.enabledEnable Solr data persistence using PVC"true"
solr.persistence.existingClaimName of an existing PVC to use""
solr.persistence.storageClassPVC Storage Class for Solr data volume""
solr.persistence.accessModesPVC Access Mode for Solr data volume["ReadWriteOnce"]
solr.persistence.sizePVC Storage Request for Solr data volume500Mi
solr.persistence.annotationsAnnotations for the PVC{}
solr.persistence.labelsLabels for the PVC{}
solr.persistence.selectorSelector to match an existing Persistent Volume{}
solr.persistence.dataSourceCustom PVC data source{}

Examples

Custom Properties


# Custom configuration files for xwiki 
customConfigs:
 # Properties key that exists, replace in line is done with value here defined. 
 # If key don't exists, this key and value will be appended in that specific file. 
 # This files are list of key: value that are translated as key=value in that file.
 xwiki.cfg:
   xwiki.superadminpassword: "s3cr3t"
 # Extension repository should be writed as items of the array value extension.repositories
 xwiki.properties:
   extension.repositories:
      - "xwiki-extensions-xxx:maven:http://172.25.128.67:8081/repository/xwiki/"
      - store.xwiki.com:xwiki:https://store.xwiki.com/xwiki/rest/

# Properties to be passed to Java process with -D parameters using JAVA_OPTS 
properties:
 http.proxyHost: "proxy.mycompany.com"
 http.proxyPort: 7777
 https.proxyHost: "proxy.mycompany.com"
 https.proxyPort: 7777

As part of project XWiki for OpenDesk, it's possible to use System Property Updater extension, that's enable to change object properties or attachment references using helm chart properties. 

Example that changes logo to a new logo and some preferences on XWiki settings page: 


# Properties to be passed to Java process with -D parameters using JAVA_OPTS 
properties:
 "attachment:xwiki:[email protected]": "data:image/svg+xml;base64,AAA....=="
 "property:xwiki:XWiki.XWikiPreferences^XWiki.XWikiPreferences.colorTheme": "FlamingoThemes.Iceberg"
 "property:xwiki:XWiki.XWikiPreferences^XWiki.XWikiPreferences.timezone": "Europe/Berlin"
 "property:xwiki:XWiki.XWikiPreferences^XWiki.XWikiPreferences.default_language": "de"
 "property:xwiki:XWiki.XWikiPreferences^XWiki.XWikiPreferences.languages": "de"

Cluster

XWiki 1.2.0+ The cluster setup is in a beta/experimental version. It needs a version of XWiki 15.0+ XWiki.

To have a single XWiki data volume shared with all replicas, on this example we use NSF Ganesha server Provisioner

To discover all pods, it is required that the service account (is created automatically) used if cluster is enabled have pod permission to "get", "list" and "watch" inside the namespace that release was installed. It's recommended to use a dedicated namespace if you want to isolate some XWiki cluster from other workloads -n namespace --create-namespace

helm repo add nfs-ganesha-server-provisioner https://kubernetes-sigs.github.io/nfs-ganesha-server-and-external-provisioner/
helm install nfs-server-provisioner nfs-ganesha-server-provisioner/nfs-server-provisioner --set persistence.enabled=true 

Minimal values to enable cluster settings: 

image:
 tag: 15-mysql-tomcat

cluster:
 enabled: true
 replicas: 1

persistence:
 enabled: true
 storageClass: "nfs"
 accessModes:
    - ReadWriteMany

solr:
 enabled: true
 persistence:
   enabled: true

Monitoring

There is a preconfigured Glowroot on this chart that can be used for tracing, error log and reporting system. To enable, set XWiki 1.1.0+ glowroot.enabled to true

Follow one example of how to access service/dashboard using port forward:
kubectl port-forward xwiki-0 4000:4000

To see more details about other tools to monitoring XWiki, check Administrator Guide/Monitoring page. 

Logging

 
To change the logging settings of XWiki, it's possible to override the entire logback config file or simply add extra elements at the end of the configuration. To see more details about XWiki logging system, check Administrator Guide/Logging page. 

logback:
 enabled: true
 extraConfiguration: |
   <logger name="org.xwiki" level="debug"/>
   <logger name="com.xwiki" level="debug"/>
# Example to override all other configs elements, you can use: 
#  customConfiguration: |
#    <appender name="stdout" class="ch.qos.logback.core.ConsoleAppender">
#      <!-- Direct log messages to stdout -->
#      <Target>System.out</Target>
#      <encoder>
#        <pattern>%d [%t] %-5p %-30.30c{2} - %m %n</pattern>
#      </encoder>
#    </appender>

Backup

There are some tools that can manage the backups on k8s workloads. We can suggest Velero, as we already used on some internal clusters.

XWiki backup needs to be viewed to see all paths/components that needs to be saved.

Important volumes/paths to be considered:

  • xwiki volume, or /usr/local/xwiki/data path.
  • Database volume/Database dump. If PostgreSQL, there is some backup parameters that can be used.
  • If using an external solr: xwiki-solr-data volume, or another volume if using a custom external solr instance.

Sizing

Check XWiki Performance guide that contains more detailed options and settings related to sizes and performance. 

Recommended initial resources are equivalent to 1 CPU unit and 2G of memory. These values may vary depending on the XWiki use case.  

The default (chart) persistence size (XWiki Data) is low, it's recommended to give more space if usage will be with large pages/attachments. 

Events that needs to be monitored to sizing changes: 

  • In case of any “Out of Memory” error, proper increase on memory needs to be done. Important note that in some cases this error can be released with memory leeks or other issues. And the huge Java memory heap, requires more CPU unit to proper run without pressure on GC. 
  • Long processing time (Waiting long time for page to load/save), can be released with lack of CPU units or pressure on Memory. If memory is low and CPU is high, maybe only CPU unit increase is required. If memory usage is height, maybe there are height GC activities and sometimes more memory can help. 
  • Error save page, or add new attachments. Can be out of space problem, check Database avaliable size and XWiki data volume. 

 version 

NameDescriptionValue
solr.enabledDeploy a Solr instance. By default, use an internal instance"false"
solr.replicaCountNumber of replica1
solr.imageThe name of the Solr Docker image"gridexx/xwiki:solr8"
solr.extraEnvVarsXWiki 1.2.4+ Mapping extra ENV variables[]
solr.resources.limitsThe resources limits for Solr{}
solr.resources.requestsThe requested resources for Solr{}
solr.service.portNamePort name of service'solr-node'
solr.service.nameName of service'http'
solr.service.typeKubernetes service type'ClusterIP'
solr.service.externalPortExternal port8983
solr.service.internalPortInternal/Container port8983 
solr.persistence.enabledEnable Solr data persistence using PVC"true"
solr.persistence.existingClaimName of an existing PVC to use""
solr.persistence.storageClassPVC Storage Class for Solr data volume""
solr.persistence.accessModesPVC Access Mode for Solr data volume["ReadWriteOnce"]
solr.persistence.sizePVC Storage Request for Solr data volume500Mi
solr.persistence.annotationsAnnotations for the PVC{}
solr.persistence.labelsLabels for the PVC{}
solr.persistence.selectorSelector to match an existing Persistent Volume{}
solr.persistence.dataSourceCustom PVC data source{}

Examples

Custom Properties


# Custom configuration files for xwiki 
customConfigs:
 # Properties key that exists, replace in line is done with value here defined. 
 # If key don't exists, this key and value will be appended in that specific file. 
 # This files are list of key: value that are translated as key=value in that file.
 xwiki.cfg:
   xwiki.superadminpassword: "s3cr3t"
 # Extension repository should be writed as items of the array value extension.repositories
 xwiki.properties:
   extension.repositories:
      - "xwiki-extensions-xxx:maven:http://172.25.128.67:8081/repository/xwiki/"
      - store.xwiki.com:xwiki:https://store.xwiki.com/xwiki/rest/

# Properties to be passed to Java process with -D parameters using JAVA_OPTS 
properties:
 http.proxyHost: "proxy.mycompany.com"
 http.proxyPort: 7777
 https.proxyHost: "proxy.mycompany.com"
 https.proxyPort: 7777

As part of project XWiki for OpenDesk, it's possible to use System Property Updater extension, that's enable to change object properties or attachment references using helm chart properties. 

Example that changes logo to a new logo and some preferences on XWiki settings page: 


# Properties to be passed to Java process with -D parameters using JAVA_OPTS 
properties:
 "attachment:xwiki:[email protected]": "data:image/svg+xml;base64,AAA....=="
 "property:xwiki:XWiki.XWikiPreferences^XWiki.XWikiPreferences.colorTheme": "FlamingoThemes.Iceberg"
 "property:xwiki:XWiki.XWikiPreferences^XWiki.XWikiPreferences.timezone": "Europe/Berlin"
 "property:xwiki:XWiki.XWikiPreferences^XWiki.XWikiPreferences.default_language": "de"
 "property:xwiki:XWiki.XWikiPreferences^XWiki.XWikiPreferences.languages": "de"

Cluster

XWiki 1.2.0+ The cluster setup is in a beta/experimental version. It needs a version of XWiki 15.0+ XWiki.

To have a single XWiki data volume shared with all replicas, on this example we use NSF Ganesha server Provisioner

To discover all pods, it is required that the service account (is created automatically) used if cluster is enabled have pod permission to "get", "list" and "watch" inside the namespace that release was installed. It's recommended to use a dedicated namespace if you want to isolate some XWiki cluster from other workloads -n namespace --create-namespace

helm repo add nfs-ganesha-server-provisioner https://kubernetes-sigs.github.io/nfs-ganesha-server-and-external-provisioner/
helm install nfs-server-provisioner nfs-ganesha-server-provisioner/nfs-server-provisioner --set persistence.enabled=true 

Minimal values to enable cluster settings: 

image:
 tag: 15-mysql-tomcat

cluster:
 enabled: true
 replicas: 1

persistence:
 enabled: true
 storageClass: "nfs"
 accessModes:
    - ReadWriteMany

solr:
 enabled: true
 persistence:
   enabled: true

Monitoring

There is a preconfigured Glowroot on this chart that can be used for tracing, error log and reporting system. To enable, set XWiki 1.1.0+ glowroot.enabled to true

Follow one example of how to access service/dashboard using port forward:
kubectl port-forward xwiki-0 4000:4000

To see more details about other tools to monitoring XWiki, check Administrator Guide/Monitoring page. 

Logging

 
To change the logging settings of XWiki, it's possible to override the entire logback config file or simply add extra elements at the end of the configuration. To see more details about XWiki logging system, check Administrator Guide/Logging page. 

logback:
 enabled: true
 extraConfiguration: |
   <logger name="org.xwiki" level="debug"/>
   <logger name="com.xwiki" level="debug"/>
# Example to override all other configs elements, you can use: 
#  customConfiguration: |
#    <appender name="stdout" class="ch.qos.logback.core.ConsoleAppender">
#      <!-- Direct log messages to stdout -->
#      <Target>System.out</Target>
#      <encoder>
#        <pattern>%d [%t] %-5p %-30.30c{2} - %m %n</pattern>
#      </encoder>
#    </appender>

Backup

There are some tools that can manage the backups on k8s workloads. We can suggest Velero, as we already used on some internal clusters.

XWiki backup needs to be viewed to see all paths/components that needs to be saved.

Important volumes/paths to be considered:

  • xwiki volume, or /usr/local/xwiki/data path.
  • Database volume/Database dump. If PostgreSQL, there is some backup parameters that can be used.
  • If using an external solr: xwiki-solr-data volume, or another volume if using a custom external solr instance.

Sizing

Check XWiki Performance guide that contains more detailed options and settings related to sizes and performance. 

Recommended initial resources are equivalent to 1 CPU unit and 2G of memory. These values may vary depending on the XWiki use case.  

The default (chart) persistence size (XWiki Data) is low, it's recommended to give more space if usage will be with large pages/attachments. 

Events that needs to be monitored to sizing changes: 

  • In case of any “Out of Memory” error, proper increase on memory needs to be done. Important note that in some cases this error can be released with memory leeks or other issues. And the huge Java memory heap, requires more CPU unit to proper run without pressure on GC. 
  • Long processing time (Waiting long time for page to load/save), can be released with lack of CPU units or pressure on Memory. If memory is low and CPU is high, maybe only CPU unit increase is required. If memory usage is height, maybe there are height GC activities and sometimes more memory can help. 
  • Error save page, or add new attachments. Can be out of space problem, check Database avaliable size and XWiki data volume. 

 version 

NameDescriptionValue
solr.enabledDeploy a Solr instance. By default, use an internal instance"false"
solr.replicaCountNumber of replica1
solr.imageThe name of the Solr Docker image"gridexx/xwiki:solr8"
solr.extraEnvVarsXWiki 1.2.4+ Mapping extra ENV variables[]
solr.resources.limitsThe resources limits for Solr{}
solr.resources.requestsThe requested resources for Solr{}
solr.service.portNamePort name of service'solr-node'
solr.service.nameName of service'http'
solr.service.typeKubernetes service type'ClusterIP'
solr.service.externalPortExternal port8983
solr.service.internalPortInternal/Container port8983 
solr.persistence.enabledEnable Solr data persistence using PVC"true"
solr.persistence.existingClaimName of an existing PVC to use""
solr.persistence.storageClassPVC Storage Class for Solr data volume""
solr.persistence.accessModesPVC Access Mode for Solr data volume["ReadWriteOnce"]
solr.persistence.sizePVC Storage Request for Solr data volume500Mi
solr.persistence.annotationsAnnotations for the PVC{}
solr.persistence.labelsLabels for the PVC{}
solr.persistence.selectorSelector to match an existing Persistent Volume{}
solr.persistence.dataSourceCustom PVC data source{}

Examples

Custom Properties


# Custom configuration files for xwiki 
customConfigs:
 # Properties key that exists, replace in line is done with value here defined. 
 # If key don't exists, this key and value will be appended in that specific file. 
 # This files are list of key: value that are translated as key=value in that file.
 xwiki.cfg:
   xwiki.superadminpassword: "s3cr3t"
 # Extension repository should be writed as items of the array value extension.repositories
 xwiki.properties:
   extension.repositories:
      - "xwiki-extensions-xxx:maven:http://172.25.128.67:8081/repository/xwiki/"
      - store.xwiki.com:xwiki:https://store.xwiki.com/xwiki/rest/

# Properties to be passed to Java process with -D parameters using JAVA_OPTS 
properties:
 http.proxyHost: "proxy.mycompany.com"
 http.proxyPort: 7777
 https.proxyHost: "proxy.mycompany.com"
 https.proxyPort: 7777

As part of project XWiki for OpenDesk, it's possible to use System Property Updater extension, that's enable to change object properties or attachment references using helm chart properties. 

Example that changes logo to a new logo and some preferences on XWiki settings page: 


# Properties to be passed to Java process with -D parameters using JAVA_OPTS 
properties:
 "attachment:xwiki:[email protected]": "data:image/svg+xml;base64,AAA....=="
 "property:xwiki:XWiki.XWikiPreferences^XWiki.XWikiPreferences.colorTheme": "FlamingoThemes.Iceberg"
 "property:xwiki:XWiki.XWikiPreferences^XWiki.XWikiPreferences.timezone": "Europe/Berlin"
 "property:xwiki:XWiki.XWikiPreferences^XWiki.XWikiPreferences.default_language": "de"
 "property:xwiki:XWiki.XWikiPreferences^XWiki.XWikiPreferences.languages": "de"

Cluster

XWiki 1.2.0+ The cluster setup is in a beta/experimental version. It needs a version of XWiki 15.0+ XWiki.

To have a single XWiki data volume shared with all replicas, on this example we use NSF Ganesha server Provisioner

To discover all pods, it is required that the service account (is created automatically) used if cluster is enabled have pod permission to "get", "list" and "watch" inside the namespace that release was installed. It's recommended to use a dedicated namespace if you want to isolate some XWiki cluster from other workloads -n namespace --create-namespace

helm repo add nfs-ganesha-server-provisioner https://kubernetes-sigs.github.io/nfs-ganesha-server-and-external-provisioner/
helm install nfs-server-provisioner nfs-ganesha-server-provisioner/nfs-server-provisioner --set persistence.enabled=true 

Minimal values to enable cluster settings: 

image:
 tag: 15-mysql-tomcat

cluster:
 enabled: true
 replicas: 1

persistence:
 enabled: true
 storageClass: "nfs"
 accessModes:
    - ReadWriteMany

solr:
 enabled: true
 persistence:
   enabled: true

Monitoring

There is a preconfigured Glowroot on this chart that can be used for tracing, error log and reporting system. To enable, set XWiki 1.1.0+ glowroot.enabled to true

Follow one example of how to access service/dashboard using port forward:
kubectl port-forward xwiki-0 4000:4000

To see more details about other tools to monitoring XWiki, check Administrator Guide/Monitoring page. 

Logging

 
To change the logging settings of XWiki, it's possible to override the entire logback config file or simply add extra elements at the end of the configuration. To see more details about XWiki logging system, check Administrator Guide/Logging page. 

logback:
 enabled: true
 extraConfiguration: |
   <logger name="org.xwiki" level="debug"/>
   <logger name="com.xwiki" level="debug"/>
# Example to override all other configs elements, you can use: 
#  customConfiguration: |
#    <appender name="stdout" class="ch.qos.logback.core.ConsoleAppender">
#      <!-- Direct log messages to stdout -->
#      <Target>System.out</Target>
#      <encoder>
#        <pattern>%d [%t] %-5p %-30.30c{2} - %m %n</pattern>
#      </encoder>
#    </appender>

Backup

There are some tools that can manage the backups on k8s workloads. We can suggest Velero, as we already used on some internal clusters.

XWiki backup needs to be viewed to see all paths/components that needs to be saved.

Important volumes/paths to be considered:

  • xwiki volume, or /usr/local/xwiki/data path.
  • Database volume/Database dump. If PostgreSQL, there is some backup parameters that can be used.
  • If using an external solr: xwiki-solr-data volume, or another volume if using a custom external solr instance.

Sizing

Check XWiki Performance guide that contains more detailed options and settings related to sizes and performance. 

Recommended initial resources are equivalent to 1 CPU unit and 2G of memory. These values may vary depending on the XWiki use case.  

The default (chart) persistence size (XWiki Data) is low, it's recommended to give more space if usage will be with large pages/attachments. 

Events that needs to be monitored to sizing changes: 

  • In case of any “Out of Memory” error, proper increase on memory needs to be done. Important note that in some cases this error can be released with memory leeks or other issues. And the huge Java memory heap, requires more CPU unit to proper run without pressure on GC. 
  • Long processing time (Waiting long time for page to load/save), can be released with lack of CPU units or pressure on Memory. If memory is low and CPU is high, maybe only CPU unit increase is required. If memory usage is height, maybe there are height GC activities and sometimes more memory can help. 
  • Error save page, or add new attachments. Can be out of space problem, check Database avaliable size and XWiki data volume. 

 version 

NameDescriptionValue
solr.enabledDeploy a Solr instance. By default, use an internal instance"false"
solr.replicaCountNumber of replica1
solr.imageThe name of the Solr Docker image"gridexx/xwiki:solr8"
solr.extraEnvVarsXWiki 1.2.4+ Mapping extra ENV variables[]
solr.resources.limitsThe resources limits for Solr{}
solr.resources.requestsThe requested resources for Solr{}
solr.service.portNamePort name of service'solr-node'
solr.service.nameName of service'http'
solr.service.typeKubernetes service type'ClusterIP'
solr.service.externalPortExternal port8983
solr.service.internalPortInternal/Container port8983 
solr.persistence.enabledEnable Solr data persistence using PVC"true"
solr.persistence.existingClaimName of an existing PVC to use""
solr.persistence.storageClassPVC Storage Class for Solr data volume""
solr.persistence.accessModesPVC Access Mode for Solr data volume["ReadWriteOnce"]
solr.persistence.sizePVC Storage Request for Solr data volume500Mi
solr.persistence.annotationsAnnotations for the PVC{}
solr.persistence.labelsLabels for the PVC{}
solr.persistence.selectorSelector to match an existing Persistent Volume{}
solr.persistence.dataSourceCustom PVC data source{}

Examples

Custom Properties


# Custom configuration files for xwiki 
customConfigs:
 # Properties key that exists, replace in line is done with value here defined. 
 # If key don't exists, this key and value will be appended in that specific file. 
 # This files are list of key: value that are translated as key=value in that file.
 xwiki.cfg:
   xwiki.superadminpassword: "s3cr3t"
 # Extension repository should be writed as items of the array value extension.repositories
 xwiki.properties:
   extension.repositories:
      - "xwiki-extensions-xxx:maven:http://172.25.128.67:8081/repository/xwiki/"
      - store.xwiki.com:xwiki:https://store.xwiki.com/xwiki/rest/

# Properties to be passed to Java process with -D parameters using JAVA_OPTS 
properties:
 http.proxyHost: "proxy.mycompany.com"
 http.proxyPort: 7777
 https.proxyHost: "proxy.mycompany.com"
 https.proxyPort: 7777

As part of project XWiki for OpenDesk, it's possible to use System Property Updater extension, that's enable to change object properties or attachment references using helm chart properties. 

Example that changes logo to a new logo and some preferences on XWiki settings page: 


# Properties to be passed to Java process with -D parameters using JAVA_OPTS 
properties:
 "attachment:xwiki:[email protected]": "data:image/svg+xml;base64,AAA....=="
 "property:xwiki:XWiki.XWikiPreferences^XWiki.XWikiPreferences.colorTheme": "FlamingoThemes.Iceberg"
 "property:xwiki:XWiki.XWikiPreferences^XWiki.XWikiPreferences.timezone": "Europe/Berlin"
 "property:xwiki:XWiki.XWikiPreferences^XWiki.XWikiPreferences.default_language": "de"
 "property:xwiki:XWiki.XWikiPreferences^XWiki.XWikiPreferences.languages": "de"

Cluster

XWiki 1.2.0+ The cluster setup is in a beta/experimental version. It needs a version of XWiki 15.0+ XWiki.

To have a single XWiki data volume shared with all replicas, on this example we use NSF Ganesha server Provisioner

To discover all pods, it is required that the service account (is created automatically) used if cluster is enabled have pod permission to "get", "list" and "watch" inside the namespace that release was installed. It's recommended to use a dedicated namespace if you want to isolate some XWiki cluster from other workloads -n namespace --create-namespace

helm repo add nfs-ganesha-server-provisioner https://kubernetes-sigs.github.io/nfs-ganesha-server-and-external-provisioner/
helm install nfs-server-provisioner nfs-ganesha-server-provisioner/nfs-server-provisioner --set persistence.enabled=true 

Minimal values to enable cluster settings: 

image:
 tag: 15-mysql-tomcat

cluster:
 enabled: true
 replicas: 1

persistence:
 enabled: true
 storageClass: "nfs"
 accessModes:
    - ReadWriteMany

solr:
 enabled: true
 persistence:
   enabled: true

Monitoring

There is a preconfigured Glowroot on this chart that can be used for tracing, error log and reporting system. To enable, set XWiki 1.1.0+ glowroot.enabled to true

Follow one example of how to access service/dashboard using port forward:
kubectl port-forward xwiki-0 4000:4000

To see more details about other tools to monitoring XWiki, check Administrator Guide/Monitoring page. 

Logging

 
To change the logging settings of XWiki, it's possible to override the entire logback config file or simply add extra elements at the end of the configuration. To see more details about XWiki logging system, check Administrator Guide/Logging page. 

logback:
 enabled: true
 extraConfiguration: |
   <logger name="org.xwiki" level="debug"/>
   <logger name="com.xwiki" level="debug"/>
# Example to override all other configs elements, you can use: 
#  customConfiguration: |
#    <appender name="stdout" class="ch.qos.logback.core.ConsoleAppender">
#      <!-- Direct log messages to stdout -->
#      <Target>System.out</Target>
#      <encoder>
#        <pattern>%d [%t] %-5p %-30.30c{2} - %m %n</pattern>
#      </encoder>
#    </appender>

Backup

There are some tools that can manage the backups on k8s workloads. We can suggest Velero, as we already used on some internal clusters.

XWiki backup needs to be viewed to see all paths/components that needs to be saved.

Important volumes/paths to be considered:

  • xwiki volume, or /usr/local/xwiki/data path.
  • Database volume/Database dump. If PostgreSQL, there is some backup parameters that can be used.
  • If using an external solr: xwiki-solr-data volume, or another volume if using a custom external solr instance.

Sizing

Check XWiki Performance guide that contains more detailed options and settings related to sizes and performance. 

Recommended initial resources are equivalent to 1 CPU unit and 2G of memory. These values may vary depending on the XWiki use case.  

The default (chart) persistence size (XWiki Data) is low, it's recommended to give more space if usage will be with large pages/attachments. 

Events that needs to be monitored to sizing changes: 

  • In case of any “Out of Memory” error, proper increase on memory needs to be done. Important note that in some cases this error can be released with memory leeks or other issues. And the huge Java memory heap, requires more CPU unit to proper run without pressure on GC. 
  • Long processing time (Waiting long time for page to load/save), can be released with lack of CPU units or pressure on Memory. If memory is low and CPU is high, maybe only CPU unit increase is required. If memory usage is height, maybe there are height GC activities and sometimes more memory can help. 
  • Error save page, or add new attachments. Can be out of space problem, check Database avaliable size and XWiki data volume. 

 version 

NameDescriptionValue
solr.enabledDeploy a Solr instance. By default, use an internal instance"false"
solr.replicaCountNumber of replica1
solr.imageThe name of the Solr Docker image"gridexx/xwiki:solr8"
solr.extraEnvVarsXWiki 1.2.4+ Mapping extra ENV variables[]
solr.resources.limitsThe resources limits for Solr{}
solr.resources.requestsThe requested resources for Solr{}
solr.service.portNamePort name of service'solr-node'
solr.service.nameName of service'http'
solr.service.typeKubernetes service type'ClusterIP'
solr.service.externalPortExternal port8983
solr.service.internalPortInternal/Container port8983 
solr.persistence.enabledEnable Solr data persistence using PVC"true"
solr.persistence.existingClaimName of an existing PVC to use""
solr.persistence.storageClassPVC Storage Class for Solr data volume""
solr.persistence.accessModesPVC Access Mode for Solr data volume["ReadWriteOnce"]
solr.persistence.sizePVC Storage Request for Solr data volume500Mi
solr.persistence.annotationsAnnotations for the PVC{}
solr.persistence.labelsLabels for the PVC{}
solr.persistence.selectorSelector to match an existing Persistent Volume{}
solr.persistence.dataSourceCustom PVC data source{}

Examples

Custom Properties


# Custom configuration files for xwiki 
customConfigs:
 # Properties key that exists, replace in line is done with value here defined. 
 # If key don't exists, this key and value will be appended in that specific file. 
 # This files are list of key: value that are translated as key=value in that file.
 xwiki.cfg:
   xwiki.superadminpassword: "s3cr3t"
 # Extension repository should be writed as items of the array value extension.repositories
 xwiki.properties:
   extension.repositories:
      - "xwiki-extensions-xxx:maven:http://172.25.128.67:8081/repository/xwiki/"
      - store.xwiki.com:xwiki:https://store.xwiki.com/xwiki/rest/

# Properties to be passed to Java process with -D parameters using JAVA_OPTS 
properties:
 http.proxyHost: "proxy.mycompany.com"
 http.proxyPort: 7777
 https.proxyHost: "proxy.mycompany.com"
 https.proxyPort: 7777

As part of project XWiki for OpenDesk, it's possible to use System Property Updater extension, that's enable to change object properties or attachment references using helm chart properties. 

Example that changes logo to a new logo and some preferences on XWiki settings page: 


# Properties to be passed to Java process with -D parameters using JAVA_OPTS 
properties:
 "attachment:xwiki:[email protected]": "data:image/svg+xml;base64,AAA....=="
 "property:xwiki:XWiki.XWikiPreferences^XWiki.XWikiPreferences.colorTheme": "FlamingoThemes.Iceberg"
 "property:xwiki:XWiki.XWikiPreferences^XWiki.XWikiPreferences.timezone": "Europe/Berlin"
 "property:xwiki:XWiki.XWikiPreferences^XWiki.XWikiPreferences.default_language": "de"
 "property:xwiki:XWiki.XWikiPreferences^XWiki.XWikiPreferences.languages": "de"

Cluster

XWiki 1.2.0+ The cluster setup is in a beta/experimental version. It needs a version of XWiki 15.0+ XWiki.

To have a single XWiki data volume shared with all replicas, on this example we use NSF Ganesha server Provisioner

To discover all pods, it is required that the service account (is created automatically) used if cluster is enabled have pod permission to "get", "list" and "watch" inside the namespace that release was installed. It's recommended to use a dedicated namespace if you want to isolate some XWiki cluster from other workloads -n namespace --create-namespace

helm repo add nfs-ganesha-server-provisioner https://kubernetes-sigs.github.io/nfs-ganesha-server-and-external-provisioner/
helm install nfs-server-provisioner nfs-ganesha-server-provisioner/nfs-server-provisioner --set persistence.enabled=true 

Minimal values to enable cluster settings: 

image:
 tag: 15-mysql-tomcat

cluster:
 enabled: true
 replicas: 1

persistence:
 enabled: true
 storageClass: "nfs"
 accessModes:
    - ReadWriteMany

solr:
 enabled: true
 persistence:
   enabled: true

Monitoring

There is a preconfigured Glowroot on this chart that can be used for tracing, error log and reporting system. To enable, set XWiki 1.1.0+ glowroot.enabled to true

Follow one example of how to access service/dashboard using port forward:
kubectl port-forward xwiki-0 4000:4000

To see more details about other tools to monitoring XWiki, check Administrator Guide/Monitoring page. 

Logging

 
To change the logging settings of XWiki, it's possible to override the entire logback config file or simply add extra elements at the end of the configuration. To see more details about XWiki logging system, check Administrator Guide/Logging page. 

logback:
 enabled: true
 extraConfiguration: |
   <logger name="org.xwiki" level="debug"/>
   <logger name="com.xwiki" level="debug"/>
# Example to override all other configs elements, you can use: 
#  customConfiguration: |
#    <appender name="stdout" class="ch.qos.logback.core.ConsoleAppender">
#      <!-- Direct log messages to stdout -->
#      <Target>System.out</Target>
#      <encoder>
#        <pattern>%d [%t] %-5p %-30.30c{2} - %m %n</pattern>
#      </encoder>
#    </appender>

Backup

There are some tools that can manage the backups on k8s workloads. We can suggest Velero, as we already used on some internal clusters.

XWiki backup needs to be viewed to see all paths/components that needs to be saved.

Important volumes/paths to be considered:

  • xwiki volume, or /usr/local/xwiki/data path.
  • Database volume/Database dump. If PostgreSQL, there is some backup parameters that can be used.
  • If using an external solr: xwiki-solr-data volume, or another volume if using a custom external solr instance.

Sizing

Check XWiki Performance guide that contains more detailed options and settings related to sizes and performance. 

Recommended initial resources are equivalent to 1 CPU unit and 2G of memory. These values may vary depending on the XWiki use case.  

The default (chart) persistence size (XWiki Data) is low, it's recommended to give more space if usage will be with large pages/attachments. 

Events that needs to be monitored to sizing changes: 

  • In case of any “Out of Memory” error, proper increase on memory needs to be done. Important note that in some cases this error can be released with memory leeks or other issues. And the huge Java memory heap, requires more CPU unit to proper run without pressure on GC. 
  • Long processing time (Waiting long time for page to load/save), can be released with lack of CPU units or pressure on Memory. If memory is low and CPU is high, maybe only CPU unit increase is required. If memory usage is height, maybe there are height GC activities and sometimes more memory can help. 
  • Error save page, or add new attachments. Can be out of space problem, check Database avaliable size and XWiki data volume. 

 version 

NameDescriptionValue
solr.enabledDeploy a Solr instance. By default, use an internal instance"false"
solr.replicaCountNumber of replica1
solr.imageThe name of the Solr Docker image"gridexx/xwiki:solr8"
solr.extraEnvVarsXWiki 1.2.4+ Mapping extra ENV variables[]
solr.resources.limitsThe resources limits for Solr{}
solr.resources.requestsThe requested resources for Solr{}
solr.service.portNamePort name of service'solr-node'
solr.service.nameName of service'http'
solr.service.typeKubernetes service type'ClusterIP'
solr.service.externalPortExternal port8983
solr.service.internalPortInternal/Container port8983 
solr.persistence.enabledEnable Solr data persistence using PVC"true"
solr.persistence.existingClaimName of an existing PVC to use""
solr.persistence.storageClassPVC Storage Class for Solr data volume""
solr.persistence.accessModesPVC Access Mode for Solr data volume["ReadWriteOnce"]
solr.persistence.sizePVC Storage Request for Solr data volume500Mi
solr.persistence.annotationsAnnotations for the PVC{}
solr.persistence.labelsLabels for the PVC{}
solr.persistence.selectorSelector to match an existing Persistent Volume{}
solr.persistence.dataSourceCustom PVC data source{}

Examples

Custom Properties


# Custom configuration files for xwiki 
customConfigs:
 # Properties key that exists, replace in line is done with value here defined. 
 # If key don't exists, this key and value will be appended in that specific file. 
 # This files are list of key: value that are translated as key=value in that file.
 xwiki.cfg:
   xwiki.superadminpassword: "s3cr3t"
 # Extension repository should be writed as items of the array value extension.repositories
 xwiki.properties:
   extension.repositories:
      - "xwiki-extensions-xxx:maven:http://172.25.128.67:8081/repository/xwiki/"
      - store.xwiki.com:xwiki:https://store.xwiki.com/xwiki/rest/

# Properties to be passed to Java process with -D parameters using JAVA_OPTS 
properties:
 http.proxyHost: "proxy.mycompany.com"
 http.proxyPort: 7777
 https.proxyHost: "proxy.mycompany.com"
 https.proxyPort: 7777

As part of project XWiki for OpenDesk, it's possible to use System Property Updater extension, that's enable to change object properties or attachment references using helm chart properties. 

Example that changes logo to a new logo and some preferences on XWiki settings page: 


# Properties to be passed to Java process with -D parameters using JAVA_OPTS 
properties:
 "attachment:xwiki:[email protected]": "data:image/svg+xml;base64,AAA....=="
 "property:xwiki:XWiki.XWikiPreferences^XWiki.XWikiPreferences.colorTheme": "FlamingoThemes.Iceberg"
 "property:xwiki:XWiki.XWikiPreferences^XWiki.XWikiPreferences.timezone": "Europe/Berlin"
 "property:xwiki:XWiki.XWikiPreferences^XWiki.XWikiPreferences.default_language": "de"
 "property:xwiki:XWiki.XWikiPreferences^XWiki.XWikiPreferences.languages": "de"

Cluster

XWiki 1.2.0+ The cluster setup is in a beta/experimental version. It needs a version of XWiki 15.0+ XWiki.

To have a single XWiki data volume shared with all replicas, on this example we use NSF Ganesha server Provisioner

To discover all pods, it is required that the service account (is created automatically) used if cluster is enabled have pod permission to "get", "list" and "watch" inside the namespace that release was installed. It's recommended to use a dedicated namespace if you want to isolate some XWiki cluster from other workloads -n namespace --create-namespace

helm repo add nfs-ganesha-server-provisioner https://kubernetes-sigs.github.io/nfs-ganesha-server-and-external-provisioner/
helm install nfs-server-provisioner nfs-ganesha-server-provisioner/nfs-server-provisioner --set persistence.enabled=true 

Minimal values to enable cluster settings: 

image:
 tag: 15-mysql-tomcat

cluster:
 enabled: true
 replicas: 1

persistence:
 enabled: true
 storageClass: "nfs"
 accessModes:
    - ReadWriteMany

solr:
 enabled: true
 persistence:
   enabled: true

Monitoring

There is a preconfigured Glowroot on this chart that can be used for tracing, error log and reporting system. To enable, set XWiki 1.1.0+ glowroot.enabled to true

Follow one example of how to access service/dashboard using port forward:
kubectl port-forward xwiki-0 4000:4000

To see more details about other tools to monitoring XWiki, check Administrator Guide/Monitoring page. 

Logging

 
To change the logging settings of XWiki, it's possible to override the entire logback config file or simply add extra elements at the end of the configuration. To see more details about XWiki logging system, check Administrator Guide/Logging page. 

logback:
 enabled: true
 extraConfiguration: |
   <logger name="org.xwiki" level="debug"/>
   <logger name="com.xwiki" level="debug"/>
# Example to override all other configs elements, you can use: 
#  customConfiguration: |
#    <appender name="stdout" class="ch.qos.logback.core.ConsoleAppender">
#      <!-- Direct log messages to stdout -->
#      <Target>System.out</Target>
#      <encoder>
#        <pattern>%d [%t] %-5p %-30.30c{2} - %m %n</pattern>
#      </encoder>
#    </appender>

Backup

There are some tools that can manage the backups on k8s workloads. We can suggest Velero, as we already used on some internal clusters.

XWiki backup needs to be viewed to see all paths/components that needs to be saved.

Important volumes/paths to be considered:

  • xwiki volume, or /usr/local/xwiki/data path.
  • Database volume/Database dump. If PostgreSQL, there is some backup parameters that can be used.
  • If using an external solr: xwiki-solr-data volume, or another volume if using a custom external solr instance.

Sizing

Check XWiki Performance guide that contains more detailed options and settings related to sizes and performance. 

Recommended initial resources are equivalent to 1 CPU unit and 2G of memory. These values may vary depending on the XWiki use case.  

The default (chart) persistence size (XWiki Data) is low, it's recommended to give more space if usage will be with large pages/attachments. 

Events that needs to be monitored to sizing changes: 

  • In case of any “Out of Memory” error, proper increase on memory needs to be done. Important note that in some cases this error can be released with memory leeks or other issues. And the huge Java memory heap, requires more CPU unit to proper run without pressure on GC. 
  • Long processing time (Waiting long time for page to load/save), can be released with lack of CPU units or pressure on Memory. If memory is low and CPU is high, maybe only CPU unit increase is required. If memory usage is height, maybe there are height GC activities and sometimes more memory can help. 
  • Error save page, or add new attachments. Can be out of space problem, check Database avaliable size and XWiki data volume. 

 version 

NameDescriptionValue
solr.enabledDeploy a Solr instance. By default, use an internal instance"false"
solr.replicaCountNumber of replica1
solr.imageThe name of the Solr Docker image"gridexx/xwiki:solr8"
solr.extraEnvVarsXWiki 1.2.4+ Mapping extra ENV variables[]
solr.resources.limitsThe resources limits for Solr{}
solr.resources.requestsThe requested resources for Solr{}
solr.service.portNamePort name of service'solr-node'
solr.service.nameName of service'http'
solr.service.typeKubernetes service type'ClusterIP'
solr.service.externalPortExternal port8983
solr.service.internalPortInternal/Container port8983 
solr.persistence.enabledEnable Solr data persistence using PVC"true"
solr.persistence.existingClaimName of an existing PVC to use""
solr.persistence.storageClassPVC Storage Class for Solr data volume""
solr.persistence.accessModesPVC Access Mode for Solr data volume["ReadWriteOnce"]
solr.persistence.sizePVC Storage Request for Solr data volume500Mi
solr.persistence.annotationsAnnotations for the PVC{}
solr.persistence.labelsLabels for the PVC{}
solr.persistence.selectorSelector to match an existing Persistent Volume{}
solr.persistence.dataSourceCustom PVC data source{}

Examples

Custom Properties


# Custom configuration files for xwiki 
customConfigs:
 # Properties key that exists, replace in line is done with value here defined. 
 # If key don't exists, this key and value will be appended in that specific file. 
 # This files are list of key: value that are translated as key=value in that file.
 xwiki.cfg:
   xwiki.superadminpassword: "s3cr3t"
 # Extension repository should be writed as items of the array value extension.repositories
 xwiki.properties:
   extension.repositories:
      - "xwiki-extensions-xxx:maven:http://172.25.128.67:8081/repository/xwiki/"
      - store.xwiki.com:xwiki:https://store.xwiki.com/xwiki/rest/

# Properties to be passed to Java process with -D parameters using JAVA_OPTS 
properties:
 http.proxyHost: "proxy.mycompany.com"
 http.proxyPort: 7777
 https.proxyHost: "proxy.mycompany.com"
 https.proxyPort: 7777

As part of project XWiki for OpenDesk, it's possible to use System Property Updater extension, that's enable to change object properties or attachment references using helm chart properties. 

Example that changes logo to a new logo and some preferences on XWiki settings page: 


# Properties to be passed to Java process with -D parameters using JAVA_OPTS 
properties:
 "attachment:xwiki:[email protected]": "data:image/svg+xml;base64,AAA....=="
 "property:xwiki:XWiki.XWikiPreferences^XWiki.XWikiPreferences.colorTheme": "FlamingoThemes.Iceberg"
 "property:xwiki:XWiki.XWikiPreferences^XWiki.XWikiPreferences.timezone": "Europe/Berlin"
 "property:xwiki:XWiki.XWikiPreferences^XWiki.XWikiPreferences.default_language": "de"
 "property:xwiki:XWiki.XWikiPreferences^XWiki.XWikiPreferences.languages": "de"

Cluster

XWiki 1.2.0+ The cluster setup is in a beta/experimental version. It needs a version of XWiki 15.0+ XWiki.

To have a single XWiki data volume shared with all replicas, on this example we use NSF Ganesha server Provisioner

To discover all pods, it is required that the service account (is created automatically) used if cluster is enabled have pod permission to "get", "list" and "watch" inside the namespace that release was installed. It's recommended to use a dedicated namespace if you want to isolate some XWiki cluster from other workloads -n namespace --create-namespace

helm repo add nfs-ganesha-server-provisioner https://kubernetes-sigs.github.io/nfs-ganesha-server-and-external-provisioner/
helm install nfs-server-provisioner nfs-ganesha-server-provisioner/nfs-server-provisioner --set persistence.enabled=true 

Minimal values to enable cluster settings: 

image:
 tag: 15-mysql-tomcat

cluster:
 enabled: true
 replicas: 1

persistence:
 enabled: true
 storageClass: "nfs"
 accessModes:
    - ReadWriteMany

solr:
 enabled: true
 persistence:
   enabled: true

Monitoring

There is a preconfigured Glowroot on this chart that can be used for tracing, error log and reporting system. To enable, set XWiki 1.1.0+ glowroot.enabled to true

Follow one example of how to access service/dashboard using port forward:
kubectl port-forward xwiki-0 4000:4000

To see more details about other tools to monitoring XWiki, check Administrator Guide/Monitoring page. 

Logging

 
To change the logging settings of XWiki, it's possible to override the entire logback config file or simply add extra elements at the end of the configuration. To see more details about XWiki logging system, check Administrator Guide/Logging page. 

logback:
 enabled: true
 extraConfiguration: |
   <logger name="org.xwiki" level="debug"/>
   <logger name="com.xwiki" level="debug"/>
# Example to override all other configs elements, you can use: 
#  customConfiguration: |
#    <appender name="stdout" class="ch.qos.logback.core.ConsoleAppender">
#      <!-- Direct log messages to stdout -->
#      <Target>System.out</Target>
#      <encoder>
#        <pattern>%d [%t] %-5p %-30.30c{2} - %m %n</pattern>
#      </encoder>
#    </appender>

Backup

There are some tools that can manage the backups on k8s workloads. We can suggest Velero, as we already used on some internal clusters.

XWiki backup needs to be viewed to see all paths/components that needs to be saved.

Important volumes/paths to be considered:

  • xwiki volume, or /usr/local/xwiki/data path.
  • Database volume/Database dump. If PostgreSQL, there is some backup parameters that can be used.
  • If using an external solr: xwiki-solr-data volume, or another volume if using a custom external solr instance.

Sizing

Check XWiki Performance guide that contains more detailed options and settings related to sizes and performance. 

Recommended initial resources are equivalent to 1 CPU unit and 2G of memory. These values may vary depending on the XWiki use case.  

The default (chart) persistence size (XWiki Data) is low, it's recommended to give more space if usage will be with large pages/attachments. 

Events that needs to be monitored to sizing changes: 

  • In case of any “Out of Memory” error, proper increase on memory needs to be done. Important note that in some cases this error can be released with memory leeks or other issues. And the huge Java memory heap, requires more CPU unit to proper run without pressure on GC. 
  • Long processing time (Waiting long time for page to load/save), can be released with lack of CPU units or pressure on Memory. If memory is low and CPU is high, maybe only CPU unit increase is required. If memory usage is height, maybe there are height GC activities and sometimes more memory can help. 
  • Error save page, or add new attachments. Can be out of space problem, check Database avaliable size and XWiki data volume. 

 version 

NameDescriptionValue
solr.enabledDeploy a Solr instance. By default, use an internal instance"false"
solr.replicaCountNumber of replica1
solr.imageThe name of the Solr Docker image"gridexx/xwiki:solr8"
solr.extraEnvVarsXWiki 1.2.4+ Mapping extra ENV variables[]
solr.resources.limitsThe resources limits for Solr{}
solr.resources.requestsThe requested resources for Solr{}
solr.service.portNamePort name of service'solr-node'
solr.service.nameName of service'http'
solr.service.typeKubernetes service type'ClusterIP'
solr.service.externalPortExternal port8983
solr.service.internalPortInternal/Container port8983 
solr.persistence.enabledEnable Solr data persistence using PVC"true"
solr.persistence.existingClaimName of an existing PVC to use""
solr.persistence.storageClassPVC Storage Class for Solr data volume""
solr.persistence.accessModesPVC Access Mode for Solr data volume["ReadWriteOnce"]
solr.persistence.sizePVC Storage Request for Solr data volume500Mi
solr.persistence.annotationsAnnotations for the PVC{}
solr.persistence.labelsLabels for the PVC{}
solr.persistence.selectorSelector to match an existing Persistent Volume{}
solr.persistence.dataSourceCustom PVC data source{}

Examples

Custom Properties


# Custom configuration files for xwiki 
customConfigs:
 # Properties key that exists, replace in line is done with value here defined. 
 # If key don't exists, this key and value will be appended in that specific file. 
 # This files are list of key: value that are translated as key=value in that file.
 xwiki.cfg:
   xwiki.superadminpassword: "s3cr3t"
 # Extension repository should be writed as items of the array value extension.repositories
 xwiki.properties:
   extension.repositories:
      - "xwiki-extensions-xxx:maven:http://172.25.128.67:8081/repository/xwiki/"
      - store.xwiki.com:xwiki:https://store.xwiki.com/xwiki/rest/

# Properties to be passed to Java process with -D parameters using JAVA_OPTS 
properties:
 http.proxyHost: "proxy.mycompany.com"
 http.proxyPort: 7777
 https.proxyHost: "proxy.mycompany.com"
 https.proxyPort: 7777

As part of project XWiki for OpenDesk, it's possible to use System Property Updater extension, that's enable to change object properties or attachment references using helm chart properties. 

Example that changes logo to a new logo and some preferences on XWiki settings page: 


# Properties to be passed to Java process with -D parameters using JAVA_OPTS 
properties:
 "attachment:xwiki:[email protected]": "data:image/svg+xml;base64,AAA....=="
 "property:xwiki:XWiki.XWikiPreferences^XWiki.XWikiPreferences.colorTheme": "FlamingoThemes.Iceberg"
 "property:xwiki:XWiki.XWikiPreferences^XWiki.XWikiPreferences.timezone": "Europe/Berlin"
 "property:xwiki:XWiki.XWikiPreferences^XWiki.XWikiPreferences.default_language": "de"
 "property:xwiki:XWiki.XWikiPreferences^XWiki.XWikiPreferences.languages": "de"

Cluster

XWiki 1.2.0+ The cluster setup is in a beta/experimental version. It needs a version of XWiki 15.0+ XWiki.

To have a single XWiki data volume shared with all replicas, on this example we use NSF Ganesha server Provisioner

To discover all pods, it is required that the service account (is created automatically) used if cluster is enabled have pod permission to "get", "list" and "watch" inside the namespace that release was installed. It's recommended to use a dedicated namespace if you want to isolate some XWiki cluster from other workloads -n namespace --create-namespace

helm repo add nfs-ganesha-server-provisioner https://kubernetes-sigs.github.io/nfs-ganesha-server-and-external-provisioner/
helm install nfs-server-provisioner nfs-ganesha-server-provisioner/nfs-server-provisioner --set persistence.enabled=true 

Minimal values to enable cluster settings: 

image:
 tag: 15-mysql-tomcat

cluster:
 enabled: true
 replicas: 1

persistence:
 enabled: true
 storageClass: "nfs"
 accessModes:
    - ReadWriteMany

solr:
 enabled: true
 persistence:
   enabled: true

Monitoring

There is a preconfigured Glowroot on this chart that can be used for tracing, error log and reporting system. To enable, set XWiki 1.1.0+ glowroot.enabled to true

Follow one example of how to access service/dashboard using port forward:
kubectl port-forward xwiki-0 4000:4000

To see more details about other tools to monitoring XWiki, check Administrator Guide/Monitoring page. 

Logging

 
To change the logging settings of XWiki, it's possible to override the entire logback config file or simply add extra elements at the end of the configuration. To see more details about XWiki logging system, check Administrator Guide/Logging page. 

logback:
 enabled: true
 extraConfiguration: |
   <logger name="org.xwiki" level="debug"/>
   <logger name="com.xwiki" level="debug"/>
# Example to override all other configs elements, you can use: 
#  customConfiguration: |
#    <appender name="stdout" class="ch.qos.logback.core.ConsoleAppender">
#      <!-- Direct log messages to stdout -->
#      <Target>System.out</Target>
#      <encoder>
#        <pattern>%d [%t] %-5p %-30.30c{2} - %m %n</pattern>
#      </encoder>
#    </appender>

Backup

There are some tools that can manage the backups on k8s workloads. We can suggest Velero, as we already used on some internal clusters.

XWiki backup needs to be viewed to see all paths/components that needs to be saved.

Important volumes/paths to be considered:

  • xwiki volume, or /usr/local/xwiki/data path.
  • Database volume/Database dump. If PostgreSQL, there is some backup parameters that can be used.
  • If using an external solr: xwiki-solr-data volume, or another volume if using a custom external solr instance.

Sizing

Check XWiki Performance guide that contains more detailed options and settings related to sizes and performance. 

Recommended initial resources are equivalent to 1 CPU unit and 2G of memory. These values may vary depending on the XWiki use case.  

The default (chart) persistence size (XWiki Data) is low, it's recommended to give more space if usage will be with large pages/attachments. 

Events that needs to be monitored to sizing changes: 

  • In case of any “Out of Memory” error, proper increase on memory needs to be done. Important note that in some cases this error can be released with memory leeks or other issues. And the huge Java memory heap, requires more CPU unit to proper run without pressure on GC. 
  • Long processing time (Waiting long time for page to load/save), can be released with lack of CPU units or pressure on Memory. If memory is low and CPU is high, maybe only CPU unit increase is required. If memory usage is height, maybe there are height GC activities and sometimes more memory can help. 
  • Error save page, or add new attachments. Can be out of space problem, check Database avaliable size and XWiki data volume. 

 

Prerequisites & Installation Instructions

Requirements

Install

To install chart with the release name xwiki

helm repo add xwiki-helm https://xwiki-contrib.github.io/xwiki-helm
# Use --devel install most recent released (beta/alpha) version
helm install xwiki xwiki-helm/xwiki

Source

To install using local chart definitions or other not released version:

git clone https://github.com/xwiki-contrib/xwiki-helm
# git checkout branch-name
cd xwiki-helm/charts/xwiki
helm dependency update
helm install xwiki .

Tests

Current tests are unit tests created to run with helm-unittest plugin: 

helm plugin install https://github.com/helm-unittest/helm-unittest
helm unittest charts/xwiki

Signing

This chart is signed using Chart Releaser Action that runs on GitHub Actions. Instructions about how to use can be found in this tutorial. You can verify this chart against this GPG key: 

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQINBGVKL+0BEACZrgs4fX3MpshxfxbSGqz9gXLLHmKjeTYCmx9CFGzJIyZNjQPf
LGd0RVZ2fViLyj2Hbw0MorK+6IV3ak1Qyv+FBmOxdrw9ZdhI6Q/rOwuRjabA1qGH
saF477z+v4d+RplD0ldNehqBMOz0pMh0SPB7jX+nMIP5xEJhG0E2LeVWmy/ej3m6
fI4t5GjdoSVrM4p7jxSbfXQAaStNNV3nU8JpYCvSu0QWSnD9Z1QwZhzf1xWseggc
eHNEQhoOKDKNOJCet71m7RKnzjoxowFE1pBM1UYEymSEf7mnNpXlmtlFwnGkWuZN
wo+8QF5iDhpUd1TJ3Lk2iIitsW7uxDpSvkeRlxY3WWWWujn2nlod66SC8rvGeUUf
6YVqPYIhBS+mA3cG8vDq7TR6MPhCChWWNjPYwk9AgZjemGUxw1r20xWENSV92a06
odHtNlX2PhyUtph0lfc/tUoxnzK/EYTtoWx8M5RP1HluNeo9oICBW9pu0/wTFas6
fnaSducZCBwyH2DrONF3ohSmL7vVMQXVZyCddItel5d6VUuzafnDqWy1vATcPlVi
FBIzVq1F39F6PkQWq+ggEaw2T/Kj19vMxGvgOPmFSxERNCYIOHj7HVeYmKS700/j
Jfzvi8isFAPQq3HFEStp3+3FWKPXnJPwpPryXhzvH26sz1kKQj4hXvKzJQARAQAB
tD9YV2lraSBTQVMgKEtleXMgdXNlZCBvbiBIZWxtIENoYXJ0cyByZWxlYXNlcykg
PGluZnJhQHh3aWtpLmNvbT6JAlEEEwEIADsWIQS4GzbnJ3q84GxKVvBox6+f3A0T
FQUCZUov7QIbAwULCQgHAgIiAgYVCgkICwIEFgIDAQIeBwIXgAAKCRBox6+f3A0T
FcVGEACEbkTtce/99q7a8da6FmnyXZO337ZlUBQUY2K4dAZYBCzqQLEzxUMnPw8f
UFE+iOQZJOtAH0BUcRaPHZT1HsRyhd/nGu5QpJKFmKnygzAdfHOiJ5Z0CJs9rRHi
oHHxmEGwRrq8dvjB40f9UzBhMhrpO1oab0+WSTSxV/R/I3Wp2lfoVKr9XhV5ztxc
5YCB+8TZUmucZmOMCdNxMaFVOsk25kVigVFRWv8EkYUWJ3AXaFtLib8NwRSBUAI1
He1jixrzq69eLJ0Z7QQPjfMx0C3ZousJdeUj4ct3R/VGt6xFnBrAXD7/co9zMZkL
uSDapiNy9VVURs8CMYJ2Iyxfk674LlUPYYVMVlC5zrn5Q1zGsvYzoucEqwiFh02H
a7E1L8qlMNqjiJSr15BAyXcGnSNie+SECsKuiKHBoxtHofcBf7566zd9yh57Y79E
jAIh02rIxyqun+1p8V2hcqaN/uOWbUYdbqmq92jnwiL5XE/YKFcNZqNQSvapIon1
MNNMXjwhBM6SmLjKMU6ZRPMDul/Cl9sWsswDdIrAVEtlr9rV5hmrd6n4C5d/xAK6
VdAd16sFizu7512eRk1hOmkBp7XuVKTsD33NmkEFm3Wf0magkd2EKJ+p0ak79oPB
22kX/d+0KhUfrS7Fq67IPevbSLc48gwrk46Y9yLsocKovNXgnbkCDQRlSi/tARAA
u2uZOAiPquwaWA22oDYoSNqKB5+DIM9ZPQjG93zIEdyls44chal59A5Ug9wscQoq
jfuUaho5Vt/MEpqO9WPZweW9LdkvpImSbHNGTtnBZPI5q5s4ytanf2QeBhsTOkKx
zBU9szVLhqbDgzCwGgmf4b+rtg1zOl2p2BF5rLWEHom3oCkwJjJWoHpl79QD9GL/
q8HZ1ughFaQRTW+pG8BxIyHreffkKn7ZWxXhL+XbfN5+Ocmqq9kxhkWl638K5Ab8
Ay6ESjLES84wgeTvmonI9H/qkI/Mj27fD4Ny2LnhBLitprpmUkVAFoHQxxsP5lCG
8U7j1aEOXZzhD59Bzz2CXQ2NAFoYFibw1hJmvi9e2QJdZL12fp6id6jvJWUcrO2h
6v2EXkNhp6Cgsd/CqclnkJhJgZx9C9xbPNN89SOC5GvDTrU3z3oC2076xJjT1vSr
slU6gYY9S3qb9HpDH7/exP8V55GyS/ik/6RRCvoBgqnwQVK9MGoba4eHle2EIdkv
rrm5goSrHECx67DsfZkXzz9vlq5JNOkQDY2UO7jnjlSj8d7mTQckD6PtcuR+gOwq
KlHm6xXEfysgLLlkpUMpTDkGrDpfVZOeUmCTXlLXVbvZqsEFsghKvpBJgRp9AmVw
8Q7vQ0S23X1BrWI2W/IgVqXDx92sjmCLZJhELkA5yfUAEQEAAYkCNgQYAQgAIBYh
BLgbNucnerzgbEpW8GjHr5/cDRMVBQJlSi/tAhsMAAoJEGjHr5/cDRMVw9IP/RGA
2/FW5Py8WCDwzGn6+uZE4E1PI35v5WLO76yOBKw1Mxp3RAERc16i3RO/HrgaisfV
E3j7HoyF8wWUX7yg4P5R3RNLBs54NGMmBarACsaUbM/0QCITQ8zZvQhPU852A1/V
HP6VofCvpwhspPbsi5JdSIVFE3XsRz2ZoMjW5PyTHIKylgT3Ut0aAKpWsfoE5AVd
2MjZaN6nt8BSFgWoBYyx5MbhPS4IvFW5SWokn0tP1aSUHaGj+1uDFXa+ZvYwHsRL
X/zsBrnYJ1Eng93X4BYx6TE7SrOxEYHWssBlxfPzCMX26msrfQy1RhZe8c5FpVff
XfG5h8SXnxyRx+SF6s9Kyh9EKEM8uwjmBwteFDhEEY/vMMZaFt5UQcQ/1gVS+j3r
EKw8/mc7aqFz29wS3o5aiB+6vJsJMHl3aGsT6k3+Mp4DnSnrX0/R1nHLuKQr6UTH
gxEe3dij9wbtx64fzT3sLW9141Y/rGtJo+GNPm8z4mITzeSBSkD6WVzvPq7m1hoR
iHVlIaZL0mJnvg4LN3anI6r5dbsYoIKOS0HbrPls6B7E8qRg4DNNHKuD3/LkIT+r
8usz3UI1NYb1wwdjguKmTEuq320YYCcyDmIFDu4NGH/MyMq2U8Wc8+zrUr8dxdoO
6zdoc2S1fih168kWWR2ceBuY9szPbAYQrKwzJA9Q
=57n1
-----END PGP PUBLIC KEY BLOCK-----

Example: 

# Download and convert key from ASCII armor format to binary.
curl https://extensions.xwiki.org/xwiki/bin/download/Extension/XWikiHelm/WebHome/helm-charts.asc | gpg --dearmor > helm-charts.gpg
# Verify thatthe signed chart:
helm fetch --verify xwiki-helm/xwiki --version 1.2.4 --keyring helm-charts.gpg 

Upgrading

v1.2.x to v1.3.0

There are no upgrade restrictions or major changes break. But this version introduced service account by default. In case of a fallback or backup restore, a direct fix to Workload might be required to manage service account reference.

v1.1.x to v1.2.0

In this version, external Solr usage changed. If enabled, a preconfigured workload will be created. To use another external instance as previous version, you need to disable this and use only the properties settings to configure the external instance using the official guide

Option replicaCount was renamed to cluster.replicas 

v0.X to v1.0.0

In this version some persistent mappings have been modified, so it is strongly recommended to perform a backup. Velero is a useful tool for managing Kubernetes backups.

For releases that utilize database settings/install, the recommended approach is to install new Helm release and perform data migration accordingly. See Import/Export

Release Notes

v1.3.1

v1.3.0

v1.2.6

v1.2.5

v1.2.4

v1.2.3

v1.2.2

v1.2.1

v1.1.3

v1.2.0

v1.1.2

v1.1.1

v1.1.0

v1.0.0

Here are the updates in this release: 

  • Support for Kubernetes v1.23+ 
  • Upgrade of the Helm definition to use v2 API.
  • Changed the repository for MySQL and PostgreSQL to use Bitnami. 
  • Added MariaDB (10.11.2) as database option using chart version 12.1.4.
  • Updated the MySQL (8.0.33) chart version to 9.9.0.
  • Updated the PostgreSQL (15.2.0) chart version to 12.4.2.
  • Upgraded unittesting to lasted version. 
  • Added new persistent options for XWiki data. 
  • Introduced Github workflow actions to perform testing and release. 
  • Added support config xwiki properties and cfg using helm chart values. 

Jira issues solved: 

Get Connected