Docker обслуживание нескольких сайтов на разных доменах

Ещё один докер с nginx и заведенными в него сетями контейнеров

а как быть, если у меня «каждый сайт» так сказать в «своей сети». Например такое есть в каждом docker-compose.yml:

networks:
  my_site_network:
    driver: bridge
    name: my_site_network

Как тогда сделать, чтобы «отдельный nginx» подключался к «этим сетям» и мог использовать «имена контейнеров» из docker-compose.yml других сайтов?*

Если правильно помню надо добавить эту сеть в в подобном виде в “главный nginx” компоуз, а в «сайтовые» компоузы с флажком external: true

Пойду, разверну телефонию, где каждый внутренний номер ext будет крутиться на отдельном докере с астериском. А потом буду думать, как мне на входящие звонки зарулить соединение на нужный докер с нужным ext.

Поставить nginx без докера и настроить reverse-proxy для каждого контейнера.

Хорошего вам CD/CI в будущем телефоноАстерексГоду

На прошлой работе для такого использовался: https://github.com/nginx-proxy/nginx-proxy

Вы сделали хорошее настроение на день! Будем надеяться на скорейшую вакцину от Docker-мозга.

да но тогда придется у каждого «nginx-сайта» выкинуть наружу порт, и сделать его «уникальным». А я хотел бы, чтобы этот «nginx-прокси» мог по домену решать, на какой «nginx» переслать запрос

Да я понял Вас))

Но тут такое дело, что каждый сайт это отдельный gitlab репозиторий, а крутиться они все должны на одной VPS :(

Да вы батенька извращенец)

nginx-proxy https://github.com/nginx-proxy/nginx-proxy

Можно добавить домен поиска для интерфейса докера и резолвить через него что-то типа container.docker. Минусом будет, что nginx не запустится, пока все контейнеры не стартанут.

Запускаешь ещё один Docker контейнер, внутри Nginx/Caddy/Traefik или какой-то ещё веб-сервер. Этот контейнер должен быть в той же Docker сети, что и все контейнеры, которые должны смотреть в Интернет, прописываешь proxy_pass на целевое имя контейнера + порт (в Docker bridge сетях есть свой DNS по имени контейнера).

ЛИБО

Запускаешь Nginx/Caddy/Trafefik/etc на хосте, в каждом контейнере пробрасываешь его HTTP порт на уникальный локальный порт хоста (благо порт контейнера и порт хоста не обязаны совпадать). А в веб-сервере на хосте уже делаешь proxy_pass localhost:ПОРТ.

ЛИБО

Если у тебя приложения де факто статика, то можно поднять S3-хранилище (Garage какой-нибудь с поддержкой режима хостинга сайтов) и деплоить туда свою статику в разные бакеты вместо отдельных контейнеров с Nginx. Тогда можно будет наружу выставить один S3-демон вместо кучи разных Nginx.

Радикально других решений не предполагающих какой-то прослойки слушающей 80-й порт не существует в природе.

Контейнер может быть подключен одновременно к нескольким сетям.

Просто прописываешь у контейнера nginx в networks все сети всех приложений (но только те, которым нужно публиковать свой HTTP, к какому-нибудь Postgres подключать не обязательно). Либо создаёшь специальную nginx_network и подключаешь к ней все контейнеры приложений.

Лично я предпочитаю второй вариант. У меня на сервере есть caddy_network, postgres_network, redis_network и т. д. Каждое приложение подключается к тем сетям, доступ к чему ему нужен для работы.

Если у тебя у каждого приложения свой docker compose файл, то прописываешь nginx_network в них как external: true и делаешь docker compose up для nginx раньше, чем для любого приложения (при этом docker compose down не убьёт приложения, а оставит сеть активной, так что ты без проблем сможешь перезапускать nginx контейнер отдельно от приложений). В первом же случае так не получится (nginx придётся запускать ПОСЛЕ всех-всех приложений), поэтому лучше второй вариант.

Немножко по другой теме, chroot и SystemVinit плохо и костыли говорили они! Но упорно бежали за светом вложенности контейнеров, преодолевая современные namespaces во имя Поттеринга; молодых и амбициозных разработчиков

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

А Docker предоставляет унифицированную возможность запустить своё приложение в аналоге chroot, выбрать базу для него, смонтировать тома в него, пробросить порты, настроить перезапуск при падениях и т. д.

То же самое и с SystemVinit. Мейнтейнеру каждого сервиса нужно писать свой скрипт запуска/перезапуска/остановки, а systemd позволяет писать коротенькие service-файлы, возможностей которых достаточно для 99% ситуаций (а там где недостаточно, в качестве команды прописывается шелл-скрипт и он уже делает что-угодно).

Короче, суть в том, что стандартизированные системы позволяющие сделать одну вещь одним-двумя предпочительными способами и при этом достаточно гибкие для 95% приложений (а для 5% имеющие какие-то workaround) оказываются популярнее систем, где предпочтительный (или единственный) способ что-то сделать - писать скрипт на тьюринг полном языке под каждую задачу (зато это работает в 100% случаев сразу).

Лучше поставить Caddy, гораздо проще управляется.

Там еще можно посмотреть - а нужен ли тебе Docker?

Может стоит вложится в изучение Podman и сделать миграцию на Podman.

Тогда можно будет снести этот daemon docker и «зажить нормальной половой жизнью».

Там точно так же кто-то должен слушать 0.0.0.0:80 и перенаправлять на нужный домен.

Тебе нужно что-то с Service auto discovery. Nginx такое не умеет, насколько я знаю, умеет Traefik или Caddy с плагином

1. Тупое решение:

Поставь на саму VPS caddy https://caddyserver.com/ (если хочется без головняка) или nginx, если умеешь в него и готов пое…ся (понастраивать) с certbot (не забыть обновление серта по cron, ага).

Дальше этот reverse-proxy у тебя будет TLS терминировать, а трафик зарулишь на порты в docker.

Есть ВАЖНЫЙ нюанс: если ты заэкпоузишь порты приложений из docker на машину, то они по умолчанию будут торчать в дикий интернет (и да, обойдут твои правила firewall - см. ссылку), а тебе оно не нужно. См. https://docs.docker.com/engine/network/firewall-iptables/

2. Умное решение. Я бы собрал все в одном compose, и туда же прописал caddy, только его порты оставил торчать на магину и наружу. Минимум усилий.

3. Еще вариант. Поднять отдельный контейнер с reverse-proxy и ему разрешить доступ к сетям из твоих compose. Тут посложнее настраивать.

Лучше поставить Caddy, гораздо проще управляется.

Плюсусю. Если не нужны десятки тыщ RPS, то caddy - прямо идеальная история. Очень доволен эксплуатацией на своих «лабораторных» машинках и взял бы в прод для неогромных нагрузок. Настраивается очень просто + автоматом получает серты для TLS и обновляет их, т.е. эту часть вопроса просто вообще больше никогда не надо трогать руками.

Запускаешь Nginx/Caddy/Trafefik/etc на хосте, в каждом контейнере пробрасываешь его HTTP порт на уникальный локальный порт хоста

Это хороший, но немного опасный совет. Если вытащить порты докера на машину, то они (без доп. действий) будут торчать на весь интернет сразу. Поэтому такое решение потребует дополнительных настроек фильтрации сетевого трафика. https://docs.docker.com/engine/network/packet-filtering-firewalls/

Я же написал «на уникальный локальный порт хоста». Это подразумевает, что при пробросе порта нужно указать не просто «8080:80», а что-то типа «127.0.0.1:8080:80». В таком случае сам докер забиндит порт на хосте лишь на локальный адрес и доступен извне он не будет.

Трогать файервол нужно в более сложных случаев (например, если хочется порт всё же совсем наружу вытащить, но только для определённых входящих IP и т. п.).

Но тут такое дело, что каждый сайт это отдельный gitlab репозиторий, а крутиться они все должны на одной VPS :(

Вы хотите что бы с вами поделились личными практическими навыками в гамаке и стоя?

Ну в целом да) Хочу узнать как в основном люди «крутят» несколько сайтов в docker-е на одной VPS

Но спасибо) Прочитав советы решил делать, через caddy. достаточно просто и то, что мне нужно)