# #google-cloud-platform
Вопрос:
Я оказался в сложной ситуации, связанной с использованием бессерверных vpc-разъемов в облачном режиме. Службе необходимо вызывать как другие внутренние(например, разрешать вызов только через внутренний трафик) облачные службы, так и некоторые внешние службы/URL-адреса. Учитывая два варианта маршрутизации через соединитель, а именно (1. Направлять только трафик на частные IP-адреса через соединитель) и (2. Направлять весь трафик через соединитель), мне кажется невозможным настроить соединитель таким образом, чтобы он правильно разрешал как внешние, так и внутренние URL-адреса.
При использовании первого варианта URL-адреса для внутренних облачных служб не разрешаются должным образом, но внешние разрешаются. Для облачных сервисов не существует статических IP-адресов, поэтому использование «внутренних» IP-адресов не является вариантом.
При выборе второго варианта внутренние URL-адреса разрешаются правильно, но не внешние.
Есть ли выход из этой ситуации?
Комментарии:
1. Вы не можете достичь того, чего хотите. Кроме того, полагаться на статический общедоступный IP-адрес-не очень хороший дизайн, но я знаю, что устаревшее/старое приложение для дизайна когда-нибудь понадобится.
Ответ №1:
Правильный вариант, если вы хотите получить доступ как к внутренним, так и к внешним URL-адресам, — это «Направлять трафик только на частные IP-адреса через соединитель». Как говорится в общедоступной документации Google: «В вашу сеть VPC направляются только запросы к диапазонам IP-адресов RFC 1918 и RFC 6598 или внутренним DNS-именам. Все остальные запросы направляются непосредственно в Интернет». [1]
Если у вас возникли проблемы с доступом к внутренним URL-адресам, когда вы выбираете этот параметр, скорее всего, вы блокируете их на уровне брандмауэра в подсети VPC.
Чтобы проверить правила брандмауэра в вашем проекте, вы можете выполнить следующую команду в консоли gcloud:
gcloud compute firewall-rules list
[1] https://cloud.google.com/run/docs/configuring/connecting-vpc
Комментарии:
1. Похоже, правила брандмауэра не влияют на работу в облаке. Только когда я переключаюсь с Разрешить только внутренний, чтобы Разрешить весь трафик, к которому Служба B доступна из службы A (показывает, что брандмауэр не имеет к этому никакого отношения), в противном случае я получаю 403, и я вроде как не удивлен. Если служба A не настроена на маршрутизацию всего трафика через соединитель VPC и пытается получить доступ к службе B (которая имеет «Разрешить только внутренний трафик» для входа) по общедоступному URL-адресу, службе A не будет назначен внутренний IP-адрес, и служба B получит запрос от службы A и отклонит его, поскольку он не является внутренним.
Ответ №2:
Цель бессерверного подключения VPC-обеспечить внутренний доступ из вашего бессерверного приложения к внутренним ресурсам VPC GCP, как указано в следующем документе [1].
При этом, если приложению, развернутому через Cloud Run, требуются внешние ресурсы GCP; это должно обрабатываться самим составом используемого образа, а не подключением без сервера VPC.
Вторая часть, которую я мог бы получить из вашего ответа, заключается в том, что у вас есть несколько служб, настроенных в Cloud Run, и вам необходимо взаимодействовать между ними.
В этой части я хочу отметить, что, возможно, лучшим подходом вместо бессерверного подключения VPC было бы объединить ваши службы и упаковать их в один файл docker.
Вы можете найти примеры того, как запускать несколько служб в контейнере, в следующем документе [2].
После создания образа docker с объединенными службами вы можете сохранить его в любом поддерживаемом реестре и развернуть с помощью Cloud Run, как указано в следующем документе [3].
[1] https://cloud.google.com/vpc/docs/serverless-vpc-access
[2] https://docs.docker.com/config/containers/multi-service_container/