crazy-max/docker-dokuwiki

DokuWiki Docker image

About

Docker image for DokuWiki, a simple to use and highly versatile Open Source wiki software that doesn't require a database.

Tip

Want to be notified of new releases? Check out 🔔 Diun (Docker Image Update Notifier) project!

---

• Features
• Build locally
• Image
• Environment variables
• Volumes
• Ports
• Usage
  • Docker Compose
  • Command line
• Upgrade
• Notes
  • Sending mails with SMTP
• Contributing
• License

Features

• Run as non-root user
• Multi-platform image
• msmtpd SMTP relay image to send emails
• Traefik as reverse proxy and creation/renewal of Let's Encrypt certificates (see this template)

Build locally

git clone https://github.com/crazy-max/docker-dokuwiki.git
cd docker-dokuwiki

# Build image and output to docker (default)
docker buildx bake

# Build multi-platform image
docker buildx bake image-all

Image

Registry	Image
Docker Hub	crazymax/dokuwiki
GitHub Container Registry	ghcr.io/crazy-max/dokuwiki

Following platforms for this image are available:

$ docker run --rm mplatform/mquery crazymax/dokuwiki:latest
Image: crazymax/dokuwiki:latest
 * Manifest List: Yes
 * Supported platforms:
   - linux/amd64
   - linux/arm/v6
   - linux/arm/v7
   - linux/arm64
   - linux/ppc64le
   - linux/s390x

Environment variables

• TZ: The timezone assigned to the container (default UTC)
• PUID: Dokuwiki user id (default 1500)
• PGID: Dokuwiki group id (default 1500)
• MEMORY_LIMIT: PHP memory limit (default 256M)
• UPLOAD_MAX_SIZE: Upload max size (default 16M)
• CLEAR_ENV: Clear environment in FPM workers (default yes)
• OPCACHE_MEM_SIZE: PHP OpCache memory consumption (default 128)
• LISTEN_IPV6: Enable IPv6 for Nginx (default true)
• REAL_IP_FROM: Trusted addresses that are known to send correct replacement addresses (default 0.0.0.0/32)
• REAL_IP_HEADER: Request header field whose value will be used to replace the client address (default X-Forwarded-For)
• LOG_IP_VAR: Use another variable to retrieve the remote IP address for access log_format on Nginx. (default remote_addr)
• DOKUWIKI_RUN_INDEXER: Run DokuWiki indexer on startup (default true)

Volumes

• /data: Contains configuration, plugins, templates and data

⚠️ Note that the volume should be owned by the user/group with the specified PUID and PGID. If you don't give the volume correct permissions, the container may not start.

Ports

• 8000: HTTP port

Usage

Docker Compose

Docker compose is the recommended way to run this image. Copy the content of folder examples/compose in /var/dokuwiki/ on your host for example. Edit the compose and env files with your preferences and run the following commands:

docker compose up -d
docker compose logs -f

Command line

You can also use the following minimal command :

docker run -d -p 8000:8000 --name dokuwiki \
  -v $(pwd)/data:/data \
  crazymax/dokuwiki:latest

Upgrade

Recreate the container whenever I push an update:

docker compose pull
docker compose up -d

Notes

Sending mails with SMTP

A Dokuwiki SMTP Plugin is available to send emails over external SMTP servers. When the plugin is installed you have to configure it:

Here we use our msmtpd service published on port 2500 declared in our compose.yml.

Contributing

Want to contribute? Awesome! The most basic way to show your support is to star the project, or to raise issues. You can also support this project by becoming a sponsor on GitHub or by making a PayPal donation to ensure this journey continues indefinitely!

Thanks again for your support, it is much appreciated! 🙏

License

MIT. See LICENSE for more details.

docker-dokuwiki's Issues

Issues running the container

The first issue was that it was expecting all the folders (attic, cache, index, locks, etc) in the root folder. I used the docker run command in the README.

The issue that stopped me though is this:
"For security reasons this script will only work with a new and unmodified Dokuwiki installation. You should either re-extract the files from the downloaded package or consult the complete Dokuwiki installation instructions"

I just git cloned the repo and ran it with the command you suggested. I didn't modify any files.

Plugins partially broken

Behaviour

Steps to reproduce this issue

1. Install the searchindex plugin
2. Try to reindex

Expected behaviour

The ui should update nicely and reindex all pages

Actual behaviour

Hangs at "Searching pages" and the developer console shows a 500 error. Errorlogs show:

2020/10/20 15:11:49 [error] 530#530: *75 FastCGI sent in stderr: "PHP message: PHP Warning:  require_once(//inc/init.php): failed to open stream: No such file or directory in /data/plugins/searchindex/ajax.php on line 17PHP message: PHP Fatal error:  require_once(): Failed opening required '//inc/init.php' (include_path='.:/usr/share/php7') in /data/plugins/searchindex/ajax.php on line 17" while reading response header from upstream

The reason for this is that searchindex (and maybe other plugins) construct DOKU_INC like this:
https://github.com/splitbrain/dokuwiki-plugin-searchindex/blob/32e56a59996ea3a10b3a70f0239fc13d58f1174b/ajax.php#L16

This breaks down when the plugins are symlinked into the data directory. Any ideas on how to improve this?

Confusion between `/data` & `/var/www`

Behaviour

It's difficult to understand how this image plays with data.
As Dockerfile (and documentation) tells there is a /data where to store data.
But the nginx seems configured to use /var/www as root.
And the data seems be copied at the both place but with different owners.

Steps to reproduce this issue

1. Fresh install with a empty binded volume on /data
2. Specify PUID/PGID (for my case it's 1007) through env
3. Start image

Expected behaviour

We should see data only in /data and not in /var/www

Actual behaviour

The data are copied at the two places. In /data folder it's chowned as expected with right PUID/PGID but in /var/www it's an other uid/gid and nginx reads data into this folder.
As nginx is started through 1007:1007 it fails to write into these folder as /install.php tells us

    {DOCUMENT_ROOT}/data is not writable by DokuWiki. You need to fix the permission settings of this directory!
    {DOCUMENT_ROOT}/data/pages is not writable by DokuWiki. You need to fix the permission settings of this directory!
    {DOCUMENT_ROOT}/data/attic is not writable by DokuWiki. You need to fix the permission settings of this directory!
    {DOCUMENT_ROOT}/data/media is not writable by DokuWiki. You need to fix the permission settings of this directory!
    {DOCUMENT_ROOT}/data/media_attic is not writable by DokuWiki. You need to fix the permission settings of this directory!
    {DOCUMENT_ROOT}/data/media_meta is not writable by DokuWiki. You need to fix the permission settings of this directory!
    {DOCUMENT_ROOT}/data/meta is not writable by DokuWiki. You need to fix the permission settings of this directory!
    {DOCUMENT_ROOT}/data/cache is not writable by DokuWiki. You need to fix the permission settings of this directory!
    {DOCUMENT_ROOT}/data/locks is not writable by DokuWiki. You need to fix the permission settings of this directory!
    {DOCUMENT_ROOT}/data/index is not writable by DokuWiki. You need to fix the permission settings of this directory!
    {DOCUMENT_ROOT}/data/tmp is not writable by DokuWiki. You need to fix the permission settings of this directory!

Configuration

• Include all necessary configuration files : docker-compose.yml, .env, ...

version: '2.4'

services:
  dokuwiki:
    image: crazymax/dokuwiki:latest
    volumes:
      - './data:/data'
    environment:
      - PUID=1007
      - PGID=1007
    networks:
      - web
    restart: unless-stopped
    labels:
      traefik.enable: "True"
      traefik.frontend.rule: "Host:doku.xxxx.vv"

networks:
  web:
    external: true

Logs

> Container logs (set LOG_LEVEL to debug if applicable)
dokuwiki_1  | [s6-init] making user provided files available at /var/run/s6/etc...exited 0.
dokuwiki_1  | [s6-init] ensuring user provided files have correct perms...exited 0.
dokuwiki_1  | [fix-attrs.d] applying ownership & permissions fixes...
dokuwiki_1  | [fix-attrs.d] done.
dokuwiki_1  | [cont-init.d] executing container initialization scripts...
dokuwiki_1  | [cont-init.d] 00-fix-logs.sh: executing...
dokuwiki_1  | [cont-init.d] 00-fix-logs.sh: exited 0.
dokuwiki_1  | [cont-init.d] 01-fix-uidgid.sh: executing...
dokuwiki_1  | [cont-init.d] 01-fix-uidgid.sh: exited 0.
dokuwiki_1  | [cont-init.d] 02-fix-perms.sh: executing...
dokuwiki_1  | Fixing perms...
dokuwiki_1  | [cont-init.d] 02-fix-perms.sh: exited 0.
dokuwiki_1  | [cont-init.d] 03-config.sh: executing...
dokuwiki_1  | Setting timezone to UTC...
dokuwiki_1  | Setting PHP-FPM configuration...
dokuwiki_1  | Setting PHP INI configuration...
dokuwiki_1  | Setting OpCache configuration...
dokuwiki_1  | Setting Nginx configuration...
dokuwiki_1  | Initializing DokuWiki files / folders...
dokuwiki_1  | Adding preload.php...
dokuwiki_1  | Copying global config...
dokuwiki_1  | First install detected...
dokuwiki_1  | Creating initial data folder...
dokuwiki_1  | Bootstrapping configuration...
dokuwiki_1  | Saving bundled plugins list... 30 found
dokuwiki_1  | Saving bundled templates list... 2 found
dokuwiki_1  | Checking user plugins in /data/plugins...
dokuwiki_1  | Checking user templates in /data/tpl...
dokuwiki_1  | >>
dokuwiki_1  | >> Open your browser to install DokuWiki through the wizard (/install.php)
dokuwiki_1  | >>
dokuwiki_1  | [cont-init.d] 03-config.sh: exited 0.
dokuwiki_1  | [cont-init.d] 04-create-services.sh: executing...
dokuwiki_1  | [cont-init.d] 04-create-services.sh: exited 0.
dokuwiki_1  | [cont-init.d] done.
dokuwiki_1  | [services.d] starting services
dokuwiki_1  | [services.d] done.
dokuwiki_1  | Setting up watches.
dokuwiki_1  | Watches established.
dokuwiki_1  | 2020/04/14 13:04:03 [notice] 305#305: using the "epoll" event method
dokuwiki_1  | 2020/04/14 13:04:03 [notice] 305#305: nginx/1.16.1
dokuwiki_1  | 2020/04/14 13:04:03 [notice] 305#305: OS: Linux 4.9.185-xxxx-std-ipv6-64
dokuwiki_1  | 2020/04/14 13:04:03 [notice] 305#305: getrlimit(RLIMIT_NOFILE): 1048576:1048576
dokuwiki_1  | 2020/04/14 13:04:03 [notice] 305#305: start worker processes
dokuwiki_1  | 2020/04/14 13:04:03 [notice] 305#305: start worker process 327
dokuwiki_1  | 2020/04/14 13:04:03 [notice] 305#305: start worker process 328
dokuwiki_1  | 2020/04/14 13:04:03 [notice] 305#305: start worker process 329
dokuwiki_1  | 2020/04/14 13:04:03 [notice] 305#305: start worker process 330
dokuwiki_1  | [14-Apr-2020 13:04:03] NOTICE: fpm is running, pid 307
dokuwiki_1  | [14-Apr-2020 13:04:03] NOTICE: ready to handle connections

Maybe I just don't understand where is my mistake, but don't see where is it

Containers do not shut down properly

Behaviour

A sudo time docker stop -t 15 wiki takes 15 seconds to execute, which seems to indicate that the container needed to be killed

Steps to reproduce this issue

sudo docker run -d --name wiki crazymax/dokuwiki:edge
sudo time docker stop --time 15 wiki
wiki
0.05user 0.01system 0:15.28elapsed 0%CPU (0avgtext+0avgdata 59948maxresident)k
128inputs+0outputs (1major+7511minor)pagefaults 0swaps

The container process seems to shut down quickly:

2021/02/20 10:54:25 [notice] 494#494: signal 15 (SIGTERM) received from 487, exiting
[20-Feb-2021 10:54:25] NOTICE: Terminating ...
2021/02/20 10:54:25 [notice] 530#530: exiting
2021/02/20 10:54:25 [notice] 569#569: exiting
2021/02/20 10:54:25 [notice] 591#591: exiting
2021/02/20 10:54:25 [notice] 542#542: exiting
2021/02/20 10:54:25 [notice] 534#534: exiting
2021/02/20 10:54:25 [notice] 532#532: exiting
2021/02/20 10:54:25 [notice] 529#529: exiting
2021/02/20 10:54:25 [notice] 531#531: exiting
2021/02/20 10:54:25 [notice] 569#569: exit
2021/02/20 10:54:25 [notice] 531#531: exit
2021/02/20 10:54:25 [notice] 534#534: exit
2021/02/20 10:54:25 [notice] 529#529: exit
[20-Feb-2021 10:54:25] NOTICE: exiting, bye-bye!
2021/02/20 10:54:25 [notice] 542#542: exit
2021/02/20 10:54:25 [notice] 591#591: exit
2021/02/20 10:54:25 [notice] 530#530: exit
2021/02/20 10:54:25 [notice] 532#532: exit
2021/02/20 10:54:25 [notice] 494#494: signal 17 (SIGCHLD) received from 529
2021/02/20 10:54:25 [notice] 494#494: worker process 529 exited with code 0
2021/02/20 10:54:25 [notice] 494#494: worker process 531 exited with code 0
2021/02/20 10:54:25 [notice] 494#494: worker process 532 exited with code 0
2021/02/20 10:54:25 [notice] 494#494: signal 29 (SIGIO) received
2021/02/20 10:54:25 [notice] 494#494: signal 17 (SIGCHLD) received from 569
2021/02/20 10:54:25 [notice] 494#494: worker process 569 exited with code 0
2021/02/20 10:54:25 [notice] 494#494: signal 29 (SIGIO) received
2021/02/20 10:54:25 [notice] 494#494: signal 17 (SIGCHLD) received from 534
2021/02/20 10:54:25 [notice] 494#494: worker process 534 exited with code 0
2021/02/20 10:54:25 [notice] 494#494: signal 29 (SIGIO) received
2021/02/20 10:54:25 [notice] 494#494: signal 17 (SIGCHLD) received from 530
2021/02/20 10:54:25 [notice] 494#494: worker process 530 exited with code 0
2021/02/20 10:54:25 [notice] 494#494: signal 29 (SIGIO) received
2021/02/20 10:54:25 [notice] 494#494: signal 17 (SIGCHLD) received from 591
2021/02/20 10:54:25 [notice] 494#494: worker process 542 exited with code 0
2021/02/20 10:54:25 [notice] 494#494: worker process 591 exited with code 0
2021/02/20 10:54:25 [notice] 494#494: exit

but from the looks of it not all processes got reaped:

➜  ~ sudo docker exec wiki ps -ef
PID   USER     TIME  COMMAND
    1 root      0:00 s6-svscan -t0 /var/run/s6/services
  721 root      0:00 s6-supervise socklog/log
  723 root      0:00 s6-supervise socklog
  728 nobody    0:00 socklog unix /dev/log
  729 nobody    0:00 s6-log -bp - +^cron\. T /var/log/socklog/cron - +^daemon\. T /var/log/socklog/daemon - +^\.debug: T /var/log/socklog/debug - +\..err: +\.error: +\.emerg: +\.alert: +\.crit: T /var/log/socklog/errors + -auth\. -authpriv\. T /var/log/socklog/everything - +^kern\. T /var/log/socklog/kernel - +^mail\. T /var/log/socklog/mail - +\.info: +\.notice: +\.warn: -^auth\. -^authpriv\. -^mail\. -^news\. -^cron\. T /var/log/socklog/messages - +^auth\. +^authpriv\. T /var/log/socklog/secure - +^user\. T /var/log/socklog/user
  742 dokuwiki  0:00 inotifywait -m /data/plugins /var/www/lib/plugins /data/tpl /var/www/lib/tpl
  744 dokuwiki  0:00 {watch_folders} /bin/sh /usr/local/bin/watch_folders
 1061 root      0:00 ps -ef

Expected behaviour

Container should shut down cleanly

Actual behaviour

Container only shut down after stop time elapsed

Configuration

• Docker version (type docker --version) : Docker version 20.10.3, build 48d30b5
• Docker compose version if applicable (type docker-compose --version) :
• Platform (Debian 9, Ubuntu 18.04, ...) : Fedora 33
• System info (type uname -a) : Linux apollo13 5.10.15-200.fc33.x86_64 #1 SMP Wed Feb 10 17:46:55 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
• Include all necessary configuration files : docker-compose.yml, .env, ...

Can you add the package php81-iconv

Behaviour

Steps to reproduce this issue

1. latest instance of image
2. bootstrap3 template and gallery plugin
3. I have a gallery includes in a page and get the error

Expected behaviour

Tell me what should happen

Actual behaviour

Error: Call to undefined function iconv()
/data/tpl/bootstrap3/inc/simple_html_dom.php(1763)
#0 /data/tpl/bootstrap3/inc/simple_html_dom.php(1544): simple_html_dom->parse_charset()

After installing with apk php81-iconv package and restarting the container it was fixed. So could you please add to the next image this package?

Thanks Christian

Missing SQLite & PDO SQLite support (unable to use some plugins)

Steps to reproduce this issue

After a fresh install go to Admin Panel > Extension Manager and install both struct Plugin and sqlite Plugin. Then go to Admin Panel > Additional Plugins > Struct Schema Assignments

Expected behaviour

No errors, and plugins working properly.

Actual behaviour

Page shows these errors:

• SQLite & PDO SQLite support missing in this PHP install - plugin will not work
• The struct plugin requires the sqlite plugin. Please install and enable it.

---

So please, could you include php7-pdo_sqlite and php7-sqlite3 also?

Thank you!

Support for an option to disable reindex behavior

Currently the image unconditionally runs the indexer during startup

docker-dokuwiki/rootfs/etc/cont-init.d/03-config.sh

Line 119 in 916478c

runas_user php7 /var/www/bin/indexer.php -c

Since the whole data directory is mapped this should usually not be needed. It would be great if it were possible to add an option to disable indexing (after all the pages + index should be in sync anyways). What is the rationale behind reindexing? Depending on the fs and wiki size this can be rather slow so I'd like to avoid it.

I see two options:

• Drop the code completely
• Add an env var to disable it

Personally I'd go for option 1, but maybe I miss an important reason for doing this during startup. I Could write a PR if you tell me which approach you'd prefer.

HTTPS

I'd like this to work via HTTPS. Only HTTP is mentioned on port 8000. Is this by design and can this be done via traefik as a reverse proxy? I can see an example but need a bit more to go on if you can explain.

Can write pages but not conf/local.php (change settings)

Hello
Thanks for this great docker image :-)

I've all running well except editing "Configuration Settings" is not saved event with "superuser" account. I can edit pages. Filesystem rights are same for page & conf/local.php. To change config I've to edit local.php by hand.

But I can edit ACL and extensions activation, the conf/act.auth.php and conf/plugins.local.php are well modified ...

docker image : crazymax/dokuwiki latest sha256:77e30e47cb0d71f9b18871953b908fcf124ccad37a611f9b3fa297a58f840644
with dokuwiki Release 2020-07-29 "Hogfather"

Have u got any idea ? Thanks.

Sending notification emails?

Hi, thanks for putting this Dockerfile together!

One thing that's apparently lacking is outgoing email notification support. Do you happen to know how that could be added? Unfortunately my own experience level with this stuff ranges from "minimal" to "nonexistent".

It looks like the required steps are something like this:

1. Install and configure MSMTP to act as a sendmail alternative, because the Busybox built-in sendmail is very limited
2. Configure PHP to use MSMTP as above, via sendmail_from and sendmail_path in php.ini file.
3. Add the appropriate variables to the Docker-compose file for your send-from address, SMTP account info, etc., and inject them into the Dockerfile where needed.

Does that seem right?

And step 3 this actually need to be done? Or can php.ini be safely written in the data directory from the "host side", once the container has been created?

Latest version on Raspberry Pi 4 (latest upgrade)

I get the following loop in the logs with this:

s6-svscan: warning: unable to iopause: Operation not permitted,
s6-svscan: warning: executing into .s6-svscan/crash,
s6-supervise s6-fdholderd: fatal: unable to iopause: Operation not permitted,
s6-svscan panicked! Dropping to a root shell.,
/bin/sh: can't access tty; job control turned off,
/run/s6/services # ,
s6-svscan: warning: unable to iopause: Operation not permitted,
s6-svscan: warning: executing into .s6-svscan/crash,
s6-supervise s6-fdholderd: fatal: unable to iopause: Operation not permitted,
s6-svscan panicked! Dropping to a root shell.,
/bin/sh: can't access tty; job control turned off,
/run/s6/services # ,
s6-svscan: warning: unable to iopause: Operation not permitted,
s6-supervise s6-fdholderd: fatal: unable to iopause: Operation not permitted,
s6-svscan: warning: executing into .s6-svscan/crash,
s6-svscan panicked! Dropping to a root shell.,
/bin/sh: can't access tty; job control turned off,
/run/s6/services # ,
s6-svscan: warning: unable to iopause: Operation not permitted,
s6-svscan: warning: executing into .s6-svscan/crash,
s6-supervise s6-fdholderd: fatal: unable to iopause: Operation not permitted,
s6-svscan panicked! Dropping to a root shell.,
/bin/sh: can't access tty; job control turned off,
/run/s6/services # ,
s6-svscan: warning: unable to iopause: Operation not permitted,
s6-svscan: warning: executing into .s6-svscan/crash,
s6-svscan panicked! Dropping to a root shell.,
s6-supervise s6-fdholderd: fatal: unable to iopause: Operation not permitted,
/bin/sh: can't access tty; job control turned off,
/run/s6/services # ,
s6-svscan: warning: unable to iopause: Operation not permitted,
s6-svscan: warning: executing into .s6-svscan/crash,
s6-supervise s6-fdholderd: fatal: unable to iopause: Operation not permitted,
s6-svscan panicked! Dropping to a root shell.,
/bin/sh: can't access tty; job control turned off,
/run/s6/services #

There is some noise around s6 and a bug in Apline 3.13. How do I pull an earlier release (I tried with a version name as per the git repo, but that does not work)

Correct way to mount data

Behaviour

Steps to reproduce this issue

I already have an existing installation of dokuwiki, local on my host.
I want to use the same files to mount them on the container and serve them from there. These files are owned by my personal user with UID/GID=1000

1. Edit the docker-compose.yml file to mount the volume:

    volumes:
      - "<absoulte_path>/dokuwiki/data:/data"

2. Set PUID and PGID=1000 in .env.
3. docker compose up -d --build

Expected behaviour

I expected the wiki to be immediately hosted in localhost:8000.

Actual behaviour

The first weird thing is that the image looks for the /data/conf/local.protected.php to decide if this is a first installation. My installation didn't have this file, so I created it manually.
Still, when I start the container, line 69 in https://github.com/crazy-max/docker-dokuwiki/blob/master/rootfs/etc/cont-init.d/03-config.sh#L69 looks for /data/data to decide if the data folder has been initialized. Of course, this doesn't exist, because I mounted my dokuwiki/data folder, not dokuwiki.
Fair enough, I change my `docker-compose.yml into

    volumes:
      - "<absoulte_path>/dokuwiki:/data"

But now I get

Copying global config...
cp: can't create '/data/conf/mediameta.php': Permission denied
cp: can't create '/data/conf/entities.conf': Permission denied
cp: can't create '/data/conf/.htaccess': Permission denied
cp: can't create '/data/conf/scheme.conf': Permission denied
cp: can't create '/data/conf/users.auth.php.dist': Permission denied
cp: can't create '/data/conf/wordblock.conf': Permission denied
cp: can't create '/data/conf/acronyms.conf': Permission denied
cp: can't create '/data/conf/smileys.conf': Permission denied
cp: can't create '/data/conf/mime.conf': Permission denied
cp: can't create '/data/conf/license.php': Permission denied
cp: can't create '/data/conf/acl.auth.php.dist': Permission denied
cp: can't create '/data/conf/local.php.dist': Permission denied
cp: can't create '/data/conf/plugins.php': Permission denied
cp: can't create '/data/conf/manifest.json': Permission denied
cp: can't create '/data/conf/plugins.required.php': Permission denied
cp: can't create '/data/conf/dokuwiki.php': Permission denied
cp: can't create '/data/conf/mysql.conf.php.example': Permission denied
cp: can't create '/data/conf/interwiki.conf': Permission denied

Upon inspecting the mounted folder in my host, I see that both /data/plugins and /data/tpl folders are owned by a user named "100999", so something is definitely wrong, but I can't put my finger on it.

Any pointers, especially in the correct volume mount incantation? Thanks in advance!

Configuration

• Docker version (type docker --version) : Docker version 20.10.17, build 100c701

• Docker compose version if applicable (type docker-compose --version) : N/A, now using docker compose instead of docker-compose

• Platform (Debian 9, Ubuntu 18.04, ...) : Ubuntu 22.04

• System info (type uname -a) : Linux george-ThinkPad-E14-Gen-2 5.15.0-46-generic #49~20.04.1-Ubuntu SMP Thu Aug 4 19:15:44 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

• Include all necessary configuration files : docker-compose.yml, .env, ...

Docker info

> Output of command `docker info`

Logs

> Container logs (set LOG_LEVEL to debug if applicable)