Skip to content

Latest commit

 

History

History
72 lines (53 loc) · 4.31 KB

README.md

File metadata and controls

72 lines (53 loc) · 4.31 KB

Gibbon in Docker

What this setup does

The Dockerfiles in php and webserver create minimal images with apache, configured for php-fpm, and php-fpm to enable gibbon to run.

docker-compose.yml assumes there is an additional reverse proxy - in this case jwilder/nginx-proxy, either running in one container or running nginx and docker-gen separated, on the network "webfront". It further assumes there is an external network "backup" for accessing the database to create backups i.e. with Bareos in Docker.

If you migrate your database put your databasedump in ./db/initdb/ before the first time you run docker-compose up -d. Adjustments to the database, like migration to another URL have to be done by you either in advance in the dump or via SQL using the mysql client.

Since the download URL pattern on Github changed from version 21.0.01 to 22.0.00 it is no longer possible to download 21.0.01.

What you have to do

Basic Setup

If you want to run gibbon without a separate reverse proxy you can use docker-compose.simple.yml:

  1. Clone the repo
  2. rename docker-compose.simple.yml to docker-compose.yml
  3. copy example.env to .env
  4. change the values in .env to match your domain, and LOCALE and passwords
  5. run docker-compose pull
  6. run docker-compose build
  7. run docker-compose up -d
  8. visit your server the way you set it up either via a domain name or via ip:80 and start the Gibbon web based setup process

Setup with reverse Proxy and TLS

  1. Clone the repo
  2. run docker network create webfront
  3. run docker network create backup
  4. setup jwilder/nginx-proxy in a separate docker-compose project. If you plan on using it in production add letsencrypt-nginx-proxy-companion to your nginx-proxy setup
  5. add the network webfront to nginx-proxy
  6. copy example.env to .env
  7. change the values in .env to match your domain, and LOCALE and passwords
  8. run docker-compose pull
  9. run docker-compose build
  10. run docker-compose up -d
  11. visit your server the way you set it up either via a domain name or via ip:80 and start the Gibbon web based setup process

Upgrade

Upgrades paths tested:

  • 21.0.01 to 22.0.00 (with older php - version)
  • 22.0.01 to 23.0.02 (with older php - version)
  • 24.0.01 to 25.0.01 (with php 8.1, 8.2 and 8.3)
  • 25.0.01 to 26.0.00 (with php 8.1, 8.2 and 8.3)

Attention: Upgrades from older Gibbon - versions were tested with older php - versions. If an upgrade won't work, try switching to an older php - version in php/Dockerfile. Nonetheless I' recommend using recent versions of gibbon and php to profit from security patches.

The upgrade procedure reflects https://docs.gibbonedu.org/administrators/getting-started/updating-gibbon/.

  1. Backup your database and installation files.
  2. edit your .env file to reflect the desired version
  3. Login to your Gibbon installation and go to Admin > System Admin > Update
  4. run docker-compose up -d
  5. Refresh the Update page, and it should show there are some database updates to be run. Run these by pressing the Submit button.

Backupstrategy

As mentioned above a separate backup network is created for using backup software like Bareos to backup the database. The volume where your gibbon data resides should also be backed up. Since I use a docker volume I tend to mount it in a bareos filedaemon container and use bareos.

Another option would be to use a directory on your host to mount into $GIBBON_BASEDIR and any backup mechanism for your docker host system. Backupscripts, and scripts for backup rotation are also added to the database container and executed by the ofelia (crontab) container. So you find your databasebackups under ./db/backup.

Therefore you should be fine using tar, rsync, borg or any other tool on those two directories.

Reset your installation

With the bash script reset.sh you are able to start fresh.

Please use it with caution. It removes all the volumes, and therefore the database as well as the files, from the current project. I recommend executing it with bash ./reset.sh instead of changing its mode to executeable to prevent running it without thinking twice about deleting your data.