Найти в Дзене
Linux | Network | DevOps

Домашняя лаборатория DevOps: Proxmox + Terraform

Сделаю небольшое отступление, которое я пишу уже после всех проб и ошибок. В целом, делать кластер из 2-х нод имеет смысл только для централизованного управления нодами, ВМ и бекапами на NFS (в том числе и через Terraform, но об этом будет позже). Потому что для хорошей работы HA (high availability — высокая доступность) необходимо от 3-х и более нод для кворума. Ещё моя идея состояла в том, чтобы связать NAS и 2 ноды в одну сеть 2,5 гигабита. В своем решении я сделал виртуальный маршрутизатор, но моя личная рекомендация — покупать отдельный маршрутизатор на 2,5 (или выше) гигабита и уже спокойно подключать туда всё железо. Если у вас уже есть в наличии маршрутизатор, то момент создания виртуалки OpenWRT можно пропустить. Так как у меня не было маршрутизатора на 2,5 гигабита,
я решил создать виртуальный. На моих серверах уже есть порты 2.5
гигабита, осталось их правильно задействовать. Получилось примерно следующее: Виртуалку я поднимал с помощью скрипта с сайта Proxmox VE Helper-Sc
Оглавление

Создание кластера Proxmox

Сделаю небольшое отступление, которое я пишу уже после всех проб и ошибок. В целом, делать кластер из 2-х нод имеет смысл только для централизованного управления нодами, ВМ и бекапами на NFS (в том числе и через Terraform, но об этом будет позже). Потому что для хорошей работы HA (high availability — высокая доступность) необходимо от 3-х и более нод для кворума. Ещё моя идея состояла в том, чтобы связать NAS и 2 ноды в одну сеть 2,5 гигабита. В своем решении я сделал виртуальный маршрутизатор, но моя личная рекомендация — покупать отдельный маршрутизатор на 2,5 (или выше) гигабита и уже спокойно подключать туда всё железо. Если у вас уже есть в наличии маршрутизатор, то момент создания виртуалки OpenWRT можно пропустить.

Так как у меня не было маршрутизатора на 2,5 гигабита,
я решил создать виртуальный. На моих серверах уже есть порты 2.5
гигабита, осталось их правильно задействовать.

Получилось примерно следующее:

  • из домашнего роутера в server1 приходит патчкорд с сетью
  • на сервере1 развёрнута виртуальная машина с OpenWRT. Выбрал её потому, что использую эту роутерную ОС на домашнем AX3000T — уже есть опыт работы
  • в роутерную виртуалку подключены мосты, которые физически используют порты по 2,5 гигабита
Параметры сети у server1
Параметры сети у server1
Параметры виртуалки с OpenWRT
Параметры виртуалки с OpenWRT

Виртуалку я поднимал с помощью скрипта с сайта Proxmox VE Helper-Scripts.

Настройки в OpenWRT минимальные: нужно объединить все интерфейсы в один bridge device и на его основе создать lan интерфейс.

Параметры bridge device в OpenWRT
Параметры bridge device в OpenWRT
Параметры lan интерфейса
Параметры lan интерфейса

В итоге мы получаем виртуальный роутер, который пропускает трафик через себя на физические порты.

Не обязательно использовать OpenWRT, можно задействовать PfSense и
подобные виртуальные роутеры. Такое у меня получалось даже на крошечной
ВМ с Alpine Linux, но для наглядности и возможности управления через
веб-интерфейс я взял OpenWRT.

В дальнейшем я подключил в порты server1 2,5 гигабит NAS и server2. Используя iperf3, получил примерно 2,4 гигабита скорости , что в целом меня устраивает. Да, признаю, в данный момент схема не отказоустойчивая, так как при падении server1 потеряется доступность к NAS и server2, поэтому в дальнейшем я, возможно, заменю виртуальный роутер на физический. Но в таком режиме к моменту выхода статьи у меня uptime близится к трём месяцам и пока проблем с виртуальным роутером не было.

Итак, сеть настроили. Перейдем к кластеризации. На первой ноде
(server1) переходим в Datacenter - Cluster и нажимаем Create Cluster.
Придумываем название кластера и нажимаем Create.

Инициализация кластера
Инициализация кластера

После получения об успешной инициализации кластера нам становится доступна кнопка Join Information. Копируем зашифрованный в Base64 json с
информаций подключения.

Информация для подключения к кластеру
Информация для подключения к кластеру

Теперь логинимся на вторую ноду (server2) и также переходим в Datacenter -
Cluster. Тут нам нужна кнопка Join Cluster. Нажимаем на неё и вводим
скопированный Base64 и пароль к первой ноде. Нажимаем Join.

Подключение второй ноды к кластеру
Подключение второй ноды к кластеру

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

Пример процесса подключения к кластеру
Пример процесса подключения к кластеру

Таким образом можно подключить дополнительные ноды, при этом ограничений на число нод нет. В итоге получаем централизованное управление нодами, бекапами, дисками и сетью.

Теперь попробуем добавить NFS папку с NAS. Идём в Datacenter - Storage - Add - Add NFS и заполняем следующим образом:

Добавляем NFS как хранилище
Добавляем NFS как хранилище

После подключения NFS папки настроим бекапы наших ВМ на NAS. Переходим в Datacenter - Backup и создаём новую задачу:

Настройка бекапов
Настройка бекапов

В General я исключил часть ВМ для бекапирования, так как одна ВМ —
это виртуальный роутер, и там не планируется изменения, а вторая ВМ —
это темплейт, из которого я создаю новые ВМ копированием или при
использовании Terraform. Во вкладке Retention я указал хранить последние
5 бекапов. То есть при частоте копирования раз в сутки у нас будет
сохраняться 5 суточных бекапов для отката/восстановления ВМ.

Настройка глубины бекапов
Настройка глубины бекапов

Использование Terraform в Proxmox

Terraform — это инструмент IaC (инфраструктуры как код), который позволяет
описывать инфраструктуру в .tf файлах. А сами файлы можно хранить в git
репозитории, что дополнительно добавляет гибкости. Terraform использует
Hashicorp Language (HCL). Это yaml/jsonーподобный язык, который в
основном используется в продуктах компании Hashicorp. В дальнейшем,
возможно, понадобится VPN для просмотра документации и получение
провайдера.

После того как я настроил Proxmox для работы с Terraform, я перестал в целом создавать ВМ в интерфейсе Proxmox, так как всё, что мне нужно, было уже описано в .tf файлах, и для создания новой ВМ я просто копировал блоки кода, изменяя нужные параметры.

Итак, для запуска проекта terraform нам нужен провайдер. Рабочий провайдер для Proxmox —  это proxmox provider от разработчика Telmate (нужен VPN). Далее я приведу примеры конфигов, которые настроены у меня. Документация для глубокого изучения находится вот тут (тоже нужен VPN).

Файл «provider.tf» инициализации провайдера и настройка подключения к кластеру:

#секция установки провайдера
terraform {
required_providers {
proxmox = {
source = "Telmate/proxmox"
version = "3.0.1-rc6"
}
}
}

#секция подключения к кластеру/ноде
provider "proxmox" {
pm_tls_insecure = true
pm_api_url = "https://192.168.0.100:8006/api2/json"
pm_password = var.password
pm_user = "root@pam"
}

Файл «variable.tf» с переменными (его можно дополнять в дальнейшем):

#тут вписываем свой ssh ключ
variable "ssh_key" {
description = "My SSH public key"
type = string
default = "ssh-rsa …"
}

variable "password" {
description = "my PVE password"
type = string
default = "enter_your_proxmox_password"
}

Небольшое отступление.

По факту базовый конфиг взят отсюда.
Здесь находится описание того, как создать cloud-init template в
proxmox для дальнейшего его использования в Terraform. В рамках моего
кластера файл
«main.tf» выглядит вот так:

#определяем id, имя ВМ, целевой сервер и ресурсы ВМ.
resource "proxmox_vm_qemu" "gitlab" {
vmid = 180
name = "gitlab"
target_node = "server1"
agent = 1
cores = 2
memory = 8192
boot = "order=scsi0"
clone = "Ubuntu-24.04" #выбираем, с какого темплейта клонируем
full_clone = true
scsihw = "virtio-scsi-single"
vm_state = "running"
automatic_reboot = true

cicustom = "vendor=local:snippets/qemu-guest-agent.yml" #этот момент описан по ссылке выше, если вкратце - мы передаём команды, которые будут введены после старта склонированной ВМ
ciupgrade = true
nameserver = ""
ipconfig0 = "ip=192.168.0.180/24,gw=192.168.0.1"
skip_ipv6 = true
ciuser = "alex"
cipassword = "1"
sshkeys = var.ssh_key

#эта секция не используется, нужна для защиты ВМ от случайного удаления при использовании командной строки terraform
# lifecycle {
# prevent_destroy = true
# }

serial {
id = 0
}

disks {
scsi {
scsi0 {
disk {
storage = "local-lvm"
size = "32G"
}
}
}
ide {
ide2 {
cloudinit {
storage = "local-lvm"
}
}
}
}

network {
id = 0
bridge = "vmbr0"
model = "virtio"
}
}

В целом на этом всё. Строчки из последнего файла можно копировать неограниченное число раз, изменяя имя и параметры под себя.

Для запуска всего этого нам нужно установить Terraform на ваш ПК, откуда будет управляться кластер. Документация для установки под различные ОС находится вот тут.

После установки и написания файлов вводим следующие команды:

  1. terraform init – установка и инициализация провайдера
  2. terrafrom plan – планирование инфраструктуры (в терминале покажет, какие ресурсы будут созданы)
  3. terrafrom apply – создание ВМ (вылезет запрос, нужно написать yes)

Terraform считает ваши файлы, клонирует template, введёт прописанные параметры и запустит ВМ. А к ней уже можно подключаться через ssh, используя ранее указанный в файлах ключ.

Заключение, планы, рекомендации

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

Для подготовки этой статьи были использованы следующие ресурсы: