Руслан

в alpine группа www-data есть с uid 82
добавить пользователя можно так:

adduser www-data -S -H --disabled-password -g "www-data" -h /dev/null -u 82 -G www-data

Но тогда для пользователя и группы ID будут 82, а в той же ubuntu ID 33

Я бы сделал по другому. Для обоих образов (nginx и php) добавил бы одинаковые группы и пользователи, скажем www:www с ID - 1010 через Dockerfile:

RUN addgroup -S -g 1010 www && adduser www -S -H --disabled-password -g "www" -h /dev/null -u 1010 -G www

ну и в том же Dockerfile указал что запускаться из под этого пользователя:
USER 1010
На хост машине тоже бы добавил пользователя и группу с таким же ID

Ну и в конфигах nginx и php указал бы пользователя www

Создаете docker-compose.yml, прописываете все используемые сервисы и связи между ними и как использовать ими переменные ENV. Для каждого сервиса описанного в docker-compose.yml указываете Dockerfile в котором указываете какой образ использовать + различные инструкции, например git clone Ваших кодов, где скачать скрипты инициализации СУБД (для инициализации базы удобно использовать docker-entrypoint-initdb.d), копирование конфигов в контейнер и прочее...
Все ваши секретные данные (пароли и прочее) прописываете в .env файле который отдаете заказчику по безопасному каналу связи.
Ну и все, отдаете заказчику пустой проект, но со всеми прописанными инструкциями в docker-compose.yml и Dockerfile для контейнеров.

Можно sql скрипты с дампами положить в папку docker-entrypoint-initdb.d
При первом ините контейнера они исполнятся и будет и структура и данные которые Вам нужны

Как тут уже написали можно но не нужно, в 99% случаев это так. Но... бывают задачи, например у меня есть один агент написанный на питоне и к нему в довесок нужны filebeat и merticbeat. Можно было бы поднять 3 контейнера, но начинаются шаманства с тем как читать логи и метрики в разрезе процессов в другом контейнере. К тому же, как и у Вас, мне нужно тиражировать агента и ставить в кучу мест, кое где лютые ИБшники закрыли доступ к половине ресурсов интернета, и таскать по 3 образа не удобно, проще все собрать в один и с него поднять за 5 секунд.

Решается ваша задача достаточно просто, есть такая замечательная вещь как supervisor. Он запускается как основной процесс контейнера, и он, в свою очередь, поддерживает работу 3-х других процессов, перезпуская их в случае краша. Запускается контейнер через docker-compose что гарантирует перезапуск контейнера в случае его краша.

Делайте так как Вам удобно, один контейнер - один процесс это для большей части типичных задач, но не для всех!

Контейнер живет ровно столько сколько жив процесс запущенный в нем командой ENTRYPOINT [ "php", "./index.php" ], как только Ваш скрипт index.php завершает работу контейнер останавливается.
Какую задачу Вы хотите решить? От этого зависит как сделать правильно.

В Dockerfile укажите что необходимо установить supervisor, напишите свой конфиг для него, через него запускайте сколько угодно служб. Вообще философия докера 1 контейнер - 1 процесс. Контейнер живет пока живет процесс. При запуске контейнера можно запустить только 1 процесс.
Т.е. supervicor и будет этим процессом который не дает закончить работу контейнеру. А все остальные процессы управляются супервизором.

Ответ же на виду:

Sub-process /usr/bin/dpkg returned an error code (1)

Поиск в гугле
https://www.google.com/search?q=Sub-process+%2Fusr...

Сообщение об ошибке «Sub-process /usr/bin/dpkg returned an error code (1)» указывает на проблему с установщиком пакета. Это может произойти в Ubuntu после неудачной установки программного обеспечения или в случае повреждения установщика.

Вот все варианты решения проблемы:
https://phoenixnap.com/kb/fix-sub-process-usr-bin-....

127.0.0.x это localhost он же loopback , по этому 2 одинаковых порта опубликовать не выйдет. Не имеет значение при этом четвертый актет, это все будет localhost. Вам надо или разные порты под разные экземпляры монги публиковать или иметь на машине разные реальные адреса, для этого Вам надо иметь 2 сетевые карты с разными реальными сетевыми ip адресами.

Еще вариант, поднять 3 докер с webui (например mongotron.io) все 3 контейнера обеднить сетью docker-compose, тогда они смогут работать каждый со своим портом на выделенном докером адресе, пробросить наружу адрес webui, и управлять монгами через него, далее монги объединить в кластер и мастеру опубликовать порт наружу.