Хостинг статического сайта в Google Cloud Storage и настройка CDN

Быстрые ссылки

• Что такое «статический» сайт
• Создание Cloud Storage и включение Cloud CDN
• Чеклист ролей и критерии приёмки
• Устранение неполадок и рекомендации по безопасности

Что такое «статический» сайт

«Статический» не означает запрет на JavaScript или динамическое поведение в браузере. Это означает, что сервер не генерирует HTML в ответ на каждый запрос — вы отдаёте набор файлов: HTML, CSS, JavaScript и медиа.

Примеры:

• Статический: сайт, собранный статическим генератором (Hugo, Jekyll), SPA на React, где весь рендер происходит в браузере.
• Динамический: Wordpress/PHP или любой серверный рендер, где HTML формируется на сервере по запросу.

Преимущества статического хостинга в Cloud Storage:

• Минимум администрационной работы (нет инстансов и NGINX).
• Масштабируется автоматически.
• Стоимость — только хранение и исходящий трафик, плюс стоимость Load Balancer’а (минимум ~20 USD/мес в типичных сценариях).

Когда не стоит использовать статический хостинг:

• Нужен серверный рендер/персонализация контента на сервере.
• Нужна базовая аутентификация и динамическая логика на бэкенде.

Создание Cloud Storage и публикация файлов

1. Перейдите в Cloud Storage Console и создайте бакет.

2. Выберите мульти‑региональный стандартный уровень хранения (multi-region, Standard) и включите uniform access control (единый контроль доступа).

3. По умолчанию бакет приватный. Чтобы сделать сайт общедоступным, откройте вкладку «Permissions», добавьте нового участника, укажите allUsers и роль Storage Object Viewer. Система покажет предупреждение о публичном доступе.

4. Скопируйте файлы сайта вручную или синхронизируйте директорию с помощью gsutil:

gsutil rsync -R public gs://bucketname

После синхронизации сайт будет доступен по адресу типа https://storage.googleapis.com//index.html. Для собственного домена и HTTPS нужен Load Balancer.

Настройка HTTPS Load Balancer и Cloud CDN

1. Перейдите в Networking Console → Load Balancing и создайте новый балансировщик.

2. Выберите конфигурацию HTTPS Load Balancing и укажите, что балансировщик будет «internet‑facing» (доступен из интернета).

3. В разделе Backend Configuration добавьте backend bucket — укажите имя бакета, включите Cloud CDN, если требуется кэширование ближе к пользователям.

Включение Cloud CDN ускоряет отдачу статических файлов и снижает задержки у пользователей, особенно при глобальной аудитории.

4. Настройте routing rules: чаще всего достаточно направлять весь трафик на один бэкенд, но можете использовать несколько бакетов (например, один для сайта, другой для больших медиафайлов).

5. Для frontend конфигурации выберите HTTPS и присвойте статический IP‑адрес (в диалоге можно создать новый статический IP).

6. SSL: можно создать Google‑managed сертификат (бесплатно) или загрузить свой сертификат. Свяжите сертификат с доменом и выберите его в выпадающем списке.

7. Нажмите «Review and Finalize». После создания балансировщика настройте DNS — добавьте A‑запись вашего домена, указывающую на статический IP балансировщика.

Критерии приёмки

• Главная страница доступна по HTTPS и корректно возвращает index.html.
• Статика обслуживается с ожидаемыми заголовками кэширования (Cache-Control) и без лишних блокировок.
• Сертификат валиден, браузер не показывает предупреждений.
• Ресурсы (картинки, JS, CSS) загружаются корректно и, при включённом CDN, видны быстрые ответы из кэша.
• DNS корректно указывает на статический IP балансировщика.

Роль‑ориентированные чеклисты

Developer:

• Проверить, что index.html корректно относит пути (относительные/абсолютные URL).
• Убедиться в корректных заголовках Cache‑Control для статических ресурсов.
• Тестировать SPA‑маршрутизацию (при необходимости настроить 404 → index.html редирект).

DevOps:

• Создать бакет с uniform access.
• Настроить backend bucket и включить Cloud CDN.
• Выделить и прикрепить статический IP.
• Настроить managed SSL или загрузить сертификат.

Безопасность / Сопровождение:

• Оценить риск публикации PII в статических файлах.
• Рассмотреть использование Signed URLs или Signed Policy для приватных загрузок.
• Настроить мониторинг и оповещения (логирование запросов, ошибки 5xx).

Product Owner:

• Утвердить план миграции и SLA для сайта.
• Проверить бюджет на Load Balancer и трафик.

Устранение неполадок

Проблема: сайт возвращает 403 при доступе к объектам

• Проверьте права доступа в Permissions; убедитесь, что allUsers имеет роль Storage Object Viewer (если сайт должен быть публичным).
• Убедитесь, что объект имеет публичный доступ (object ACL) — при uniform access ACL управляются через IAM.

Проблема: сертификат не валиден / HTTPS не работает

• Убедитесь, что сертификат привязан к балансировщику и домен валиден.
• DNS указывает на статический IP балансировщика и запись распространяется (время распространения может быть до 24 часов).

Проблема: кэш CDN не обновляет контент

• Инвалидация Cloud CDN или версия файлов (fingerprinting) поможет сразу обновить ресурсы.

Безопасность и конфиденциальность

Важно:

• Публичный бакет означает, что все объекты в нём доступны любому пользователю интернета. Не храните PII, ключи или секреты.
• Для приватных ресурсов используйте Signed URLs/Signed Policy, а не публичный доступ.
• Проверьте соответствие требованиям локального законодательства по хранению персональных данных (GDPR/локальные регуляции) при размещении пользовательских данных.

Альтернативные подходы и когда это не сработает

• Если сайт требует серверной логики (например, авторизация на сервере, работа с базой данных), используйте Compute Engine/GKE/Cloud Run плюс CDN перед ним.
• Если вы хотите бесплатный вариант для простого проекта — посмотрите Firebase Hosting с бесплатным тарифом.

Решение: когда выбрать Cloud Storage + CDN — диаграмма

flowchart TD
  A[Нужен ли серверный рендер?] -->|Да| B[Использовать сервер: Cloud Run/Compute]
  A -->|Нет| C[Можно использовать статический хостинг]
  C --> D[Хранить в Cloud Storage]
  D --> E{Нужен HTTPS и кастомный домен?}
  E -->|Да| F[Добавить HTTPS Load Balancer + backend bucket]
  E -->|Нет| G[Доступ с storage.googleapis.com]
  F --> H[Включить Cloud CDN при необходимости]

Короткая методика миграции (mini‑methodology)

1. Подготовьте сборку сайта (например, папка public/).
2. Создайте бакет с uniform access и мульти‑регионом.
3. Загрузите файлы через gsutil rsync.
4. Проверяйте доступность по storage.googleapis.com.
5. Настройте Load Balancer + backend bucket для HTTPS и кастомного домена.
6. Настройте DNS и проверьте сертификат.
7. Включите Cloud CDN и настройте политику инвалидации.

Краткое руководство по тестированию (test cases)

• Входной тест: GET /index.html возвращает 200 и Content-Type: text/html.
• HTTPS тест: https://вашдомен/ открывается без предупреждений браузера.
• CDN тест: первый запрос приходит с backend, последующие из кэша (логирование ответов).
• Ручной тест SPA: обновить страницу на вложенном маршруте → должен вернуть index.html.

Глоссарий в одну строку

• Cloud Storage: объектное хранилище Google для файлов и медиа.
• CDN (Cloud CDN): сеть распределённого кэширования для ускорения доставки контента.
• Load Balancer: точка входа, распределяющая трафик и предоставляющая HTTPS.
• Backend bucket: способ привязать Cloud Storage бакет как backend для балансировщика.

Короткое объявление (для маркетинга, 100–200 слов)

Разместите свой сайт быстро и надёжно: статический сайт в Google Cloud Storage позволяет отказаться от управления серверами и NGINX. Подключите HTTPS через HTTPS Load Balancer и ускорьте доставку контента с помощью Cloud CDN — всё это масштабируется автоматически и удобно в обслуживании. В статье — пошаговая настройка, чеклисты для разработчиков и DevOps, критерии приёмки и советы по безопасности. Если нужен бесплатный вариант для простого проекта — рассмотрите Firebase Hosting.

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