Closed surrealchemist closed 1 year ago
Hi @surrealchemist ,
What is your intended use-case? This image is intended for development and not production. It is not a thin image - it contains a lot of dependencies that you are highly unlikely to need on a standard production system and you would be better off using the standard php images tailored to your requirement and needs.
All of the images I came across did things with bootstrapping that didn't make sense for running in container service and it was the closest I could find without having to create one from scratch which I didn't have time to do.
I could go back and rebuild it piece by piece at some point but it would take time from my other work. Since we are a non-profit which doesn't primarily focus on tech we don't have a large staff and plenty going on all the time.
Our previous moodle instances are on a server that is now out of date, and would take more work to replace. The price for AWS ECS Fargate is very low and allows us to easily automate updating, where our old instance had a very cobbled together workflow using git running on an EC2 server. Upgrading PHP packages and the OS is a task we don't want to be stuck with again as everything else we have now is moving to container services.
The architecture we have set up is similar to this, without the CDN or Redis, and I am using AWS Copilot to manage/deploy everything instead. https://aws.amazon.com/blogs/publicsector/modernize-moodle-lms-aws-serverless-containers/ Their reference uses bitnami's moodle image but that had a lot going on that would have created me more work just to simplify it to work the way we want. I have a config file that is set up to automatically pull from environment variables and those can be maintained as secrets which are stored in SSM or Secret Manager so they aren't exposed.
The goal is to have it managed by code so I don't have to babysit everything, leveraging copilot which helps set up load balancer/database/persistent storage. I can spin up new environments easily instead of relying on a single point of failure hosting things on a single server.
Thanks for the background @surrealchemist,
The issue we have is that this image is very fat. It includes drivers for postgres, mysql/mariadb/aurora, Oracle DB, and MS SQL Server. It also includes every possible extension that any possible Moodle feature may require, from memcached, to redis, to solr, to ldap, and half a dozen others that most people do not want.
Generally speaking the recommendation is to create an image which is relatively slim and only includes the features that you need -- our image is definitely not that, and that's why we specify that it is not intended for production. It's also missing some of the necessary orchestration such as cron.
I know that many are building on top of the official php images with their requirements. There's also an alternative and easily configurable container from thecodingmachine: https://github.com/thecodingmachine/docker-images-php
A sample Dockerfile using thecodingmachine as a basis may look like:
############################################################################
# PHP Extension configuration
############################################################################
# Install the following extensions.
# Note: This line must come before the FROM line.
ARG PHP_EXTENSIONS="apcu pgsql bz2 imagick igbinary gd intl imap"
############################################################################
# Source image selection
############################################################################
# Build the image from thecodingmachine.
FROM thecodingmachine/php:8.1-v4-slim-apache
# If using the Apache image in production, switch the user back to www-data.
# https://github.com/thecodingmachine/docker-images-php#using-this-image-in-production
ENV APACHE_RUN_USER=www-data \
APACHE_RUN_GROUP=www-data
############################################################################
# PHP Configuration
############################################################################
# Set any php.ini settings here.
# Use the production php.ini file as a base.
ENV TEMPLATE_PHP_INI=production
# Configure Memory limit to something higher.
ENV PHP_INI_MEMORY_LIMIT=1g
# How many GET/POST/COOKIE input variables may be accepted
# See MDL-71390 for more info. This is the recommended / required
# value to support sites having 1000 courses, activities, users....
ENV PHP_INI_MAX_INPUT_VARS=5000
# Increase the maximum filesize to 200M, which is a more realistic figure.
ENV PHP_INI_UPLOAD_MAX_FILESIZE=200M
# Increase the maximum post size to accomodate the increased upload_max_filesize.
# The default value is 6MB more than the default upload_max_filesize.
ENV PHP_INI_POST_MAX_SIZE=206M
############################################################################
# cron configuration
############################################################################
# The cron daemon used by thecodingmachine images is supercronic.
# https://github.com/thecodingmachine/docker-images-php#supercronic-options
# By default it does not allow overlappign cron jobs, but Moodle benefits
# from these.
ENV SUPERCRONIC_OPTIONS="=overlapping"
# Configure the Moodle cron job to run regularly.
# This configuration runs every 15 seconds, but you may need to tailor to
# your requirements.
# example.
# https://github.com/thecodingmachine/docker-images-php#setting-up-cron-jobs
ENV CRON_USER=www-data \
CRON_SCHEDULE="*/15 * * * *" \
CRON_COMMAND="php /var/www/html/admin/cli/cron.php"
You can easily create a GitHub repo with this dockerfile, and have it automatically push to AWS ECR using a GitHub action (see https://towardsaws.com/build-push-docker-image-to-aws-ecr-using-github-actions-8396888a8f9e for an example).
It would also be possible to configure a GitHub Action to automatically rebuild your images whne there is a new version of the upstream images. We do that in MoodleHQ by comparing php images against the official images, but it should be possible to find a way of doing this. Here's our version for inspiration: https://github.com/moodlehq/moodle-php-apache/blob/master/.github/workflows/trigger_new_builds.yml#L5
And you can easily add a 'workflow_dispatch' trigger to your build to allow you to run it on demand: https://docs.github.com/en/actions/using-workflows/manually-running-a-workflow https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_dispatch
I've created an example here which only builds on manual trigger, and changes to the repository (but not the parent repo). You can see that here: https://github.com/andrewnicols/moodlehq-production_template_pgsql
That's pushing to here: https://gallery.ecr.aws/y9g5h2p2/andrewnicols/moodlehq/production_template_pgsql
Due to the number of possible options we really aren't well placed to generate such an image as it would suit only a very small number of people.
Hope this helps,
Andrew
Thanks. The information is helpful. I have a completely working environment using this image that we have a dev using. I will just have to get a replacement Dockerfile I make myself using some of those tips. The copilot tool does the build and deploy for you by setting up pipelines so it really has taken all of those tasks off my plate at least.
I can use docker hub fine, the main request was so we can get around some of the rate limits and not depend on it but you gave me some useful information in the process. Sometimes deadlines get in the way of doing things the right way, but I am trying my best. hah
I don't see this image available on AWS ECR Public Gallery. It would be very nice if it was built and sent there as an option. Many docker users are switching to using other repositories, and since our environments are in AWS it would make sense to have it there: https://gallery.ecr.aws