GibbonEdu / core

Gibbon is a flexible, open source school management platform designed to make life better for teachers, students, parents and leaders.
https://gibbonedu.org
GNU General Public License v3.0
460 stars 299 forks source link

Add Docker / docker-compose option to deploy gibbon #1762

Open mrestivill opened 8 months ago

mrestivill commented 8 months ago

Description The main idea is to simplify deployment of gibbon on servers using containers.

Motivation and Context This will also be deployed using docker-compose.yml using the original mysql/mariadb instance with users/password.

How Has This Been Tested? I've tested the deployment of the application using this command:

docker-compose -p gibbon up -d

Accessing the port http://localhost:80 also accessing to mysql using localhost:3306.

yookoala commented 8 months ago

Thanks for taking on this. I planned to do this a long time ago but was distracted.

Some thoughts:

  1. Exposing the root folder of Gibbon would defeat the purpose of containerize the site. I think the default image should only mount the uploads folder as volume, if possible.
  2. For better deployment flow, the hardcoded config file should be replaced with environment variables (i.e. dot env). Also the installer should support a semi-auto installation (i.e. with a docker specific config.php that takes environment variables, and the environment variable set correctly, the installer should start installing without user input of database information).
yookoala commented 8 months ago

One more thing. The minmal PHP version is now PHP 7.4. And I think the default PHP version of the container should be as new as possible (PHP 8.2 or 8.3) for security and features.

fvlasie commented 8 months ago

We may want to expose modules and themes folders too.....

mrestivill commented 8 months ago

I've changed the base docker image to apache, to simplify generation of the docker image. I've also added an entrypoint file to activate debug mode based on environment variables.

mrestivill commented 8 months ago

Next steps will be identify what variables we need on the runtime of the container to write config.php file.

mrestivill commented 8 months ago

I've added the 4 variables from config.php, I generate the file during startup when no config.php is found using env vars, also deletes install directory.

mrestivill commented 8 months ago

The config.php is generated with the environment variables but the database is empty, should I use gibbon.sql to initializate the database or some parameters on config.php to autoinitialize the app.

Thanks

mrestivill commented 8 months ago

I just added the sql file in docker-compose to initialize the bbdd.

mrestivill commented 5 months ago

@yookoala Hi, Could you have a look on the PR, thanks

kleo commented 5 months ago

Hi @mrestivill I've recently tried it out and this skips the installer.

While system requirements is ok and database settings are already setup using environment variables and docker-gibbon-entrypoint, for this setup how would I go on to create my administrator user account?

yookoala commented 5 months ago

@mrestivill: Working on a headless setup for this. May have something to add later. Sorry for the hold up (very busy these days).

@SKuipers if you find this good enough, please merge without my update. Thanks.

SKuipers commented 4 months ago

Thank you so much @mrestivill for your work on this and @yookoala for your feedback and ideas. My sincere apologies for the lack of a response, it's not for a lack of appreciation, but simply a lack of capacity. Its been an incredibly busy school year and I'm a full-time teacher on top of maintaining Gibbon. My school has, luckily, recently hired a university intern to help build capacity for Gibbon development. I am going to ask him to take a look at this and test it out for us in the coming week. It is interesting to see that it skips the installer. I wonder, longer term, what we could develop to help support headless installation?

yookoala commented 4 months ago

Thank you so much @mrestivill for your work on this and @yookoala for your feedback and ideas. My sincere apologies for the lack of a response, it's not for a lack of appreciation, but simply a lack of capacity. Its been an incredibly busy school year and I'm a full-time teacher on top of maintaining Gibbon. My school has, luckily, recently hired a university intern to help build capacity for Gibbon development. I am going to ask him to take a look at this and test it out for us in the coming week. It is interesting to see that it skips the installer. I wonder, longer term, what we could develop to help support headless installation?

I think it would help to have a semi-auto installation, such that user can:

  1. Setup a docker with existing database config injected through environment variable.
  2. Visit the docker and follow up the installation (i.e. site name, account, email, and other settings).

What Does it Mean for Docker Users?

Imagine a user installation through docker would be like:

  1. Install docker.
  2. Install 2 containers either by docker-compose or other orchestration service: (a) docker get mariadb (b) docker get gibbonedu/gibbon
  3. Setup mariadb to start with MARIADB_USER, MARIADB_PASSWORD, MARIADB_ROOTPASSWORD and etc (see their [official page](https://hub.docker.com//mariadb) for details about these variables).
  4. Setup gibbon to start with injected environment variable (a) mariadb's hostname (probably "mysql") through docker network. (b) mariadb's username and password (align with MARIADB_USER, MARIADB_PASSWORD above) (c) Add individual language folder / module to the container with VOLUME.
  5. Open a browser to start database installation without filling in the database setup step.
  6. Fill in site information in the next step on browser.
  7. Finished installation.

Why?

Site name and site informations should probably be filled by hand (unless we're talking about really massive deployment / some automatic Gibbon SaaS hosting). But database information should probably be automated or at least scriptable by a degree, especially for a docker container.

A containerized setup will probably have everything setup with scripts. The database server hostname, username, password would probably be setup automatically in the process. There is no need for the user to find out then manually fill-in those information by hands. Also, those information might be dynamically changed later.

In general, application following 12 factor methodology will be easier to automatically deploy and scale up. I think it will be good to make Gibbon docker feasible for such setup (I also described here before).

Another advantage would be to quickly setup for development and testing (Part of the reason I think of this is because I hated manually setup Gibbon again and again for testing).

How Things would Work?

My thinking is like:

  1. Add a config (template) variant / example that would setup things with getenv.
  2. Have an extra flag variable in config that accepts automatic setup. Installer will be run if (a) database config is correctly setup; and (b) there are no Gibbon tables in the database; and (c) the "acceptHeadlessSetup" flag (or something like this) is explicitly set to "true".
  3. After setup, the flag can explicitly set to "false" to prevent installer fired up for some sort of database failure.
  4. Maybe add support to .env file for development. (Optional)
mrestivill commented 4 months ago

The current proposed docker-compose.yml creates the database, and also executes the ./gibbon.sql file when the database is empty (see /docker-entrypoint-initdb.d folder used inside mysql docker documentation: https://hub.docker.com/_/mysql) . The admin user will be the default one inside gibbon.sql. Docker-compose also supports the use of .env file as a source of variables. The init script can be configured to obtain, as a variable, the admin user and generate a random password printed inside the logs. For now the password can be changed inside the application by admin (using default credentials) during setup as a poststep.

yookoala commented 4 months ago

The current docker-composer.yml setup is not bad. What I'm proposing should not block this PR. It is meant to be improvements to the docker file.

Ideally, the docker file should not depend on docker-compose. It should be useful on its own. A headless installation with environment variable support customized deployments different from one single default setup. And thus I think is more ideal than the current proposed changes. All that said, I don't yet have the time to finish my headless installer PR.

mrestivill commented 2 months ago

This Dockerfile does not depend on docker-compose. Docker-compose is an example of deployment with a standard database docker and gibbonEdu docker. The container can be configured with external database and also be deployed with standard database container.