I'm not sure what you're asking for. Is there anything we need to do to make it easier to build DokuWiki docker images that is different from #791?

But TBH I don't really understand why you'd even want DokuWiki in a Docker container. Use a generic PHP/Apache container, mount some local volume and extract a DokuWiki tarball there. Done. Moving DokuWiki into the container just complicates things but seems not to give any advantages?

no feedback given

The advantage would be getting everything set up in one command, and avoiding any mess with incorrect PHP versions, missing modules, bad PHP config etc.

Another solution could be including an example docker-compose.yml that picks specific versions of PHP & nginx + demonstrates how to wire everything together in a reliable way.

My feeling is that these kind of initiatives are (probably) very nice to offer, but it is than really helpful if its setup and more relevant maintainance then are performed by others than the default maintainers of DokuWiki. There are a couple of these techniques, which are probably useful for wiki admins, but it should not increase, in my opinion, the work for the current maintainers, because there are already enough other things that need attention. So thereby my encouragement to all interested in this, is it possible to help self contributing to building and maintaining this? Thanks in advance!

https://hub.docker.com/search/?isAutomated=0&isOfficial=0&page=1&pullCount=0&q=dokuwiki&starCount=0
~ 300 000+ Pulls.
205 repositories.
Not counting the ones where someone did set it up without involvement of hub.docker.com.
It would really be great if there was an official minimal dokuwiki image.
This would help the security of dokuwiki installations as a whole.

It could also increase the installations of dokuwiki, and bring new developers, because people tend to surf the official docker images. https://docs.docker.com/docker-hub/official_repos/

Just my opinion, I am installing a dokuwiki now and have a certain distrust in these images.

Hi,

But TBH I don't really understand why you'd even want DokuWiki in a Docker container. Use a generic PHP/Apache container, mount some local volume and extract a DokuWiki tarball there. Done. Moving DokuWiki into the container just complicates things but seems not to give any advantages?

Here are some reasons:

• nowadays we don't have servers dedicated to 1 service. We might run multiple Apache, NGINX, NodeJS servers on the same service
• ‎ security: isolation is better. One compromised service shouldn't impact another service
• ‎ updates (therefore also security) : updating a service and its libraries is easier because we "just" need to rebuild the image+container regularly. And here again, isolation make upgrade issues less scary.
• ‎ automation : we don't want to deploy things manually. Docker + all the tools associated (docker compose, ...) makes this quite easy
• service orchestration : using a container in the first step. It really make sense after it's inside a Docker cluster (swarm, kubernetes,...) then we can use the same management rules for all containers (proxies, load balancing, data management,...)
• ‎ easier to get started: if I want to try Dokuwiki, if I don't know if it's good or not I can start a new Dokuwiki in 1 minute. I don't have Apache installed on my machine and I don't want to install one.
• ‎ portability : once you have set up a Dokuwiki in dev you can copy paste the same definition files to production and it will work "exactly" the same.
• ‎ more people will be willing to try it (this is a great product by the way)

So.... I wanted to install Dokuwiki this week and I have then created a container. Here are my configuration files (in case someone is interested):

Dockerfile:

FROM php:7.0-apache
 
COPY dokuwiki.tgz /opt/src/dokuwiki.tgz
COPY custom-start.sh /custom-start.sh
 
RUN chmod +x /start.sh && \
    cd /opt/src/ && \
    tar zxf dokuwiki.tgz && \
    rm -fr /var/www/html && \
    cp -R dokuwiki /var/www/html && \
    chown -R www-data /var/www/html

CMD ["/custom-start.sh"]

custom-start.sh

#!/bin/sh

if [ ! -f /var/www/html/data/index.php ]; then
  echo "Init data folder"
  cp -R /opt/src/dokuwiki/data/* /var/www/html/data/
  cp -R /opt/src/dokuwiki/data/.htaccess /var/www/html/data/
  chown -R www-data /var/www/html
fi

docker-php-entrypoint apache2-foreground

docker-compose.yml:

version: '3'
services:
  web:
    build: .
    ports:
      - 80
    volumes:
      - /opt/data/some-host-folder-for-dokukiwi:/var/www/html/data

Regards,

@DidierHoarau great work!
how does your solution handle installed add-ons?

@DidierHoarau you answered why you would prefer a Docker over non-Docker installation. I get that. But what advantage do you get from a custom DokuWiki container over a generic Apache/PHP container?

If you don't really care about maintaining the installation for a long term and just quickly want to try out DokuWiki, eg. you're fine that everything is inside the container, just use the bitnami stack.

Otherwise you will want to keep all customizable stuff outside the container. That includes configuration, plugins, templates and actual page/media data. Your container only addresses the latter. Building a container that addresses all four is complicated and would need a solution for #791. Otherwise you will break one of your goals: updates.

Until someone solves #791 it is much easier to just mount a full DokuWiki install as a volume to an existing Apache/PHP container. That gives you all your goals except update-ability (which is partly solved by the upgrade plugin).

So here's the deal: we will add an official Docker image when someone creates a build config that solves the plugin problem of #791.

Hi,

@minexew

I guess I didn't handle this part properly :)
I just installed a few plugins and restarted the container and as it was working I assume (wrongly it seems) that it was handled.

@splitbrain

Actually after reading the this thread and #791 ... I think these are exactly the reason why users would need an official image:

• An image (and its documenation) will explain the parts that need to be handled differently. (for volume, for updates, ...). A users that might not now those aspect might create a non-functional image (like mine maybe)
• Is Apache+PHP enough or is there other libraries that are recommended? Some CMS need other libs
• There is an aspect of the installation not handled in my post: how to download the sources?
• Regarding update, I'm thinking about update of Dokuwiki but also update of all the system libs and tools (Apache, ...). Those tools can come with some vulnerabilities and might need to be updated regularly

Also, we are taking about official images but just putting example of Dockerfile in the documentation might be a good start.

To be honest I didn't spend that much time checking how to dockerise Dokuwiki... I will try to read a little more about #791 and see if I can come with comments/ideas.

Hi,

I indeed see that creating a Docker Image for Dokuwiki is not that straitforward.

Here is what I've done so far:

Dockerfile

FROM php:7.0-apache

COPY entrypoint.sh /entrypoint.sh

RUN chmod +x /entrypoint.sh && \
    mkdir -p /opt/src && \
    curl https://download.dokuwiki.org/src/dokuwiki/dokuwiki-stable.tgz --output /opt/src/dokuwiki.tgz && \
    cd /opt/src/ && \
    tar zxf dokuwiki.tgz && \
    rm -f dokuwiki.tgz && \
    mv dokuwiki* dokuwiki && \
    rm -fr /var/www/html && \
    cp -R dokuwiki /var/www/html && \
    chown -R www-data /var/www/html

EXPOSE 80 443
VOLUME ["/var/www/html/data", "/var/www/html/lib"]

CMD ["/entrypoint.sh"]

entrypoint.sh

#!/bin/bash

set -e

# Volumes Init
if [ ! -f /var/www/html/data/index.php ]; then
  echo "Init data folder"
  cp -R /opt/src/dokuwiki/data/* /var/www/html/data/
  cp -R /opt/src/dokuwiki/data/.htaccess /var/www/html/data/
  chown -R www-data /var/www/html
fi

if [ ! -f /var/www/html/lib/index.html ]; then
  echo "Init lib folder"
  cp -R /opt/src/dokuwiki/lib/* /var/www/html/lib/
  chown -R www-data /var/www/html/lib
fi

if [ ! -f /var/www/html/conf/.htaccess ]; then
  echo "Init conf folder"
  cp -R /opt/src/dokuwiki/conf/* /var/www/html/conf/
  chown -R www-data /var/www/html/conf
fi

# Lib upgrade
function copy_extra_lib {
  FOLDER_ORIGIN=$1
  FOLDER_DESTINATION=$2
  for FILEPATH_ORIGIN in ${FOLDER_ORIGIN}/*; do
    if [ -d "${FILEPATH_ORIGIN}" ]; then
      FILENAME=$(basename "${FILEPATH_ORIGIN}")
      if [ ! -d "${FOLDER_DESTINATION}/${FILENAME}" ]; then
        echo "Keeping Lib: ${FILENAME}";
        cp -R ${FILEPATH_ORIGIN} ${FOLDER_DESTINATION}/${FILENAME}
      fi
    fi
  done
}

rm -fr /opt/tmp/lib
mkdir -p /opt/tmp/lib
cp -R /opt/src/dokuwiki/lib/* /opt/tmp/lib

copy_extra_lib "/var/www/html/lib/plugins" "/opt/tmp/lib/plugins"
copy_extra_lib "/var/www/html/lib/tpl" "/opt/tmp/lib/tpl"
rm -fr /var/www/html/lib/*
cp -R /opt/tmp/lib/* /var/www/html/lib/
chown -R www-data /var/www/html/lib

# Start Server
docker-php-entrypoint apache2-foreground

docker-compose.yml

version: '3'

services:

  web:
    build: .
    ports:
      - 80
    volumes:
      - /some-folder/wiki/data:/var/www/html/data
      - /some-folder/wiki/lib:/var/www/html/lib
      - /some-folder/wiki/conf:/var/www/html/conf

I would agree that upgrading the lib folder like that is not very clean... but I guess that it can be a temporary workaround. What do you think? Is there an aspect that I forgot to handle?

Regards,

@DidierHoarau, I'm looking for way to host Dokuwiki for production use , did you tried your code, can I use it not for testing but for production?

Also, several ideas: what about nginx + php-fpm and Alpine for both?..

Docuwiki have not official (with _ prefix) image, and it's really bad for community. You will get much more users after that...

@DidierHoarau, I'm looking for way to host Dokuwiki for production use , did you tried your code, can I use it not for testing but for production?

Also, several ideas: what about nginx + php-fpm and Alpine for both?..

Hi @lorddaedra ,

I've tested part of my code. Actually after your comment I've made further tests and I found some issues. I will try to check and post update here if I find a way to fix them. That said, You should be careful about what I post. I'm not a Dokuwiki expert and you will need to make some more tests on your side. On my side, I am using it for non-critical data.

Also, I tend to prefer nginx but in that case the configuration with Apache was easier.

Regards

Hello,

I used the bitnami/dokuwiki image (https://hub.docker.com/r/bitnami/dokuwiki/) and it's quite perfect for me.
Actually I had a physical dokuwiki server already installed and I migrated all data content folder in my new docker installation (with volume) and It's fine .

But, almost all my plugins were installed and functionnal; except one : graphviz (https://www.dokuwiki.org/plugin:graphviz).
I installed /usr/bin/dot binary in my container but still not working.

I tried with another image : https://hub.docker.com/r/michaelsiebertz/dokuwiki/ with graphviz already installed in it. The image is working without data persistent volume.
And I absolutely need persistent volume to put all data I've got from my actual dokuwiki .

So,
To sum up :

• I found 1 image works with volument persistence but not graphviz plugin
• I found 1 image works with graphviz plugin but not persistence volume

If someone knows how to fix this or has already got a functionnal image with graphviz plugin And Data Volume persistence . I am very interested in it.

Little additionnal point : I am using Rancher to deploy my containers and I didn't find how to use --volume-from option in Rancher.

Thank you in advance.

Best Regards

i have some weird idea, maybe it's something worth.

build official dokuwiki image containing only data. one wanting to use it builds their own images from whatever origin:

FROM dokuwiki:20170219e as doku-src
FROM php:7.0-apache

COPY --from=doku-src /usr/src/dokuwiki /usr/src/dokuwiki

and the official image is just built from scratch:

FROM scratch
ADD https://download.dokuwiki.org/src/dokuwiki/dokuwiki-stable.tgz /usr/src/dokuwiki.tar.gz

benefit is that such data only image is easy to use, and trusted, perhaps even signed. it could later contain useful scripts for entrypoint or plugin installation...

I have also created a container, and the data persistence works pretty well.

https://github.com/riotkit-org/docker-dokuwiki

I resolved it by moving data, lib and conf directory out of the project at build stage, and at entrypoint copying them to the project when volumes are mounted.

So here's the deal: we will add an official Docker image when someone creates a build config that solves the plugin problem of #791.

@splitbrain So do you consider the approach described here #791 (comment) and here #791 (comment) a viable solution?

I have reopened this issue, because I came up with an IMHO very elegant solution to the problem of separating out user files from the DokuWiki setup: an overlay file system.

My first approach is available in PR #3381 - the basics seem to work just fine, but help with actually improving the image are welcome.

I have reopened this issue, because I came up with an IMHO very elegant solution to the problem of separating out user files from the DokuWiki setup: an overlay file system.

My first approach is available in PR #3381 - the basics seem to work just fine, but help with actually improving the image are welcome.

I haven't seen this approach before, but it looks like something worth trying.

One thing I'm not so sure about is that this will lead to all changed files being kept in the host-mounted persistent volume regardless of their actual purpose. Usually we want to separate between directories that contain persistent data and expose them as volumes and other directories like cache, logs, indexes, etc. that aren't exposed at all.

Also the need to keep the overlayfs workdir inside the volume is not that neat, as it also only contains temporary data as far as I understand.

I will try to build the experimental image and post my results to the PR thread.

I am closing this issue in favor of a follow up one at #4261