Google Cloud Platform — это большой набор облачных сервисов: серверы, базы данных, хранилища, сеть и ещё сотни вещей. На первый взгляд это стена из названий, и легко растеряться. Но почти всё стоит на четырёх опорах. Разберитесь с ними — и остальное встроится в понятную картину.

Эти четыре опоры: иерархия ресурсов (где всё лежит и кто за это платит), Cloud IAM (кто и что имеет право делать), регионы и зоны (где физически живут ресурсы и как пережить сбой) и VPC (как устроена ваша сеть). Дальше — по порядку. Если вы знакомы с AWS, по ходу будут пометки, что чему соответствует.

Иерархия: организация, папка, проект

В GCP ресурсы разложены по трёхуровневой матрёшке.

  • Организация (organization) — верхний уровень, привязанный к вашей компании (домену). Здесь общие политики и настройки.
  • Папка (folder) — промежуточная группировка: по отделам, командам или средам.
  • Проект (project) — то, внутри чего создаются сами ресурсы: виртуальные машины, базы, сети. Проект — это главная единица изоляции и биллинга: к нему привязан платёжный аккаунт, у него свои квоты и права.

Ключевая единица здесь — проект. Практика та же, что в других облаках: под разные среды заводят разные проекты — отдельный под production, отдельный под staging, отдельный «песочницу». Зачем так: если кто-то случайно удалит ресурсы или утечёт доступ, беда не выйдет за пределы одного проекта, а в счёте сразу видно, какой проект сколько потратил. (В терминах AWS проект примерно соответствует аккаунту.)

Главный практический вывод: «у нас есть GCP» всегда тянет вопрос «а в каком проекте?».

Cloud IAM: кто и что может делать

Cloud IAM отвечает на один вопрос: кто имеет право делать что и с каким ресурсом. Здесь три ключевых понятия.

Роль (role) — набор разрешений. Есть примитивные роли на весь проект — Viewer (только смотреть), Editor (создавать и менять), Owner (плюс раздавать права), — и множество узких предопределённых ролей вида roles/storage.objectAdmin (управлять объектами в хранилище) или roles/cloudsql.client (подключаться к базе). Узкие роли — то, что нужно на практике.

Привязка (binding) — это назначение «кому — какую роль — на каком ресурсе». Роль выдают на организацию, папку, проект или отдельный ресурс, и права наследуются вниз.

Участник (member) — тот, кому выдают роль: человек (аккаунт Google или корпоративная учётка через federation), группа или сервисный аккаунт — учётная запись для программ и виртуальных машин.

Два правила, которые экономят нервы и деньги.

Первое: ваш код не должен носить с собой ключи. Когда программа работает на виртуальной машине GCP, к машине привязывают сервисный аккаунт, и приложение получает временный токен прямо из сервера метаданных — без секретов в коде. В GKE ту же роль играет Workload Identity. Это тот же принцип, что instance profile в AWS. Ключи сервисного аккаунта в виде JSON-файла в git — классический путь к утечке.

Второе: минимум прав (least privilege). Давайте роли ровно то, что нужно: сервису — доступ к своему бакету и своей базе, а не Editor на весь проект. Подробный разбор — в статье про Cloud IAM.

Регионы и зоны

Регион — географическая площадка: например, europe-west1. Ресурсы привязаны к региону, и данные сами между регионами не путешествуют — копию настраивают отдельно.

Зона (zone) — изолированный дата-центр внутри региона (europe-west1-b, -c, -d): своё питание, охлаждение и сеть, чтобы авария в одной зоне не задела соседнюю. Зоны одного региона связаны быстрыми каналами.

Зачем это знать новичку:

  • Отказоустойчивость строят на нескольких зонах одного региона. Копии приложения и реплики базы разносят по зонам, сверху — балансировщик; упадёт зона — сервис продолжит работать.
  • Крупная авария региона — редкость; защита от неё (мультирегион) стоит дороже и настраивается отдельно. Это тема отказоустойчивости и восстановления.
  • Трафик между зонами и регионами стоит денег — это видно в счёте.

Как строить высокую доступность — в статье про масштабирование и доступность.

VPC: ваша сеть

VPC (Virtual Private Cloud) — ваша сеть внутри GCP. Особенность GCP: сеть глобальна, а подсети привязаны к регионам. То есть одна VPC охватывает все регионы, а внутри неё вы заводите региональные подсети. Минимальный набор понятий:

  • Подсети (subnets) — региональные диапазоны адресов; ресурсы получают внутренний IP, а чтобы стать доступным из интернета, ресурсу нужен внешний IP (или он прячется за балансировщиком).
  • Правила файрвола (firewall rules) — сетевой фильтр на уровне VPC с разрешающими и запрещающими правилами и приоритетами; цель правила задают тегами или сервисными аккаунтами.
  • Для исходящего доступа из внутренних ресурсов используют Cloud NAT, а до сервисов Google по приватной сети дотягиваются через Private Google Access.

Правило простое: серверы и базы держат без внешнего IP, наружу смотрят только балансировщики и точки входа. Глубже — в статье про сеть.

Где это применяется

Эти четыре опоры всплывают в любой работе с GCP. Создаёте ресурс — выбираете проект, регион и зону. Запускаете приложение — привязываете сервисный аккаунт вместо ключей. Поднимаете базу — держите её без внешнего IP и закрываете правилами файрвола. Любой следующий сервис (вычисления, функции, управляемые базы) стоит на этом фундаменте.

Где спотыкаются начинающие:

  • Хранят JSON-ключ сервисного аккаунта в коде или git вместо привязки аккаунта к машине — самая частая и дорогая ошибка.
  • Раздают Editor/Owner широко «чтобы заработало» и забывают сузить.
  • Дают базе внешний IP ради удобства — и получают сканирование извне.
  • Путают регион и зону или не понимают, почему ресурс «не виден» — часто он в другом проекте или регионе.

Что учить дальше: глубже сеть и Cloud IAM, затем — где запускать сервис. Когда дойдёт до автоматизации, описывайте инфраструктуру кодом: Terraform. Аналогичный разбор для Amazon — основы AWS.