Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
wants to merge 26 commits into
base: v27.0.00
Choose a base branch
from

Conversation

mrestivill
Copy link

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
Copy link
Member

yookoala commented Dec 4, 2023

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
Copy link
Member

yookoala commented Dec 4, 2023

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
Copy link
Member

fvlasie commented Dec 5, 2023

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

@mrestivill
Copy link
Author

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
Copy link
Author

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

@mrestivill
Copy link
Author

mrestivill commented Dec 21, 2023

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
Copy link
Author

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
Copy link
Author

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

@mrestivill
Copy link
Author

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

@kleo
Copy link

kleo commented Mar 26, 2024

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
Copy link
Member

@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
Copy link
Member

SKuipers commented Apr 8, 2024

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
Copy link
Member

yookoala commented Apr 8, 2024

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_ROOT_PASSWORD and etc (see their official page 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
Copy link
Author

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
Copy link
Member

yookoala commented Apr 9, 2024

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
Copy link
Author

mrestivill commented Jun 20, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants