Забываем про ручное создание ВМ: как автоматизировать Proxmox с Terraform

[M_AJ]

Для читателя, которыы после прочтения уже готов бежать внедрить замечу, что Терраформ провайдер для Проксмокса ещё год назад был крайне сырым. Прежде чем начать внедрять у себя, стоит хотя бы бегло ознакомится с issues на Гитхабе. Возможно окажется, что в вашем конкретном случае будет проще самостоятельно дёргать API

[YuriyShakhov]

Спасибо за дополнение! Согласен, что при выборе любого инструмента стоит изучить GitHub Issues. 

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

[trublast]

Лет 5 назад пользовался провайдером tf для proxmox, было терпимо. Провайдер виртуалки нарезал, диски ширил, даже мигрировал между гиперами. Были некоторые моменты, связанные с тем, что кластер из Проксмоксов - не совсем "кластер", а все же набор гиперов, между которыми виртуалочки нужно переносить. Несколько мешала эта "прибитость" машины к гиперу. Если я через UI мигрировал виртуалку, то тераформ надо было править, и стейт синкать.
Но с тех пор проксмокс развился, появились ресурс пулы и SDN. Так что "ну почти VSphere для бедных". Или для гиков. Ну и попроще, чем openstack.

[berendiaev]

Затверждаю, тф провайдер проксмокса это просто кошмар!

Последний раз, когда приходилось к нему прибегнуть - я прямо пару часов потратил для того, чтобы найти версию, в которой починен один из старых багов и ещё не внедрён новый - и это оказалась одна из rc версий!.

Но, без терраформа с проксмоксом работать - мучение, т.к. создание ВМ из темплейта с пробросом клауд-инита без терраформа совсем неудобное. Потому что проксмокс весьма своеобразно работает с клауд инитом.

[vokrob]

Хороший туториал, но в 2026 всерьёз обсуждать Telmate-провайдер, почти не акцентируя его баги и ограничения, выглядит как реклама, а не продакшен-опыт

[JuriM]

Других альтернативных модулей почему-то нет, приходится использовать этот. И баги фиксятся, хоть и медленно.

[vokrob]

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

[JuriM]

Рынок вообщето огромный, но с модулями у тф всегда какаято беда

[OSPF]

"bpg/proxmox" гораздо лучшее

[JuriM]

Есть способ заставить тф игнорировать отдельные поля при tf plan, без указания target вручную? Есть большой риск что модуль просто пересоздаст виртуалку с нуля.

Есть ли опыт миграции уже существующих виртуалок в тф, без риска пересоздания виртуалок модулем?

[YuriyShakhov]

Есть способ заставить тф игнорировать отдельные поля при tf plan, без указания target вручную? Есть большой риск что модуль просто пересоздаст виртуалку с нуля.

Для игнорирования полей можно использовать ignore_changes. Например, если нужно игнорировать изменение IP:
lifecycle {
ignore_changes = [
ipconfig0
]
}

Также можно использовать prevent_destroy, в блоке lifecycle, чтобы гарантировать, что ресурс не будет пересоздан.

Есть ли опыт миграции уже существующих виртуалок в тф, без риска пересоздания виртуалок модулем?

Лично я не пробовал это делать, однако в Terraform есть возможность использовать блок import и затем выполнить команду:

terraform plan -generate-config-out="generated_resources.tf"

[trublast]

Мы же Кубернетес там на виртуалочках запускаем? Тогда может сразу сюда https://github.com/k8s-proxmox/cloud-provider-proxmox ?

[berendiaev]

Ну а капи менеджмент кластер тоже чем-то надо поднять?

[trublast]

Ну не обязательно тераформом. Зачем нужен какой-то кусок кластера, который менеджится не так, как остальные ноды?

Это может быть какая-то виртуалка в облаке, которая потом уничтожается. Или докер -контейнер на машине того, кто проводит инсталляцию. Или бинарь/скрипт, который дёргает ручки api до того момента, когда кластер поднимется, и начнет дергать ручки сам