Vamp

Нужно монтировать /usr/share/elasticsearch/data

volumes:
      - /home/user/green:/usr/share/elasticsearch/data

Ваш образ создан from scratch. Это значит, что в нём только приложение. И больше ничего лишнего нет. В том числе и бинарника /bin/bash, путь к которому вы указываете в /etc/passwd

Возьмите образ на основе альпины: anycable/anycable-go:1.2-alpine
Там есть /bin/sh, пакетный менеджер и ещё всяких разных утилит по мелочи.

"нет возможности из процесса, поднятого в докере запускать под-процессы"

Это неправда. Те же самые nginx и php-fpm запускают мастер процесс и стартуют кучу своих воркеров как отдельные процессы.

Простейший способ сделать то что вы хотите - запустить скрипт внутри контейнера

docker run -d -v /home/project:/var/www php:8.1-cli php /var/www/worker.php

В дальнейшем если воркер упадет, докер его перезапустит. И таких docker run команд выполняете столько, сколько хотите одновременно работающих воркеров.

что такое dev суфикс (freetype и freetype-dev) и как понять какую версию ставить (я ставил методом тыка, когда получал ошибки и гуглил)

Dev суффикс означает, что в данном пакете присутствуют файлы, необходимые для компиляции кода, использующего устанавливаемую библиотеку. Устанавливать нужно обе версии. Обычная версия "freetype" содержит саму библиотеку в so файле, которую gd будет подключать в рантайме. Dev версия "freetype-dev" нужна для сборки самого gd, так как модуль собирается из исходников.

почему, например, для mycrypt мне сперва нужно загрузить именно libmcrypt-dev, потом через pecl скачать mcrypt, а потом через алиас docker-php-ext-enable включить (экспериментировал и не работает с другими сценариями), а если смотреть на opcache, тот тут сразу docker-php-ext-install и все, а xdebug еще один сценарий: pecl -> docker-php-ext-enable - почему все по разному, как это понять?

Для разных модулей требуются разные сторонние библиотеки. Для gd это freetype (для работы со шрифтами), libpng (для поддержки формата png), libjpeg-turbo (для поддержки jpeg). У opcache таких зависимостей нет, поэтому ничего дополнительно устанавливать не требуется.

в чем отличие этих сценариев установки расширений (что делает каждая команда, простыми словами)?

У php есть модули, которые поставляются с самим php. Например: zip, opcache, pdo_mysql, intl. Такие модули устанавливаются специально предусмотренным для этого скриптом docker-php-ext-install. Этот скрипт распаковывает исходники php, собирает запрошенные вами модули, копирует их в /usr/local/lib/php/extensions/no-debug-non-zts-20190902 (в других образах php путь может отличаться), прописывает загрузку модуля в ini и удаляет распакованные ранее исходники. То есть под капотом скрипт docker-php-ext-install вызывает скрипты docker-php-source, docker-php-ext-configure, docker-php-ext-enable.

А есть модули, которые хостятся отдельно на сайте pecl.php.net. Это официальный репозиторий, где хостятся всякие разные сторонние модули типа mcrypt, imagick, xdebug. Для их установки нужно использовать утилиту pecl. Так как pecl автоматически не включает модули в ini, из-за этого необходимо самому включать их при помощи скрипта docker-php-ext-enable.

нагуглил что
docker-php-source - создает /usr/src/php

Ещё распаковывает туда исходники самого php и поставляемых с ним модулей.

docker-php-ext-install - скачивает (ОТКУДА?)

Из архива /usr/src/php.tar.xz

docker-php-ext-configure- конфигурирует перед установкой (что это значит?)

Этот скрипт настраивает настройки, с которыми будет скомпилирован модуль. Например, тот же gd можно собрать без поддержки jpeg если сконфигурировать без опции --with-jpeg. Нужно ли запускать docker-php-ext-configure так же зависит от того, что написано в документации. Очень мало модулей требует предварительной конфигурации перед установкой. Мне на ум приходит только gd.

В целом, официальная документация php вам поможет понять каким способом нужно устанавливать модули. Смотрим раздел requirements. Если написано "This extension is bundled with PHP", значит нужно устанавливать при помощи скрипта docker-php-ext-install. Если написано что-то вроде "This PECL extension is not bundled with PHP", значит нужно устанавливать через pecl.

Независимо от способа установки, нужно всегда устанавливать библиотеки, от которых зависят конкретные нужные вам модули. Например, в том же imagick написано "ImageMagick >= 6.2.4 is required". Это значит, что нужно установить библиотеку imagemagick. В вашем базовом образе на основе alpine 3.16 в репозиториях ОС присутствует версия 7.1.0, которая подходит под условие >= 6.2.4:

/var/www/html # apk info imagemagick
imagemagick-7.1.0.35-r0 description:
Collection of tools and libraries for many image formats

imagemagick-7.1.0.35-r0 webpage:
https://imagemagick.org/

imagemagick-7.1.0.35-r0 installed size:
4664 KiB

Для intl нужна "ICU library, version 4.0.0 or newer". Такая библиотека тоже присутствует в репозиториях альпины:

/var/www/html # apk info icu
icu-71.1-r2 description:
International Components for Unicode library

icu-71.1-r2 webpage:
https://icu.unicode.org/

icu-71.1-r2 installed size:
796 KiB

Dev версии библиотек нужны только в момент установки модулей. Дальше их желательно удалить, чтобы уменьшить размер вашего образа.

RUN DEBIAN_FRONTEND=noninteractive apt-get install -y php php-pgsql php-mbstring php-xml php-apcu composer php-mongodb php-curl php-memcached

У вас сложности с тем, что xdebug является инициатором коннекта на ваш домашний ip. И если домашний провайдер выдаёт вам не белый IP, то напрямую такой коннект сделать не удастся.

Выходом может быть проброс порта через ssh.

ssh -R 9003:172.17.0.2:9003 user@vpsaddr
Данная команда установит ssh соединение с логином user на ваш vps по адресу vpsaddr и откроет на этом сервере порт 9003, который сквозь ssh соединение будет прозрачно проксироваться на 9003 порт уже на вашем локальном компьютере.

Вам нужно будет только узнать какой локальный IP адрес у вашего контейнера и подставить его вместо 172.17.0.2, который я указал для примера.

Узнать его можно командой
docker inspect ваш-контейнер | grep IPAddress
Этот ip адрес нужно прописать в xdebug.client_host и в опцию -R вместо 172.17.0.2.

Вам нужно установить на хост node_exporter (можно в докере). Он будет собирать метрики с хоста и экспортировать их для prometheus.

Необходимо установить расширение mongodb для самого PHP и дополнительную библиотеку alcaeus/mongo-php-adapter.

Единственный официальный способ изменить настройки контейнера - удалить и запустить новый с измененными настройками. Чтобы не терять настройки, удобнее всего записывать их в конфиги формата compose, с которыми работает утилита docker-compose.

Чтобы не терять данные контейнера их нужно размещать в папках, подключаемых через volume. Всё остальное будет уничтожено при переделке контейнера.

Потому что нужно устанавливать пакет php7.3-bcmath. На вашем же скриншоте видно, что установилась версия модуля для PHP 7.4: php-bcmath is already the newest version (2:7.4+73+ubuntu18.04.1+deb.sury.org+1)

В dev окружении почти никогда не бывает такой же образ как в prod. Но docker позволяет сделать очень близко к проду при помощи наследования. То есть prod наследуется от, допустим, php:7.3.3-fpm, устанавливает нужные модули и опции php.ini, а dev образ наследуется от prod и доустанавливает xdebug, composer, node, модифицирует только нужные для дева опции php.ini.

Такая организация позволяет почти не тратить время на актуализацию dev образа. Поменялся prod - в одну команду пересобрали и dev. Очень удобно.

Корнем всей иерархии будет это базовый prod образ, в котором нет никаких файлов проекта. Уже от него наследуются dev и образы с запакованным приложением. В контейнер на основе dev образа монтируете рабочую директорию проекта и работаете как удобно.

Иерархия наследования получается примерно такая:

php:7.3.3-fpm
└─ prod:base
   ├─ dev:latest
   ├─ prod:0.0.1
   ├─ prod:0.1.15
   └─ prod:1.0.4
      └─ prod:latest  (плавающий тег, указывающий
                       на самый свежий релиз)

При таком подходе у вас будет 3 докерфайла - prod:base, dev и финальный prod.

Можно обойтись двумя докер файлами, если на прод подсовывать скрипты проекта через volume, как и в dev. Я как раз использую этот вариант, так как в моей компании применяется continuous delivery. Грубо говоря, это когда почти каждый коммит в master сразу улетает на прод. Если каждый раз собирать новый образ, становится слишком много образов, за которыми приходится отдельно следить и удалять старые, чтобы избежать переполнения реестра. Плюс возникают сложности с обеспечением атомарности деплоя, так как сервис становится недоступен в момент рестарта контейнера, из-за чего приходится городить балансировку и/или blue-green деплоймент.

С volume всё просто - залил в него новый код, переключил симлинк и всё готово. А базовый образ меняется относительно редко - обычно когда выходит новая версия PHP. В этом случае можно и ручками обновить базовый образ на сервере. Но этот вариант хорош только когда мало серверов. Для больших кластеров конечно лучше работает вариант с упаковкой приложения в отдельный образ.