feat(docker): application build via docker#2037
feat(docker): application build via docker#2037zaidmasri wants to merge 3 commits intoGibbonEdu:v31.0.00from
Conversation
|
@SKuipers is there anything I can do to help make this easier for your review? |
|
Hi @zaidmasri Thank you so much for your PR, my sincere apologies for the delay in responding. I have kept trying to find a moment to have a look, with the Christmas break leading into Chinese New Year (a busy time of year in Hong Kong). There was another PR started with a Docker file as well, I wonder if these are compatible of if your new docker compose file would supersede it? Thanks again for your contribution, we greatly appreciate it. At the moment we're a very small team with limited capacity, but we are keen to modernize the codebase with these types of improvements. |
|
Hi @zaidmasri Thanks for submitting this. Docker support is a great addition to Gibbon! I've reviewed the Dockerfile in detail and fixed a few minor issues mainly for consistency. I've opened a follow-up PR with fixes applied and fully tested. PR: https://github.com/GibbonEdu/core/pull/2077/commits. All of the above have been fixed and tested in my PR. The updated setup was verified on macOS (Apple Silicon, Docker 29.2.1). The installer loads cleanly, all system requirement checks pass, and the database connection succeeds. Before the changes are merged, could you please take a look and review and test the changes there? Please take a look and let me know if you have any questions. Happy to discuss any of the changes. |
| @@ -0,0 +1,54 @@ | |||
| FROM php:8.2-apache | |||
There was a problem hiding this comment.
PHP version 8.2 is hard-coded into the Dockerfile here. In case developers want to use other PHP versions, might be better to declare a PHP_VERSION build time ARG variable and interpolate it into this FROM declaration. The value for PHP_VERSION can come from a .env file which is read in by docker-compose.yml.
| WORKDIR /var/www/html | ||
|
|
||
| # 4. Clone Gibbon v31 (Latest Stable) | ||
| RUN git clone --depth 1 --branch v31.0.00 https://github.com/GibbonEdu/core.git . \ |
There was a problem hiding this comment.
I think this will bake in the Gibbon version 31 source code into the Docker image. For a local development environment, it would be better to mount the source code as a volume in docker-compose.yml. Any changes made to the source code can then be seen in your local Gibbon installation running as a Docker application.
For a production deployment, baking in a specific version of Gibbon source code is correct, but the version number is still hard-coded.
| && rm -rf .git | ||
|
|
||
| # 5. Install PHP Dependencies | ||
| RUN composer install --no-dev --optimize-autoloader |
There was a problem hiding this comment.
Another way is to install composer dependencies outside of the Docker build process by executing docker-compose exec -T app composer install. This will shorten the Docker image build time.
| RUN echo "upload_max_filesize = 50M" > /usr/local/etc/php/conf.d/gibbon.ini \ | ||
| && echo "post_max_size = 50M" >> /usr/local/etc/php/conf.d/gibbon.ini \ | ||
| && echo "max_input_vars = 5000" >> /usr/local/etc/php/conf.d/gibbon.ini \ | ||
| && echo "memory_limit = 256M" >> /usr/local/etc/php/conf.d/gibbon.ini |
There was a problem hiding this comment.
The PHP environment values are hardcoded here. Instead, could have an external PHP config file with these values in it then mount this config file as a volume in docker-compose.yaml.
| restart: always | ||
|
|
||
| db: | ||
| image: mysql:8.0 |
There was a problem hiding this comment.
The version of MySQL is hardcoded here. Could keep the version number in a .env file instead so it can be more easily configured.
|
Hi @zaidmasri, Nice work with this Docker setup, I managed to get it working. I have some comments below. For a local development environment, I think it's better to mount the Gibbon source code as volumes in docker-compose.yaml because it looks like it is baked into the image using git clone in Dockerfile. If you make any changes to your local source code then they would then be seen in Gibbon that you have running locally as a Docker application. Various variable values are hardcoded - it would be good to have these in a .env file so that they can be more easily configured. Perhaps have default values in a .env-template file that users can copy into the root directory of the Gibbon repo. There are already a lot of files in the repo's root directory. Maybe have a new directory called To make it easier to start a Gibbon Docker application, could have the Docker build commands in a |
4 participants
Description
This PR introduces a Docker-based local development environment for Gibbon Core. It modernizes the repository's tooling by providing a standardized containerized setup, eliminating "works on my machine" issues.
The setup is split into two modular configuration files:
docker-compose.yaml: The base configuration defining the core services (appanddb), networks, and volumes suitable for production-like builds.docker-compose.dev.yaml: A development override that exposes ports (e.g.,8080) and sets environment variables specifically for local testing.Motivation and Context
Currently, setting up a local Gibbon development environment requires manually configuring PHP, Apache, and MySQL, which can be error-prone and inconsistent across operating systems (macOS, Windows, Linux).
This change solves the following problems:
bcmath,intl,gd, etc.) required by Gibbon v31+.How Has This Been Tested?
I have tested these changes on macOS (Intel) using Docker Compose CLI and deployed to a production-like environment using Coolify.
Test Scenarios:
http://localhost:8080.appcontainer can successfully communicate with thedbcontainer using the hostnamedband default credentials.bcmath,gd,zip) are loaded and functional.How to Run (Instructions for Reviewers)
Option 1: Local Development (Recommended)
This command uses the override file to expose the app on port
8080.dbgibbon/gibbonpassOption 2: Production/Base Build
To test the standalone base configuration (no ports exposed to host by default, mimics production internal networking):
Shutdown:
To stop containers and remove volumes (resetting the database):
Screenshots
Local
VPS
Below is the configuration used to deploy this branch via Coolify. By pointing the setup wizard to the fork containing these Docker files, the platform automatically handled the build and deployment process without manual intervention.
Future Enhancements
Dynamic Extension Loading: Support for installing additional PHP extensions via build arguments or configuration files.
CI/CD Pipeline Integration: Automate the build and publication of the Docker image to a container registry (e.g., GHCR). This will allow users to pull a pre-built image rather than building from source locally.
Headless Provisioning: Enable full instance configuration via environment variables to bypass the web-based installation wizard, facilitating automated/unattended deployments.
I would appreciate your feedback on edge cases you perceive, particularly if I were to use this as a production build