-Прежде чем пытаться использовать внутренний HTTPS LB, я уже протестировал внешний HTTPS LB, доступный непосредственно в Интернет для серверной корзины.
В этом случае я создал все необходимые ресурсы в GCP.
(google_compute_global_forwarding_rule, google_compute_target_https_proxy, google_compute_global_address, google_dns_managed_zone, google_dns_record_set, google_compute_ssl_certificate, google_compute_url_map, google_compute_backend_bucket, google_storage_bucket с storage_class "MULTI_REGION")
Я активировал общий доступ для ведра.
Наконец, статический веб-сайт для ведра доступен непосредственно в Интернете и в этом случае работает правильно.
Цель: Статический веб-сайт для корзин не будет напрямую доступен в Интернете в тестовых средах.
-SO Я попробовал внутреннюю https LB: я создал все необходимые ресурсы (google_compute_forwarding_rule, google_compute_region_target_https_proxy, google_compute_address с использованием частного DNS, google_compute_region_url_map, google_compute_backend_bucket, сегмент регионального хранилища....).
У меня возникла ошибка при создании ресурса google_compute_region_url_map, в котором default_service указывает на серверную корзину. Ошибка сообщения указывает на то, что нет бэкэнда в том же регионе.
Проблема связана с google_compute_backend_bucket, который является глобальным, а не региональным (в GCP нет региональной серверной корзины).
Я также заметил, что все образцы внутренних https LB в GCP относятся к серверной службе, а не к серверной корзине.
-Я провел некоторое исследование о подключении частного сервиса с внутренним https LB (https://cloud.google.com/load-balancing/docs/l7-internal).
Но я думаю, что это не сработает еще и по той же причине: он должен быть региональным, а у нас нет регионального бекенда.
Что вы думаете? Есть ли у вас какие-либо предложения? Возможна ли эта цель в GCP?
