nginx, fastcgi_pass и правильная настройка

 Если работаем через сокет, какой блок часто можно встретить?

    location ~ \.php$ {

        fastcgi_pass unix:/var/run/php-docker/php8.2-fpm.sock;

        fastcgi_index index.php;

        fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;

        include fastcgi_params;

    }

Но есть нюанс: $realpath_root в данном случае сломан, вероятно потому что там должен быть реальный путь, но там пусто, файлы же в докере.. 

https://nginx.org/en/docs/http/ngx_http_core_module.html#variables

$realpath_root

an absolute pathname corresponding to the root or alias directive’s value for the current request, with all symbolic links resolved to real paths

Вариант - вписывать туда путь явно или через вспомогательную переменную. Хотя с $document_root тоже работает, если где-то выше выставлен root

fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

Но читаемость всё-равно будет не очень: всё-таки ожидается, что root локальный. Можно придумать свою переменную типа

set $root_in_docker /srv/.../ ;

и потом 

fastcgi_param SCRIPT_FILENAME $root_in_docker$fastcgi_script_name;

только не забыть потом

root $root_in_docker;

а то показывает дефолтную nginx страницу. Хотя и так не очень правильно, но - работает

docker, php, fpm - не работает healthcheck

 В случае фпм нельзя сделать курл на fastcgi порт, и особенно на сокет.

На помощь приходит https://github.com/renatomefi/php-fpm-healthcheck

Хинт для убунты: вместо apk install fcgi нужно apt install libfcgi-bin

Docker + php - что брать за основу?

 Из-за ряда особенностей alpine тут не лучший выбор (и см ниже), хотя и он будет работать.

1) FROM php:8.2-fpm и вариации

Плюсы: сообщество любит именно эти образы, как "оригинальные". При этом например FROM php:5.4 сам образ скачает, но что-то поставить туда уже не выйдет, всё дропнуто давно (впрочем, пока ещё можно взять centos:7 и там как раз 5.4 штатно, но об этом дальше)

Докерфайл под нужный движок гуглится за несколько минут

Минусы: 

- лютое неудобство писать докерфайлы, потому что какие-то модули уже стоят (mbstring) и попытка их собрать обламывается (нет модуля онигурама), но об этом надо или просто знать, или гуглить, сама установка требует чтения док на тему docker-php-ext-configure + docker-php-ext-install, то есть опять чтения доков что конкретно надо на каждый модуль... Конечно всё решаемо, но можно легко потерять несколько дней на полной ерунде.

- Нагугленные версии файлов часто не собирают, нужно править ошибки, например

docker-php-ext-configure gd --with-png-dir=/usr --with-jpeg-dir=/usr --with-webp-dir=/usr 

а потом оказывается что и путь не нужен, и -dir пропадает (--with-png), и один из with в принципе.. Иногда нужно -dev пакетов докидывать и так далее.

А ещё полно таких приколов:

&& git clone -b php7 https://github.com/phpredis/phpredis.git /usr/src/php/ext/redis && docker-php-ext-install redis \ ....

- если нужен не очень стандартный модуль - это начинается доолгий квест или с поиском такого в чужих докерфайлах, или чтение док. Проблема тут больше в том, что это нужно не один раз, а на каждый нестандартный модуль. Впрочем, фермошлёпы с типовыми решениями - не столкнутся.

2) FROM ubuntu:22.04, вариант debian:11 или вообще centos:7

Плюсы: если проект уже катили прямо на машину, то есть обкатанные процедуры, список версий давно подобран и проверен, написать с нуля докерфайл - минуты, и он почти гарантированно выдаст рабочую сборку.

Полнейшее единообразие с тем что собирается в режиме хоста, минимальное количество багов из-за смены платформы.

Возможность ставить конкретную версию, если оказалось что последняя версия нам что-то ломает, как минимум на время исправления нашего/их кода, возможность сделать фриз нужных пакетов

Минусы: штатно в дистрибутиве есть только одна версия, если нужно другую то нужно подключать того же Ondrej. Но при условии что платформа уже была где-то развёрнута - всё нужное и так известно. И даже нужные модули, собранные руками, просто копируем отдельным шагом и получаем тот же результат.

3) FROM composer:2

Подвид п.1, только на базе alpine, c docker-php-ext-install и подобным. Иногда вылезают косяки с заменой libc.

С другой стороны, очень хороший вариант, если сначала собрали все нужные модули, подготовили vendor/ итд, и потом COPY --from= перенесли только нужное в новый пустой альпин образ. Это будет меньше обычного и достаточно безопасно.

4) брать уже готовые образы, типа FROM octobercms/october-dev, но именно с октобером вообще прикол - у оф образа 4 звезды, а у "левого" aspendigital/octobercms - 41. И что брать? Хотя и тут понятно, у aspendigital последняя версия пхп 7.4, а уже желательно 8.0 и выше.

Итого: попытки поднять вопрос "что брать за основу" по чатам показали, что нет явного преимущества ни у одного метода. Обычно говорили про скорость сборки (вот только компиляция из п.1 конечно "быстрее" чем apt install уже собранного, да), размеры (именно в данном случае итоговый образ обычно выходит больше гигабайта в обоих случаях, и опять же, компилятор со всеми библиотеками никогда не будет занимать меньше места чем минимальная версия дистрибутива, куда сделали apt install --no-install-recommends), безопасность - но никто не смог объяснить в чём тут безопасность.. При этом помним важное правило безопасности - нужно брать именно проверенные слои в прод. И тут первый метод самый слабый, если в случае п.2 мы обнаружили проблему - можем явно указать рабочую версию и пересобрать контейнер, то в п.1 нужно зарываться в гит-версии и прочее, если мы свои промежуточные сборки не версионировали и всё было latest.

А если погрузиться в multi-stage builds, кэширование слоёв и прочее - всё становится ещё сложнее. И опять без какого-то значительного преимущества одного решения.

И я например с давних лет придерживаюсь политики "компиляторов в проде быть не должно", что исключает п.1 для меня. Сильно больше векторов атаки. Впрочем, п.3 при этом весьма неплох, пока нет деплоя в "мульти-окружения", то есть хост+докер, там я выбираю п.2

И да, можно взять php:8.2-alpine, доставить композер и см выше, но смысл если есть п.3?

Осваиваем php-fpm

Все кому надо уже перешли, но мало ли... Ну и как обычно, хождение по граблям.

php fpm

Что есть php-fpm и зачем оно нужно

fastcgi process manager

Работа через mod_php имеет особенности - все скрипты исполняются от пользователя апача (www, www-data, apache), и даже для 1000 сайтов рабочих процессов php относительно немного и равно количеству воркеров апача. Минусы - каждый воркер ест в среднем 150Мб памяти, и нет разделения доступа. С доступом можно решить через всякие suexec, но это порой немалое снижение быстродействия.
PHP, запускаемый как CGI (не FastCGI!) – страшный атавизм. Быть такого не должно.
Чем такая схема плоха. Если в двух словах – на каждое обращение к php-скрипту запускается новый процесс интерпретатора PHP. Все это работает очень медленно, производительность сайта будет крайне низкой.
Можно запустить под каждого пользователя по fastcgi-процессу, 1 или даже нескольким. Расход памяти на процесс будет меньше, но если создать по 2 процесса на 1000 сайтов - это 2000 fastcgi процессов. Немало.
В этом случае помогает fpm - он управляет fastcgi процессами, при этом их достаточно небольшое количество и создание не такая проблема. Хотя по-моему, актуально скорее для масс-хостиинга -- для больших проектов с единичными сайтами на сервер достаточно простого fastcgi.

Как выбрать по-настоящему хороший хостинг (пара строк взята оттуда)
Nginx + php-fpm на CentOS 5.3
Centos5.5 Nginx 0.8.33 + PHP5.3.1(fpm) + MySQL5.5.0(phpmyadmin) — полная настройка для начинающих — 1 часть
Установка и настройка: Nginx + php5-fpm на debian

PHP и FPM

Некоторые говорят, что FPM пока несколько нестабилен. И просто не везде подходит.
Во freebsd можно выбирать, собирать с этим патчем или нет (даже на 5.3.6), тогда как в centos 5.6 включена версия с патчем, и как я понимаю, возможности его убрать штатно нет. Только пересобирать ручками.
Про дебиан не в курсе, но думаю, там тоже оно включено.
gentoo тоже в шоколаде.. )) спасибо USE флагам.

Вообще, он штатно включен с версии 5.3.3