Вернуться к главной странице, списку всех тем

6. Запуск приложений на серверах в интернете. Использование готовых решений, когда мы просто заказываем, какое приложение нам нужно, а запускают его автоматически за нас

Что ты узнаешь: чем аренда сервера отличается от аренды готового сервиса, как заказать инфраструктуру в облаке и как не получить неприятный счёт в конце месяца

Что нужно знать заранее: темы 1–5. Особенно тема 2 (сети, DNS) и тема 5 (Kubernetes — в облаке его дают готовым)

Сколько времени займёт: 3 часа теории + 5–6 часов практики

Твой шаг в сквозном проекте: вынесешь «Заметки» со своего ноутбука на настоящий сервер в интернете, доступный по публичному адресу

⚠️ Внимание: в этой теме впервые тратятся реальные деньги. Все задания рассчитаны на бесплатный пробный период, но неудалённый ресурс продолжает списывать средства. Правило темы — «удалил — проверь, что удалил»

Представь себе, что у тебя есть кафе. Чтобы его открыть, тебе нужно: купить здание, провести электричество, оборудовать кухню, нанять поваров, закупить продукты. Это долго, дорого, и если завтра передумаешь — потратишь кучу денег впустую.

А теперь представь, что есть огромная сеть кафе, у которой можно арендовать всё что угодно:

Именно так устроены облака. Раньше компании покупали серверы, ставили их в дата-центры, нанимали администраторов. Сегодня всё можно «арендовать» в облаке у провайдера — Yandex Cloud, Cloud.ru (бывший SberCloud), VK Cloud, AWS, Google Cloud, Azure — и платить только за то, что реально использовал.

Что такое облако и зачем оно нужно

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

Главные преимущества облака:

  1. Эластичность — мгновенно увеличиваешь или уменьшаешь ресурсы. Чёрная пятница на интернет-магазине? За пару минут добавил 50 серверов. Нагрузка спала? Удалил их и больше не платишь.
  2. Нет капитальных затрат — не нужно покупать железо на миллионы рублей вперёд. Платишь по факту (модель pay-as-you-go).
  3. Глобальное присутствие — у крупных провайдеров десятки дата-центров по всему миру. Можно разместить приложение ближе к пользователям, чтобы оно работало быстрее.
  4. Надёжность — облако само заботится о физическом железе, охлаждении, питании, замене сгоревших дисков. Тебе об этом думать не нужно.
  5. Готовые сервисы — облако предлагает не только «голые» серверы, но и сотни готовых решений: базы данных, очереди сообщений, объектные хранилища, балансировщики нагрузки, Kubernetes-кластеры. Это всё работает «из коробки», тебе не нужно ничего настраивать с нуля.

Три классические модели облачных услуг

IaaS — Infrastructure as a Service (Инфраструктура как сервис)

Ты получаешь «голые» виртуальные машины, виртуальные сети, диски, IP-адреса. Дальше всё настраиваешь сам: операционную систему ты выбираешь, программы ставишь сам, безопасность настраиваешь сам.

Примеры IaaS-сервисов:

Аналогия: ты арендовал пустое помещение под кафе. Стены, потолок, электричество есть, дальше всё сам.

PaaS — Platform as a Service (Платформа как сервис)

Ты получаешь готовую платформу под свои приложения. Не нужно думать про операционную систему, обновления, патчи безопасности — этим занимается провайдер. Ты просто заливаешь свой код или указываешь Docker-образ, а платформа сама его запускает и масштабирует.

Примеры PaaS-сервисов:

Аналогия: ты арендовал помещение с полностью оборудованной кухней. Плита, посуда, холодильник, газ — всё уже есть. Ты только готовишь.

SaaS — Software as a Service (Программа как сервис)

Ты получаешь готовую программу, которой просто пользуешься. Ничего настраивать не нужно вообще.

Примеры SaaS-сервисов:

Аналогия: ты пришёл в готовое кафе и кушаешь. Всё сделали за тебя.

Сравнительная таблица: что обслуживает провайдер, а что ты

Что нужно поддерживать On-premise (своё железо) IaaS PaaS SaaS
Физические серверы Ты Облако Облако Облако
Виртуализация Ты Облако Облако Облако
Операционная система Ты Ты Облако Облако
Среда выполнения Ты Ты Облако Облако
Приложение Ты Ты Ты Облако
Данные Ты Ты Ты Облако (часто)

FaaS и Serverless — следующий шаг эволюции

FaaS (Function as a Service) или Serverless — это PaaS, доведённый до предела. Ты не управляешь даже контейнерами и серверами. Ты пишешь функцию (например, на Python или JavaScript), загружаешь её в облако, и облако само её запускает, когда приходит HTTP-запрос или происходит событие (например, новый файл в хранилище).

Преимущества:

Недостатки:

Примеры: Yandex Cloud Functions, AWS Lambda, Cloud.ru Function как сервис, Cloudflare Workers.

Публичные, частные и гибридные облака

Базовые понятия облачной инфраструктуры

Что бы ты ни выбрал — Yandex Cloud, AWS или другой — основные понятия везде похожи:

  1. VPC (Virtual Private Cloud) — виртуальная сеть в облаке, изолированная от других клиентов. Это твой собственный «остров» с диапазоном IP-адресов (например, 10.0.0.0/16).
  2. Subnet (Подсеть) — часть VPC, расположенная в одной зоне доступности. Например, 10.0.1.0/24 в зоне ru-central1-a и 10.0.2.0/24 в зоне ru-central1-b.
  3. Zone (Зона доступности) — отдельный дата-центр в регионе. Если упадёт целый дата-центр, твоё приложение должно работать в другой зоне. Стандартная практика — размещать приложение минимум в двух зонах.
  4. Security Group (Группа безопасности) — виртуальный файрвол на уровне сети. Здесь ты разрешаешь, какой трафик может приходить к серверу и уходить от него. Например: «разрешить входящий TCP на 443 порт со всего интернета, входящий 22 порт только с моего IP».
  5. Public IP (Публичный IP) / EIP (Elastic IP) — внешний IP-адрес, по которому к серверу можно подключиться из интернета. Без него сервер живёт только во внутренней сети.
  6. Load Balancer (Балансировщик нагрузки) — распределяет входящий трафик между несколькими серверами. Например, у тебя 5 одинаковых веб-серверов, балансировщик равномерно отправляет запросы на каждый.
  7. Object Storage (S3-совместимое хранилище) — хранилище файлов с почти бесконечным объёмом. Платишь за гигабайты и за количество запросов.
  8. Managed DB — управляемая база данных. Облако само делает бэкапы, обновления, репликацию.
  9. IAM (Identity and Access Management) — система прав. Кто может что делать в облаке. Принцип: «давай минимально необходимые права» (principle of least privilege).

Оптимизация затрат — почему облако может стать очень дорогим

Облако удобно, но если им неаккуратно пользоваться, счёт в конце месяца может приятно удивить (в плохом смысле). Базовые правила экономии:

  1. Гаси то, что не используешь. Запустил машину на тест и забыл — она будет работать 24/7 и каждый час капать деньги. Удаляй или останавливай.
  2. Используй автомасштабирование. Ночью никто не работает с сайтом? Опусти количество реплик до 1. Днём — до 10.
  3. Резервированные ресурсы (Reserved Instances, Savings Plans). Если знаешь, что машина нужна 24/7 целый год — заплати вперёд с большой скидкой (до 70%).
  4. Spot / Preemptible Instances. Машины из «излишков» провайдера, дешевле в 3–5 раз, но облако может их забрать обратно через 5 минут. Подходят для пакетных задач, отказоустойчивого Kubernetes-кластера, аналитики.
  5. Right-sizing. Не заказывай 16 ядер, если приложение использует 2. Регулярно пересматривай.
  6. Object Storage tiers. Холодные архивы храни в дешёвых классах (Cold Storage, Glacier), они в 5–10 раз дешевле горячих.
  7. Тегируй ресурсы (labels/tags). Каждый ресурс должен иметь тег team=backend, env=prod, project=billing — иначе через полгода будет невозможно понять, кто за что платит.
  8. FinOps-практики. Это отдельная дисциплина — управление затратами в облаке. В крупных компаниях есть целые FinOps-команды.

Облака в России

После 2022 года международные провайдеры (AWS, GCP, Azure) перестали обслуживать российских клиентов. В России активно развиваются отечественные провайдеры:

  1. Yandex Cloud — крупнейший российский облачный провайдер. Полный набор сервисов: виртуальные машины, Managed Kubernetes, Managed PostgreSQL/MySQL/ClickHouse, Object Storage, ML-сервисы, AI Studio.
  2. Cloud.ru (бывший SberCloud) — облако от Сбербанка. Сильная сторона — интеграция с экосистемой Сбера, GPU-сервисы для ML.
  3. VK Cloud — облако от VK. Хороший набор PaaS-сервисов, Managed Kubernetes.
  4. Selectel — один из старейших российских хостингов и облаков. Сильная сторона — выделенные серверы и приватные облака.
  5. MWS (МТС Web Services) — облако от МТС.
  6. Beeline Cloud — облако от Билайн.
  7. T1 Cloud — облако от группы Т1.

Для зарубежного рынка по-прежнему доминируют AWS (около 30% рынка), Microsoft Azure (около 25%), Google Cloud (около 12%). Также набирают популярность Alibaba Cloud (Китай), Oracle Cloud Infrastructure.

Теоретические вопросы

  1. В чём принципиальная разница между IaaS, PaaS и SaaS? Приведи примеры каждого. Ответ: IaaS — арендуешь «голую» виртуальную машину и всё настраиваешь сам (Yandex Compute, AWS EC2). PaaS — арендуешь готовую платформу под приложение, ОС и систему обслуживает провайдер (Managed Kubernetes, Managed PostgreSQL). SaaS — пользуешься готовой программой как сервисом (GitHub, Notion, Яндекс 360).

  2. Что такое VPC и зачем она нужна? Ответ: Виртуальная изолированная сеть в облаке со своим диапазоном IP-адресов. Нужна для того, чтобы твои ресурсы не были перепутаны с ресурсами других клиентов облака и могли безопасно общаться между собой по внутренней сети.

  3. Что такое Security Group, чем она отличается от классического файрвола? Ответ: Security Group — это виртуальный файрвол, привязанный не к сети, а к ресурсу (виртуальной машине, базе). Правила задаются в декларативном виде. В отличие от классического iptables, ты не пишешь команды, а описываешь «что разрешено» — остальное автоматически запрещено.

  4. Зачем размещать приложение в нескольких зонах доступности? Ответ: Чтобы пережить падение целого дата-центра. Если все реплики в одной зоне и она упадёт — приложение недоступно. Если они в двух или трёх зонах — пользователи даже не заметят отказа одной из них.

  5. Что такое serverless / FaaS? В каких случаях он оправдан, в каких нет? Ответ: Модель, где ты пишешь функции, а облако их запускает по событию (HTTP-запрос, новый файл в хранилище и т. д.) и масштабирует с нуля до тысяч одновременных вызовов. Оправдан для редких или нестабильных нагрузок, событийных задач, webhooks. Неоправдан для постоянно нагруженных сервисов (получится дорого) и для приложений, требовательных к холодному старту (например, низколатентные API).

  6. Что такое vendor lock-in? Как его минимизировать? Ответ: Зависимость от одного провайдера. Чем больше ты используешь уникальных сервисов AWS (например, Lambda, DynamoDB), тем сложнее уйти в Yandex Cloud. Минимизировать: использовать переносимые технологии (Kubernetes, PostgreSQL, S3-совместимое хранилище), описывать инфраструктуру через Terraform/OpenTofu (об этом в теме 7), избегать сильно специфичных API.

  7. Чем Object Storage отличается от обычного диска? Ответ: Обычный диск (Block Storage) подключается к одной машине и работает как файловая система. Object Storage — это HTTP API: каждый файл — это «объект», доступный по уникальному URL. Object Storage почти бесконечно масштабируется (петабайты), оплачивается за гигабайты и за количество запросов. Block Storage быстрее (низкая задержка), но не масштабируется до петабайт и привязан к одной машине.

  8. Что такое Reserved Instances и Spot Instances? Ответ: Reserved — машина, которую ты резервируешь на 1 или 3 года, платишь сразу со скидкой 30–70%. Подходит для постоянных нагрузок. Spot (или Preemptible в GCP, Прерываемые в Yandex Cloud) — машины из свободных мощностей провайдера, дешевле в 3–5 раз, но провайдер может их забрать в любой момент с предупреждением за 30 секунд — 2 минуты. Подходят для отказоустойчивых нагрузок: Kubernetes с автоскейлингом, пакетная обработка, тестовые окружения.

  9. Что такое IAM и почему «принцип минимальных привилегий» важен? Ответ: IAM (Identity and Access Management) — система управления правами доступа. Принцип минимальных привилегий: давай ровно те права, которые нужны для задачи, и не больше. Если у сервисного аккаунта приложения есть права администратора и приложение скомпрометируют — атакующий получит полный контроль над всем облаком. Если есть только право читать одну S3-корзину — ущерб минимален.

  10. Что такое Managed Service и какие у него плюсы и минусы по сравнению с самостоятельной установкой? Ответ: Управляемый сервис — облако само устанавливает, обновляет, бэкапит, мониторит. Например, Managed PostgreSQL. Плюсы: экономия времени, автоматические бэкапы и failover, обновления безопасности «из коробки». Минусы: дороже, чем самостоятельно установленный PostgreSQL на той же машине; ограничения в конфигурации (не все расширения и параметры доступны); привязка к провайдеру.

  11. Что такое Region и Availability Zone? Сколько обычно зон в одном регионе? Ответ: Регион — это географически разделённая локация (например, ru-central1 — это Россия). Зона доступности — отдельный изолированный дата-центр внутри региона. Обычно 2–4 зоны в регионе, расположенные физически в десятках километров друг от друга (отдельное здание, питание, охлаждение, сетевые каналы). У Yandex Cloud сейчас три зоны в Москве и Подмосковье.

  12. Что такое CDN и зачем он нужен? Ответ: Content Delivery Network — сеть из десятков серверов по всему миру, которые кэшируют статический контент сайта (картинки, видео, CSS, JS). Пользователь получает файлы с ближайшего узла CDN, а не с твоего основного сервера. Преимущества: скорость загрузки, разгрузка основного сервера, защита от DDoS-атак. Примеры: Cloudflare, Yandex Cloud CDN, CloudMTS CDN.

  13. Что такое DNS в облаке (Managed DNS)? Ответ: Управляемый DNS-сервис, который держит зоны твоих доменов на отказоустойчивой инфраструктуре провайдера. Yandex Cloud DNS, AWS Route 53, Cloudflare DNS. Чаще всего такие сервисы умеют health-checks и geo-routing — отправлять пользователей на ближайший сервер.

  14. Что лучше для базы данных в проде: запустить самому на ВМ или взять Managed? Ответ: Для большинства задач — Managed. Самостоятельный запуск экономит деньги, но требует постоянной экспертизы по администрированию БД: бэкапы, восстановление, тюнинг, обновления, мониторинг репликации, failover. Цена ошибки очень высокая (потеря данных). Managed имеет смысл всегда, кроме случаев, когда нужна экзотическая конфигурация или экономия на каждой копейке.

  15. Что такое FinOps? Ответ: Дисциплина (и часто отдельная команда), отвечающая за управление облачными затратами в крупных компаниях. Включает в себя: тегирование ресурсов, расчёт unit economics («сколько облака стоит обработка одного заказа»), регулярные ревью затрат, переговоры о скидках, обучение команд экономии. В компании с расходами от $1 млн в месяц на облако FinOps окупается с лихвой.

Вопросы с собеседований

  1. Что такое модель разделяемой ответственности? Ответ: Договорённость о том, кто за что отвечает. Провайдер отвечает за безопасность самого облака: дата-центры, железо, гипервизор, сеть. Клиент — за безопасность в облаке: настройку доступов, шифрование данных, обновления операционной системы на своих машинах, правила групп безопасности. Большинство утечек происходит по вине клиента, а не провайдера: типичный случай — бакет, открытый на публичное чтение

  2. Чем зона доступности отличается от региона и как выбирать регион? Ответ: Регион — географическая локация, зона — отдельный дата-центр внутри неё. Регион выбирают по трём критериям: близость к пользователям (задержка), требования законодательства к месту хранения данных и цена, которая между регионами различается. Между зонами одного региона задержка порядка миллисекунды, между регионами — десятки миллисекунд, и это уже влияет на архитектуру

  3. Приложение должно пережить отказ целого региона. Что это меняет? Ответ: Многое и дорого. Нужны копии в двух регионах, репликация данных между ними (а это задержка и вопрос согласованности), балансировка на уровне DNS, регулярные учения по переключению. Прежде чем строить такое, отвечают на вопрос, сколько стоит час простоя: для большинства систем достаточно нескольких зон в одном регионе

  4. Что такое сервисный аккаунт в облаке и чем он лучше ключей доступа? Ответ: Учётная запись для программы, а не человека. Виртуальная машина или под получает временные автоматически обновляемые полномочия просто по факту того, чем она является. Постоянные ключи доступа при этом не нужны, а именно они утекают в репозитории чаще всего. Правило: долгоживущий ключ — это последнее средство

  5. Что такое Infrastructure as Code и почему в облаке без него плохо? Ответ: Описание инфраструктуры текстовыми файлами в репозитории. Без него окружения расползаются (в тестовом одно, в боевом другое, и никто не помнит почему), забытые ресурсы тратят деньги, а воспроизвести конфигурацию после аварии невозможно. Подробно — тема 7

  6. Как в облаке устроено резервное копирование и что с ним чаще всего не так? Ответ: Снимки дисков, автоматические копии управляемых баз, версионирование объектных хранилищ. Главная проблема не в создании копий, а в том, что их не проверяют: восстановление впервые пробуют во время аварии и обнаруживают, что копия пуста или неполна. Правило: копия существует, только если из неё успешно восстановились — в теме 8 это один из пунктов чек-листа

  7. Почему счёт за облако вырос вдвое? Как искать причину? Ответ: По разбивке затрат в консоли биллинга: по сервисам, по тегам, по проектам. Частые виновники: забытые машины и диски от удалённых машин, неиспользуемые статические адреса, исходящий трафик (он почти всегда платный, а входящий обычно нет), логи и метрики с большим сроком хранения, снимки дисков. Именно поэтому теги на ресурсах обязательны: без них невозможно понять, чьё это

  8. Чем управляемый Kubernetes отличается от кластера, поднятого вручную? Ответ: Провайдер берёт на себя управляющие ноды: их доступность, обновление, резервное копирование etcd. Ты платишь и отвечаешь только за рабочие ноды и свои приложения. Самостоятельная установка оправдана редко: когда нужны нестандартные настройки API-сервера или кластер работает вне облака

  9. Что такое прерываемые (spot) машины и как на них строить работу? Ответ: Дешёвые машины из свободных мощностей, которые провайдер может забрать, предупредив за короткое время. Подходят для того, что переживает потерю узла: пакетная обработка, тестовые окружения, часть нод Kubernetes-кластера. Правила: не держать на них состояние, корректно обрабатывать сигнал завершения и всегда иметь запас обычных нод

  10. Как правильно организовать доступы в облаке? Ответ: Права выдавать группам и ролям, а не людям поимённо; минимально необходимый набор; отдельные проекты или каталоги под окружения, чтобы тестовое не имело доступа к боевому; обязательная двухфакторная аутентификация; корневой аккаунт не использовать в повседневной работе; включённый журнал аудита. Разбор инцидента начинается с вопроса «кто и что мог сделать», и ответ на него должен быть в журнале

  11. Приложение в облаке стало медленно работать. С чего начать? Ответ: Понять, где именно медленно: у пользователя, на балансировщике, в приложении или в базе — это задача мониторинга из темы 8. Специфично для облака проверяют: не упёрлись ли в квоты и лимиты сервиса, не исчерпан ли запас производительности диска (у дешёвых дисков он накопительный и заканчивается), не работает ли машина на сниженной доле процессора, не ходит ли трафик между зонами там, где не должен

  12. Что важно учесть при переезде из одного облака в другое? Ответ: Больше всего проблем создают данные: их объём, время переноса и плата за исходящий трафик. Дальше — уникальные сервисы провайдера, которым нет прямого аналога, различия в сетевой модели и правах доступа. Переезд упрощает опора на переносимые технологии: Kubernetes, PostgreSQL, S3-совместимое хранилище, инфраструктура как код

Практическая часть

Все задания ниже можно выполнить в бесплатном пробном периоде одного из облаков: Yandex Cloud даёт 4000 рублей грантов и месяц на ознакомление, Cloud.ru — 4000 рублей, VK Cloud — 3000 рублей. Бери любое, шаги похожие.

Задание 1. Регистрация в облачном провайдере

Цель: Получить аккаунт и пройти базовую настройку.

Шаги:

  1. Зарегистрируйся в Yandex Cloud: https://cloud.yandex.ru → «Подключиться»
  2. Активируй пробный период (потребуется привязка карты — деньги не списываются, пока ты не превысишь грант или не выйдешь из пробного периода)
  3. Создай свой первый каталог (folder) — это «папка» для всех ресурсов проекта
  4. Установи официальный CLI: 
    curl -sSL https://storage.yandexcloud.net/yandexcloud-yc/install.sh | bash
  5. Авторизуйся: yc init — следуй инструкциям, выбери каталог и зону по умолчанию
  6. Проверь, что всё работает: 
    yc config list
yc compute instance list

    Список машин должен быть пустым.

Задание 2. Запуск первой виртуальной машины (IaaS)

Цель: Понять, как работает IaaS на практике, и поднять веб-сервер.

Шаги:

  1. Создай SSH-ключ, если ещё нет: 
    ssh-keygen -t ed25519 -C "your.email@example.com"
# ключ появится в ~/.ssh/id_ed25519 (приватный) и ~/.ssh/id_ed25519.pub (публичный)
  2. Создай ВМ через CLI: 
    yc compute instance create \
  --name my-first-vm \
  --zone ru-central1-a \
  --network-interface subnet-name=default-ru-central1-a,nat-ip-version=ipv4 \
  --create-boot-disk image-folder-id=standard-images,image-family=ubuntu-2404-lts,size=20 \
  --memory 2 --cores 2 --core-fraction 20 \
  --ssh-key ~/.ssh/id_ed25519.pub

    Объяснение параметров:

    • --core-fraction 20 — гарантированная доля CPU 20% (это самые дешёвые «прерываемые» по нагрузке машины)
    • --memory 2 --cores 2 — 2 ГБ RAM и 2 ядра
    • nat-ip-version=ipv4 — выдать публичный IPv4-адрес
    • image-family=ubuntu-2404-lts — Ubuntu 24.04 LTS

  3. Найди публичный IP в выводе предыдущей команды (поле address в one_to_one_nat).

  4. Подключись по SSH: 
    ssh -i ~/.ssh/id_ed25519 yc-user@<публичный_IP>
  5. Установи nginx внутри ВМ: 
    sudo apt update
sudo apt install -y nginx
sudo systemctl status nginx

  6. Открой 80-й порт через Security Group или (в Yandex Cloud по умолчанию) проверь, что 80 уже разрешён. Если нет — добавь правило.

  7. Зайди на http://<публичный_IP> через браузер — должна открыться приветственная страница nginx.

  8. Не забудь удалить ВМ после практики, иначе деньги/грант будут расходоваться: 
    yc compute instance delete my-first-vm

Задание 3. Object Storage (S3-совместимое хранилище)

Цель: Загрузить файлы в S3, сделать корзину публичной для статики.

Шаги:

  1. Создай bucket (корзину): 
    yc storage bucket create \
  --name my-test-bucket-<уникальный_суффикс> \
  --public-read

    Имя bucket должно быть глобально уникальным в облаке.

  2. Установи s3cmd или aws-cli для работы с S3-совместимым API: 
    pip3 install awscli --break-system-packages
  3. Настрой aws-cli на работу с Yandex Object Storage: 
    aws configure --profile yandex
# Access Key ID:    создаёшь в IAM Yandex Cloud
# Secret Access Key: оттуда же
# Region: ru-central1
# Output: json
  4. Загрузи файл: 
    echo "<h1>Привет из облака!</h1>" > index.html
aws --profile yandex --endpoint-url=https://storage.yandexcloud.net \
  s3 cp index.html s3://my-test-bucket-<суффикс>/index.html
  5. Открой файл в браузере: 
    https://my-test-bucket-<суффикс>.storage.yandexcloud.net/index.html
  6. Удали bucket после практики: 
    aws --profile yandex --endpoint-url=https://storage.yandexcloud.net \
  s3 rm s3://my-test-bucket-<суффикс>/index.html
yc storage bucket delete --name my-test-bucket-<суффикс>

Задание 4. Managed PostgreSQL (PaaS)

Цель: Понять, насколько Managed-сервисы быстрее настраиваются.

Шаги:

  1. Создай Managed PostgreSQL-кластер минимальной конфигурации: 
    yc managed-postgresql cluster create \
  --name my-pg \
  --environment production \
  --network-name default \
  --resource-preset s3-c1-m4 \
  --host zone-id=ru-central1-a,subnet-name=default-ru-central1-a,assign-public-ip=true \
  --user name=admin,password=ChangeMe_StrongPass123! \
  --database name=app,owner=admin \
  --postgresql-version 16
  2. Подожди 5–10 минут, пока кластер развернётся: 
    yc managed-postgresql cluster get my-pg
# Поле status: должно стать RUNNING
  3. Получи строку подключения и подключись через psql: 
    yc managed-postgresql hosts list --cluster-name my-pg
psql "host=<host_FQDN> port=6432 dbname=app user=admin sslmode=verify-full target_session_attrs=read-write"
  4. Создай тестовую таблицу: 
    CREATE TABLE users (id SERIAL PRIMARY KEY, name TEXT, created_at TIMESTAMP DEFAULT NOW());
INSERT INTO users (name) VALUES ('Alice'), ('Bob');
SELECT * FROM users;

  5. Сравни: сколько времени у тебя ушло на разворачивание Managed PG vs. сколько ушло бы на ручную установку, тюнинг, настройку бэкапов, репликации на ВМ.

  6. Удали кластер: 
    yc managed-postgresql cluster delete my-pg

Задание 5. Сквозной проект: «Заметки» переезжают в интернет

Цель: вынести приложение с ноутбука на настоящий сервер, доступный из интернета любому человеку

Шаги:

  1. Создай виртуальную машину, как в задании 2, но назови её осмысленно:

    yc compute instance create \
  --name notes-prod \
  --zone ru-central1-a \
  --network-interface subnet-name=default-ru-central1-a,nat-ip-version=ipv4 \
  --create-boot-disk image-folder-id=standard-images,image-family=ubuntu-2404-lts,size=20 \
  --memory 2 --cores 2 --core-fraction 20 \
  --ssh-key ~/.ssh/id_ed25519.pub

  2. Запиши публичный IP в переменную и подключись:

    IP=$(yc compute instance get notes-prod --format json | grep -o '"address": "[0-9.]*"' | tail -1 | cut -d'"' -f4)
echo "$IP"
ssh -i ~/.ssh/id_ed25519 yc-user@"$IP"

  3. На сервере поставь Docker и забери свой репозиторий из темы 3:

    sudo apt update && sudo apt install -y docker.io docker-compose-v2 git
sudo usermod -aG docker "$USER" && exit     # выйти и зайти снова, чтобы права применились

    ssh -i ~/.ssh/id_ed25519 yc-user@"$IP"
git clone https://github.com/<твой_логин>/notes.git
cd notes
docker compose up -d --build
docker compose ps
curl http://localhost:8080/

    Обрати внимание: compose.yml из темы 4 заработал на чужой машине без единой правки. Ровно за этим мы упаковывали приложение в контейнер

  4. Открой порт наружу. Проверь правила группы безопасности в консоли облака: нужен входящий TCP на порт 8080 (или перевесь nginx на 80). Затем с своего компьютера:

    curl http://<публичный_IP>:8080/

    Отправь ссылку другу — это первый момент курса, когда твоё приложение доступно кому-то, кроме тебя

  5. Посчитай деньги. Открой в консоли раздел биллинга и посмотри, сколько стоит эта машина в час и в месяц. Прикинь, во сколько обойдётся такой сервис при работе круглый год. Это важный навык: инженер должен уметь назвать стоимость того, что он развернул

  6. Удали всё:

    yc compute instance delete notes-prod
yc compute instance list          # список должен быть пуст
yc vpc address list               # и здесь тоже

Ожидаемый вывод: приложение открывается по публичному IP с любого устройства; после удаления машины список ресурсов пуст

Типичные ошибки:

Задание 6. Сравнение: подними блог за полчаса

Цель: Прочувствовать разницу между моделями.

Подними простой блог (например, Ghost или WordPress) тремя способами:

  1. IaaS: возьми ВМ → установи MySQL → установи WordPress → настрой nginx → настрой бэкапы → SSL через Let’s Encrypt. Замерь, сколько ушло времени.

  2. PaaS: возьми Managed MySQL/PostgreSQL + Cloud Run / Yandex Serverless Containers / VK Cloud App Engine. Загрузи Docker-образ WordPress.

  3. SaaS: просто зарегистрируйся на платформе, которая хостит блоги как сервис (например, Notion или Telegraph для совсем простых случаев). Сравни время до публикации первого поста.

Что ты должен понять: в каких случаях SaaS вообще не подходит (нужна кастомизация), в каких PaaS — оптимально, а в каких нужно идти в IaaS (нестандартные требования, экономия, vendor independence).

Финальное напоминание

🛑 Перед закрытием курса убедись, что все ресурсы удалены:

yc compute instance list           # машин быть не должно
yc storage bucket list             # корзин быть не должно
yc managed-postgresql cluster list # БД быть не должно
yc vpc address list                # статичных IP быть не должно (они платные)
yc compute disk list               # дисков быть не должно

Любой неудалённый ресурс продолжит списывать деньги. Это правило №1 любого облачного инженера: «удалил — проверь, что удалил».

Заметил, сколько кликов и команд ушло на создание одной машины? И сколько шансов забыть что-то удалить? Именно поэтому в реальной работе инфраструктуру не создают руками — её описывают кодом. Об этом следующая тема

Проверь себя: тема освоена, если ты можешь

Следующая тема: Ansible и Terraform →