Actually I think the current docker image is already quite production ready, so you did a good job
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”:
-
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 existingdocker-entrypoint.sh
script I guess?
Optionally, also addxwiki.authentication.ldap.trylocal=1
(very important for us) -
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.
-
Tomcat java opts variable:
-Xmx1024m
ist not enough for our installation, so i have to editsetenv.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 thatxwiki.plugin.image.defaultQuality = 0.8
because our faces were ugly in our avatarsopenoffice.homePath and autostart
→ openoffice is already included in the docker image, LibreOffice did get better results when importing M$ office thoughrendering.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