# Шаблони VM і cloud-init у Proxmox VE: швидкий деплой

> Як створити шаблон VM у Proxmox VE на основі cloud-init: підготовка образу, налаштування мережі і SSH-ключів, клонування через API.

## Що таке шаблон VM і навіщо потрібен cloud-init

Шаблон у Proxmox VE — це заготовка віртуальної машини, з якої можна швидко клонувати нові VM без повторного встановлення операційної системи. Cloud-init — стандарт налаштування хмарних образів під час першого старту: він задає ім'я хоста, мережу, користувача і SSH-ключ ще до того, як система повністю завантажиться.

Разом шаблон і cloud-init перетворюють розгортання сервера на операцію на хвилину: клонували шаблон, передали параметри мережі і ключа, запустили VM — вона сама сконфігурується під час першого завантаження. Це особливо корисно під час масового створення [віртуальних машин](https://www.zevshost.net/uk/kb/proxmox-vm-sozdat/) з однаковою базовою конфігурацією.

## Як підготувати хмарний образ під шаблон

Для шаблону використовується не звичайний ISO, а готовий хмарний образ дистрибутива у форматі qcow2 — він вже містить агент cloud-init і не потребує ручного встановлення через інсталятор.

```
wget https://cloud-images.ubuntu.com/noble/current/noble-server-cloudimg-amd64.img
qm create 9000 --name ubuntu-24-04-template --memory 2048 --cores 2 --net0 virtio,bridge=vmbr0
```

Номер 9000 умовний: як ID шаблонів зручно резервувати діапазон 9000-9999, щоб не плутати їх із робочими VM. Назву варто одразу зробити зрозумілою, наприклад із версією дистрибутива.

## Як створити шаблон із VM у Proxmox VE

Після створення VM у неї імпортують завантажений диск і підключають окремий пристрій cloud-init, який зберігає параметри першого запуску.

```
qm importdisk 9000 noble-server-cloudimg-amd64.img local-zfs
qm set 9000 --scsihw virtio-scsi-pci --scsi0 local-zfs:vm-9000-disk-0
qm set 9000 --ide2 local-zfs:cloudinit
qm set 9000 --boot c --bootdisk scsi0
qm set 9000 --serial0 socket --vga serial0
qm template 9000
```

Остання команда `qm template 9000` перетворює звичайну VM на шаблон: диск переводиться в режим лише для читання, а сама VM зникає зі списку тих, що можна запускати — тепер вона слугує джерелом для клонів.

## Налаштування cloud-init: користувач, SSH-ключ, мережа

Параметри першого запуску задаються на вкладці Cloud-Init картки VM або через CLI ще до перетворення VM на шаблон.

| Параметр | Призначення |
| --- | --- |
| User | ім'я облікового запису, яке буде створено в системі |
| SSH public key | публічний ключ для входу без пароля |
| IP Config | статичний IP або DHCP для мережевого інтерфейсу |
| DNS domain/servers | домен пошуку і адреси DNS-серверів |

Якщо задати користувача і ключ на рівні шаблону, кожен клон отримає однакові стартові дані, а конкретну IP-адресу зручніше перевизначати вже після клонування — під конкретний сервер.

## Клонування VM із шаблону: пов'язані і повні клони

Із шаблону можна зробити два типи клонів: пов'язаний (linked clone) і повний (full clone). Пов'язаний клон зберігає лише різницю з диском шаблону і створюється майже миттєво, але залежить від вихідного шаблону і потребує сховище з підтримкою такого режиму. Повний клон копіює весь диск цілком і не залежить від шаблону після створення.

```
qm clone 9000 201 --name web-01 --full
```

Детальніше про різницю між знімками і клонами, а також про те, коли пов'язаний клон небезпечніший за повний, розказано у статті про [знімки і клонування VM](https://www.zevshost.net/uk/kb/proxmox-snapshot-clone/).

## Автоматизація масового розгортання через API

Клонування і налаштування cloud-init зручно викликати скриптом, якщо сервери розгортаються регулярно: параметри IP, імені і ключа можна передати одразу після клонування однією командою.

```
qm clone 9000 202 --name web-02 --full
qm set 202 --ipconfig0 ip=10.0.0.22/24,gw=10.0.0.1
qm set 202 --sshkeys ~/.ssh/deploy_key.pub
qm start 202
```

Той самий результат досягається через REST API без консолі вузла — це зручно для CI/CD і зовнішніх систем оркестрації. Подробиці викликів і авторизації через токен описані у статті про [REST API і автоматизацію Proxmox VE](https://www.zevshost.net/uk/kb/proxmox-api-automation/).

## Чек-лист перед використанням шаблону в продакшені

- Образ базується на офіційному хмарному дистрибутиві з підтримкою cloud-init.
- ID шаблонів винесено в окремий діапазон і не перетинається з робочими VM.
- SSH-ключ у шаблоні веде на обліковий запис, до якого немає доступу у сторонніх.
- Свідомо обрано тип клону: пов'язаний для швидкості, повний для незалежності від шаблону.
- Процес клонування і налаштування мережі перевірено на тестовому сервері перед масовим запуском.

Після перевірки шаблон можна сміливо використовувати для повторюваного розгортання серверів однакової конфігурації без ручного встановлення ОС на кожній машині.

## Часті питання

### Який тип клону краще обрати для робочого сервера — пов'язаний чи повний?

Пов'язаний клон створюється майже миттєво і зберігає лише різницю з диском шаблону, але назавжди залежить від нього і потребує сховище з відповідною підтримкою — тому він добре підходить для тестових і тимчасових машин. Повний клон копіює весь диск цілком і після створення вже не пов'язаний із шаблоном, що робить його надійнішим для серверів, які мають працювати незалежно і довго.

### Що станеться, якщо задати конкретну IP-адресу вже на рівні самого шаблону?

Якщо задати статичну IP прямо в шаблоні, кожен клон, створений із нього, під час запуску намагатиметься використати ту саму адресу, що призведе до конфлікту в мережі. Тому мережеві параметри зручніше перевизначати вже після клонування — для кожного нового сервера окремо, а на рівні шаблону задають лише спільні для всіх клонів дані, такі як користувач і SSH-ключ.

### Чи підійде звичайний інсталяційний ISO-образ замість хмарного для створення шаблону?

Немає сенсу: звичайний інсталяційний ISO не містить агента cloud-init і потребує повноцінного встановлення системи через інсталятор із ручним вибором параметрів. Увесь сенс підходу із шаблонами — у готовому хмарному образі, який вже вміє налаштовуватися автоматично під час першого запуску, тому для швидкого масового розгортання застосовують саме його, а не класичний інсталяційний диск.

### Навіщо шаблонам зазвичай виділяють окремий діапазон ID, а не нумерують разом із робочими VM?

Окремий діапазон ID усуває плутанину між шаблонами і робочими серверами: без нього легко випадково запустити, змінити чи видалити сам шаблон, думаючи, що це звичайна віртуальна машина. Якщо номери шаблонів візуально виділені, адміністратор одразу бачить, з чим має справу, і ризик зачепити джерело клонів помилково помітно знижується.

---

Джерело: https://www.zevshost.net/uk/kb/proxmox-shablony-cloud-init/