mureevms: Я нашел в чем была проблема!!!
Конец nginx.conf выглядит так:
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
То есть я подключал и свой конфиг из conf.d и подключался дефолтный из sites-enabled, вот второй перебивал первый, я удалил строчку со sites-enabled и все заработало!!!
mureevms: Меня удивляет то, что в логах ничего нет. Вот когда я перехожу на queryme.ru логи приходят в access, а вот уже на site.queryme.ru логов вообще нет, получается что nginx rev prox вообще не пересылает меня туда, так что получается что я где то накосячил в nginx настройках
mureevms: Да оно и так должно работать, я уже второй день каждую строчку перечитываю и не могу понять что я упустил, по ходу придется еще раз перечитывать документацию docker и docker-compose и смотреть конфиги реверс прокси
mureevms: как бы заранее не известно какой айпишник выделится в контейнере , поэтому там есть shell скрипт, который из глобальных переменных берет SITE_IP и SITE_PORT и подкидвает их в upstream, а там где стоит listen 80; это слушается не из контейнера, а глобально, либо я совсем тупой и вообще бред несу)
В будущем планирую добавить бэкенд и засунуть его в контейнер и бд, которую тоже засуну в свой контейнер, я хотел отделить внешние порты и внутренние, те я могу достучаться только через 80 порт до реверс прокси сервера, а тот уже переправит куда нужно, на сайт через site.queryme.ru или бэкенд api.queryme.ru через upstream. Объявление локальной сети не обязательно.
Насчет имени site в правилах сборки то оно есть
nginxreverseproxy:
build: ./nginx-reverse-proxy
expose:
- "80"
- "443"
links:
- query:site <-------- вот оно, я говорю что буду обращаться к контейнеру query через "site"
Артем Лисовский: Ну не скейлить же все программно, выйдет не красиво, а вообще мое решение лучше, тк в конечном счете вы будете использовать один спрайт лист, который подтянется с сервера. В одном спрайтлисте может быть большое количество спрайтов, но вся прелесть в том, что для одного спрайтлиста делается всего один drawcall, а в вашем случае, если спрайтов много, то для каждого вызывается отдельный drawcall. Поэтому использование спрайтлиста намного выгодней, и масштабировать проще один спрайтлист чем каждый спрайт
Mr4x: Что то типа того?
Где root /var/www/public/; - путь к директории с index.html и компонентами?
server {
listen 80;
index index.html;
server_name localhost;
error_log /var/log/nginx/error.log;
access_log /var/log/nginx/access.log;
root /var/www/public/;
Смотри, допустим в AppComponent в Angular2 я настрою роутинг для всех страниц, типа такого { path: '/auth', name: 'Auth', component: AuthComponent}
Потом на Golang напишу роуты для index.html и папки assets, в которой лежат все остальные компоненты. Но допустим какой хэндлер будет обрабатывать запросы типа localhost/auth или localhost/registration? И еще есть проблема, все запросы проходят через index.html и допустим я перейду на тот же самый localhost/auth со своим темплейтом и компонентом и обновлю страницу, то ангуляр не сможет вывести ничего, так как роуты остались в главном компоненте AppComponent, как с этим быть ?
Roman Kravchik: Ну да, конечно, апи запросы в любом случае роутить надо, плюс статика, я имел в виду что сами переходы между страницами роутить не буду, чтоб исключить рендеринг с бэкенда, все переходы между страницами будут на клиенте. Например как мобильные приложения: вся отрисовка в клиенте, клиент отправляет только http запросы, и отрисовывает их у себя
