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

Не надо ничего автоматизировать - либо подмонтируй volume с правильными конфигами (a2enmod headers всего лишь делаем симлинк на конфиг с настройками mod_headers), либо собери на основе этого образа свой в котором уже будут правильные кнфиги.

Docker & Gitlab - быстрый деплой для любого проекта

Разница в бинарях - Python на хостовой машине собран без отладочной информации, а тот, который в образе python:3.10.4 собран с нею.

Выходом из ситуации будет - взять базовый образ Debian и установить в него Python из штатного репозитория с помощью штатного пакетного менеджера, тогда результат теста бенчмарка на хостовой машине и в контейнере не будет отличаться.

Можно пойти дальше и собрать Python из исходников самому, но самостоятельная сборка это такое себе развлечение (хотя с помощью pyenv делать это довольно просто), а выигрыш не такой уж и значительный - устанавливать бинарные пакеты сильно проще.

PS
Никогда не используй образы Alpine - там вместо glibc суррогат под названием musl. В прочем для статически слинкованных бинарей на Go использовать можно, но тогда уж выгоднее использовать scratch

Директория с данными не пуста, поэтому скрипт создающий кастомного пользователя не запустился.
Почисти дирекорию с данными, если она просто примонтирована к контейнеру через bind mount или сотри volume.

docker compose up -d

Если в docker-compose.yml укажешь build context вместо образа, то всё это можно будет делать одной командой:
docker compose up -d --build rest-api-client

Артефакт сборки надо поместить в /app

Тут не помешает двухстейджевая сборка, чтобы оптимизировать размер образа:

FROM node:18 as static-builder

WORKDIR /app

COPY package*.json ./

RUN npm install --legacy-peer-deps

COPY . .

RUN npm run build

# EXPOSE 3000 - эта директива оставлена для обратной совместимости и ни какие порты не открывает, можно её не использовать

FROM nginx

COPY --from=static-builder /app/publc /usr/shared/nginx/html
# или другой каталог, если артефакт сборки помещается не в /app/publc

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 файловай система и всё что было на предыдущем слое создано там и останется

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