Создайте балансировщик нагрузки на GCP (GAE). Домены сертификатов SSL зависли в состоянии FAILED
Я новичок в этой теме. Мы используем GCP (App Engine, стандарт) для размещения одного приложения nodejs. Однако по разным причинам мы решили создать два сервиса — этап и по умолчанию (представьте, что одно и то же приложение работает параллельно).
Один из них по умолчанию подключен к личному домену (GAE предоставил SSL-сертификат) и работает правильно. Доступ к сервису Stage можно получить с помощью URL-адреса, сгенерированного Google (stage-dot-example.appspot.com), и он, очевидно, защищен SSL-сертификатами.
Затем нам нужно было пройти проверку безопасности у наших партнеров, и мы использовали для этого сцену .
В результате нам придется отключить TLSv1.0 и TLSv1.1. С GAE нам нужно создать балансировщик нагрузки и переключить политику SSL на конкретную TLS.
Проблема : чтобы создать внешний балансировщик нагрузки HTTPS, вам необходимо создать ресурс сертификата SSL (т. е. у вас должен быть собственный домен). Я думаю, что с пользовательским доменом это не должно быть сложно, но как мне это сделать на сцене ? Использую ли я свой промежуточный домен (...appspot.com) в ресурсе SSL-сертификата? Если да - что делать с записями DNS и внешним IP (нужно в записях А и АААА переключить IP на внешний IP)?
Или, если я делаю что-то не так, не могли бы вы указать мне правильное направление?
ОБНОВЛЕНИЕ + ОБНОВЛЕНИЕ 2
Я решил пойти по пути, предложенному Wojtek_B. Итак, я проверил stage.example.com, и он работал нормально без Load Balancer.
На данный момент мои записи DNS включают 4 записи A и 4 записи AAAA от @ с IP-адресами, предоставленными Google, и 3 записи CNAME (www, stage, www.stage), указывающие на «ghs.googlehosted.com».
Затем я создал ресурс сертификата SSL с 4 доменами: example.com, www.example.com, stage.example.com, www.stage.example.com.
Затем я добавил внешний балансировщик нагрузки HTTPS (с внешним IP-адресом, например, 1.2.3.4 и SSL-сертификатом, упомянутым выше).
Я добавил новые записи A для @, www, stage и www.stage, чтобы указать на 1.2.3.4. Я удалил записи CNAME, поскольку они чрезмерны.
После ожидания в течение 2-3 часов (TTL составляет 1/2 часа) все субдомены были активированы, кроме example.com (зависло в FAILED_NOT_VISIBLE).
ОТВЕЧАТЬ
Я некоторое время боролся с управляемым SSL-сертификатом, который застревал в состоянии подготовки. Я следовал этому руководству , в котором вы должны создать только внешний IP-адрес (v4). Но у меня также было 4 записи AAAA (полученные при проверке домена) с (очевидно) ipv6. Поэтому я попытался зарезервировать внешний IP-адрес (v6), и перевод всех 4 (суб)доменов в активное состояние занял меньше минуты.
Всего за несколько минут обе службы через LB были запущены и заработали с необходимыми конфигурациями TLS.