GCS Reverse Proxy
1.0.0
Обратный прокси -сервер Google Cloud Storage. Для размещения частных статических сайтов с использованием частных объектов Google Cloud Storage.
Вы хотите обслуживать статические сайты, используя свои ведра GCS, но вы хотите ограничить доступ к ним.
Этот Micro Service с обратным прокси -сервером будет вести себя как простой HTTP -сервер для массива ведра GCS. Затем вы можете использовать любой подходящий метод для ограничения доступа к нему. Например, позади его позади Nginx, Caddy или VPN.
Доступ к частным объектам GCS через браузер требуют специальных токенов, которые кодируются в URL. Это сломает большинство (если не все) статические сайты, поскольку они не могут генерировать эти токены или предсказать URI любых активов, на которые он запрашивает или ссылается. Однако общедоступность объекта хранения означает, что нет способа ограничить доступ к нему.
Этот обратный прокси -сервер будет служить частному объекту над HTTP в ожидаемом (относительном), URI и вообще не ограничит доступ к этим объектам. Однако, поместив этот сервер за другим обратным прокси, таким как NGINX или поместив его на VPN, вы сможете контролировать доступ таким образом, чтобы удовлетворить ваши потребности.
NB (если у вас установлена GCLOUD SDK, запустите
gcloud infoв вашей оболочке, чтобы проверить, что вы вошли в систему, и иметь правильный набор идентификатора проекта).
TARGET_BUCKETS env var ожидает, что запятая отделен списк ведра, например:
TARGET_BUCKETS='bucket-one,bucket-two'
Сервер будет бросаться, если не будет определено один или несколько Target_buckets.
Установка HISTORY Env var на True запустит сервер в режиме истории для лучшей поддержки SPA. Он ответит файлом root root index.html для любого пути, который не имеет расширения файла.
npm install
TARGET_BUCKETS="bucket-name" npm start
Как только сервер будет запущен и запускается, чтобы получить доступ к частному объекту в ведре, должен сделать запрос получить:
<proxy-host>:<proxy-port>/<bucket-name>/<file-path>
Если путь файла существует в ведре, а сервер имеет предвидение для его чтения, обратный прокси отправит свое содержимое в качестве ответа. Если по какой -либо причине файл не может быть получен из ведра, то сервер вернет 404.
Если запрашиваемое ведро не находится в списке target_buckets, то он вернет 403, независимо от его реального ведра или нет.
В настоящее время поддерживается только метод запроса GET.
Наличие одного режима ведра означает, что нет необходимости префикс все запросы с помощью пути имени ведра, поэтому запрос <proxy-host>:<proxy-port>/<file-path> будет запросить путь файла из единого целевого ведра.
Этот проект использует Micro, что означает, что мы можем использовать отличные инструменты Micro-Dev в разработке.
TARGET_BUCKETS="bucket-name" npm run dev
ADC использует учетную запись службы по умолчанию, которая вычисляет двигатель, двигатель Kubernetes, App Engine и облачные функции, для приложений, которые работают в этих службах.
От настройки аутентификации для сервера до производственных приложений сервера
Из -за вышесказанного я рекомендую вам использовать Compute Engine, Engine Kubernetes или двигатель приложений, где для вас будет обрабатываться аутентификация.
Я предоставил Dockerfile для начала работы без необходимости установить узел. Это не будет работать локально, поскольку не настраивает какую -либо аутентификацию с Google Cloud SDK.
Однако при развертывании в вычислительном экземпляре Engine VM Authentication обрабатывается для вас. Чтобы увидеть, как развернуть изображение Docker на экземпляре VM, ознакомьтесь с этим руководством. Не забудьте установить переменную среды TARGET_BUCKETS , которая может быть сделана, следуя этому руководству.
