craftcms / docker

Craft CMS Docker images.

Craft Docker Images

Note: We are going to deprecate these images and archive this repository. Please see this issue for additional details. New images are located at craftcms/image.

These images are provided as a starting point for your Docker-based Craft CMS deployments. They’re discrete, lightweight, and pre-configured to meet Craft’s requirements in production and development environments.

Images

There are three main "types" of images provided for different types of applications; php-fpm, nginx, and cli. Each image allows the developer to select a PHP version (e.g. craftcms/nginx:8.2).

Each image and PHP version also provides a -dev variant which has Xdebug installed and is useful for local development (e.g. craftcms/php-fpm:8.2-dev), as well as database tools for creating and restoring backups. Images that do not include -dev are considered production.

Note: you are not required to use -dev images for local development, they are provided with Xdebug and to make debugging easier.

To keep the production images lean and secure, database tools are NOT included by default (they are included in the -dev variants). If you want to create database backups from the Craft control panel, you will need to install these yourself.

Supported PHP versions are aligned with PHP's official support, meaning that once a PHP version is EOL, we will no longer build new images for that version.

php-fpm

The php-fpm image is provided as the base image (and is also used for the nginx image) and requires you "bring your own server".

Image	Use	Environment	Status
craftcms/php-fpm:8.2	web	production
craftcms/php-fpm:8.2-dev	web	development
craftcms/php-fpm:8.1	web	production
craftcms/php-fpm:8.1-dev	web	development
craftcms/php-fpm:8.0	web	production	EOL on 2023-11-26
craftcms/php-fpm:8.0-dev	web	development	EOL on 2023-11-26
craftcms/php-fpm:7.4	web	production	EOL
craftcms/php-fpm:7.4-dev	web	development	EOL
craftcms/php-fpm:7.3	web	production	EOL
craftcms/php-fpm:7.3-dev	web	development	EOL
craftcms/php-fpm:7.2	web	production	EOL
craftcms/php-fpm:7.2-dev	web	development	EOL
craftcms/php-fpm:7.1	web	production	EOL
craftcms/php-fpm:7.1-dev	web	development	EOL
craftcms/php-fpm:7.0	web	production	EOL
craftcms/php-fpm:7.0-dev	web	development	EOL

Nginx

The nginx image is used for a typical installation and includes an Nginx server configured for Craft CMS and php-fpm.

Image	Use	Environment	Status
craftcms/nginx:8.2	web	production
craftcms/nginx:8.2-dev	web	development
craftcms/nginx:8.1	web	production
craftcms/nginx:8.1-dev	web	development
craftcms/nginx:8.0	web	production	EOL on 2023-11-26
craftcms/nginx:8.0-dev	web	development	EOL on 2023-11-26
craftcms/nginx:7.4	web	production	EOL
craftcms/nginx:7.4-dev	web	development	EOL
craftcms/nginx:7.3	web	production	EOL
craftcms/nginx:7.3-dev	web	development	EOL
craftcms/nginx:7.2	web	production	EOL
craftcms/nginx:7.2-dev	web	development	EOL
craftcms/nginx:7.1	web	production	EOL
craftcms/nginx:7.1-dev	web	development	EOL
craftcms/nginx:7.0	web	production	EOL
craftcms/nginx:7.0-dev	web	development	EOL

cli

The image type cli which is used to run queues, migrations, etc. and the image does not expose ports for HTTP/S or PHP-FPM.

Image	Use	Environment	Status
craftcms/cli:8.2	web	production
craftcms/cli:8.2-dev	web	development
craftcms/cli:8.1	web	production
craftcms/cli:8.1-dev	web	development
craftcms/cli:8.0	web	production	EOL on 2023-11-26
craftcms/cli:8.0-dev	web	development	EOL on 2023-11-26
craftcms/cli:7.4	web	production	EOL
craftcms/cli:7.4-dev	web	development	EOL
craftcms/cli:7.3	web	production	EOL
craftcms/cli:7.3-dev	web	development	EOL
craftcms/cli:7.2	web	production	EOL
craftcms/cli:7.2-dev	web	development	EOL
craftcms/cli:7.1	web	production	EOL
craftcms/cli:7.1-dev	web	development	EOL
craftcms/cli:7.0	web	production	EOL
craftcms/cli:7.0-dev	web	development	EOL

Usage

There are two main types of images: php-fpm for handling the web application, and cli for running queues and other Craft CLI commands. Additionally, we provide an nginx image, which combines php-fpm and nginx into a single image for simplicity and ease of development.

This example uses a Docker multi-stage build to install composer dependencies inside a separate layer before copying them into the final image.

# use a multi-stage build for dependencies
FROM composer:2 as vendor
COPY composer.json composer.json
COPY composer.lock composer.lock
RUN composer install --ignore-platform-reqs --no-interaction --prefer-dist

FROM craftcms/php-fpm:8.2

# the user is `www-data`, so we copy the files using the user and group
COPY --chown=www-data:www-data --from=vendor /app/vendor/ /app/vendor/
COPY --chown=www-data:www-data . .

Database tools

This example uses the craftcms/nginx repository and installs the database tools to enable backups from the Craft CMS control panel. Note: These will be included automatically if using the -dev image variants.

# composer dependencies
FROM composer:2 as vendor
COPY composer.json composer.json
COPY composer.lock composer.lock
RUN composer install --ignore-platform-reqs --no-interaction --prefer-dist

FROM craftcms/nginx:8.2

# switch to the root user to install mysql tools
USER root
RUN apk add --no-cache mysql-client postgresql-client
USER www-data

# the user is `www-data`, so we copy the files using the user and group
COPY --chown=www-data:www-data --from=vendor /app/vendor/ /app/vendor/
COPY --chown=www-data:www-data . .

Permissions

The image is designed to be run by a www-data user that owns of the image’s /app directory. Running as non-root is considered a Docker best practice, especially when shipping container images to production.

Note: You can use the USER root directive to switch back to root to install any additional packages you need.

Running Locally with Docker Compose

We recommend running Docker locally if you’re shipping your project to a Docker-based environment such as Amazon Web Services Elastic Container Services (ECS). The following Docker Compose file will setup your local environment with the following:

1. web service that will handle running PHP and Nginx
2. postgres service that will store your content
3. console service that will run the queue locally
4. redis service that will handle queue and caching

version: "3.6"
services:
  console:
    image: craftcms/cli:8.2-dev
    env_file: .env
    environment:
      XDEBUG_CONFIG: client_host=host.docker.internal
    depends_on:
      postgres:
        condition: service_healthy
      redis:
        condition: service_healthy
    volumes:
      - .:/app
    command: php craft queue/listen

  web:
    image: craftcms/nginx:8.2-dev
    ports:
      - 8080:8080
    env_file: .env
    environment:
      XDEBUG_CONFIG: client_host=host.docker.internal
    depends_on:
      postgres:
        condition: service_healthy
      redis:
        condition: service_healthy
    volumes:
      - .:/app

  postgres:
    image: postgres:13-alpine
    ports:
      - 5432:5432
    environment:
      POSTGRES_DB: dev_craftcms
      POSTGRES_USER: craftcms
      POSTGRES_PASSWORD: SecretPassword
    volumes:
      - db_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD", "pg_isready", "-U", "craftcms", "-d", "dev_craftcms"]
      interval: 5s
      retries: 3

  redis:
    image: redis:5-alpine
    ports:
      - 6379:6379
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]

volumes:
  db_data:

Using Xdebug

Xdebug is install on the -dev image variants, but you will still need to set xdebug.client_host. We do not do this in our images, as it is platform-specific. However, if you are on Docker Desktop for Mac or Windows, you can use host.docker.internal.

This can be done via environment variable: XDEBUG_CONFIG=client_host=host.docker.internal. See example

Installing Extensions

This image is based off the official Docker PHP FPM image (Alpine Linux). Therefore you can use all of the tools to install PHP extensions. To install an extension, you have to switch to the root user. This example switches to the root user to install the sockets extension for PHP 8.2. Note that it switches back to www-data after installation:

FROM craftcms/php-fpm:8.2

# switch to the root user
USER root
RUN docker-php-ext-install sockets
USER www-data

# the user is www-data, so we copy the files using the user and group
COPY --chown=www-data:www-data --from=vendor /app/vendor/ /app/vendor/
COPY --chown=www-data:www-data . .

Customizing PHP Settings

Some PHP settings may be customized by setting environment variables for the php-fpm or cli images.

In this example, we’re setting the PHP memory limit to 512M rather than the default 256M:

version: "3.6"
services:
  php-fpm:
    image: craftcms/php-fpm:8.2-dev
    volumes:
      - .:/app
    env_file: .env
    environment:
      PHP_MEMORY_LIMIT: 512M
  # ...

Customizable Settings

PHP Setting	Environment Variable	Default Value
memory_limit	PHP_MEMORY_LIMIT	256M
max_execution_time	PHP_MAX_EXECUTION_TIME	120
upload_max_filesize	PHP_UPLOAD_MAX_FILESIZE	20M
max_input_vars	PHP_MAX_INPUT_VARS	1000
post_max_size	PHP_POST_MAX_SIZE	8M
opcache.enable	PHP_OPCACHE_ENABLE	1
opcache.revalidate_freq	PHP_OPCACHE_REVALIDATE_FREQ	0
opcache.validate_timestamps	PHP_OPCACHE_VALIDATE_TIMESTAMPS	0
opcache.max_accelerated_files	PHP_OPCACHE_MAX_ACCELERATED_FILES	10000
opcache.memory_consumption	PHP_OPCACHE_MEMORY_CONSUMPTION	256
opcache.max_wasted_percentage	PHP_OPCACHE_MAX_WASTED_PERCENTAGE	10
opcache.interned_strings_buffer	PHP_OPCACHE_INTERNED_STRINGS_BUFFER	16
opcache.fast_shutdown	PHP_OPCACHE_FAST_SHUTDOWN	1

docker's Issues

PHP open_basedir restrictions

Description

When using the Nginx images, the open_basedir PHP setting is set on the images. The Nginx configuration we are using is explicitly setting that value here: https://github.com/craftcms/docker/blob/stable/nginx/craftcms/php_fastcgi.conf#L16. Which was generated from https://www.digitalocean.com/community/tools/nginx.

This can create problems trying to access tools outside of the /app directory. Original report: https://discord.com/channels/456442477667418113/707324026577485934/813816543313657856

We need to disable this for development images.

libtasn1 vulnerability reported

Hey, it's your friendly developer with a sysdig scan in his CD system.

 - CVE-2021-46848   Critical libtasn1-4.18.0-r0   APKG    4.18.0-r1    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-46848

User ID and Group ID adjustment

Description

Not all servers allow chmod of files that are not owned by the current user.
When the image requires the files from the host but inside the image there is a forced userID en GroupID of 33:33
It will create permission issues.

Allowing the www-data user to change userID in the container will give an option to match de operating user ID

Blackfire APM attempting to run even if not configured

Description

We are seeing [Error] APM: Locking APM for 300 seconds for reason: Cannot connect to the agent very frequently in our logs. I assume this is coming from Blackfire, as it is installed in these images (

docker/7.4/Dockerfile

Lines 127 to 131 in 009b990

	# copy the blackfire script
	COPY blackfire-install.sh /tmp/blackfire-install.sh
	# run the installation script
	RUN set -ex && sh /tmp/blackfire-install.sh && rm -rf /tmp/blackfire*

).

I worry there is some type of performance hit here for those not actually using Blackfire. Is it mandatory to include this in these images? Would a ENV var toggle be appropriate here, or removing it entirely?

Steps to reproduce

1. Run container, view logs

Additional info

• Craft version: 3.7.34
• PHP version: 7.4.28
• Database driver & version: MySQL 5.7.31
• Plugins & versions: n/a

Missing PHP extensions in Base image

Description

While running a deployment via gitlab-ci the latest base image craftcms/nginx:8.0 was pulled from Docker Hub.
The subsequent composer install failed because several PHP extensions were suddenly missing.
Has there been a change in the base image that caused this?

How could we possibly avoid changes like that? Is there a versioning in place so we can set fixed versions for the base images we use?

Problem 1
- Root composer.json requires PHP extension ext-simplexml * but it is missing from your system. Install or enable PHP's simplexml extension.

Problem 2
- craftcms/cms is locked to version 3.7.28 and an update of this package was not requested.
- craftcms/cms 3.7.28 requires ext-dom * -> it is missing from your system. Install or enable PHP's dom extension.

Steps to reproduce

1. Create a Dockerfile which pulls the base image craftcms/nginx:8.0
2. Run composer install

Additional info

• Craft version: 3.7.x
• PHP version: 8.0
• Database driver & version: mysql
• Plugins & versions: n/a

Database dump with just base image doesn't work

Description

The database dump functionality when using a postgres database no longer works. It looks like the postgres client was just removed from the image Since the database dump from the control panel requires the postgres client to be installed, does it make sense to keep that dependency in the image?

Steps to reproduce

1. Create a new craft project: https://craftcms.com/docs/3.x/installation.html
2. Update the .env file with the following credentials:

DB_DRIVER=pgsql
DB_SERVER=host.docker.internal
DB_PORT=5432
DB_DATABASE=craft
DB_USER=craft
DB_PASSWORD=secret
DB_SCHEMA=public
DB_TABLE_PREFIX=

3. Start a PostgreSQL database: docker run --rm --env POSTGRES_USER=craft --env POSTGRES_PASSWORD=secret -d -p 5432:5432 postgres:13
4. From within the project directory, start the web server in the Craft docker image: docker run --rm -d -v "$(pwd):/app" -p 80:8080 craftcms/nginx:8.0
5. In your browser, follow through the install steps: http://localhost/index.php?p=admin/install
6. Login with the account you just created
7. In Utilities > Database Backup, click Backup
8. See error!

2021-11-08 11:15:52 [-][1][fa3bd882bbbcddbef1853ef1b38cadb3][error][yii\base\Exception] yii\base\Exception: Could not create backup: The shell command "PGPASSWORD="••••••" pg_dump --dbname=craft --host=host.docker.internal --port=5432 --username=craft --if-exists --clean --no-owner --no-privileges --no-acl --file="/app/storage/backups/test--2021-11-08-191552--v3.7.20.sql" --schema=public --column-inserts --exclude-table-data 'public.assetindexdata' --exclude-table-data 'public.assettransformindex' --exclude-table-data 'public.sessions' --exclude-table-data 'public.templatecaches' --exclude-table-data 'public.templatecachequeries' --exclude-table-data 'public.templatecacheelements' --exclude-table-data 'public.cache' --exclude-table-data 'public.templatecachecriteria'" failed with exit code 127: sh: pg_dump: not found in /app/vendor/craftcms/cms/src/controllers/UtilitiesController.php:346
Stack trace:
#0 [internal function]: craft\controllers\UtilitiesController->actionDbBackupPerformAction()
#1 /app/vendor/yiisoft/yii2/base/InlineAction.php(57): call_user_func_array(Array, Array)
#2 /app/vendor/yiisoft/yii2/base/Controller.php(181): yii\base\InlineAction->runWithParams(Array)
#3 /app/vendor/yiisoft/yii2/base/Module.php(534): yii\base\Controller->runAction('db-backup-perfo...', Array)
#4 /app/vendor/craftcms/cms/src/web/Application.php(287): yii\base\Module->runAction('utilities/db-ba...', Array)
#5 /app/vendor/craftcms/cms/src/web/Application.php(596): craft\web\Application->runAction('utilities/db-ba...', Array)
#6 /app/vendor/craftcms/cms/src/web/Application.php(266): craft\web\Application->_processActionRequest(Object(craft\web\Request))
#7 /app/vendor/yiisoft/yii2/base/Application.php(392): craft\web\Application->handleRequest(Object(craft\web\Request))
#8 /app/web/index.php(26): yii\base\Application->run()
#9 {main}

Additional info

• Craft version: 3.7.20
• PHP version: 8.0
• Database driver & version: Postgresql 13
• Plugins & versions: N/A

Missing libgomp prevents imagick from loading

Description

The Docker image pulls Imagick 3.5.0 via PECL. However, the PHP extension requires a dependency on a shared library which isn't included in the Dockerfile. As a result, PHP will throw PHP core warnings and CraftCMS will yield PHP errors both via PHP-FPM as well as via the CLI.

Steps to reproduce

1. Set up a fresh environment and use the Dockerfile to build an image. (I use Docker Compose)
2. In my case, I try to restore a SQL dump using the craft command via the docker CLI tool:

$ docker exec -it project_name php craft db/restore /var/www/storage/backups/project--
2021-06-30-084743--v3.6.15.sql

I get these errors:

PHP Warning:  PHP Startup: Unable to load dynamic library 'imagick' (tried: /usr/local/lib/php/extensions/no-debug-non-zts-20190902/imagick (Error loading shared library /usr/local/lib/php/extensions/no-debug-non-zts-20190902/imagick: No such file or directory), /usr/local/lib/php/extensions/no-debug-non-zts-20190902/imagick.so (Error loading shared library libgomp.so.1: No such file or directory (needed by /usr/local/lib/php/extensions/no-debug-non-zts-20190902/imagick.so))) in Unknown on line 0
Restoring database backup ... done
PHP Core Warning 'yii\base\ErrorException' with message 'PHP Startup: Unable to load dynamic library 'imagick' (tried: /usr/local/lib/php/extensions/no-debug-non-zts-20190902/imagick (Error loading shared library /usr/local/lib/php/extensions/no-debug-non-zts-20190902/imagick: No such file or directory), /usr/local/lib/php/extensions/no-debug-non-zts-20190902/imagick.so (Error loading shared library libgomp.so.1: No such file or directory (needed by /usr/local/lib/php/extensions/no-debug-non-zts-20190902/imagick.so)))'

in ./Unknown:0

Stack trace:
#0 [internal function]: yii\base\ErrorHandler->handleFatalError()
#1 {main}

This caught my eye: Error loading shared library libgomp.so.1: No such file or directory (needed by /usr/local/lib/php/extensions/no-debug-non-zts-20190902/imagick.so)

So I added libgomp to the Dockerfile, like below, and rebuild the image. That solved the issue for me.

RUN set -ex && \
    apk --no-cache add \
    ...
    libjpeg-turbo \
    libgomp \
    freetype-dev \
    ...

Additional info

• Craft version: Not relevant
• PHP version: 7.4
• Database driver & version: not relevant
• Plugins & versions: Imagick 3.5.0

Set allowed clients on php-fpm image

Description

The default php-fpm config allows access to from all connections/clients.

If this value is left blank, connections will be accepted from any ip address

We should consider an option to limit the connection to only specific clients. The pfp-fpm configuration has the option listen.allowed_clients that takes multiple IP addresses separated by commas (e.g. 10.0.0.1 and 10.0.0.3).

Since we cannot hard code an IP address we should expose an environment variable (e.g. PHP_FPM_ALLOWED_CLIENTS) in the configuration file to allow users to customize the allowed clients. Perhaps the default should be 127.0.0.1 for security purposes?

Vulnerability reported in libde265 package

Description

Our build pipeline runs a sysdig scan on deployment, which is now failing because of the following high vulnerability:

HIGH Vulnerability found in os package type (APKG) - libde265 (fixed in: 1.0.8-r2)(CVE-2022-1253 - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-1253)

We believe a fix similar to #57 would be needed.

High vulnerability reported in `libde265`

Description

Another day, another sysdig vulnerability scan. 🙄

Our scan is reporting a high vulnerability in libde265-1.0.8-r2

   Vulnerability    Severity Package                                  Type     Fix version      URL
 - CVE-2022-47655   High     libde265-1.0.8-r2                        APKG     1.0.11-r0        https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-47655

@timkelty any chance you can rebuild the docker images to get the latest security fixes?

mysqldump: Plugin caching_sha2_password could not be loaded: Error loading shared library /usr/lib/mariadb/plugin/caching_sha2_password.so: No such file or directory

Description

When running the backup database option in Craft CMS through Utilities mysqdump is throwing an exit code. The full stack trace is below.

I know more recently mysql-client tools where added to the dev images, as before mysqdump wasn't included at all. The path within the php-fpm Docker container at /usr/lib/mariadb/plugin/ is indeed empty, although I'm using MySQL 8 not mariadb so I'm not sure why it's being referenced. I'm wondering if the client tools have been built against mariadb?

yii\base\Exception: Could not create backup: The shell command "mysqldump --defaults-extra-file="/tmp/my.cnf" --add-drop-table --comments --create-options --dump-date --no-autocommit --routines --default-character-set=utf8 --set-charset --triggers --no-tablespaces --single-transaction --no-data --result-file="/app/storage/backups/nottingham-college--2021-02-19-112326--v3.6.6.sql" dev_craftcms && mysqldump --defaults-extra-file="/tmp/my.cnf" --add-drop-table --comments --create-options --dump-date --no-autocommit --routines --default-character-set=utf8 --set-charset --triggers --no-tablespaces --no-create-info --ignore-table=dev_craftcms.craft_assetindexdata --ignore-table=dev_craftcms.craft_assettransformindex --ignore-table=dev_craftcms.craft_sessions --ignore-table=dev_craftcms.craft_templatecaches --ignore-table=dev_craftcms.craft_templatecachequeries --ignore-table=dev_craftcms.craft_templatecacheelements --ignore-table=dev_craftcms.craft_cache --ignore-table=dev_craftcms.craft_templatecachecriteria dev_craftcms >> "/app/storage/backups/nottingham-college--2021-02-19-112326--v3.6.6.sql"" failed with exit code 2: mysqldump: Got error: 1045: "Plugin caching_sha2_password could not be loaded: Error loading shared library /usr/lib/mariadb/plugin/caching_sha2_password.so: No such file or directory" when trying to connect in /app/vendor/craftcms/cms/src/controllers/UtilitiesController.php:345
Stack trace:
#0 [internal function]: craft\controllers\UtilitiesController->actionDbBackupPerformAction()
#1 /app/vendor/yiisoft/yii2/base/InlineAction.php(57): call_user_func_array(Array, Array)
#2 /app/vendor/yiisoft/yii2/base/Controller.php(181): yii\base\InlineAction->runWithParams(Array)
#3 /app/vendor/craftcms/cms/src/web/Controller.php(190): yii\base\Controller->runAction('db-backup-perfo...', Array)
#4 /app/vendor/yiisoft/yii2/base/Module.php(534): craft\web\Controller->runAction('db-backup-perfo...', Array)
#5 /app/vendor/craftcms/cms/src/web/Application.php(274): yii\base\Module->runAction('utilities/db-ba...', Array)
#6 /app/vendor/craftcms/cms/src/web/Application.php(577): craft\web\Application->runAction('utilities/db-ba...', Array)
#7 /app/vendor/craftcms/cms/src/web/Application.php(253): craft\web\Application->_processActionRequest(Object(craft\web\Request))
#8 /app/vendor/yiisoft/yii2/base/Application.php(392): craft\web\Application->handleRequest(Object(craft\web\Request))
#9 /app/web/index.php(23): yii\base\Application->run()
#10 {main}

Steps to reproduce

1. Use any dev PHP image
2. Try running a database backup from Utilities in Craft CMS CP
3. You will get an error saying to check the logs for more info, which the stack trace is the reason of the export failure.

Additional info

• Craft version: 3.6.6
• PHP version: 7.4 (dev image)
• Database driver & version: MySQL 8

github-tag-action runs too often

Description

Hey @timkelty, it's me again.

I noticed that there are a lot of duplicate git tags on a single git commit, probably because of the scheduled (nightly) builds

Steps to reproduce

See commit refs of tags, e.g. 74b77e0:

Craft install fails - nl is not a valid language.

Description

craft install fails due to missing locales
We use the cli image to install and test our craft site in github actions.
It suddenly broke with this error:
Invalid arguments:
- nl is not a valid language.

after some investigation this was due to the updated craftcms/cli:8.1 image

did something change/go wrong with the resource bundle in the latest image build?

Steps to reproduce

1. try to run an install with the --language argument with the latest cli image
2. e.g. docker-compose run --rm craftcliservice php craft install/craft --email [email protected] --language nl --password password --site-name "Site (NL)" --site-url @siteUrl

.env file issue

Docker Compose does not expect quotes around variable values in a .env file. Instructing Docker Compose to use the .env file generated by Craft results in the quotes being interpreted literally.

webp Image Transforms not working

Description

Hi,

we are using webp with image transforms and realized that it is not working anymore with new projects we are creating with nitro.

[error][craft\errors\AssetTransformException] craft\errors\AssetTransformException: The `webp` format is not supported on this server! in /app/vendor/craftcms/cms/src/services/AssetTransforms.php:1526

Is it possible that the recent change from #25 dropped webp support? I am almost sure it was working before with your Dockerfiles. I suspect this line https://github.com/craftcms/docker/blob/main/7.4/Dockerfile#L56

@khalwat explicitly suggested --with-webp but it is missing in the Dockerfile (only --with-jpeg) here #25

Thank you for looking into this

PS.:
gd_info() also says no webp support

array(14) { ["GD Version"]=> string(26) "bundled (2.1.0 compatible)" ["FreeType Support"]=> bool(true) ["FreeType Linkage"]=> string(13) "with freetype" ["GIF Read Support"]=> bool(true) ["GIF Create Support"]=> bool(true) ["JPEG Support"]=> bool(true) ["PNG Support"]=> bool(true) ["WBMP Support"]=> bool(true) ["XPM Support"]=> bool(false) ["XBM Support"]=> bool(true) ["WebP Support"]=> bool(false) ["BMP Support"]=> bool(true) ["TGA Read Support"]=> bool(true) ["JIS-mapped Japanese Font Support"]=> bool(false) }

Steps to reproduce

1. create asset transformation with webp

Additional info

• Craft version: 3.6.x
• PHP version: 7.4
• Database driver & version: MySQL 5.7

Security vulnerabilities reported in container re. libpq and zlib

Description

Our automated Sysdig scan is currently showing two known vulnerabilities in dependencies of the Docker container. Not sure if this is anything you can or should deal with, or if we just need to wait for it to be fixed upstream, but putting here for reference.

- CVE-2022-2625    High     libpq-14.4-r0      APKG     14.5-r0          https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-2625
- CVE-2022-37434   Critical zlib-1.2.12-r1     APKG     1.2.12-r2        https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-37434

Dummies guide to getting started

I'm looking into using Docker as an alternative to MAMP (and Nitro - as I'm getting errors with the initial setup), and I'm not sure I'm getting off the right foot.

Looking at the README, I created a DockerFile using the craftcms/nginx repo, then created a docker-compose and nginx.conf files with the example data given in the README. These 3 files went into a CraftCMS folder I had created with composer (composer create-project etc.) ... is this correct?

I had created an empty folder the just had the DockerFile, docker-compose.yml, and the nginx.conf files in then ran docker-compose up but it didn't appear to actually install Craft at any stage - even though there's a composer command within docker-compose. Should I be taking come files/content from the stable branch in this repo e.g. 7.3?

Buggy iconv in PHP-FPM images

Description

Thanks for providing some docker images for Craft CMS development, I used these as a base and tweaked some stuff for my environment. I have found however that the PHP images are shipping a buggy version of iconv which is known issue in Docker land:

docker-library/php#240

The solution is to add this to the PHP Dockerfile:

RUN apk add --no-cache --repository http://dl-cdn.alpinelinux.org/alpine/edge/community/ gnu-libiconv
ENV LD_PRELOAD /usr/lib/preloadable_libiconv.so php

This seems to be used elsewhere as well. There is a test case from the original issue to confirm if iconv is broke in the image:

php -d error_reporting=22527 -d display_errors=1 -r 'var_dump(iconv("UTF-8", "UTF-8//IGNORE", "This is the Euro symbol '\''€'\''."));'

If the above returns:

Notice: iconv(): Wrong charset, conversion from `UTF-8' to `UTF-8//IGNORE' is not allowed in Command line code on line 1

iconv is broke. Which does happen. SEOMatic triggered the issue and led me to finding the workaround for Docker.

Just wanted to flag this for anyone who might be using the images.

Unable to install Craft Commerce

Description

I was unable to install the Craft Commerce plugin when running Craft using these docker containers.

Steps to reproduce

1. Setup Craft using the Docker Compose file suggested in this repo (I've also included mine below)
2. Run docker-compose up and go through the Craft setup process
3. Navigate to the Plugin Store in Craft and attempt to install the Commerce plugin OR run composer require craftcms/commerce -- both produce the same result.

I received the following error:

Using version ^3.2 for craftcms/commerce
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - craftcms/commerce 3.2.1 requires ibericode/vat ^1.1.2 -> satisfiable by ibericode/vat[1.1.2, 1.1.3, 1.2.0, 1.2.1].
    - craftcms/commerce 3.2.2 requires ibericode/vat ^1.1.2 -> satisfiable by ibericode/vat[1.1.2, 1.1.3, 1.2.0, 1.2.1].
    - craftcms/commerce 3.2.2.1 requires ibericode/vat ^1.1.2 -> satisfiable by ibericode/vat[1.1.2, 1.1.3, 1.2.0, 1.2.1].
    - craftcms/commerce 3.2.3 requires ibericode/vat ^1.1.2 -> satisfiable by ibericode/vat[1.1.2, 1.1.3, 1.2.0, 1.2.1].
    - craftcms/commerce 3.2.4 requires ibericode/vat ^1.1.2 -> satisfiable by ibericode/vat[1.1.2, 1.1.3, 1.2.0, 1.2.1].
    - craftcms/commerce 3.2.5 requires ibericode/vat ^1.1.2 -> satisfiable by ibericode/vat[1.1.2, 1.1.3, 1.2.0, 1.2.1].
    - craftcms/commerce 3.2.6 requires ibericode/vat ^1.1.2 -> satisfiable by ibericode/vat[1.1.2, 1.1.3, 1.2.0, 1.2.1].
    - craftcms/commerce 3.2.7 requires ibericode/vat ^1.1.2 -> satisfiable by ibericode/vat[1.1.2, 1.1.3, 1.2.0, 1.2.1].
    - craftcms/commerce 3.2.0 requires dompdf/dompdf ^0.8.4 -> satisfiable by dompdf/dompdf[v0.8.4, v0.8.5, v0.8.6].
    - craftcms/commerce 3.2.0.1 requires dompdf/dompdf ^0.8.4 -> satisfiable by dompdf/dompdf[v0.8.4, v0.8.5, v0.8.6].
    - craftcms/commerce 3.2.0.2 requires dompdf/dompdf ^0.8.4 -> satisfiable by dompdf/dompdf[v0.8.4, v0.8.5, v0.8.6].
    - ibericode/vat 1.2.1 requires php >=7.1 -> your PHP version (7.4.11) overridden by "config.platform.php" version (7.0) does not satisfy that requirement.
    - ibericode/vat 1.2.0 requires php >=7.1 -> your PHP version (7.4.11) overridden by "config.platform.php" version (7.0) does not satisfy that requirement.
    - ibericode/vat 1.1.3 requires ext-soap * -> the requested PHP extension soap is missing from your system.
    - ibericode/vat 1.1.2 requires ext-soap * -> the requested PHP extension soap is missing from your system.
    - dompdf/dompdf v0.8.6 requires php ^7.1 -> your PHP version (7.4.11) overridden by "config.platform.php" version (7.0) does not satisfy that requirement.
    - dompdf/dompdf v0.8.5 requires php ^7.1 -> your PHP version (7.4.11) overridden by "config.platform.php" version (7.0) does not satisfy that requirement.
    - dompdf/dompdf v0.8.4 requires php ^7.1 -> your PHP version (7.4.11) overridden by "config.platform.php" version (7.0) does not satisfy that requirement.
    - Installation request for craftcms/commerce ^3.2 -> satisfiable by craftcms/commerce[3.2.0, 3.2.0.1, 3.2.0.2, 3.2.1, 3.2.2, 3.2.2.1, 3.2.3, 3.2.4, 3.2.5, 3.2.6, 3.2.7].

  To enable extensions, verify that they are enabled in your .ini files:
    - /usr/local/etc/php/php-cli.ini
    - /usr/local/etc/php/conf.d/docker-php-ext-sodium.ini
    - /usr/local/etc/php/conf.d/docker-php-ext-zip.ini
  You can also run `php --ini` inside terminal to see which files are used by PHP in CLI mode.

Installation failed, reverting ./composer.json to its original content.

I resolved this issue by removing the platform directive from composer.json via composer config platform --unset.

Repeating the above attempt to install the Commerce plugin, I now get:

Composer was unable to install the updates due to a dependency conflict.

Composer output: Package "craftcms/vue-asset" listed for update is not installed. Ignoring.
Loading composer repositories with package information
Updating dependencies
Your requirements could not be resolved to an installable set of packages.

Problem 1
- ibericode/vat 1.2.1 requires ext-soap * -> the requested PHP extension soap is missing from your system.
- ibericode/vat 1.2.0 requires ext-soap * -> the requested PHP extension soap is missing from your system.
- ibericode/vat 1.1.3 requires ext-soap * -> the requested PHP extension soap is missing from your system.
- ibericode/vat 1.1.2 requires ext-soap * -> the requested PHP extension soap is missing from your system.
- craftcms/commerce 3.2.7 requires ibericode/vat ^1.1.2 -> satisfiable by ibericode/vat[1.1.2, 1.1.3, 1.2.0, 1.2.1].
- Installation request for craftcms/commerce 3.2.7 -> satisfiable by craftcms/commerce[3.2.7].

To enable extensions, verify that they are enabled in your .ini files:
-
- /usr/local/etc/php/conf.d/craft-cms.ini
- /usr/local/etc/php/conf.d/docker-php-ext-gd.ini
- /usr/local/etc/php/conf.d/docker-php-ext-imagick.ini
- /usr/local/etc/php/conf.d/docker-php-ext-intl.ini
- /usr/local/etc/php/conf.d/docker-php-ext-opcache.ini
- /usr/local/etc/php/conf.d/docker-php-ext-pdo_mysql.ini
- /usr/local/etc/php/conf.d/docker-php-ext-pdo_pgsql.ini
- /usr/local/etc/php/conf.d/docker-php-ext-redis.ini
- /usr/local/etc/php/conf.d/docker-php-ext-sodium.ini
- /usr/local/etc/php/conf.d/docker-php-ext-zip.ini
- /usr/local/etc/php/conf.d/xdebug.ini
You can also run php --ini inside terminal to see which files are used by PHP in CLI mode.
Running update with --no-dev does not mean require-dev is ignored, it just means the packages will not be installed. If dev requirements are blocking the update you have to resolve those problems.

I then resolved that problem by installing the Soap extension manually in the php-fpm container:

% docker-compose exec --user root php-fpm sh

# apk add libxml2-dev

# docker-php-ext-install soap

# exit

% docker-compose restart php-fpm 

I was then able to successfully install the Commerce plugin.

Possible Resolution

I think that this would be resolved by adding the following to the Dockerfile here

apk add libxml2-dev

docker-php-ext-install soap

Happy to make a pull request with those changes but would like to know that I'm on the right track first and haven't overlooked something simpler.

Additional info

PHP version 7.4.11
OS version Linux 4.19.76-linuxkit
Database driver & version MySQL 8.0.21
Image driver & version Imagick 3.4.4 (ImageMagick 7.0.10-25)
Craft edition & version Craft Solo 3.5.12.1
Yii version 2.0.38
Twig version 2.13.1
Guzzle version 6.5.5
Imagine version 1.2.3-dev

My Docker Compose file:

cat docker-compose.yml 
version: "3.6"
services:
  php-fpm:
    image: craftcms/php-fpm:7.4-dev
    volumes:
      - .:/app
#    env_file: .env
  nginx:
    image: nginx:stable-alpine
    ports:
      - 8000:80
    volumes:
      - ./nginx.conf:/etc/nginx/conf.d/default.conf
      - .:/app
  console:
    image: craftcms/cli:7.4-dev
    volumes:
      - .:/app
#    env_file: .env
    command: ["./craft", "queue/listen"]
  mysql:
    image: mysql:8.0
    ports:
      - 3306:3306
    environment:
      MYSQL_ROOT_PASSWORD: SuperPassword123456!
      MYSQL_DATABASE: dev_craftcms
      MYSQL_USER: craftcms
      MYSQL_PASSWORD: SecretPassword
    volumes:
      - db_data:/var/lib/mysql
  redis:
    image: redis:5-alpine
    ports:
      - 6379:6379
volumes:
  db_data:

Expat security vulnerability

@timkelty I know you have more important things to worry about this week, but when you get a minute could you rebuild the images? We are unable to deploy currently as sysdig is reporting a vulnerability in the expat package. Looks like you already added expat explicitly to your Dockerfiles for a previous vulnerability with a >- constraint, so I would think a simple rebuild with no other changes would take care of this. Thank!

CRITICAL Vulnerability found in os package type (APKG) - expat (fixed in: 2.4.9-r0)(CVE-2022-40674 - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-40674)

The craftcms/nginx:<ver>-dev images on Docker Hub do not load nitro.conf

Description

In 1.2.7 the ability to add a nitro.conf file to the root was added and it to be included in the default.conf nginx config. This only fails to work for nginx images 7.3-8.0 however and 7.0-7.2 are fine.

Steps to reproduce

1. start up a container using any of the craftcms/nginx:-dev images on docker hub (except 7.0-7.2)
2. ssh into the container and look at the /etc/nginx/conf.d/default.conf file and see it is the production file and doesn't include include /app/*nitro.conf;

You can also inspect the layers of any of those images and see that NGINX_CONF is set to default.conf instead of dev.default.conf

Update Alpine so CVE-2023-38545 can be resolved

Description

Running apk update --no-cache && apk add --no-cache curl does not update curl to 8.4.0. Upgrading Alpine resolves this.

Steps to reproduce

1. apk update --no-cache && apk add --no-cache curl
2. curl --version
3. curl 8.3.0 ......

Additional info

• Craft version:
• PHP version:
• Database driver & version:
• Plugins & versions:

Image size/layer bloat

e40abfd#r55190078

the corresponding image layer went from 165MB to 695MB

Imagick does not limit its memory usage, can crash php-fpm processes

Description

e.g. For a container with a 768M memory limit, uploading a 6MB GIF to the Assets section will cause the php-fpm process to exhaust all available memory then be killed.

This can be limited by setting ENV MAGICK_MEMORY_LIMIT 200M in the image (or some other sane memory limit for the use case).

Would like to suggest that this gets baked in to the image.

Steps to reproduce

1. Upload a large image to the Asset library
2. See 502 in the network tab, logs

[16-Nov-2022 07:27:43] WARNING: [pool www] child 30 exited on signal 9 (SIGKILL) after 161.276694 seconds from start
[16-Nov-2022 07:27:43] NOTICE: [pool www] child 35 started
2022/11/16 07:27:43 [error] 19#19: *1 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 172.24.0.1, server: _, request: "POST /index.php?p=admin/actions/assets/upload HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "localhost", referrer: "http://localhost/admin/assets/assets"

This happens after just a few seconds.

Additional info

• Craft version: 3.7.59
• PHP version: 7.4
• Database driver & version: MySQL 8
• Plugins & versions: N/A
• Image: craftcms/nginx:8.0

New CVEs

@timkelty We're getting a decent list of CVEs cropping up again in our sysdig scan. Possible to run a rebuild?

 - CVE-2023-27533   High     curl-7.83.1-r6                           APKG     8.0.1-r0         https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-27533
 - CVE-2023-27534   High     curl-7.83.1-r6                           APKG     8.0.1-r0         https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-27534
 - CVE-2023-27535   High     curl-7.83.1-r6                           APKG     8.0.1-r0         https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-27535
 - CVE-2023-27536   Critical curl-7.83.1-r6                           APKG     8.0.1-r0         https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-27536
 - CVE-2023-27537   Medium   curl-7.83.1-r6                           APKG     8.0.1-r0         https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-27537
 - CVE-2023-27538   Medium   curl-7.83.1-r6                           APKG     8.0.1-r0         https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-27538
 - CVE-2023-28879   Critical ghostscript-9.56.1-r0                    APKG     9.56.1-r1        https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-28879
 - CVE-2023-27533   High     libcurl-7.83.1-r6                        APKG     8.0.1-r0         https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-27533
 - CVE-2023-27534   High     libcurl-7.83.1-r6                        APKG     8.0.1-r0         https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-27534
 - CVE-2023-27535   High     libcurl-7.83.1-r6                        APKG     8.0.1-r0         https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-27535
 - CVE-2023-27536   Critical libcurl-7.83.1-r6                        APKG     8.0.1-r0         https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-27536
 - CVE-2023-27537   Medium   libcurl-7.83.1-r6                        APKG     8.0.1-r0         https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-27537
 - CVE-2023-27538   Medium   libcurl-7.83.1-r6                        APKG     8.0.1-r0         https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-27538
 - CVE-2022-29858   Medium   assets-1.0.0                             npm      None             https://nvd.nist.gov/vuln/detail/CVE-2022-29858
 - CVE-2022-38724   Medium   assets-1.0.0                             npm      None             https://nvd.nist.gov/vuln/detail/CVE-2022-38724
 - VULNDB-306015    High     setuptools-59.4.0                        python   65.5.1           https://us2.app.sysdig.com/secure//#/scanning/vulnerabilities/VULNDB-306015

Separately, is this the best forum to request this? Let me know if you'd prefer something other than GH issues!

Add Blackfire extension

Description

Add the blackfire extensions to the images to support profiling PHP requests.

MySQL 8.0: mbind: Operation not permitted logs in console

Description

When using the MySQL 8.0 container, you can see a lot of mbind: Operation not permitted log spam in the console.

A fix is using cap_add on a docker-compose.yml such as:

service:
  mysql:
    image: mysql:8.0
    cap_add:
      - SYS_NICE

Nitro 2.x is affected by this when using MySQL 8.

More info here: https://stackoverflow.com/questions/55559386/how-to-fix-mbind-operation-not-permitted-in-mysql-error-log

To clarify this doesn't break anything in terms of MySQL 8 usage, but will spam the console logs.

Steps to reproduce

1. Create a docker environment using MySQL 8.
2. See the above errors logged

Additional info

• Craft version: 3.6.7
• PHP version: 7.4
• Database driver & version: MySQL 8

Upgrade pgdump to 15.3

Description

Update pgdump to latest

failed with exit code 1: pg_dump: error: server version: 15.3; pg_dump version: 14.8

Steps to reproduce

1. Go to http://localhost/admin/utilities/db-backup
2. Check "Download backup" and click on button backup

Then i get
There was a problem backing up your database. Please check the Craft logs.

Additional info

• Craft version: 4.4.15
• PHP version: 8.0.29
• Database driver & version: PostgreSQL 15.3
• Plugins & versions: Nope

ERROR LOG

2023-07-12 22:16:02 [web.ERROR] [yii\base\Exception] yii\base\Exception: Could not create backup: The shell command "PGPASSWORD="••••••••••••••••••••••••••••••••" pg_dump --dbname=craftcms --host=devcrafthost-postgres --port=5432 --username=craftcms --if-exists --clean --no-owner --no-privileges --no-acl --file="/app/storage/backups/devcrafthost--2023-07-12-221602--v4.4.15.sql" --schema=public --column-inserts --exclude-table-data 'public.craft_assetindexdata' --exclude-table-data 'public.craft_imagetransformindex' --exclude-table-data 'public.craft_resourcepaths' --exclude-table-data 'public.craft_sessions' --exclude-table-data 'public.craft_cache'" failed with exit code 1: pg_dump: error: server version: 15.3; pg_dump version: 14.8
pg_dump: error: aborting because of server version mismatch in /app/vendor/craftcms/cms/src/controllers/UtilitiesController.php:226
Stack trace:
#0 [internal function]: craft\controllers\UtilitiesController->actionDbBackupPerformAction()
#1 /app/vendor/yiisoft/yii2/base/InlineAction.php(57): call_user_func_array(Array, Array)
#2 /app/vendor/yiisoft/yii2/base/Controller.php(178): yii\base\InlineAction->runWithParams(Array)
#3 /app/vendor/yiisoft/yii2/base/Module.php(552): yii\base\Controller->runAction('db-backup-perfo...', Array)
#4 /app/vendor/craftcms/cms/src/web/Application.php(304): yii\base\Module->runAction('utilities/db-ba...', Array)
#5 /app/vendor/craftcms/cms/src/web/Application.php(607): craft\web\Application->runAction('utilities/db-ba...', Array)
#6 /app/vendor/craftcms/cms/src/web/Application.php(283): craft\web\Application->_processActionRequest(Object(craft\web\Request))
#7 /app/vendor/yiisoft/yii2/base/Application.php(384): craft\web\Application->handleRequest(Object(craft\web\Request))
#8 /app/web/index.php(12): yii\base\Application->run()
#9 {main} {"memory":18545120,"exception":"[object] (yii\\base\\Exception(code: 0): Could not create backup: The shell command \"PGPASSWORD=\"••••••••••••••••••••••••••••••••\" pg_dump --dbname=craftcms --host=devcrafthost-postgres --port=5432 --username=craftcms --if-exists --clean --no-owner --no-privileges --no-acl --file=\"/app/storage/backups/devcrafthost--2023-07-12-221602--v4.4.15.sql\" --schema=public --column-inserts --exclude-table-data 'public.craft_assetindexdata' --exclude-table-data 'public.craft_imagetransformindex' --exclude-table-data 'public.craft_resourcepaths' --exclude-table-data 'public.craft_sessions' --exclude-table-data 'public.craft_cache'\" failed with exit code 1: pg_dump: error: server version: 15.3; pg_dump version: 14.8
pg_dump: error: aborting because of server version mismatch at /app/vendor/craftcms/cms/src/controllers/UtilitiesController.php:226)"} 
2023-07-12 22:16:02 [web.INFO] [application] Request context:

Security vulnerabilities reported in container

Description

Our automated Sysdig scan is showing some vulnerabilities in dependencies of the Docker container.

Not sure if this is as simple a fix as a rebuild or if it's "hurry up and wait" for it to be fixed upstream, but including the report here for your reference:

Vulnerabilities report
   Vulnerability    Severity Package                                  Type     Fix version      URL
 - CVE-2022-32221   Unknown  curl-7.83.1-r3                           APKG     7.83.1-r4        https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-32221
 - CVE-2022-42915   Critical curl-7.83.1-r3                           APKG     7.83.1-r4        https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-42915
 - CVE-2022-42916   High     curl-7.83.1-r3                           APKG     7.83.1-r4        https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-42916
 - CVE-2022-43680   High     expat-2.4.9-r0                           APKG     2.5.0-r0         https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-43680
 - CVE-2022-32221   Unknown  libcurl-7.83.1-r3                        APKG     7.83.1-r4        https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-32221
 - CVE-2022-42915   Critical libcurl-7.83.1-r3                        APKG     7.83.1-r4        https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-42915
 - CVE-2022-42916   High     libcurl-7.83.1-r3                        APKG     7.83.1-r4        https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-42916
 - CVE-2022-29858   Medium   assets-1.0.0                             npm      None             https://nvd.nist.gov/vuln/detail/CVE-2022-29858

Provide documentation on NGINX and Caddy Server

We need to provide examples on shipping these images with NGINX and Caddy Server.

Nginx make client_max_body_size configurable.

Description

The nginx image sets a client_max_body_size of 25MB. Trying to upload files bigger than 25MB results in a error 413. Setting the Env Vars:

PHP_POST_MAX_SIZE=64M
PHP_UPLOAD_MAX_FILESIZE=64M

is not enough to circumvent this problem. The only solution at the moment is to bindmount

/etc/nginx/nginx.conf or /etc/nginx/conf.d/default.conf

which could lead to errors when images are updated and changes their config. Adding client_max_body_size to the default.conf server block and make configurable with Env Vars as in the description of the nginx docker image could solve this.

https://hub.docker.com/_/nginx

Steps to reproduce

1. Install Craft with the nginx image
2. Try to upload a file bigger than 25MB

Additional info

• Docker Image: craftcms/nginx:7.4

High vulnerability reported in `tar-1.34-r0`

Description

Friendly neighborhood dev here with a new sysdig scan vulnerability 😀

Our scan is reporting a high vulnerability in tar-1.34-r0

   Vulnerability    Severity Package                                  Type     Fix version      URL
 - CVE-2022-48303   High     tar-1.34-r0                              APKG     1.34-r1          https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-48303

@timkelty any chance you can rebuild the docker images to get the latest security fixes?

Make Nginx document root configurable

It'd be super helpful for the PHP/Nginx images to allow customizing the document root by env variable.

Something like:

web:
  image: craftcms/nginx:8.1
  ports:
    - "8080:8080"
  environment:
    PHP_MEMORY_LIMIT: 512M
    ...
    NGINX_DOCUMENT_ROOT: "/web"
    depends_on:
      - "mysql"
    volumes:
      - .:/app

Xdebug setting for "client_host" and "mode"

Description

We have trouble getting xdebug connected to phpstorm (using the "craftcms/nginx:8.0-dev" container). Unless we add the "client_host" and "mode" setting:

xdebug.start_with_request=yes
xdebug.client_host=host.docker.internal
xdebug.mode=debug

Maybe its due to the nginx-proxy (https://hub.docker.com/r/jwilder/nginx-proxy) we use in front of the other containers.
Would it be possible to add these settings to the craft-cms-xdebug.ini file?

Thanks!

Additional info

• Craft version: Craft Pro 3.7.4
• PHP version: 8.0.3
• Database driver & version: MySQL 5.5.5

Don't need to expose port 9003 for Xdebug

In the various dev.Dockerfiles you have:

# expose the xdebug port
EXPOSE 9003

While it's probably not harming anything, you don't need to expose port 9003 for Xdebug (version 2.x or 3.x), because it's Xdebug that reaches out and connects to client/IDE and not the other way around.

expose is only needed if the container needs to listen on that port, which in Xdebug's case, it doesn't.

Fixed via PR: #31

Error when running image transform: No JPEG support in this PHP build

Description

Error when running image transform.

In /app/vendor/craftcms/cms/src/services/Images.php(207): craft\image\Raster->loadImage('/app/storage/ru...')

Caused by:
in Imagine\Gd::createImageFromString()
imagecreatefromstring(): No JPEG support in this PHP build

Steps to reproduce

1. Try running image transform on a JPEG image using craftcms/nginx:8.0

Possible solution

Configure gd with JPEG support
docker-php-ext-configure gd --with-freetype --with-jpeg
docker-php-ext-install -j$(nproc) gd

Is there a specific reason why this was not done?

Additional info

• Craft version: 3.6.6
• Image version: craftcms/nginx:8.0

Add Github Actions to use Matrix Builds

Buildkit does not support subdirectories. As soon as moby/buildkit#1684 is resolved, we can use a single build.yml for all building and pushing all images:

name: Docker Build
on:
  push:
    branches:
      - stable
jobs:
  build:
    runs-on: ubuntu-latest
    strategy:
      fail-fast: true
      matrix:
        php: ["7.0", "7.1", "7.2", "7.3", "7.4", "8.0"]
    name: build - ${{ matrix.php }}
    steps:
      - name: Checkout
        uses: actions/checkout@v2
      - name: Set up QEMU
        uses: docker/setup-qemu-action@v1
      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v1
      - name: Login to Docker Hub
        uses: docker/login-action@v1
        with:
          username: ${{ secrets.DOCKERHUB_USERNAME }}
          password: ${{ secrets.DOCKERHUB_TOKEN }}
      - name: Build and push php-fpm:${{ matrix.php }}
        uses: docker/build-push-action@v2
        with:
          context: ${{ matrix.php }}
          file: ./${{ matrix.php }}/Dockerfile
          push: true
          tags: craftcms/php-fpm:${{ matrix.php }}
          build-args: |
            PROJECT_TYPE=fpm
            PHP_VERSION=${{ matrix.php }}
      - name: Build and push php-fpm:${{ matrix.php }}-dev
        uses: docker/build-push-action@v2
        with:
          context: ${{ matrix.php }}
          file: ./${{ matrix.php }}/dev.Dockerfile
          push: true
          tags: craftcms/php-fpm:${{ matrix.php }}-dev
          build-args: |
            PROJECT_TYPE=php-fpm
            PHP_VERSION=${{ matrix.php }}

Python security vulnerability

Description

Our sysdig scan is reporting a critical vulnerability with python3-3.10.8-r0. Could you rebuild the images to see if it resolves it? Attaching the full report here for your reference.

Vulnerabilities report
   Vulnerability    Severity Package                                  Type     Fix version      URL
 - CVE-2022-37454   Critical python3-3.10.8-r0                        APKG     3.10.9-r0        https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-37454
 - CVE-2022-42919   High     python3-3.10.8-r0                        APKG     3.10.9-r0        https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-42919
 - CVE-2022-45061   High     python3-3.10.8-r0                        APKG     3.10.9-r0        https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-45061
 - CVE-2022-29858   Medium   assets-1.0.0                             npm      None             https://nvd.nist.gov/vuln/detail/CVE-2022-29858
 - CVE-2022-38724   Medium   assets-1.0.0                             npm      None             https://nvd.nist.gov/vuln/detail/CVE-2022-38724

Vulnerability reported in freetype package version

Description

Our CI system runs an automated sysdig scan on deployment, which is now failing with the following message:

HIGH Vulnerability found in os package type (APKG) - freetype (fixed in: 2.11.1-r1)(CVE-2022-27404 - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-27404)

I believe this will require the base image to be recompiled with that package update.

MySQL example probably should use a different image

The MySQL example here:

https://github.com/craftcms/docker#running-locally-with-docker-compose

  mysql:
    image: mysql:8.0
    ports:
      - 3306:3306
    environment:
      MYSQL_ROOT_PASSWORD: SuperPassword123456!
      MYSQL_DATABASE: dev_craftcms
      MYSQL_USER: craftcms
      MYSQL_PASSWORD: SecretPassword
    volumes:
      - db_data:/var/lib/mysql

...probably shouldn't use the "official" image... because it doesn't work with Apple Silicon M1 processors.

I'd recommend instead mysql/mysql-server:8.0 which is the official image from Oracle. It's also a little bit smaller than the official image, but with no apparent resolution in sight:

https://stackoverflow.com/questions/44854843/docker-is-there-any-difference-between-the-two-mysql-docker-images
docker-library/mysql#318

It's probably the way to go. DockerHub link: https://hub.docker.com/r/mysql/mysql-server

CVEs

@timkelty We are getting a couple CVE reports in sysdig scans again - with the tiff and libde265 packages. Would you be able to rebuild the images to hopefully pull in any upstream fixes?

Provide documentation on setting custom php.ini settings

Provide documentation on setting custom php.ini settings

Inconsistent 404 behavior

Description

In the context of Craft, HTTP requests that 404 in nginx, get passed into Craft's index.php so it has a chance to process them

https://github.com/craftcms/docker/blob/main/nginx/default.conf#L14-L17

So mysite.com/admin will resolve to mysite.com/index.php?p=admin behind the scenes.

But if you specify a PHP script directly (i.e. mysite.com/doesnotexist.php), you'll get an nginx 404 response that doesn't get passed onto Craft.

Haven't investigated much, but likely because of this line https://github.com/craftcms/docker/blob/main/nginx/craftcms/php_fastcgi.conf#L2

Disable opcache on dev images by default

As it is now, editing any files via host-mount isn't going to work, because opcache is enabled and validating timestamps.

This is easily overcome with something like:

    environment:
      PHP_OPCACHE_ENABLE: 0

…but I'm wondering if given that there is a -dev version, it would make sense to do it there by default?

Or maybe, if all -dev is going to do is enable xdebug…you could just ditch the -dev versions and handle via build args (ENABLE_XDEBUG).

That may not be a great idea though, as I believe it prevents those layers from being cacheable?

[8.x] Missing Locales

Description

For some reason, even with intl extensions installed, all locales except english seem to be missing.

I traced it back to the call ResourceBundle::getLocales('') which is part of the intl extension.

Steps to reproduce

1. Create or edit a site
2. Try to choose a language, only english and english variantes are available.

Additional info

• Craft version: 3.7.44

• PHP version: 8.1.6

• Database driver & version: MySQL 8.0.29

• Plugins & versions:

• CP Field Inspect 1.4.4

• Incognito Field 1.3.0

• MatrixMate 1.4.3

• Redactor 2.10.8

• Sentry Logger 1.2.3

Set depends_on for certain containers to control starting order

Description

I think this would be similar to #15 but the docker-compose.yml example could make use of depends_on for certain containers in order to make sure dependencies for those containers are present before it starts.

A couple of examples of where this might be beneficial in some cases, without handling this.

• If console starts before the DB backend is available, this will lead to a possible exit code or error in the container
• If the nginx container starts and tries to load before PHP-FPM is present, it will not recognise part of the default.conf and throw an exit code error in the container.

Setting depends_on will help prevent such edge cases. A safe fixed order would be something like:

• php-fpm (No direct dependency for itself)
• mysql/mariadb/postgres (No direct dependency for itself)
• redis (No direct dependency for itself)
• ngnix (php-fpm, should be started before it, so the default.conf can be loaded without issues)
• console (php-fpm and the DB backend should be available before ./craft commands are called)

Dev image performance is 10x slower than prod

Description

I'm new to CraftCMS and inherited a website for maintanence. As the first step, I've tried to setup a dev and prod Docker environments. However, there seems to be a ~10x performance penalty when using craftcms/nginx:7.4-dev as base image compared to craftcms/nginx:7.4. I'm setting devMode: false.

I can see two problems:

• Everything is slower by a factor of ~10
• Rendering _layouts/components/alerts seems to be the bottleneck

Using craftcms/nginx:7.4 (loading admin/dashboard takes under 500ms)

Using craftcms/nginx:7.4-dev (loading admin/dashboard takes under 5000ms)

Steps to reproduce

Additional info

• Craft version: Craft Pro 3.7.63.1
• PHP version: 7.4.33
• Database driver & version: MySQL 8.0.32
• Plugins & versions:
  • Control Panel CSS 2.4.0
  • Excerptify 1.0.1
  • Freeform 3.13.22.1
  • Mailchimp Subscribe 3.1.1.1
  • Navigation 1.4.31
  • Neo 2.13.16
  • Opening Hours 1.0.0
  • Redactor 2.10.11
  • Redactor Custom Styles 3.0.4
  • Redirect Manager 1.1.1
  • SS Entry Importer 1.0.3
  • Super Table 2.7.4

Nginx return 404

Description

When I try to connect to localhost:8080, nginx is returning me a 404.

Here are some relevant docker-compose logs :

web_1       | 2021-09-21 14:56:53,943 INFO supervisord started with pid 1
web_1       | 2021-09-21 14:56:54,944 INFO spawned: 'nginx' with pid 8
web_1       | 2021-09-21 14:56:54,946 INFO spawned: 'php-fpm' with pid 9
web_1       | nginx: [alert] could not open error log file: open() "/var/lib/nginx/logs/error.log" failed (13: Permission denied)
web_1       | [21-Sep-2021 14:56:55] NOTICE: [pool www] 'user' directive is ignored when FPM is not running as root
web_1       | [21-Sep-2021 14:56:55] NOTICE: [pool www] 'user' directive is ignored when FPM is not running as root
web_1       | [21-Sep-2021 14:56:55] NOTICE: [pool www] 'group' directive is ignored when FPM is not running as root
web_1       | [21-Sep-2021 14:56:55] NOTICE: [pool www] 'group' directive is ignored when FPM is not running as root
web_1       | [21-Sep-2021 14:56:55] NOTICE: fpm is running, pid 9
web_1       | [21-Sep-2021 14:56:55] NOTICE: ready to handle connections
web_1       | 2021-09-21 14:56:56,012 INFO success: nginx entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
web_1       | 2021-09-21 14:56:56,012 INFO success: php-fpm entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
web_1       | 172.23.0.1 - - [21/Sep/2021:14:59:12 +0000] "GET / HTTP/1.1" 404 117 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0" "-" 0.000 - . -

Steps to reproduce

Just execute docker-compose up on suggested docker-compose.yml.

Additional info

• image: craftcms/nginx:8.0-dev

• image: craftcms/cli:8.0-dev

• image: postgres:13-alpine

• image: redis:5-alpine

• Docker-compose file : 3.6

• docker: 20.10.8

• docker-compose: 1.29.2

• Debian : Linux debian 5.10.0-0.bpo.8-amd64

Thanks for your help.

Don't log health checks to access log

Description

To clean up the access logs in the craftcms/nginx logs, the /actions/app/health-check should not log access requests.

Supervisord INFO reaped unknown pid

Description

We see various INFO level log messages from supervisord:

09:05:47,254 INFO reaped unknown pid 375 (exit status 0)

Presumably this is expected for processes killed by PHP-FPM and/or NGINX i.e. cleaning up worker pools perhaps? If this is correct then as per https://www.dailyithelp.com/supervisord-docker-info-reaped-unknown-pid should the logging be updated to error instead of info?

Additional info

• Craft version: 4.5.4
• PHP version: 8.2.10