Open gagarine opened 1 year ago
Perhaps this image should just include the same instructions, without making the decision to use one or the other. We use this image as the basis for both our production and development environments. If the upstream php
image does not use production settings by default, this one probably shouldn't either.
This mean we always need to create a child image and add somethings like
FROM drupal:latest
# Use the default production configuration
RUN mv "$PHP_INI_DIR/php.ini-production" "$PHP_INI_DIR/php.ini"
If the upstream php image does not use production settings by default, this one probably shouldn't either. Why? It was a mistake, default should be production ready and secure -> https://github.com/docker-library/php/issues/692
I cannot think of a good way to manage this.
The opcache revalidate frequency is not compatible with dev needs.
from drupal image dockerfile
# see https://secure.php.net/manual/en/opcache.installation.php
RUN { \
echo 'opcache.memory_consumption=128'; \
echo 'opcache.interned_strings_buffer=8'; \
echo 'opcache.max_accelerated_files=4000'; \
echo 'opcache.revalidate_freq=60'; \
} > /usr/local/etc/php/conf.d/opcache-recommended.ini
Enough! I will use the official php image instead and simply add the extension needed.
I hear your argument about being production ready and secure by default, and I agree that would be nice, but unfortunately it is not that simple. Changing this now would constitute a breaking change, which could affect downstream users of this image. The issue you referenced in the upstream PHP image made the same point (https://github.com/docker-library/php/issues/692):
Shipping the
php.ini-production
by default is a breaking change and would break a lot of existing applications, so this is also a no-go.
The reason that it was originally built this way was because that is how PHP itself ships by default. It is up to the downstream user to decide how they want to configure it:
We don't currently do anything special with
php.ini
beyond what PHP's own configure/build/install process provides, so our current situation is upstream's own default. 😞
The solution, as you described, is to create a child image...
Enough! I will use the official php image instead and simply add the extension needed.
You can still use the drupal
image (unless you want to maintain all of the Drupal-specific dependencies in your child image yourself). This is how we work around the opcache
configuration for development:
RUN sed -i 's|opcache.revalidate_freq=60|opcache.revalidate_freq=0|g' /usr/local/etc/php/conf.d/opcache-recommended.ini
Just add it to your sites Dockerfile where you define everything else thats not included in the base-image, modules, themes, timezones, server-settings etc...
...
# php.ini
RUN cp /usr/local/etc/php/php.ini-production /usr/local/etc/php/php.ini;
...
Depending how you orchestrate your containers, an init container could do the trick. No need for a seperate image.
Default php.ini is not set?
From https://hub.docker.com/_/php
The doc may also explain how php.ini be optionally exposed in the host using https://docs.docker.com/compose/compose-file/08-configs/