Иван Корюков

Важно понимать, что докер демон - это сервер, и он работает по сети, т.е. может быть доступен с другой машины или из контейнера.
Самому дженкинсу докер не нужен (если не используется docker plugin для динамисеского создания агентов в контейнерах). Докер нужен агенту, потому что скорее всего вы хотите в итоге собрать докер образ.
Однако, и агенту сам докер не нужен, нужен только клиент докера, а докер-демон может быть в другом месте.
Кроме того, использовать мастер-ноду дженкинса это моветон. Это может помешать работе дженкинса. Лучше выделять отдельных агентов.
В вашем случае нужно сделать следующее: собрать докер образ агента, в котором помимо самого агента будет докер(клиент) и необходимые вам инструменты.
Далее запускаете этот образ с монтирования в него сокета докера, тогда докер-клиент внутри контейнера будет работать с докер-демоном на хосте.
Ну и далее подключаете этот агент к дженкинсу. Сам дженкинс тут может быть вообще без дополнительных инструментов, без докера и даже на другой машине, хотя проще его поднять тут же в докере.
Это не самая безопасная схема, есть недостатки.

Другой вариант - собрать образ можно через podman. Это "докер" без демона. Его легче запустить в контейнере. Опять же его надо установить в образ агента.

Ну или полноценный dind, да. Опять же в агенте.

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

1) Запуск нескольких процессов в одном контейнере противоречит концепции докера. Докер сделан так, чтобы запускать один процесс (не считая дочерних процессов)

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

Проще всего с загружаемыми файлами. Они в любом случае не должны храниться в контейнере и скорее всего это будет volume, который монтируется в оба контейнера.
Взаимодействие между контейнерами по сети тоже штука не сложная, но зависит от способа запуска контейнера.
Если контейнеры запущены через docker run в одной сети (поведение по умолчанию), то они видят друг друга по сети и могут использовать имя контейнера как dns имя.
Если два контейнера запущены в рамках одного docker-compose.yml файла (это ещё называется docker compose project), то они тоже друг друга видят, но уже не по имени контейнера, а по имени сервиса (ключ под которым контейнер указан в секции services).
Если приложение запускается в kubernetes, то там по умолчанию все контейнера pod'a имеют общий локалхост и могут обращаться к друг другу через 127.0.0.1.

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

Важно: nginx работает с dns в обход стандартных инструментов операционной системы. Если вы используете в директивах proxy_pass, fastcgi_pass доменное имя, а не ip адрес, вам нужно дополнительно указать в конфиге директиву resolver <dns-ip>;, где в качестве нужно указать ip адрес dns сервера.
Для докера это обычно 127.0.0.11, для кубера это адрес внутреннего dns сервера.

Раздавать статику можно по разному. Два концептуально разных способа:
- собрать образ nginx в котором есть статика, тут можно либо наследовать образ как сделали это вы, либо копировать статику в чистый образ nginx, что несколько чище и красивее
- убрать статику из образа вообще, выделив её в volume или cdn, но тут придётся при отгрузке сервиса актуализировать статику во внешнем хранилище

2) если очень хочется запустить несколько процессов в контейнере, то нужно запустить один процесс, который запустит остальные. Есть такие программы - менеджеры процессов. Это может быть supervosord, pm2, runit и т.п.
Это такая программа, основной задачей которой является запуск других программ. Обычно у неё есть свой файл конфигурации, в котором вы описываете какие программы запустить и как это сделать.
Ещё раз повторю - докер придуман не для этого. Не стоит делать этот приём основным при работе с докером.
Это костыль. Он иногда нужен, но очень редко.

3) То что nginx отдаёт код index.php, это проблема не настройки контейнеров, а конфигурации nginx. Если бы проблема была только в контейнерах, то вы бы получили не код скрипта, а 502.
Первое что бросается в глаза в вашем конфиге - это регулярка в локейшене для обработки php скриптов.
Попробуйте сделать как здесь.

Попробуйте использовать distorless образ - в нем нет ничего кроме рантайма необходимого вам ЯП. Этот вариант более универсальный.

Другой вариант - использовать AppArmor. Здесь уже образ не совсем самодостаточный и надо ещё запустить контейнер с особыми флагами. Зато получается именно то что вам нужно - явный запрет на конкретные действия.

Белый ip назначен вашему роутеру. У вашего компьютера другой ip адрес - адрес приватной сети, обычно начинается на 192.168 или на 10.
Когда вы запускаете программу с адресом 0.0.0.0, вы говорите ей слушать все сетевые интерфейсы вашего компьютера. Но только вашего компьютера.
Чтобы настроить доступ к вашему серверу через белый ip, вам нужно настроить на вашем роутере проброс порта. Это может называться иначе. Суть такая: вы говорите роутеру, что если пришло соединение на <адрес-роутера>:<порт-роутера>, то проксировать его на <адрес-компьютера>:<порт-компьютера>.

1) зачем вам оборачивать soketi в screen? Лучше напрямую запускать сам soketi
2) вероятно мешает опция screen -d, потому что type=simple ожидает что программа запустится и продолжит работать

Многие фасады в ларавеле позволяют получить мок или задавать ожидания прямо через фасад.
В документации пример как раз с кешем.
https://laravel.com/docs/10.x/mocking#mocking-facades

Кубернетис нужен как раз для того чтобы приложения не знали ничего о машинах. Это платформа, которая скрывает детали реализации и даёт вам абстрактные рычаги управления.
Если вам важно запускать приложение на особенных машинах, то надо пометить машины тэгом и настроить правила выбора машины через affinity/tolerations/nodeSelector.
Например так можно настроить чтобы приложение запускалось только на машинах с gpu, или только на машинах в конкретном ДЦ.
Здесь важно что вы не выясняете подходит ли вам текущая машина, а требуете чтобы приложение было запущено на подходящей.

Есть, однако, и возможность передать в под информацию о нем самом в виде env переменных. Это называется downward api - при объявлении env переменной в манифесте пода можно указать что значением будет характеристика самого пода, например значение указанного лейбла, название неймспейса, или, как вариант, название ноды, на которой запущен под.

Prometheus-operator следит за созданием сервисмониторов в определённых неймспейсах, и фильтрует сервисмониторы по лейблам.
Соответственно, вам необходимо посмотреть в манифесте прометеуса, какие значения там выставлены, и создать свой сервисмонитор с соответсвующем неймспейсе с необходимыми лейблами.

Не работает потому что nginx и веб-приложение используют один и тот же http заголовок для передачи данных авторизации. Универсального решения нет.
Как вариант, если приложение и так закрыто своей авторизацией, то basic можно и не делать. Или можно изменить заголовок авторизации в веб-приложении. Или попытаться разнести бэк и фронт на разные домены, чтобы одно было закрыто бейсиком, а другое собственной авторизацией.

Как уже написали в соседнем ответе вы можете обойтись одним только grep, однако ваша ошибка в другом.
Во-первых, вы используете возможности shell, там где его нет. Пайп это специальная команда, которая есть в sh и bash. А хелсчек exec вызывает программы напрямую.
Во-вторых, command это массив аргументов запуска. Каждая опция, каждый аргумент должен быть отдельным элементом массива, а вы просто дописали всё во второй элемент и оно распознаётся как один большой аргумент cat.

Делайте греп и помещайте каждую опцию в отдельный элемент списка.

Домен привязывается не к контейнеру, а к ip адресу.
Вы не уточнили где именно поднята эта виртуальная машина и с какой целью.

Если у вас на компьютере для личного использования, то проще всего использовать nip.io или прописать соотвествие домена и ip адреса виртуальной машины в файле hosts.

Если вы арендовали виртуальную машину у какого-то провайдера и хотите сделать её доступной для всех по домену, то нужно купить домен и в его настройках указать ip адрес виртуальной машины.
Ну или использовать всё тот же nip.io если это общий сервис для малого круга лиц.

UPD:

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

server {
    listen 80;
    server_name site-1.domain.com;
    location / {
        proxy_pass http://127.0.0.1:27073;
    }
}
server {
    listen 80;
    server_name site-2.domain.com;
    location / {
        proxy_pass http://127.0.0.1:12345;
    }
}