On July 27, 2020 at 8:27:07 PM, Michael Morris (tendo...@gmail.com) wrote:
You mention Docker - usually I've seen it used alongside Ansible, Chef or
Puppet. Each of these provisioning programs can modify the php.ini file
used on the container at deploy time without necessitating a change to PHP
itself. What advantage does the community gain from moving these decisions
from the provision files to the php.ini file?
My use case is specifically Docker and Kubernetes. Like Michal said,
containers aim to be immutable. When we deploy containers they are built
via CI with a specific base image sets up PHP with the extensions we need
and then creates a layer for our application. That means to change any one
configuration value in the php.ini file would trigger a rebuild of the
container.CI would then rebuild the container and deploy it. That can take
minutes at times. The quick way would be to change an environment variable,
mark all old containers as bad and any new ones pick up the new environment
setting as they fill in for the bad ones. Another use case. We have a
private Kubernetes stack for a specific client. With environment variables
we can turn the php.ini using environment variable but each time a new
config value is used this way we have to make sure that same environment
variable is exposed to the container. The ability to have a fallback value
while not 100% necessary does have the ability to reduce errors around
environment variables in Docker/Kubernetes deployments.
We don’t use Ansible, Chef, or Puppet. Everything is CI and kubectl. I
might understand using these tools if you are running your own Kubernetes
stack but we are not currently doing that.
On July 26, 2020 at 10:18:23 PM, Michał Marcin Brzuchalski (
michal.brzuchal...@gmail.com) wrote:
Personally I like the idea of setting ini directives via environment
variables but not by a complex syntax in ini files but rather by looking up
for a directive by environment variable name and setting it up directly for
instance:
PHP_MEMORY_LIMIT=1G php script.php
Being equivalent of:
php -dmemory_limit=1G script.php
This seems like a reasonable alternative. With this would the php.ini be
the fallback value I’m looking for with the environment variable only being
used if present?
On July 27, 2020 at 12:01:13 AM, Michał Marcin Brzuchalski (
michal.brzuchal...@gmail.com) wrote:
I do like the idea of applying INI settings with environment variables but
I believe
we should not change anything by providing complex INI parsing rules.
Your proposal inspired me to think of it more and think of potential RFC
for changing the configuration mechanism we use in PHP so it can be
slightly refactored and extracted from zend_ini into zend_config with
additional
configuration providers for "argv" values, environment variables,
INI settings and extension provider.
I believe and hope it has a potential and allows us to make things more
clear when talking
about INI settings.
We always talk about INI settings while INI is just a file format and we
apply internally
INI settings from different sources like `-d` options from the command line
or provided
by extension like mentioned in the thread .htaccess.
In summary, potential RFC proposal would be:
1. extract zend_config from zend_ini, INI directives will in a future be
considered a configuration settings/directives whatever;
2. implement different prioritized configuration providers for CLI argv,
INI files, ext, environment variables - allowing to resolve
configuration settings in a specific order
This will in a future open wide range of possibilities, like new formats to
be implemented via file format, specific configuration provider.
That sounds a little more complex that I was aiming for but does solve the
issue in a different way. I however wouldn’t be able to write that code
currently.
Thank you kindly for the responses. One comment I’ve seen that adding this
proposal would make the php.ini file no longer static. Can you please
clarify how
memory_limit = ${PHP_MEMORY_LIMIT}
is any less static than
memory_limit = ${PHP_MEMORY_LIMIT:-“256M”}
To me the ini setting is both static and deterministic. They may have
different outcomes under the proposed change but that doesn’t make it
dynamic.
Cheers,
Derek
