16.10.2021 14:11
anydasa 28 4900 Источник

Создание общедоступного URL в сети интернет к вашему локальному проекту

Что такое Ngrok, наверное знает каждый разработчик web приложений, и многие им пользуются.

Немного предыстории...

Присоединившись к новому большому проекту, над которым работают десятки разработчиков и QA специалистов, я столкнулся с тем, что разработка ведется удаленно на специально выделенных серверах.

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

Думаю все, кто более менее освоил работу в докере, уже не мыслят как можно разрабатывать без него. Причин на это много. Конечно, как и везде у докера есть своя цена и это тоже уже много раз обсуждалось.

Итак, новый проект не похож на предыдущие. Он имеет много зависимостей с другими сервисами, как внутренними так и внешними.

Большое количество внешних интерграций порождало проблему связи локального приложения с внешним миром. И если объединить внутренние сервисы используя docker netwokr не вызывало каких либо проблем, то необходимость связать внешний сервис уже требовал дополнительных инструментов.

Интеграции платежных систем всегда подразумевает, что будут callback (notification).

При такой необходимости, часто выбирают Ngrok. Хорошее решение, но в удобном варианте - платное. Особенно это ощущается, когда разработчиков много.

Т.к. Ngrok не подходил, первое что пришло в голову, создать виртуалку, на нее завести домен, и создавать ssh туннель с ним.

docker-compose.yml
version: '3.7'

services:

  callback-tunnel:
    build:
      context: ./.docker/ssh-tunnel-callback
    restart: unless-stopped
    volumes:
      - ~/.ssh:/root/ssh:ro
    environment:
      TUNNEL_HOST: ${CALLBACK_TUNNEL_HOST}
      LOCAL_PORT: ${CALLBACK_TUNNEL_LOCAL_PORT}
      LOCAL_HOST: ${CALLBACK_TUNNEL_LOCAL_HOST}
      REMOTE_PORT: ${CALLBACK_TUNNEL_REMOTE_PORT}
    networks:
      - local

  app:
    image: php
    restart: unless-stopped
    tty: true
    volumes:
      - ./:/var/www/html

где Dockerfile callback-tunnel выглядел вот так

Dockerfile
FROM alpine

RUN apk add --update openssh-client && rm -rf /var/cache/apk/*

CMD rm -rf /root/.ssh && mkdir /root/.ssh && cp -R /root/ssh/* /root/.ssh/ && chmod -R 600 /root/.ssh/* && \
ssh \
-vv \
-o StrictHostKeyChecking=no \
-N $TUNNEL_HOST \
-R *:$REMOTE_PORT:$LOCAL_HOST:$LOCAL_PORT \
&& while true; do sleep 30; done;

Данный подход решал проброс callback запросов от внешних провайдеров, но он был не надежный. Иногда при жестком разрыве соединения, порт на виртуалке оставался занятым. При совместной разработки необходимо было договариваться, кто какой порт будет использовать. Короче, решение такое себе, костыль.

Дальше - больше, при локальной разработке, бывает необходимость проверить приложение на другом устройстве, например на телефоне или планшете, или в определенной версии браузера поведение фронта не адекватное. И снова мысли об Ngrok.

Пришлось искать.

В какой то момент мне попался список бесплатных инструментов решающих данную проблему. Сам список уже не найду, но один инструмент меня сильно заинтересовал, и я решил попробовать.

Fast Reverse Proxy

https://github.com/fatedier/frp

Сервер написан на Go
JS, Vue для Dashboard

Схема

Репозиторий с примерами https://github.com/anydasa/frp-example

Как поднимал

  1. Подготовил на github репозиторий

  2. Купил домен

  3. Создал дроплет на Digital Ocean (5$ docker)

  4. Установил туда nginx

  5. Установил letsencript и создал Wildcard SSL Certificate по этой доке. Wildcard нужен для того чтоб public URL были https

  6. Настроил nginx, он выступает как первый proxy server. Можно обойтись без него, но мне так было проще

  7. Склонил https://github.com/anydasa/frp-example и запустил server-ную часть

  8. Локально,

    1. склонил https://github.com/anydasa/frp-example

    2. Создал .env из .env-example и прописал необходимые переменные

    3. запустил client-ский docker-compose

  9. В зависимости от того какой указал REVERSE_PROXY_PERSONAL_ALIAS, будет мой URL.

В моем примере есть 3 хоста (обычно нужно для проекта), и в зависимости какой PERSONAL_ALIAS указан, будут доступны по URLs. К примеру PERSONAL_ALIAS=project, тогда

  • frontend - https://project.frp.example.com

  • backend - https://admin-project.frp.example.com

  • api - https://api-project.frp.example.com

Т.к. Wildcard SSL настраивается на *.frp.example.com, то все поддомены нужно указывать без точек.

Server Nginx
server {
    listen 443 ssl;

    server_name dashboard.frp.example.com;

    ssl_certificate /etc/letsencrypt/live/frp.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/frp.example.com/privkey.pem;

    location / {
       proxy_pass       http://127.0.0.1:7500/;
       proxy_set_header host $host;
       proxy_set_header X-real-ip $remote_addr;
       proxy_set_header X-forward-for $proxy_add_x_forwarded_for;
       proxy_set_header X-Forwarded-Proto https;
       proxy_buffering  off;
       proxy_redirect   off;
   }
}

server {
    listen 443 ssl;

    server_name ~^.+\.frp\.example\.com$;

    ssl_certificate /etc/letsencrypt/live/frp.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/frp.example.com/privkey.pem;

    location / {
       proxy_pass       http://127.0.0.1:7000/;
       proxy_set_header host $host;
       proxy_set_header X-real-ip $remote_addr;
       proxy_set_header X-forward-for $proxy_add_x_forwarded_for;
       proxy_set_header X-Forwarded-Proto https;
       proxy_buffering  off;
       proxy_redirect   off;
   }
}

server {
       listen 80;
       server_name ~^.+\.frp\.example\.com$;
       return 301 https://$host$request_uri;
}
Server FRP Dockerfile
FROM alpine:3
MAINTAINER Sykchin Artem

ENV FRP_VERSION=0.37.1
ENV FRP_URL=https://github.com/fatedier/frp/releases/download/v${FRP_VERSION}/frp_${FRP_VERSION}_linux_amd64.tar.gz

WORKDIR /opt/frp

ADD ${FRP_URL} /tmp/frp.tar.gz
RUN tar --strip 1 -xvzf /tmp/frp.tar.gz -C /opt/frp && rm /tmp/frp.tar.gz

ADD frps.ini /opt/frp
ADD 404.html /opt/frp
ADD entrypoint.sh /

ENTRYPOINT ["/entrypoint.sh"]
Client 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

настройки для client proxy (proxy это контейнер)

FRP 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}

Выполняя docker-compose up, вы поднимаете проект + proxy client и связываете все вместе. Соответственно, выполняя docker-compose down вы "тушите" проект вместе с проксированием

Комментарии (28)


  1. lizergil
    16.10.2021 15:40
    #23597040

    Просветите, зачем нужно идти по публичному домену на локальное приложение?


    1. anydasa Автор
      16.10.2021 15:46
      #23597052
      +5

      1. получить callback от внешнего сервиса

      2. посмотреть на приложение со смартфона

      3. поделится ссылкой с коллегой для обсуждения

      4. https не самоподписной

      5. много причин можно найти

      но не всем это нужно, мне долгое время так же ненужно было


    1. Yser
      17.10.2021 01:54
      #23598288
      +3

      Тестировать вебхуки, например.


  1. gus26
    16.10.2021 17:09
    #23597250
    +1

    Тогда уж не "склонил", скопировал. А то смысл какой-то несуразный…


  1. Imbecile
    16.10.2021 22:34
    #23597936

    Не совсем понятны дополнительные телодвижения. Почему просто не настроить nginx, как reverse proxy, без frp?


    1. anydasa Автор
      16.10.2021 23:27
      #23598050
      +1

      Как вы собрались проксировать запрос с nginx в локальную сеть?


      1. Imbecile
        16.10.2021 23:33
        #23598060

        Если сервер с nginx не в локальной сети, то всегда можно поднять VPN.


        1. anydasa Автор
          16.10.2021 23:39
          #23598076
          +2

          Ну опишите, что для этого нужно сделать. По шагам.


          1. beatleboy
            17.10.2021 02:40
            #23598332
            +2

            Делается это так, поднимаем VPN на удаленном хосте, выдаем себе статический локальный адрес например 192.168.42.55, (прописываем его на своем компе в настройках VPN подключения).
            Далее настраиваем на VPN сервере NGINX, прикручиваем сертификат от LE (через certbot например), и добавляем server на нужный домен с proxy_pass на свой статический локальный адрес http://192.168.42.55.
            Схема достаточно простая, работает шустро и безотказно.
            Для работы reverse-proxy достаточно подключиться к VPN


            1. anydasa Автор
              17.10.2021 08:08
              #23598466
              -1

              Это уже как минимум не проще.

              А добавьте сюда вопросы менеджмента роутинга. Например появился новый дев, и теперь ему нужно тоже проксировать, добавлять правила в nginx?

              И дальше, как локально роутить трафик по контейнерам? У нас докер, одновременно может работать несколько nginx

              Да, технически это возможно. Но это совсем не проще. ИМХО.

              Но если быть откровенным, такая мысль не приходила, возможно ее так же можно до ума довести. Спасибо


              1. Smashrock
                17.10.2021 16:43
                #23599284
                +1

                Тоже не совсем понимаю, почему это сложно. На 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 на нём от атак, ботов и прочей нечести.


                1. anydasa Автор
                  17.10.2021 18:08
                  #23599482

                  Возможно я не раскрыл мысль.

                  Допустим у вас есть сервер, на нем 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т звезд на гитхабе, это как минимум намек на то что инструмент востребованный.

                  Могу предположить что вы ближе к администрированию, тогда вам возможно сложно понять понять взгляд программиста.


                  1. Smashrock
                    17.10.2021 21:16
                    #23599894

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

                    Я заинтересовался в этом способе и хочу для себя понять, он лучше используемого мной или нет, где слабые места и преимущества, безопасен он или нет.

                    Из-за чего столько вопросов - схема в статье легко заменяется на связку nginx + VPN + nginx, при условии, что мы откроем порты в контейнерах на серверах (тогда как на схеме nginx + frp + frp + возможно последний nginx в контейнере у вас сидит). Даже вот статья есть о том, что связка nginx+VPN отлично заменяет пресловутый ngrok. Может админская панель FRP помогает быстро всё настраивать - хз, на гитхабе нормально не описано это, или я не могу увидеть никак.

                    Будет круто, если сможете начертить сложную схему, которая будет возможна с минимальными затратами времени с помощью FRP и трудозатратна для связки nginx + VPN + nginx.


                    1. anydasa Автор
                      17.10.2021 21:49
                      #23600002
                      +1

                      Смотрите...

                      1. proxy frp находится в связке контейнеров. Поднимая проект (docker-compose up) поднимаешь все сразу: тунель, nginx, php, sql. после того как поработал, сделал docker-compose down и убил и прокси и nginx и тд.

                      2. ненужно править nginx серверный, в той статье что вы поделились, проксирование на 10.99.0.2:8443; это совсем не гибко, пока ты один и у тебя всегда проект будет на 8443 то пойдет, но так не бывает, в моей реальности :)

                      3. открывать порты nginx (docker) ненужно, все проксируется внутри сети докер-проекта. Т.е. вообще нет открытых портов

                      4. я не писал, но у FRP можно создать любой тунель по tcp, ssh, + куча плагинов есть

                      5. самое главное, настройка не на сервере происходит, а на клиенте. На клиенте указываешь какой хост юзаешь, в какой контейнер проксируешь, на какой порт, какой тип проксирования.

                      В статье не писал, все это в репе есть, настройка на клиенте (внутри докер контейнера) 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


                      1. Smashrock
                        17.10.2021 21:57
                        #23600022
                        +1

                        Ааа, вот оно что. Любопытно :) Спасибо вам за разъяснение!


                      1. anydasa Автор
                        17.10.2021 22:20
                        #23600062

                        да, писатель из меня еще тот)

                        да и не заметил что в 1 спойлер засунул два других, только сейчас понял, поправил. + дописал этот момент


                  1. inkvizitor68sl
                    18.10.2021 13:24
                    #23601934

                    *.dev1.example.com будет проксировать запрос на 10.0.0.1

                    Nginx может проксировать *.devX.example.com в 10.0.0.X регулярками.

                    VPN может выдавать статические адреса, можно взять pritunl, чтобы ничего не настраивать руками.

                    Тот же VPN пушем маршрутов решает проблему с доступом к другим сервисам-зависимостям и партнёрам.


                    1. anydasa Автор
                      18.10.2021 14:47
                      #23602246

                      да, вариант, мне правда не нравится, т.к. он не так красиво ложится на связку с докером, + "числовые" домены тоже не очень понятны.

                      я так понял, вы предлагаете такую схему
                      {PORT}.dev{X}.example.com -> 10.0.0.X:PORT
                      какой проект, какой дев, не ясно.
                      + тут с wildcard сертификатами сложнее становится

                      мне лучше понимать когда такой тип домена
                      cms-vasiliy.example.com
                      api-cms-vasily.example.com


          1. btyshkevich
            18.10.2021 14:31
            #23602200

            Запустить tailscale на сервере и у себя на компе. Авторизоваться своим гугловым эккаунтом. Всё.


  1. tabtre
    16.10.2021 23:31
    #23598056

    Данный подход решал проброс callback запросов от внешних провайдеров

    А что за «callback запросы» вы имели ввиду?


    1. anydasa Автор
      16.10.2021 23:34
      #23598066

      Когда запрос, к примеру от банка, прилетает к вам. Которым он уведомляет, что транзакция которую вы создали ранее, завершена успешно (или нет)


    1. riky
      17.10.2021 01:48
      #23598280

      Обычно называется Webhook


  1. ModestONE
    17.10.2021 19:44
    #23599714

    Имхо, за докером и/или подобными решениями будущее. Юзаю его уже давненько и не понимаю как люди без него обходятся. И не важно кто ты, программист, админ или просто гик.


    1. osipov_dv
      18.10.2021 08:30
      #23600700

      это вы еще молоток не купили...


      1. ModestONE
        18.10.2021 11:48
        #23601550

        молоток

        О чем речь?


        1. osipov_dv
          19.10.2021 10:08
          #23605142
          +1

          https://ru.wikipedia.org/wiki/%D0%97%D0%BE%D0%BB%D0%BE%D1%82%D0%BE%D0%B9_%D0%BC%D0%BE%D0%BB%D0%BE%D1%82%D0%BE%D0%BA


  1. DimoNj
    18.10.2021 13:14
    #23601894

    Спасибо за статью! Мне пока, правда, ngrok хватает, но кто знает, что будет дальше)


  1. softkot
    18.10.2021 13:59
    #23602082
    +1

    В контексте данной задачи ещё можно рассмотреть варианты на базе vpn zerotier. его бесплатного варианта хватит на многое, а дальше не грех и денежку заплатить.