d-stream

Концептуально: свой источник образов. Например проверенный безопасностью.
А хранить - есть разные варианты: Artifactory, Portus, Harbor, Docker Registry, Sonatype Nexus Repository Manager, Atomic Registry, Quay.io
Половина из них - умеет быть в том числе и проксёй

Можно сказать подавляющее большинство докеров работают на виртуалках.
Ну не практикуют сейчас bare metal варианты в общем случае.
То бишь стоит сервер с каким-нибудь гипервизором, а в гипервизоре крутится множество виртуалок, в каждой из которых докер...
Ну и да - на win10/11 вполне для поиграться поднимается не только docker desktop, но и в нём k3s, rancher и т.п. - этакий вариант пощупать кубера дома. Либо подходящая виртуализация - и там пускать linux в котором уже docker и далее.

Из официальной доки:

The EXPOSE instruction informs Docker that the container listens on the specified network ports at runtime. You can specify whether the port listens on TCP or UDP, and the default is TCP if the protocol is not specified.

The EXPOSE instruction does not actually publish the port. It functions as a type of documentation between the person who builds the image and the person who runs the container, about which ports are intended to be published. To actually publish the port when running the container, use the -p flag on docker run to publish and map one or more ports, or the -P flag to publish all exposed ports and map them to high-order ports.

By default, EXPOSE assumes TCP. You can also specify UDP:

bios обновлён до самого актуального?

Можно сделать "как у взрослых": поднимать второй контейнер с новой версией и переключать трафик на него. В зависимости от типа переключения получим bluegreen либо canary deployment

Собственно задача докера - изолировать софт в контейнере и не дать ему "убежать" за пределы изоляции. Соответственно в обход механизма томов - это будет разве что в рамках уязвимости.

Ну можно начать с анализа и прикинуть - что и где надо будет менять, если вдруг серьёзно вырастет нагрузка.
Напрашивается нечто типа некий балансировщик, который раскидывает запросы на множество web-серверов, ну а те соответственно стучатся в так или иначе горизонтально размасштабированную базу.
Вот и выходит что N контейнеров-клонов с nginx+php + M контейнеров с базой и перед ними - контейнер(ы) с балансировщиком.

Вот примерно такие абстрактные "линии разреза" в первом приближении.
Дальше уже можно смотреть в сторону полного перфекционизма когда 1 функция = 1[xN]контейнер

Один из вариантов - использование скриптом конфигурационных (env) файлов, которые не деплоятся в рамках сборки, а живут на каждом конкретном сервере (разовая первоначальная настройка).

"купленный домен" - это скорее купленная запись в общепринятом справочнике.
то бишь все, сунувшиеся на domen.org получат справку что надо идти по ip адресу 1.2.3.4
И они пойдут
А дальше сервер на этом адресе - должен слушать обращения и отвечать.

Отсюда:
надо на сервере начать слушать обращения - то бишь 80 порт для http и 443 порт для https и переправлять это тем или иным образом приложению (которое слушает в данном случае иной порт)

Наиболее распространенные варианты - это например nginx, haproxy и т.п.

Теперь про "имя сервера": собственно никто не мешает для кучи разных доменных имён указать один и тот же ip адрес и все обращения будут прилетать к одному серверу (L3), но в каждом обращении будет фигурировать имя к которому обращались (L7) и то самое, что слушает 80/443 порт по этой информации может например передавать (проксировать) обращения например в разные приложения/контейнеры/порты

Итого: поднять на самом сервере или в контейнере nginx/haproxy и прописать в конфигах:
при обращении domen1.org - перенаправлять в контейнер на порт 8000, когда-нибудь потом добавить что при обращении к domen2.org - перенаправлять на соседний контейнер на порт например 8001

Ну или пока упростив - слушать контейнером 80/443 порт ( 80:8000 ) и внутри контейнера пока ничего не делать дополнительного пока не появится второй домен

ну примерно вот так:

image: # имя докер-образа 

stages:
  - build
  - tests
  - deploy

build_my_project:
  stage: build
  tags: 
    - тэг раннера где запустить
  script:
    - ... # собственно действия для билда
    - ... 
    - ...
    - ...
  artifacts:
    name: как будет обзываться артефакт сборки
    paths:
    - путь до файлов в артефакт
    expire_in: 1 hour # сколько ему жить
test1: 
  stage: tests
  tags: 
    - тэг раннера где запустить
  needs:
    - build
  scripts:
    - # действия по выполнению теста

test2: 
  stage: tests
  tags: 
    - тэг раннера где запустить
  scripts:
    - # действия по выполнению теста 2

deploy_to_dev:
  stage: deploy
  tags: 
    - тэг раннера где запустить
  needs:
    - tests
  rules:
    - if: $CI_COMMIT_BRANCH == "development"
  scripts:
    - # действия деплою в dev


deploy_to_prod:
  stage: deploy
  tags: 
    - тэг раннера где запустить
  needs:
    - tests
  rules:
    - if: $CI_COMMIT_BRANCH == "master"
  scripts:
    - # действия деплою в dev

словами: на первом шаге - build выполнится то что прописано в scripts (последовательно, по строкам)
на втором шаге - test - параллельно выполнится два (ну или сколько надо блоков тестов)
на третьем - deploy - выполнится или deploy_to_prod или deploy_to_dev или ничего в зависимости от того в какой ветке идет сборка ($CI_COMMIT_BRANCH)
image: # имя докер-образа - имя соответсвующего docker-образа с подготовленной средой разработки (node:14 - для npm, mcr.microsoft.com/dotnet/sdk:6.0 - для .net6 и так далее)
можно и любой свой

needs: - описывает от каких шагов зависит шаг (это относительно свежее, ранее более жесткое dependencies:)

в правилах firewall разрешены входящие/исходящие подключения ?