docker-library / drupal

Docker Official Image packaging for Drupal
280 stars 204 forks source link

Set the default php.ini (prod or dev) #246

Open gagarine opened 1 year ago

gagarine commented 1 year ago

Default php.ini is not set?

From https://hub.docker.com/_/php

This image ships with the default php.ini-development and php.ini-production configuration files.

It is strongly recommended to use the production config for images used in production environments!

The default config can be customized by copying configuration files into the $PHP_INI_DIR/conf.d/ directory. Example

FROM php:8.2-fpm-alpine

Use the default production configuration

RUN mv "$PHP_INI_DIR/php.ini-production" "$PHP_INI_DIR/php.ini"

The doc may also explain how php.ini be optionally exposed in the host using https://docs.docker.com/compose/compose-file/08-configs/

mstenta commented 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.

gagarine commented 1 year ago

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.

gagarine commented 1 year ago

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.

mstenta commented 1 year ago

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

https://github.com/farmOS/farmOS/blob/010a895092b30423b5b66ea06aa8f552ce8b4c18/docker/dev/Dockerfile#L12

kjostling commented 10 months ago

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;
...
LaurentGoderre commented 10 months ago

Depending how you orchestrate your containers, an init container could do the trick. No need for a seperate image.