Open mrestivill opened 8 months ago
Thanks for taking on this. I planned to do this a long time ago but was distracted.
Some thoughts:
config.php
that takes environment variables, and the environment variable set correctly, the installer should start installing without user input of database information).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.
We may want to expose modules and themes folders too.....
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.
Next steps will be identify what variables we need on the runtime of the container to write config.php file.
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.
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
I just added the sql file in docker-compose to initialize the bbdd.
@yookoala Hi, Could you have a look on the PR, thanks
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?
@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.
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?
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:
Imagine a user installation through docker would be like:
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).
My thinking is like:
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.
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.
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.
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:
Accessing the port
http://localhost:80
also accessing to mysql usinglocalhost:3306
.