Инструкции (tutorials) по теме Работа в панели

Привет! Меня зовут Сергей Крайнев, я разработчик облачной платформы. В прошлой статье рассказал об использовании Terraform для создания глобального роутера и настройки сетевой связности между разными регионами облака. Сегодня продолжим тему и объединим в сеть выделенный и облачный серверы. Исходные условия Часть инфраструктуры осталась прежней — это сервер в петербургском облачном регионе ru‑1. Для демонстрации нового сценария дополнительно зарезервирован «железный» сервер в московской локации MSK-2. Облачный сервер в зоне ru-1: облачная сеть с подсетью 192.168.0.0/28, виртуальная машина (ВМ) в этой сети с IP‑адресом 192.168.0.2, облачный роутер, подключенный к сети с плавающим IP 95.213.180.201. Выделенный сервер в зоне MSK-2: облачная сеть с подсетью 172.16.0.0/28, IP‑адрес хоста в этой сети — 172.16.0.2, Такая инфраструктура позволяет решать различные задачи — в том числе те, что описаны в документации. Допустим, на ВМ1 в Санкт-Петербурге поднята база данных. Однако сам сервис и его окружение хочу развернуть на выделенном железном сервере в Москве, чтобы полностью контролировать вычислительные ресурсы. Как и ранее, решим задачу с помощью глобального роутера Selectel. В результате московский выделенный сервер станет доступен с ВМ1 по внутреннему IP-адресу в серой сети. Проверка связности полностью аналогична и выполняется с помощью ping-запросов. Целевая схема будет выглядеть так: Далее рассмотрим два способа реализации такой схемы: вручную через панель управлениями, автоматически с помощью Terraform. Способ 1. Настраиваем в панели управления Воспользуемся документацией по настройке сети в облаке и подразделом по маршрутизации до выделенного сервера. Выполним следующие шаги: создадим ресурс глобального роутера, подключить к созданному роутеру изолированную сеть региона ru-1 и нужную подсеть, выполнить ту же процедуру для сети и подсети локации MSK-2. Результат будет выглядеть так: Укажем статические маршруты на обоих хостах: на виртуальной машине: ip r add 172.16.0.0/28 via 192.168.0.1, на выделенном сервере: ip r add 192.168.0.0/28 via 172.16.0.1. В завершение проверим работоспособность схемы, запустив tcpdump на выделенном сервере: Способ 2. Автоматическая настройка с помощью Terraform Provider В статье «Автоматическое создание и настройка глобального роутера в облаке через Terraform Provider» мы подробно разобрали подключение сети с виртуальной машиной. Вспомним общие шаги. Инициализируем Terraform-провайдер. Создаем глобальный роутер. Получаем UUID облачной зоны из datasource. Подключаем сеть и подсеть в облаке к созданному глобальному роутеру. Чтобы не усложнять пример, возьмем инфраструктуру из прошлой статьи, поэтому параметры ресурсов в манифестах останутся без изменений. Шаг 1. Провайдер, роутер и сети облака Скопируем код в шаблон main.tf и убедимся, что все работает, выполнив команды: Ожидаемый вывод в консоли и интерфейсе панели управления показан ниже. Если результаты отличаются, рекомендуем сверить манифесты с примерами из прошлой статьи. Вывод результата в консоли. Ожидаемый результат в панели управления Selectel. Шаг 2. Добавляем сеть до выделенного сервера Теперь поговорим о ресурсах, которые еще не рассматривали. Начнем с подключения сети до выделенного сервера. Обязательные параметры для описания этой сущности в манифесте: router_id — UUID созданного ранее глобального роутера; zone_id — в какой зоне находится выделенный сервер; vlan — тег VLAN серой сети, к которой подключен выделенный сервер; name — имя сети внутри глобального роутера. Часть атрибутов совпадает с настройками облачной сети, но есть и отличия. Важно: zone_id в данном случае берется также из datasource, но с другими параметрами. Это логично, потому что адреса для выделенных серверов находятся в другой зоне с иным именем и типом сервиса. Тег VLAN можно найти на вкладке Сеть в настройках выделенного сервера. В нашем примере его значение — 1962. Итоговое описание ресурса выглядит так: Шаг 3. Настройка подсети выделенного сервера После добавления сети остается задать диапазон адресов подсети. Этот блок конфигурации похож на тот, что использовался для подключения облачной подсети и требует указания параметров: network_id — UUID созданной на предыдущем шаге сети; name — имя подсети внутри глобального роутера; cidr — блок IP‑адресов, в точности совпадающих с используемыми выделенным сервером; service_addresses — два IP-адреса для внутренних нужд инфраструктуры. Как и при ручной настройке в панели управления, выберем два свободных значения из конца диапазона подсети — .13 и .14 для CIDR из нашего примера; gateway — сервисный IP-адрес шлюза, который по той же логике возьмем первый из нашего диапазона — .1. В манифесте код для нашей подсети выглядит так: Проверяем итоговый результат Добавим блоки datasource, сети и подсети в шаблон, после чего применим новую конфигурацию: В облаке появятся два дополнительных ресурса: В панели управления созданные элементы инфраструктуры также станут видны: Выполним итоговую проверку: на выделенном сервере запускаем tcpdump и отслеживаем ICMP-пакеты; на виртуальной машине с помощью утилиты ping отправляем эхо‑пакеты до выделенного сервера по внутреннему адресу 172.16.0.2. Итак, мы воспроизвели настройку в панели управления и организовали сетевую связность между серверами с помощью глобального роутера. Как корректно указать зону в ресурсе сети Отдельно хотелось подсветить вопрос использования параметра зоны при создании сетей. Выше показан рекомендуемый способ — получение zone_id через datasource. Есть и альтернативный вариант:узнать zone_id через API глобального роутера и явно указать UUID: Однако стоит избегать указания имени зоны вместо UUID в этом параметре. Приведенный ниже пример некорректен и работать не будет: Ранее созданные ресурсы и import В заключение хочется уделить несколько слов импорту ресурсов в Terraform. Многие о нем слышали, но не все применяли на практике. Представим ситуацию: ресурсы созданы через API, а инструмент IaC внедряется позже. Что делать в таком случае? Пересоздание ресурсов «с чистого листа» — не вариант, а хочется добавить автоматизацию и расширять инфраструктуру с помощью Terraform. Здесь выручит команда terraform import. Чаще всего используется два подхода: точечный импорт отдельного ресурса через Terraform CLI. массовый перенос группы сущностей через шаблон и блок import. В обоих случаях инфраструктуру придется предварительно описать, как это сделано выше. Потребуется старательно собрать все требуемые параметры существующего ресурса, будто для создания дубликата. Для первого подхода (работа в CLI) выполняется команда: Ресурс будет импортирован и в дальнейшем им можно будет управлять через описание в шаблоне. Однако переносить таким образом множество объектов довольно затруднительно. Конечно, можно написать скрипт со множеством команд import и добавить все ресурсы по очереди. Но зачем страдать, если есть более изящное решение — описать секцию импортов прямо в манифесте. Предположим, сетевая топология из статьи собрана вручную в панели управления, и мы хотим перенести ее в Terraform. Для этого создаем шаблон с описанием всех элементов, как в примерах выше, а в конце добавляем конструкции import: Затем выполняем уже известные команды: Terraform импортирует ресурсы — не создает! После успешного импорта эти блоки можно удалить из манифеста и управлять конфигурацией так, будто инфраструктура изначально разворачивалась через Terraform. Заключение Terraform, очевидно, упрощает развертывание инфраструктуры. Рассмотренный в статье пример, можно полностью автоматизировать — «с чистого листа» создать и связать через глобальный роутер выделенный и облачный серверы. Готовый манифест есть в нашем репозитории. Пара команд в консоли, настройка статических маршрутов — и можно повторить описанную топологию у себя в аккаунте Selectel. Надеюсь, эта статья поможет упростить переход на автоматизацию работы с инфраструктурой с помощью Terraform. Также рекомендую к ознакомлению статью о том, «Как в Selectel с помощью Terraform заказать выделенный сервер» под любые нужды: от сервера для хостинга любимой игры — до PET проекта с LLM.

Работа в панели

Зарегистрируйтесь в панели управления