Перейти к содержимому

Объяснение общего VPC в Google Cloud | Консоль, gcloud и Terraform — Часть 14

Rahul Wagh

0:00 / 0:00

Объяснение общего VPC в Google Cloud | Консоль, gcloud и Terraform — Часть 14

1 201 просмотр · 3 недели назад
Rahul Wagh
102 тыс. подписчиков
1 201 просмотр · 3 недели назад
▬▬▬▬▬▬ 👉 Полное письменное руководство (все команды + Terraform, готово к копированию и вставке): https://crafted.jhooq.com/topics/shar... ▬▬▬▬▬▬ 🎉 🔥 Курс Udemy - AWS Networking Zero to Hero!🔥 🎉▬▬▬▬▬▬ 🚀 Мастер-класс по сетям AWS! - https://www.udemy.com/course/aws-netw... ▬▬▬▬▬▬ 🎉 🔥 Курс Udemy - Освойте Azure как профессионал!🔥 🎉▬▬▬▬▬▬ 🚀 Освойте Azure как профессионал! - https://www.udemy.com/course/azure-cl... ▬▬▬▬▬▬ 🙍🏻‍♂️Присоединяйтесь к членству на YouTube ▬▬▬▬▬▬ Присоединяйтесь к этому каналу, чтобы получить доступ к бонусам:    / @rahulwagh   ▬▬▬▬▬▬ 🙍🏻‍♂️ Видео только для участников ▬▬▬▬▬▬ Видео только для участников -    • Members-only videos   ▬▬▬▬▬▬ 🗓️ Запишитесь на консультацию ▬▬▬▬▬▬ Календарь - https://tidycal.com/rahulwagh17 Shared VPC в Google Cloud позволяет одному проекту владеть сетью, в то время как многие другие проекты запускают свои рабочие нагрузки внутри неё — без пиринга VPC, без VPN, без дублирования диапазонов IP-адресов. В этом видео мы расскажем, почему существует Shared VPC, что вы от него получаете, покажем полную практическую демонстрацию в консоли Google Cloud, а затем выполним ту же настройку, что и с помощью команд CLI gcloud и кода Terraform. К концу вы будете точно знать, когда следует использовать Shared VPC вместо пиринга VPC, и у вас будет работающий код, который вы сможете сразу же внедрить в свою собственную среду. ⏱️ ВРЕМЕННЫЕ МЕТКИ 0:00:00 - Вступление 0:00:38 - Инструкция и руководство 0:01:38 - Что такое общий VPC? 0:07:55 - Настройка роли xpnAdmin 0:10:22 - Создание SharedVPC 0:17:20 - Настройка правил брандмауэра 0:20:29 - Настройка виртуальной машины 🔑 ЧТО ВЫ УЗНАЕТЕ Проблема, для решения которой был создан Shared VPC, и почему пиринг VPC не масштабируется до десятков проектов Проект-хост против сервисного проекта: кому принадлежит сеть, кому принадлежит рабочая нагрузка Как виртуальная машина может оплачиваться одним проектом, находясь в подсети другого проекта Какие роли IAM вам нужны и где они предоставляются Подключение и отключение сервисных проектов Доступ на уровне подсети, чтобы команды видели только те подсети, которые им предназначены Полная настройка тремя способами: консоль, CLI gcloud и Terraform 💻 ИСПОЛЬЗУЕМЫЕ КОМАНДЫ GCLOUD Включение проекта-хоста: gcloud compute shared-vpc enable HOST_PROJECT_ID Присоединить сервисный проект: gcloud compute shared-vpc associated-projects add SERVICE_PROJECT_ID --host-project HOST_PROJECT_ID Вывести список присоединенных ресурсов: gcloud compute shared-vpc associated-projects list HOST_PROJECT_ID 🏗️ Используемые ресурсы Terraform google_compute_shared_vpc_host_project google_compute_shared_vpc_service_project 🔐 Важные роли IAM roles/compute.xpnAdmin — Администратор общей VPC, предоставляется на уровне организации или папки. Эта роль позволяет назначать хост-проект и присоединять сервисные проекты. roles/compute.networkUser — предоставляется администраторам сервисных проектов, для всего хост-проекта или для отдельных подсетей. Именно это позволяет им запускать ресурсы в общей сети. ⚠️ ТО, ЧТО ВЫЗЫВАЕТ СБОЙ Общая VPC требует ресурса организации — она не будет работать с автономными проектами. Правила и маршруты брандмауэра находятся в основном проекте, а не в проектах служб. Предоставление пользователю networkUser на уровне проекта обеспечивает доступ ко всем подсетям; предоставляйте его для каждой подсети отдельно, если команды должны видеть только свою собственную.