Рейтинг:3

Как перейти на сертификаты, управляемые Google, без простоев?

флаг in

Я переношу example.com из внешнего (не Google) хостинг-провайдера в GCP.

При настройке балансировщика нагрузки я заметил, что мне нужно указать example.com на балансировщик нагрузки, чтобы сертификат, управляемый Google, прошел проверку.

Я должен просто изменить запись A для example.com на (статический) IP-адрес нового балансировщика нагрузки, после чего он будет проверен.

Проблема в том, что у меня уже есть много трафика на example.com, запросы, которые происходят после того, как example.com начинает указывать на балансировщик нагрузки, но до проверки сертификата будут генерировать ошибки SSL и очень недовольных пользователей.

Кто-нибудь решил это? Я знаю, что есть способы избежать простоев, когда вращающийся сертификаты, но должен же быть какой-то способ мигрировать большие сайты без простоев?

Рейтинг:2
флаг cn

У вас будет время простоя.

Вы можете следовать этим советам, чтобы минимизировать время простоя. При правильном планировании время простоя будет очень коротким, а в некоторых случаях автоматические повторные попытки сделают это невидимым для клиентов.

Однако я не знаю дизайна вашего сайта, использования файлов cookie, аутентификации, управления сеансами и т. д. Возможны сбои, которые неизбежны. Если возможно, подумайте о том, чтобы отправить электронное письмо своим клиентам, информируя их перед обслуживанием сайта.

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

  1. Помните, что записи ресурсов DNS кэшируются глобально. TTL записи ресурса дает подсказку о том, как долго. Резолверы DNS могут свободно использовать собственную интерпретацию вашего TTL.

  2. Запишите TTL записей ресурсов, которые вы будете изменять. Теперь измените TTL на короткое значение, например 1 минуту.

  3. Прежде чем вносить окончательные изменения, подождите, пока истечет хотя бы старый TTL.

  4. Настройте свои службы и балансировщик нагрузки, прежде чем вносить какие-либо изменения в DNS. Убедитесь, что службы работают правильно, используя только IP-адрес. Если вы перенаправляете IP на домен или HTTP на HTTPS, временно отключите эти функции и включите их позже.

  5. Используйте certbot в ручном режиме и создайте сертификат, который можно загрузить в балансировщик нагрузки. Это удаляет этап создания балансировщиком нагрузки SSL-сертификата и ожидания проверки. Позже вы можете переключиться на Google Managed SSL.

  6. Настройте внешние интерфейсы Google Cloud Load Balancer HTTP и HTTPS. Настройте SSL-сертификат Let's Encrypt во внешнем интерфейсе.

  7. Планируйте оставить старый сайт работающим примерно на 30 дней после переноса. Я обычно вижу трафик в течение нескольких недель на старом сайте после миграции.

  8. Выберите время суток или день недели с наименьшим объемом трафика. Затем переключите записи ресурсов DNS. Помните, что старое значение TTL должно было истечь, чтобы для кэширования использовался новый TTL.

  9. Через несколько дней, как только вы убедитесь, что все работает, установите значения TTL на что-то обычное, например 604800 это количество секунд в одной неделе или 86400 (один день). Повторно включить перенаправление сайтов (IP -> домен, HTTP -> HTTPS), если оно используется.

флаг in
Спасибо, Джон. Только что узнал, что вы можете использовать certbot с CSR, надеюсь, это сработает. Затем переходите к сертификату, управляемому Google (очевидно, вы можете назначить два из них одновременно). Попробую и приму позже.
John Hanley avatar
флаг cn
@ AndréLaszlo - Использование CSR не поможет сократить время простоя. Все SSL-сертификаты выдаются CSR, подписанным другим сертификатом. Если вы не имеете в виду время, чтобы заполнить детали. Единственными важными значениями, которые Let's Encrypt использует из CSR, являются имена. Большинство других параметров игнорируются.
Рейтинг:1
флаг cn

В дополнение к предыдущим предложениям имейте в виду, что SSL-сертификаты, управляемые Google, не поддерживаются для региональных внешних балансировщиков нагрузки HTTP(S) и внутренних балансировщиков нагрузки HTTP(S). Для этих балансировщиков нагрузки вам потребуется использовать самоуправляемые SSL-сертификаты. Я не видел, какой тип балансировщика нагрузки вы используете, однако, прежде чем пытаться установить эту миграцию, вам необходимо ее рассмотреть. Также в этом же гид вы могли увидеть, как создавать и использовать SSL-сертификаты, управляемые Google, и рекомендации по их правильной работе.1.

Я бы посоветовал вам установить окно обслуживания для этих изменений, так как это может занять до 30 минут, прежде чем сертификат станет доступен для всех интерфейсов Google (GFE).

Кроме того, в здесь вы увидите официальное руководство с пошаговыми инструкциями по достижению такого поведения.

1 https://cloud.google.com/load-balancing/docs/ssl-certificates/google-managed-certs

2 https://cloud.google.com/load-balancing/docs/ssl-certificates/google-managed-certs#migrating-ssl

Ответить или комментировать

Большинство людей не понимают, что склонность к познанию нового открывает путь к обучению и улучшает межличностные связи. В исследованиях Элисон, например, хотя люди могли точно вспомнить, сколько вопросов было задано в их разговорах, они не чувствовали интуитивно связи между вопросами и симпатиями. В четырех исследованиях, в которых участники сами участвовали в разговорах или читали стенограммы чужих разговоров, люди, как правило, не осознавали, что задаваемый вопрос повлияет — или повлиял — на уровень дружбы между собеседниками.