Managing configuration changes when upgrading xwiki (using docker)

Help / Discuss
, ,
19

Actually I think the current docker image is already quite production ready, so you did a good job :+1:
Currently, my time is more limited again, but I’ve planned to make further pull-requests if possible.

I need to process your discussion with @rbr , I’m quite new to linux all together and acutally started to learn about docker a few months ago.

Another issue regarding upgrading xwiki (in docker):

Issue #3: Solr data ist not deleted when upgrading xwiki docker image. Upgrading the webapp says that:

Best is to not copy the solr/ subdirectory since the SOLR schema could have changed and it’s best to let XWiki reindex using the new schema

But it resides in /usr/local/xwiki/data/solr within the xwiki data volume.
Suggestion: Add an “upgrade” condition in docker-entrypoint.sh besides first_start and other_starts that deletes the SOLR data? Detecting an upgrade could be tricky though…

Will add this at the first post in the thread.

Things I’m currently missing in the docker image/compose template for making it “enterprise-production-ready”:

  1. LDAP Authentication: Very easy, just set xwiki.authentication.authclass=org.xwiki.contrib.ldap.XWikiLDAPAuthServiceImpl
    and then install the LDAP application extension and set it up via Administration GUI. This can be done via ENV variable and the existing docker-entrypoint.sh script I guess?
    Optionally, also add xwiki.authentication.ldap.trylocal=1 (very important for us)

  2. TLS/SSL configuration for tomcat: This is actually my last big TODO to check for docker, which I need our IT for. I hope it can be done easily.

  3. Tomcat java opts variable: -Xmx1024m ist not enough for our installation, so i have to edit setenv.sh

I will add these three at the top in the first post of the thread.

Other minor things we did to the default config (looking at my git diff at the moment):

  • Setting attachment store to file → Fixed in current xwiki (database storage was not usable for us)
  • xwiki.plugin.watchlist.automaticwatch=none because our normal users don’t want that
  • xwiki.plugin.image.defaultQuality = 0.8 because our faces were ugly in our avatars :smiley:
  • openoffice.homePath and autostart → openoffice is already included in the docker image, LibreOffice did get better results when importing M$ office though
  • rendering.imageDimensionsIncludedInImageURL = false because the default behaviour is not useful
  • Adding markdown to xwiki.rendering.syntaxes

Of course, you could but everything into environment variables.

Additionally, maybe Performance parameters for tuning? We currently have sometimes performance hickups on our running 8.4.3 tomcat postgres on windows server. I’ve tuned some values but still.

But we never installed the optional database indexes, maybe thats the reason.

I plan to to this also in den docker environment. Namely: postgresql performance parameters, the missing DB indexes, xwiki performance parameters. e.g. the Admin Tools Application tells me that

Your cache configuration is too low for a production usage. Your cache is set to 100 documents, it should be 1000 or more

Shouldn’t that be 500 per default?

   149  #-# Maximum number of documents to keep in the cache.
   150  #-# The default is 500.
   151  # xwiki.store.cache.capacity=500

Maybe there is more to be done. I’m playing around with a standalone SOLR container, but not sure if that helps anything, but it sounds reasonable to keep it seperate from the xwiki server.

If we can’t get everything we need into the official image, we can still fork the git repository and roll our own. Not everybody needs all that stuff. Thats the sex appeal of automated build processes.

BR