Comments 28
Просветите, зачем нужно идти по публичному домену на локальное приложение?
Не совсем понятны дополнительные телодвижения. Почему просто не настроить nginx, как reverse proxy, без frp?
Как вы собрались проксировать запрос с nginx в локальную сеть?
Если сервер с nginx не в локальной сети, то всегда можно поднять VPN.
Ну опишите, что для этого нужно сделать. По шагам.
Делается это так, поднимаем VPN на удаленном хосте, выдаем себе статический локальный адрес например 192.168.42.55, (прописываем его на своем компе в настройках VPN подключения).
Далее настраиваем на VPN сервере NGINX, прикручиваем сертификат от LE (через certbot например), и добавляем server на нужный домен с proxy_pass на свой статический локальный адрес http://192.168.42.55.
Схема достаточно простая, работает шустро и безотказно.
Для работы reverse-proxy достаточно подключиться к VPN
Это уже как минимум не проще.
А добавьте сюда вопросы менеджмента роутинга. Например появился новый дев, и теперь ему нужно тоже проксировать, добавлять правила в nginx?
И дальше, как локально роутить трафик по контейнерам? У нас докер, одновременно может работать несколько nginx
Да, технически это возможно. Но это совсем не проще. ИМХО.
Но если быть откровенным, такая мысль не приходила, возможно ее так же можно до ума довести. Спасибо
Тоже не совсем понимаю, почему это сложно. На VPS ставите nginx в режиме reverse proxy и на том же сервере ставите wireguard. А потом просто создаёте wireguard приватную сеть со всей плеядой серверов, а nginx reverse proxy на VPS пусть выбирает, куда именно и что проксировать. Ну там запрос к example.com пустит на сервер 10.0.0.1, а к api.example.com пустит на сервер 10.0.0.2.
Конечно же не забываем про плохих людей и защищаем VPS сервер и nginx на нём от атак, ботов и прочей нечести.
Возможно я не раскрыл мысль.
Допустим у вас есть сервер, на нем Nginx + VPN. У вас два разработчика в команде. Вы решили, что
*.dev1.example.com будет проксировать запрос на 10.0.0.1
*.dev2.example.com будет проксировать запрос на 10.0.0.2
Когда придет новый дев, нужно будет в конфиге Nginx правки вносить. Не проблема, но зачем? если с FRP управление какой поддомен куда вести будет уходит на плечи клиента.
Хорошо, будем руками править на reverse nginx, но дальше, все запросы для dev1 идут на 10.0.0.1, у меня развернуто 2 проекта, допустим:
site, admin-site, static-site, api-site - это 1 docker-compose
site2, admin-site2, static-site2, api-site2 - это 2 docker-compose
теперь стоит задача, создать маршруты локально,
site.dev1.example.com -> 10.0.0.1 -> docker container site
site-admin.dev1.example.com -> 10.0.0.1 -> docker container site-admin
....
когда разработка идет в докере, обычно это делаю так
version: '3.7'
services:
webserver:
image: nginx:alpine
depends_on:
- app
app:
image: php:8-fpm-alpineВы будете на клиенте в не докера еще 1 nginx ставить который будет роутить запросы? или на сервере будете указывать порты? которые откроете в докере?
И снова.... технически решаемо, но это ад становится с поддержкой.
С FRP всего этого геморроя нет.
Ngrok, кстати, на такой услуге зарабатывает, FRP 40т звезд на гитхабе, это как минимум намек на то что инструмент востребованный.
Могу предположить что вы ближе к администрированию, тогда вам возможно сложно понять понять взгляд программиста.
Смотрите, я не пытаюсь на вас напасть, поэтому давайте не будем утверждать, что кому-то сложно будет кого-то понять - обмен знаниями и опытом есть основа здорового обучения.
Я заинтересовался в этом способе и хочу для себя понять, он лучше используемого мной или нет, где слабые места и преимущества, безопасен он или нет.
Из-за чего столько вопросов - схема в статье легко заменяется на связку nginx + VPN + nginx, при условии, что мы откроем порты в контейнерах на серверах (тогда как на схеме nginx + frp + frp + возможно последний nginx в контейнере у вас сидит). Даже вот статья есть о том, что связка nginx+VPN отлично заменяет пресловутый ngrok. Может админская панель FRP помогает быстро всё настраивать - хз, на гитхабе нормально не описано это, или я не могу увидеть никак.
Будет круто, если сможете начертить сложную схему, которая будет возможна с минимальными затратами времени с помощью FRP и трудозатратна для связки nginx + VPN + nginx.
Смотрите...
proxy frp находится в связке контейнеров. Поднимая проект (docker-compose up) поднимаешь все сразу: тунель, nginx, php, sql. после того как поработал, сделал docker-compose down и убил и прокси и nginx и тд.
ненужно править nginx серверный, в той статье что вы поделились, проксирование на 10.99.0.2:8443; это совсем не гибко, пока ты один и у тебя всегда проект будет на 8443 то пойдет, но так не бывает, в моей реальности :)
открывать порты nginx (docker) ненужно, все проксируется внутри сети докер-проекта. Т.е. вообще нет открытых портов
я не писал, но у FRP можно создать любой тунель по tcp, ssh, + куча плагинов есть
самое главное, настройка не на сервере происходит, а на клиенте. На клиенте указываешь какой хост юзаешь, в какой контейнер проксируешь, на какой порт, какой тип проксирования.
В статье не писал, все это в репе есть, настройка на клиенте (внутри докер контейнера) proxy
client.ini
[common]
server_addr = {SERVER_HOST}
server_port = {SERVER_PORT}
token = {SERVER_TOKEN}
login_fail_exit = true
[frontend-{PERSONAL_ALIAS}]
type = http
local_ip = webserver
local_port = 8081
subdomain = {PERSONAL_ALIAS}
[admin-{PERSONAL_ALIAS}]
type = http
local_ip = webserver
local_port = 8082
subdomain = admin-{PERSONAL_ALIAS}
[api-{PERSONAL_ALIAS}]
type = http
local_ip = webserver
local_port = 8083
subdomain = api-{PERSONAL_ALIAS}и dockre-compose воображаемого проекта, в реальный проект перенести нужно только блок proxy и подсунуть ему нужные конфиги, см. выше
Клиентский docker-compose.yml
version: '3.7'
services:
proxy:
build: docker/proxy
depends_on:
- webserver
environment:
PERSONAL_ALIAS: ${REVERSE_PROXY_PERSONAL_ALIAS}
SERVER_HOST: ${REVERSE_PROXY_SERVER_HOST}
SERVER_TOKEN: ${REVERSE_PROXY_SERVER_TOKEN}
SERVER_PORT: ${REVERSE_PROXY_SERVER_PORT}
webserver:
image: nginx:alpine
restart: unless-stopped
volumes:
- ./docker/nginx/templates:/etc/nginx/templates
depends_on:
- app
app:
image: php:8-fpm-alpine
restart: unless-stopped
volumes:
- ./src:/var/www/html
*.dev1.example.com будет проксировать запрос на 10.0.0.1
Nginx может проксировать *.devX.example.com в 10.0.0.X регулярками.
VPN может выдавать статические адреса, можно взять pritunl, чтобы ничего не настраивать руками.
Тот же VPN пушем маршрутов решает проблему с доступом к другим сервисам-зависимостям и партнёрам.
да, вариант, мне правда не нравится, т.к. он не так красиво ложится на связку с докером, + "числовые" домены тоже не очень понятны.
я так понял, вы предлагаете такую схему
{PORT}.dev{X}.example.com -> 10.0.0.X:PORT
какой проект, какой дев, не ясно.
+ тут с wildcard сертификатами сложнее становится
мне лучше понимать когда такой тип домена
cms-vasiliy.example.com
api-cms-vasily.example.com
Запустить tailscale на сервере и у себя на компе. Авторизоваться своим гугловым эккаунтом. Всё.
Данный подход решал проброс callback запросов от внешних провайдеров
А что за «callback запросы» вы имели ввиду?
Имхо, за докером и/или подобными решениями будущее. Юзаю его уже давненько и не понимаю как люди без него обходятся. И не важно кто ты, программист, админ или просто гик.
Спасибо за статью! Мне пока, правда, ngrok хватает, но кто знает, что будет дальше)
В контексте данной задачи ещё можно рассмотреть варианты на базе vpn zerotier. его бесплатного варианта хватит на многое, а дальше не грех и денежку заплатить.
Fast Reverse Proxy как альтернатива Ngrok