Docker add php ini

Create new Dockerfile in ./apache/php/php8.1/ directory. Inside Dockerfile type:

Dockerfile

Create your custom Dockerfile from Apache / PHP image and copy .ini file to with php.ini file with the fallowing command:

Create php.ini file

RUN cp /usr/local/etc/php/php.ini-development /usr/local/etc/php/php.ini

Install new extension in docker apache-php image

Install new PHP extension using pecl and docker-php-ext-enable

# Install php extensions and creates aditional ini file in conf.d directory example: /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini RUN pecl install xdebug \ && docker-php-ext-enable xdebug RUN docker-php-ext-install pdo_mysql \ && docker-php-ext-enable pdo_mysql

Change existing settings in docker image – php.ini file.

Modify existing settings in php.ini.

sed -E -i 's/(;?)(post_max_size[[:space:]]=[[:space:]])2+M/\2328M/g' /usr/local/etc/php/php.ini

Add new / non-existing settings to docker image – in to php.ini file

# You can use this form of configuration when adding new settings to a configuration file RUN echo '[Xdebug]\n\ pdo_mysql.debug = On\n\ xdebug.remote_enable = 1\n\ xdebug.remote_connect_back = On\n\ xdebug.remote_port = "9000"\n\ xdebug.profiler_enable = 0\n\ xdebug.remote_handler = dbgp\n\ xdebug.remote_mode = req\n\ xdebug.var_display_max_depth = 5\n\ xdebug.remote_autostart = true' >> /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini

Create bash script …

Now you know how to change setting in docker image for apache-php. You might think that it would be nice to create a bash script that will check if the php.ini setting is set, is commented out or should it add a new line to config file and use it instead. This is also what I think. Perhaps in next blogpost we will create such a script, so stay keep reading. Hope this post was helpful, if so leave a comment or let me know if we could improve this post in any way.

Источник

Docker PHP/PHP-FPM Configuration via Environment Variables

PHP Docker Container Image with Full Environment Variable INI Configuration

ed: If you want to run the containers right now, jump ahead to How to Use the Images.

For several months now I have been working on PuPHPet.com’s replacement. It is a Docker-based GUI functionally similar to PuPHPet.

Docker, like Vagrant, allows sharing directories and files from the host to the container/VM. Unlike Vagrant, Docker images are easy to create, easy to share and easy to configure.

One of the most convenient differences is that with Docker containers you can pass flags to the container which can be used for configuration (if the image was created with this in mind).

For example, with the MariaDB image you create a new container and define the database credentials:

docker run -it --rm \ -e MYSQL_DATABASE=dbname \ -e MYSQL_USER=dbuser \ -e MYSQL_PASSWORD=dbpassword \ mariadb

This creates a new MariaDB container with a database named dbname , user dbuser and password dbpassword . You do not need to create a separate configuration file, the above takes care of that for you!

What if we could do the same for a PHP container? Having to keep track of a separate INI file for both PHP and PHP-FPM is not nearly as smooth as how MariaDB’s image can be configured.

Our Goals

I will talk you through the thought process required for creating a Docker image that is capable of configuring its service using environment variable flags:

I will detail the gotchas you would encounter trying to create this for yourself from scratch, and the solutions I came up with and implemented.

Quick Introduction to Docker Images

It will definitely help if you know Docker at a usable level. If you know Docker enough to only run pre-built images then I hope this will help solidify your understanding of how Docker works.

That said I am not an expert in the internal workings of Docker, and I might get some things wrong.

Docker images are blueprints for Docker containers. You need an image to run one or more instances which are known as containers.

An image can be grabbed from the Docker Hub or you can easily create your own images by writing a Dockerfile. This is a simple text file that contains instructions for creating your image.

Unless you are doing some hardcore stuff, you always start with an existing base image. For example, FROM ubuntu:18.04 means we will start with an Ubuntu 18.04 image to create our final image.

You can have as many layers as you want, with each new image extending the parent and adding more functionality. That is exactly what we will end up doing today.

PHP INI with Environment Variables (env vars)

A little-known fact is that PHP’s INI file (and PHP-FPM conf, too!) can be configured normally,

display_errors=0 error_reporting=Off date.timezone=UTC

but it can also read env vars!

display_errors=$DISPLAY_ERRORS> error_reporting=$ERROR_REPORTING> date.timezone=$DATE_TIMEZONE> 

PHP-FPM can also be configured this way:

pm = $FPM_PM> pm.max_children = $FPM_PM_MAX_CHILDREN> pm.start_servers = $FPM_PM_START_SERVICE> 

Since we can pass environment variable values when spinning up a Docker container, this can be combined to remove the need for maintaining a separate php.ini file in your project’s repo!

Caveats

A few things to keep in mind:

• You need to be explicit about which settings you want to allow env vars for. This means you can only use env vars if you have set the INI value to read from an env var ( display_errors=$ )!
• If an env var is not set, the value will be empty. This means you must either set a default value when creating the initial INI file (not always desired), or the INI value must allow empty values.
• Bash has a default value fallback when working with variables. It looks like FOO=$ . While this would have been great for our use case, INI files are not processed as Bash and thus the default value trick does not work here.

The first point means you cannot use just any Docker image, it must have been built with env vars in mind from the start. A quick search on the Docker Hub does not bring up many results for this - just about all major PHP Docker images require managing the PHP INI file directly.

The second point hurts us a little bit because some INI settings simply cannot have empty values. For example, you cannot have an extension= . PHP will complain.

In FPM if you have slowlog= FPM will crash immediately. Unfortunately some INI settings are not amenable to env vars unless you enforce a value for them.

The final point is a minor inconvenience. You cannot define a setting with an inline env var in the same line. You have to do this process separately.

This means you cannot simply have your INI file look like:

display_errors=$DISPLAY_ERRORS:-"Off"> error_reporting=$ERROR_REPORTING:-0> date.timezone=$DATE_TIMEZONE:-"UTC"> 

This would have been great but since it is strictly a Bashism it does not work within the PHP INI parser.

This forces you to keep a separate list of env vars and their values, and a separate list of INI settings calling the env vars.

We will go through these points in more detail later on.

Building Docker Image with Env Vars

Adding an env var to a Docker image within a Dockerfile is simple enough:

FROM ubuntu:18.04 ENV allow_url_fopen=1 

Now all containers that use this image and all images that extend this image, would have the env var allow_url_fopen available to them.

To change this value when spinning up a container you would simply do

docker container run -it --rm \ -e allow_url_fopen=0 \ image_name> 

would allow us to change the setting on the fly without having to further edit a static INI file.

My end goal was not to have just one or two settings available for changing, I want developers to take my images and plug them into their projects and configure as much as possible only through env vars. This means I needed to add as many INI settings as I can.

This leads to a problem. Dockerfile cannot read and grab env vars from a separate file. You have to define all env vars in the Dockerfile to be able to use them in child images or containers.

In a docker-compose file you can simply use env_file like so:

services: my_special_service: image: something env_file: - env-file.env 

If you are spinning up a container from an existing image you can likewise do

docker container run \ --env-file=$PWD>/env-file.env \ [..]

However, you cannot do the same when building a new image. There is no ENV_FILE in a Dockerfile - you have to list each env var one by one!

The problem is more obvious when I tell you I identified over 650 PHP INI settings I wanted to set as env vars. Then realize I want to support all active versions of PHP (5.6, 7.0, 7.1, 7.2, 7.3) and that means each of the four Dockerfiles now need to have 650+ lines just for the env vars.

If Dockerfile supports an ENV_VAR directive this would be a single-line solution. Since it does not, I needed to come up with some other way to add these hundreds of env vars, without junking up my Dockerfiles.

Create a Parent Image

The solution turned out to be quite simple! Since each Dockerfile extends a parent image (via FROM ), and everything available to that base image is available to the current Dockerfile, I created a Dockerfile that does nothing but define all the INI env vars my PHP images will be able to use.

For settings that have no default value, and can remain blank, I did

For settings that ship with default values, I did

Источник