Как установить частное соединение между механизмом приложений Google и вычислительным механизмом?

У меня есть веб-приложение/Api, которое в настоящее время работает на ресурсе движка приложения Google. Поскольку расчеты API требуют больших вычислительных ресурсов, я передал вычислительную часть на аутсорсинг группе управляемого автоматического масштабирования вычислительного движка Google с балансировщиком нагрузки HTTP во внешнем интерфейсе (для поддержки одного IP-адреса и балансировки нагрузки между несколькими двигатели, которые создаются динамически).

В настоящее время я просто делаю HTTP-вызов на IP-адрес балансировщика нагрузки из механизма приложения. Поскольку GAE и GCE находятся в одном регионе, это, однако, кажется крайне неэффективным (я знаю, что ядро ​​приложения и вычислительные ядра все еще находятся в двух физически разделенных центрах обработки данных). Это также представляет угрозу безопасности, поскольку я постоянно получаю звонки от случайных IP-ботов, пытающихся использовать потенциальные лазейки в системе безопасности. Кроме того, я проверяю действительность токена API только на уровне ядра приложения, так как я не хочу предоставлять пользовательской базе данных доступ к вычислительному движку (соображения безопасности), поэтому это означает, что проверка между движком приложения и вычислительным движком не выполняется. , чтобы последний отвечал на все поступающие вызовы.

Есть ли способ установить частное соединение между движком приложения и облачным движком?

Моя цель состояла бы в том, чтобы не открывать GCE для всего Интернета, учитывая, что он принимает звонки только с одного IP-адреса/ресурса.

Я пытался внести в белый список только IP-адреса движков приложений, но, к сожалению, это большой блок адресов, который очень громоздко извлекать и динамически изменять. Механизм приложения также не может использовать частный IP-адрес вычислительного механизма/серверов Google SQL.

Другие творческие идеи приветствуются!

Добавляет ли что-нибудь следующее к этой истории... stackoverflow.com/questions/19155795/…

Kolban 26.05.2019 22:35

Другое связанное обсуждение: stackoverflow.com/q/19155795/320399

blong 29.04.2020 20:10
Стоит ли изучать PHP в 2023-2024 годах?
Стоит ли изучать PHP в 2023-2024 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Приемы CSS-макетирования - floats и Flexbox
Приемы CSS-макетирования - floats и Flexbox
Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
2
2
990
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Похоже, что Бессерверный доступ к VPC может быть потенциальным решением. Из обзора взято следующее:

Serverless VPC Access enables you to connect from the App Engine standard environment and Cloud Functions directly to your VPC network. This connection makes it possible for your App Engine standard environment apps and Cloud Functions to access resources in your VPC network via internal (private) IP addresses. Using internal IP addresses improves the latency of communication between your Google Cloud Platform services and avoids exposing internal resources to the public internet.

Serverless VPC Access only allows your app or function to send requests to resources in your VPC network and receive responses to those requests. Communication in the opposite direction, where a VM initiates a request to an app or function, requires you to use the public address of the app or function.

Спасибо! мне очень помог!

benjo121212 06.06.2019 00:52

Другие вопросы по теме