Александр Карабанов

docker save --output elasticsearch.tar <image_id>

docker load --input elasticsearch.tar

rule_files:
- $PWD/alert.rules.yml

Странная конструкция надо указать полный или относительный путь - такие переменные в своём конфиге Prometheus не понимает.

volumes:
- $PWD/prometheus.yml:/etc/prometheus/prometheus.yml

Плохое решение прокидывать файл, внутрь контейнера - это можно сделать один раз в момент старта контейнера и в случае если файл изменился придётся перезапускать контейнер, чтобы это снова произошло. Лучше как Volume монтировать директорию в которую поместить файл, тогда файл в контейнере тоже измениться и достаточно будет послать SIGHUP процессу, чтобы он перечитал конфиг. Переменная $PWD здесь может быть, но её надо предварительно определить, например в .env файле или в одном из семи мест, где их можно определять.

Пример нормального подключени файла с правилами выглядит как-то так:

prometheus.yml

# Load and evaluate rules in this file every 'evaluation_interval' seconds.
rule_files:
  - '/etc/prometheus/alert-rules/*'
  # - 'first.rules'
  # - 'second.rules'

docker-compose.yml

volumes:
  - ./prometheus:/etc/prometheus

Docker это набор сервисов и утилит созданных для удобного управления встроенными в ядро Linux технологиями Namespace (для изоляции процессов) и CGroups (для управления ресурсами).

По мимо Docker существует ряд инструментов призванных делать тоже самое Systemd-Nspawn, LXC, Podman, etc - все они работают похожим образом и точно так же изолируют Linux-овые процессы. Docker самый распространённый и популярный из-за стандартизации процесса сборки образа и удобных утилит для управления жизненным циклом контейнера, Docker это как libc - только в разрезе контейнеров.

Контейнер можно запустить не имея ни одного из этих инструментов с помощью утилиты unshare - она позволяет точно также управлять Namespac-ами (управлять ресурсами придётся вручную добавив процесс в CGroups).

Контейнер это изолированный Linux процесс - соответственно запустить получиться только Linux-овый софт и больше ничего. Контейнер это не маленькая виртуальная машина, контейнер это не Java для всего. Конетейнер это только средство запустить Linux-овый процесс в изолированной среде (и, возможно, ограничить его по ресурсам), например запустить приложение требующее наличия в системе конкретных зависимостей, но отсутствующих по факту. Или запустить в целях разработки конкретную версию PHP, Python, Ruby, etc при этом избежав конфликта зависимостей и Dependency hell из-за несовместимых библиотек на хостовой машине.

Представь себе ситуацию, когда ядро Linux загрузилось и запустило только один (какой угодно) процесс, присвоив ему PID 1 - вот так контейнер выглядит изнутри.

PS
Есть конетйнеры на Windows Core они запустятся только на Windows и служат для изоляции только Windows софта и для них есть набор утилит, которые распространяются в виде набора бинарных файлов тоже, почему-то, под именемем Docker (не путать с Docker-Desktop, так как Docker-Desktop - это набор сервисов позволяющих виртуализировать ядро Linux и тем самым получить возможность запустить Linux процессы на Windows или MacOS).

Директория app находится на два уровня выше директории php в которой размещён Dockerfile - поменяй путь в директиве COPY
И WORKDIR /app создаёт директорию и делает её текущей, так что должно быть COPY ../../app .

PS
Никогда не используй Alpine образы ни для чего - этот дистрибутив оптимизирован для встраевыемых устройств с единицами мегабайт оперативной памяти и процессором с одним ядром, там вместо libc использован суррогат musl с неэффективным на б̀ольших объёмах памяти аллокатором, к тому же она не так сильно распростронена, как libc, что увеличивает вероятность столкнуться с чем нибудь вроде segmentation fault. К тому же часть пакетов в собранном виде отсутствует из-за чего во время установки происходит их сборка, что занимает значительное время, да и образ в итоге получается очень большим (компилятор то никто не умеет настраивать)

Используй debian-slim и PHP устанавливай из Sury репозитория - установка произойдёт очень быстро, а итоговый образ будет компактным (если, конечно, не забывать стирать списки пакетов и кеши на том же слое, где они были созданы)

PPS

# Remove Cache
RUN rm -rf /var/cache/apk/*

Удалять что либо на следующем слое бесполезно - там Copy on Write файловай система и всё что было на предыдущем слое создано там и останется

Можешь файл с базой хранить на хостовой машине и монтировать его в контейнер.

Замени 127.0.0.1 на имя сервиса - у каждого контейнера свой уникальный loopback интерфейс никак не связанный ни с системным ни с соседским.

Добавить в PATH путь до виртуального окружения это и есть его активация - после этого будет использоваться интерпретатор из venv
Можешь открыть в текстовом редакторе скрипт /opt/vev/bin/activate и убедиться в этом.

У Alpine вместо libc суррогат под названием musl, а так же ряд библиотек отсутствует в виде готовых бинарей и собирается из исходников во время сборки образа с неизвестно какими флагами оптимизации, ты ведь их сам не настраивал верно ;-)

Возьми в качестве базового образа debian-slim, установи туда PHP-FPM из Sury репозитория, во первых образ будет меньше размером, во вторых работать будет быстрее.

xdebug.client_host=127.0.0.1

У каждого контейнера свой отдельный loopback интерфейс и он никак не связан с хостовой системой.
Надо использовать IP шлюза контейнера - его можно узнать с помощью docker inspect <container_id> или задать явно в момент запуска контейнера.

PS
Ещё можно снять изоляцию с сети, но так делать не надо.