Конфигурирование решения Firebase Hosting с обратным прокси-сервером - PullRequest
0 голосов
/ 24 октября 2019

Это то, что у меня в настоящее время есть

domain.com ->  website A with its own firebase host (domain.firebase.com)
me.domain.com -> website B with its own firebase host (domain-me.firebase.com)

Это было несложно настроить, только несколько поддоменов, перенаправляющих на разные хосты Firebase. Теперь, что я хочу , - это обратный прокси-сервер, принимающий запрос и имеющий возможность маршрутизации трафика на различные серверы, сохраняя URL-адрес клиента только в основном домене domain.com . Я не уверен, возможно ли это специально с Firebase , поскольку существует множество примеров реализации NGINX, но в основном я хочу этого:

domain.com/ ->  website A with its own firebase host (domain.firebase.com)
domain.com/me -> website B with its own firebase host (domain-me.firebase.com)

Firebase имеет очень сложные параметры перенаправления, но перенаправляет также перезаписывает URL клиента. Таким образом, при перенаправлении клиент увидит domain-me.firebase.com вместо domain.com / me , а это не то, что я хочу.

Насколько я понял, я могу использовать функции Firebase Cloud в качестве промежуточного программного обеспечения, и он может обслуживать любой сайт по мере необходимости. Тем не менее, это приводит к большой задержке, так как облачные функции и веб-сайты, размещенные на Firebase, имеют разогрев с холодных запусков.

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

Ответы [ 2 ]

0 голосов
/ 08 ноября 2019

Чтобы ответить на мой собственный вопрос и опираться на ответ Дуга об использовании Cloud Run. Существует быстрый и безболезненный способ настройки реализации, аналогичной обратной прокси, с двумя приложениями. Для этого:

1) Создайте оба приложения и поместите их в отдельные папки, такие как папка A и папка B. Вам нужны только папки для сборки приложений, вам не нужен источникcode.

2) Создайте новое приложение Express в корне папок A и B.

3) У Express есть управление маршрутами с помощью app.get и подача файлов обратно с помощью res. sendFile.

4) Контейнер всего приложения Express, следуя инструкции Google здесь , вы можете игнорировать образец приложения, поскольку ваше новое приложение Express является приложением.

5) Загрузка в облако. Запуск новой службы. Имейте в виду, что, хотя Google Tuts не указывает, вам потребуется , чтобы дать вашему пользователю разрешение на загрузку в хранилище. Вам понадобится команда gsutil iam ch user:[user]:objectViewer gs://us.artifacts.[project-name].appspot.com Также обязательно переключитесь на текущий проект, используя команду gcloud config set project [project-name], если у вас есть несколько проектов.

6) Используйте сопоставление домена Google для сопоставления с вашим root domain, так что domain.com.

Вы должны использовать сопоставление доменов, поскольку URL-адрес, используемый Cloud Run, эфемерен ... потому что он без сервера.

Ваша папкаструктура должна выглядеть примерно так:

my-awesome-project
    index.js <- Express app and Docker entry point
    /package.json <- for your Express app
    /A
    /B
    /Dockerfile
    /node_modules

Примером роутера будет

app.get('/me/*', (req,res) =>{
    res.sendFile(path.join(__dirname+'/B/index.html'));
});

app.get('/*', (req,res) =>{
    res.sendFile(path.join(__dirname+'/A/index.html'));
});

Настройка приложений на поддоменах вместо этого работает практически так же. Создайте контейнеры для каждого отдельного приложения, выполнив шаг 4, затем сопоставьте каждый домен отдельно, используя Google Domain Mapping.

0 голосов
/ 24 октября 2019

Интеграция с Облачные функции и Облачный прогон в значительной степени ваши единственные варианты здесь. В конфигурации нет ничего, что позволяло бы вам перенаправлять ваши запросы напрямую на другие конечные точки, кроме как косвенно через HTTP-перенаправления .

...