CloudMonkey (cmk) на практиці: Apache CloudStack з термінала

Блог WebDisk · категорія: Публічна хмара · час читання: ~17 хвилин

Коротко:- cmk (CloudMonkey) — це офіційний клієнт командного рядка Apache CloudStack, платформи, на якій працює WebDisk Cloud. Панель і cmk викликають той самий API з тими самими правами; термінал додає повторюваність і запис в історії, панель виграє біля консолі машини та під час першого огляду.- Налаштування — це один профіль і пара ключів API з панелі; першу осмислену команду (list virtualmachines) виконаєте за кілька хвилин, а результат у JSON або CSV іде просто до скрипта чи таблиці.- Чесно: cmk не є інфраструктурою як кодом — він не знає цільового стану й не скасує змін. Опис середовища в репозиторії — це Terraform або Ansible; cmk призначений для запитів, разових операцій і швидкої автоматизації. >Не працюєте з терміналом? Пропустіть блоки команд — опис платформи, порівняння методів керування та розділ про межі інструмента читаються без них.

П'ятниця, 17:40. До вимкнення на вихідні лишилося двадцять чотири тестові машини — у панелі це двадцять чотири рази та сама послідовність: знайди, подробиці, меню, «Stop», підтвердь. У понеділок те саме у зворотний бік, тільки що дві машини хтось прогледить, і вони пропрацюють цілі вихідні. Ніхто не помилився — інструмент для перегляду й ухвалення рішень використали для конвеєрної роботи.

Показуємо тут другий шлях: керування хмарою з термінала — від будови API CloudStack, через cmk від встановлення до скриптів і пасток, аж до чесних меж інструмента та огляду живих клієнтів. Приклади виконаєте на будь-якому CloudStack, зокрема в публічній хмарі WebDisk — набір команд залежить від ролі вашого облікового запису та від послуг оператора.

Що таке Apache CloudStack і що з цієї архітектури бачить клієнт

CloudStack — це оркестратор IaaS, а не гіпервізор. Сам він нічого не віртуалізує — керує гіпервізорами (програмним забезпеченням, яке запускає віртуальні машини на фізичному сервері): KVM, VMware vSphere, XenServer/XCP-ng. Він додає шар, якого гіпервізори не мають: мультиорендність, мережі, сховище, облік споживання та єдиний API. Ліцензія Apache 2.0, повноправний проєкт фонду Apache з березня 2013 року — без копілефту, без «open core» одного виробника.

Усередині платформа ієрархічна: регіон → зона → под → кластер → хост. Клієнт бачить із цієї драбини один щабель — зону (zone), зазвичай один центр обробки даних. Поди, кластери й хости бачить лише адміністратор оператора, і це навмисно: ви не обираєте сервер, на якому опиниться машина.

Primary storage — первинне сховище — тримає томи машин, запущених і зупинених, і стоїть близько до хостів. Secondary storage, вторинне сховище, є ресурсом цілої зони: шаблони, образи ISO, знімки. Тому створення знімка (snapshot) тому триває — дані мандрують між сховищами, — а перший запуск машини зі щойно зареєстрованого шаблону повільніший за наступні.

Три типи системних машин, з якими клієнт стикається щодня, працюють у фоні, і ніхто їх не замовляє. SSVM обслуговує secondary storage. Console Proxy посередничає між браузером і консоллю машини — завдяки йому в панелі працює «Консоль». Virtual Router, віртуальний маршрутизатор, реалізує мережеві послуги: DHCP, DNS, source NAT, static NAT, перенаправлення портів, балансування навантаження, брандмауер і правила ACL, VPN та кінцеву точку метаданих для cloud-init. Архітектурно це важливо: NAT, перенаправлення портів і балансування навантаження не є окремими сутностями — ви керуєте ними тим самим API, що й машинами. Як вони тарифікуються, перевірите у прейскуранті оператора.

Остання річ, яка дивує в CLI: власником ресурсів є обліковий запис, а не користувач. Користувачі — це способи входу; ліміти, розрахунки і власність сидять поверхом вище. Окремим контейнером є проєкти — з власними лімітами та споживанням, в API доступні через параметр projectid. Якщо в панелі ви працюєте в контексті проєкту, а в терміналі не подасте projectid, побачите інший набір машин. WebDisk Cloud працює на CloudStack і KVM — про переїзд із vSphere ми писали з нагоди міграції з VMware до WebDisk Cloud.

Панель, API, CLI та IaC — чотири форми того самого доступу

Усе, що ви робите з CloudStack, проходить через одну кінцеву точку: шлях /client/api на сервері керування. Запит — це звичайний HTTP GET або POST із параметром command; відповідь типово в XML, а після додавання response=json — у JSON. Автентифікує підпис HMAC-SHA1, обчислений секретним ключем на відсортованому й переведеному в нижній регістр рядку параметрів. Решта інструментів із цієї статті — надбудови над тим самим.

Назви команд послідовні: дієслово + іменник — deployVirtualMachine, listVirtualMachines, stopVirtualMachine, createNetwork, associateIpAddress, deleteSnapshot. Команд майже дев'ятсот (знімок API в cmk 6.5.0 знає їх 880, з них 370 асинхронних), але звичайний обліковий запис побачить помітно менше — список залежить від ролі та версії платформи. Схема настільки регулярна, що після дня роботи ці назви вгадуються правильно. Дві речі варто знати від початку: частина команд асинхронна — повертає негайно ідентифікатор завдання (jobid), а не результат; і ключ API успадковує права ролі облікового запису, тож CLI не є бічним входом із більшими правами.

Найважливіше: графічний інтерфейс не має привілейованого каналу до платформи. Панель — хоч би яка — це звичайний клієнт того самого /client/api, а список функцій вона відкриває командою listApis; та сама команда живить автодоповнення в cmk. Висновок буває протилежним до інтуїції: нова можливість платформи потрапляє в API раніше, ніж отримує власну форму.

Звідси чотири методи керування — не рівні складності, а форми того самого доступу:

• Панель — наочність і контекст. Випадні списки розв'язують за вас UUID-и, форми стежать за порядком залежностей, а консоль машини є практично тільки тут. Не масштабується й не залишає процедури.
• Сирий API — повний контроль, нуль залежностей. Сам підпис — це кілька десятків рядків коду; ціною є решта: пагінація, асинхронні завдання, обсяг видимості, кодування структурних параметрів.
• CLI (cmk і споріднені) — повторюваність без написання клієнта; історія команд є безплатним журналом того, що сталося.
• IaC (Terraform, Ansible) — цільовий стан у репозиторії, огляд змін у pull request, відтворення середовища з нуля.

Варто знати два механізми платформи. Оператор може ввімкнути обмеження кількості викликів API — скрипт, який опитує сервер у циклі, здатен його вичерпати. Новіші випуски CloudStack мають вебхуки: платформа сама надсилає HTTP-сповіщення при подіях на кшталт зміни стану машини, тож інтеграція не мусить покладатися на опитування.

Що таке cmk і чому «cloudmonkey» означає сьогодні два різні інструменти

Це перша перешкода, на якій люди втрачають годину: два інструменти носять ту саму назву. Старший, cloudmonkey, написаний на Python і встановлюється через pip. Новіший, cmk, — це переписаний з нуля порт мовою Go: єдиний виконуваний файл, сумісний із CloudStack від версії 4.9 і вище.

Python-версію сьогодні встановлювати не варто: останній випуск на PyPI — це 5.3.3.1 від 13 жовтня 2021 року, майже п'ять років тиші. Ніхто не оголошував кінця підтримки, але опис пакета сам відсилає до версії мовою Go. Актуальний випуск cmk — це 6.5.0 від 26 серпня 2025 року (станом на серпень 2026); гілка розробки жива, але випуски виходять рідко.

Під час переписування на Go зникли: формат виводу XML, журналювання запитів у файл і розфарбовування результату. Натомість є один файл без залежностей — також для Windows — і каталог конфігурації ~/.cmk, навмисно інший, ніж у старій версії. Надсилання запитів методом POST з'явилося для пароля й даних користувача у 6.4.0, а 6.5.0 узагальнила його на всі запити та ввімкнула типово (postrequest). Додалися також запит коду двофакторної автентифікації, надсилання шаблонів та ISO і зворотна фільтрація параметром exclude=.

Як налаштувати cmk за п'ять хвилин?

Найпростіший шлях — завантажити бінарний файл із випусків проєкту. Є також формула Homebrew (brew install cloudmonkey, команда називається cmk), пакет snap і образ контейнера — у CI завжди закріплюйте конкретний тег, бо latest на Docker Hub стоїть неактуальний уже роками.

# Linux x86-64: завантажте до робочого каталогу, перевірте, і аж потім встановлюйте
curl -fsSLO https://github.com/apache/cloudstack-cloudmonkey/releases/download/6.5.0/cmk.linux.x86-64
sha256sum cmk.linux.x86-64
sudo install -m 0755 cmk.linux.x86-64 /usr/local/bin/cmk
cmk version

Контрольні суми SHA-256 (і MD5) кожного файлу проєкт публікує в примітках до випуску — порівняйте з ними результат sha256sum, перш ніж надасте файлу права на виконання і впустите його до системного каталогу. Це бінарний файл, який за мить отримає ваші ключі API. Перевірте принагідно на сторінці випусків, чи немає чогось новішого за 6.5.0 — номер версії вбудований в адресу завантаження.

Ключі API ви генеруєте самостійно — пару «ключ API + секретний ключ» і адресу кінцевої точки API знайдете в панелі WebDisk Cloud, у налаштуваннях користувача. Секретний ключ — це пароль: хто його має, може у вашій хмарі те саме, що й ви — ми вже писали, чому довговічні статичні ключі є проблемою.

Конфігурацію задавайте командами, а не текстовим редактором — чому саме, пояснює перша пастка.

cmk set profile moja-chmura # створює і вмикає профіль із цією назвою
cmk set url <АДРЕСА-КІНЦЕВОЇ-ТОЧКИ-API> # зазвичай закінчується на /client/api
cmk set apikey <ВАШ-КЛЮЧ-API>
cmk set secretkey <ВАШ-СЕКРЕТНИЙ-КЛЮЧ>
cmk set output json # json | table | text | column | csv | default
cmk sync # завантажує список API із сервера

Одне застереження: cmk зберігає обидва ключі відкритим текстом у ~/.cmk/, тож цей каталог ніколи не потрапляє ані до репозиторію, ані до образу контейнера — допишіть його до .gitignore. Решту наслідків, разом із ротацією ключа, збирає шоста пастка.

cmk sync — це не косметика: він будує локальний кеш команд, звідки беруться автодоповнення, список параметрів і знання про те, які команди асинхронні. Кеш окремий для кожного профілю, тож після додавання другої хмари зробіть sync і там. Перший тест:

cmk list zones filter=id,name,networktype
cmk list virtualmachines listall=true filter=name,state,zonename

Без аргументів cmk запускає інтерактивну оболонку: історія, пошук назад через Ctrl+r, автодоповнення по Tab. Tab на параметрі, що закінчується на id=, виконує реальний запит до сервера й підказує UUID-и з назвами ресурсів — зручно під час навчання, варте вимкнення (set autocomplete false) у великому середовищі.

Як запустити віртуальну машину однією низкою команд?

У CloudStack усе ідентифікують UUID-и, тож робота починається з розвідки. Нижче — повний шлях: чотири запити, ключ SSH, машина, публічна адреса, правило доступу.

# 1. Розвідка середовища — звідси берете чотири ідентифікатори
cmk list zones filter=id,name
cmk list serviceofferings filter=id,name,cpunumber,memory
cmk list templates templatefilter=executable zoneid=<ZONE-UUID> filter=id,name,ostypename
cmk list networks zoneid=<ZONE-UUID> filter=id,name,type,cidr

Параметр templatefilter у listTemplates обов'язковий — executable означає «шаблони, з яких я можу запустити машину».

# 2. Реєстрація публічного ключа SSH (@ зчитує вміст файлу)
cmk register sshkeypair name=laptop publickey=@/home/korystuvach/.ssh/id_ed25519.pub

# 3. Запуск машини; userdata має бути закодована в base64 — cmk не робить цього за вас
cmk deploy virtualmachine \
  name=web-01 displayname=web-01 \
  serviceofferingid=<SO-UUID> \
  templateid=<TPL-UUID> \
  zoneid=<ZONE-UUID> \
  networkids=<NET-UUID> \
  keypair=laptop \
  userdata=$(base64 -w0 cloud-init.yaml) \
  startvm=true

Зверніть увагу на розширення .pub: ви надсилаєте публічний ключ, приватний ніколи не покидає вашої машини. І друге зауваження: вміст cloud-init.yaml опиняється в аргументах процесу та в історії оболонки, тож паролі й токени передавайте механізмом цільової системи, а не файлом у командному рядку.

Обов'язковість параметрів deployVirtualMachine змінювалася між випусками: від CloudStack 4.21 обов'язкові лише serviceofferingid і zoneid (додалися volumeid і snapshotid, тож машину відтворите також із тому або знімка), у 4.20 і старших templateid обов'язковий. У своїй хмарі перевірите це командою cmk deploy virtualmachine -h — вона випише опис і список полів просто з сервера.

# 4. Публічна IP-адреса і доступ по SSH тільки з офісу
cmk associate ipaddress zoneid=<ZONE-UUID> networkid=<NET-UUID>

cmk create portforwardingrule ipaddressid=<IP-UUID> protocol=TCP \
  publicport=22 privateport=22 virtualmachineid=<VM-UUID> \
  networkid=<NET-UUID> openfirewall=false

cmk create firewallrule ipaddressid=<IP-UUID> protocol=TCP \
  startport=22 endport=22 cidrlist=203.0.113.10/32

Налаштування openfirewall=false є свідомим: правило брандмауера ви додаєте окремо, з конкретним списком адрес джерела, замість відкривати порт для всього інтернету. Готову машину варто одразу оснастити watchdog-ом — теж кілька команд, тільки що всередині системи.

Решта життєвого циклу виглядає так, як підказує інтуїція дієслово + іменник:

cmk stop virtualmachine id=<VM-UUID>
cmk start virtualmachine id=<VM-UUID>
cmk reboot virtualmachine id=<VM-UUID>
cmk scale virtualmachine id=<VM-UUID> serviceofferingid=<НОВИЙ-SO-UUID>
cmk change serviceforvirtualmachine id=<VM-UUID> serviceofferingid=<НОВИЙ-SO-UUID>
cmk create snapshot volumeid=<VOL-UUID> name=pered-onovlenniam quiescevm=true
cmk destroy virtualmachine id=<VM-UUID> expunge=true

scale virtualmachine стосується запущеної машини, change serviceforvirtualmachine — зупиненої; доступність обох залежить від гіпервізора й від оператора.

Команда повернула jobid. Як дочекатися кінця операції?

Більшість команд, які змінюють стан, асинхронні: сервер віддає ідентифікатор завдання й працює у фоні. Статус завдання має три значення: 0 — у процесі, 1 — успіх, 2 — помилка.

Типово cmk бере це на себе: налаштування asyncblock увімкнене, тож інструмент сам опитує сервер кожні дві секунди й показує лише кінцевий результат — готовий об'єкт машини замість сирого jobid. Ліміт часу дає налаштування timeout (типово 1800 секунд); після його перевищення отримаєте async API job query timed out.

Іноді хочеться навпаки: вистрелити операцію і не чекати.

cmk set asyncblock false
cmk deploy virtualmachine ... # повертає одразу ідентифікатор завдання
cmk query asyncjobresult jobid=<JOB-UUID> filter=jobstatus,jobresultcode

Це також відповідь на класичну помилку початківця: скрипт, який відразу після deploy virtualmachine налаштовує правило NAT і отримує помилку, бо машини ще немає. За asyncblock=true проблема зникає; із власним HTTP-клієнтом цикл опитування пишете самі.

Як зробити з cmk інструмент для звітів і скриптів

Два механізми перетворюють CLI на джерело даних. Перший — це filter=, список полів, які лишаються в результаті, та зворотний до нього exclude= (фільтрація локальна, подробиці в п'ятій пастці). Другий — це формат виводу: глобально через set output, одноразово прапорцем -o.

# Звіт до таблиці: усі машини облікового запису, вибрані стовпці, формат CSV
cmk -o csv list virtualmachines listall=true \
    filter=name,state,zonename,cpunumber,memory > mashyny.csv

# Те саме для подальшого обробляння в jq
cmk -o json list virtualmachines listall=true \
  | jq -r '.virtualmachine[] | [.name, .state, .zonename] | @tsv'

Параметр listall=true означає «покажи все, що мені дозволено бачити»; без нього бачите лише власні ресурси. П'ятничний конвеєр із початку статті виглядає так:

#!/usr/bin/env bash
# Зупинка всіх запущених машин, назва яких містить "test"
set -euo pipefail # помилка cmk потрапляє на stdout, а не в JSON — звідси pipefail

ids=$(cmk -o json list virtualmachines listall=true state=Running keyword=test \
      | jq -r '.virtualmachine[].id')

for id in ${ids}; do
  printf 'зупиняю %s ... ' "${id}"
  if cmk stop virtualmachine id="${id}" >/dev/null; then
    echo "ok"
  else
    echo "ПОМИЛКА" >&2
  fi
done

Перш ніж запустите цикл, огляньте сам список ідентифікаторів: keyword зіставляє фрагмент назви, тож test спіймає також latest-api чи protest-db — а це вже скрипт, який зупиняє чужі машини. Безпечніше фільтрувати за тегом (tags), ніж за назвою, а перший запуск зробити з echo перед cmk stop. Дві речі зроблено навмисно: фільтрація на боці сервера (state=Running keyword=test) замість у jq, бо тоді сервер не надсилає даних, яких ви й так не використаєте, та перевірка коду виходу замість поля errortext — причина й застереження у другій пастці.

Шість пасток cmk, яких немає в офіційній документації

1. Не пишіть ~/.cmk/config вручну. Це найдорожча помилка. Глобальні налаштування cmk тримає в безіменному блоці на початку файлу, без заголовка. Дописана з добрим наміром секція [core] не є глобальною — вона потрапляє до списку профілів серверів. Наслідки неочевидні: timeout дорівнює тоді нулю, тож кожне асинхронне завдання закінчується повідомленням async API job query timed out, а порожня назва профілю дає failed to authenticate to make API call попри правильні ключі. Ліки: задавайте все через cmk set ... і видаліть дописані секції.

2. Помилки потрапляють на стандартний вивід і не є JSON-ом. Невдалий виклик друкує звичайний текст і завершує процес кодом 1 — скрипт, який шукає поле errortext, не знайде його ніколи. Туди ж іде вивід прапорця -d, тож cmk -d ... | jq завжди впаде. Є один болісний виняток: коли cmk відкидає команду власною валідацією (повідомлення Missing required parameters), він завершується кодом 0. Друкарська помилка в назві параметра або застарілий кеш дають скрипт, який рапортує «ок», хоча не зробив нічого. Тому при критичних операціях перевіряйте не лише код виходу, а й те, чи відповідь є JSON-ом.

3. set profile з друкарською помилкою тихо створює новий профіль — із типовою адресою localhost і даними admin/password — і перемикається на нього, що дає серію незрозумілих помилок з'єднання. Команда switch profile, яка перемикає лише на наявні профілі, чекає в гілці розробки, і в 6.5.0 її немає.

4. Валідація параметрів відбувається на боці клієнта, з кешу. Без sync cmk користується вбудованим знімком списку API — у 6.5.0 він відповідає випуску 4.21 CloudStack, версії зашитій в інструмент, а не версії вашої хмари — і просить тоді на діагностичному виводі зробити sync. Застарілий кеш здатен заблокувати правильний виклик повідомленням Missing required parameters або відповісти unknown command or API requested на наявну команду. Після кожного оновлення хмари робіть cmk sync.

5. filter= фільтрує локально. Він не зменшує ані трафіку, ані навантаження сервера, не підтримує вкладених шляхів, а поданий разом із exclude= знецінює той другий. Немає також автоматичної пагінації: page і pagesize подають разом, а наступні сторінки збирає ваш скрипт.

6. Секрети лежать у файлах відкритим текстом. set apikey і set secretkey записують значення до ~/.cmk/config, а введені в інтерактивній оболонці cmk — також до ~/.cmk/history. Від 6.5.0 обидва файли мають права 0600, але вміст лишається читабельним і мандрує до кожної копії домашнього каталогу. Ключі, подані прапорцями -k/-s, видно додатково в історії оболонки й у списку процесів — очистіть такий запис або поставте перед командою пробіл, коли маєте ввімкнене HISTCONTROL=ignorespace. Ключ, який витік, ви скасовуєте, згенерувавши новий у панелі — старий тоді перестає працювати; робіть це без вагань за кожної підозри: зміни ноутбука, відходу людини з команди, випадкового коміту. За помилки перевірки сертифіката не вимикайте її налаштуванням verifycert — полагодьте довіру до центру сертифікації; без неї ваші ключі можна перехопити на льоту. І дрібниця: cmk підписує запит параметром expires, встановленим на п'ятнадцять хвилин уперед (signatureversion=3), тож розлагоджений годинник дає помилку автентифікації, яка виглядає як поганий ключ — перевірте час, перш ніж генерувати нові ключі.

Коли термінал є поганою ідеєю і чого cmk не вирішить

Без вивертів: буває, що CLI повільніший і ризикованіший за клацання.

• Дослідницька робота. Питання «що я тут узагалі маю?» — це в панелі один погляд на список зі статусами; у терміналі — три запити й мружіння очей.
• Одна операція, виконувана раз. Налаштування профілю й пошук трьох UUID-ів триває довше за п'ять клацань.
• Консоль машини. Жоден термінал її не відрендерить — хоча cmk create consoleendpoint virtualmachineid=<VM-UUID> поверне адресу для відкриття в браузері. Зіпсований fstab, через який система не піднімається, ви й так полагодите лише у вікні консолі.
• Незворотні операції. destroy virtualmachine ... expunge=true не спитає «точно?». Панель спитає.
• Складні конструкції із залежностями. За VPC з кількома шарами, списками ACL і тунелем VPN форма змушує дотримати правильного порядку; CLI дозволить збудувати це неправильно, і ви дізнаєтеся про це пізніше.
• Середовище, яке має бути відтворюваним. Тут відповіддю є Terraform або Ansible: cmk виконує команди, а не утримує декларацію. Цей шлях ми описали окремо — керування CloudStack за допомогою Terraform, від налаштування провайдера до кластера Kubernetes з коду. Скрипт на bash, який «майже» є інфраструктурою як кодом, — це найгірший із можливих світів.

Є також межа з нашого боку: роль клієнтського облікового запису не охоплює адміністративних команд оператора. Хостів, пулів адрес, пропозицій послуг (service offerings) ані параметрів зони ви не побачите через API — тут лишається звернення до нас, і жодне CLI цього не скоротить.

І межа обсягу: cmk керує ресурсами платформи — машинами, томами, мережами, адресами, шаблонами — але не даними в них. Об'єктним сховищем, сумісним із S3, ви керуєте інструментами екосистеми S3 (aws CLI, rclone, s5cmd), а не CloudMonkey. Нутрощі операційної системи — це завдання для cloud-init та Ansible.

Чим ще керують CloudStack-ом? Стан екосистеми на серпень 2026

cmk є референсним клієнтом, але не єдиним. Дати походять із репозиторіїв і реєстрів пакетів, бо в цій екосистемі «існує» і «підтримується» — це дві різні речі:

• cs (Python) — бібліотека і CLI в одному, конфігурація в ~/.cloudstack.ini, сама обробляє асинхронні завдання. Типовий вибір для скриптів на Python; випуск від червня 2026 року. Тверда залежність колекції Ansible.
• cloudstack-cli (Ruby) — операторський інструмент з операціями вищого рівня: машина з правилами перенаправлення однією командою, декларативні «стеки», звіти. Розвивається однією людиною, але регулярно; випуск від квітня 2026 року.
• apache/cloudstack-go — офіційний SDK мовою Go і фундамент решти екосистеми (провайдер Terraform, контролери Kubernetes), найживіша з бібліотек. Архівного xanzy/go-cloudstack у новому коді не використовуйте.
• Apache Libcloud (Python) — коли код має бути переносним між CloudStack та іншими хмарами. Абстракція, однак, губить специфіку платформи: проєкти, домени, VPC, пропозиції послуг.
• Java, PHP, Node.js, .NET — прямо: живих клієнтів немає. Jclouds потрапив до архіву Apache у 2025 році, решта стоїть на комітах багаторічної давнини. Лишається власний тонкий клієнт на сирому API або виклик cmk ззовні.
• Terraform і OpenTofu — провайдер cloudstack/cloudstack, стабільна версія 0.6.0 від жовтня 2025 року (саме в ній з'явилися ресурси кластерів Kubernetes), кандидат 0.7.0-rc1 від серпня 2026 року з міграцією на plugin framework. Розвивається під егідою Apache. Читає конфігураційний файл CloudMonkey, що зручно локально, — але в CI подавайте ключі змінними середовища замість копіювати файл із секретами поруч із кодом.
• Ansible — колекція ngine_io.cloudstack, після року тиші сильно оновлена: випуск 3.0.0 у жовтні 2025 року і три наступні в самому лише серпні 2026 року. Увага: у 3.0.0 модулі втратили префікс cs_. Є також модуль api_request — хвіртка до довільного виклику API без обчислювання підпису.
• Kubernetes — Cluster API Provider CloudStack для декларативного створення кластерів, cloud controller manager для балансувальників навантаження й міток вузлів, драйвер CSI для постійних томів. Останній є проєктом спільноти, а не фонду Apache — на відміну від apache/cloudstack-go.
• Packer і Vagrant — чесне попередження: плагін Packer стоїть на випуску 2022 року, плагін Vagrant покинутий від 2019 року. Образ зберіть чим завгодно іншим і зареєструйте командою register template.
• Pulumi — рідного провайдера немає, і ніщо на це не вказує; єдиний шлях — це міст до провайдера Terraform.

Найчастіші запитання

Що таке cmk і чим він відрізняється від старого cloudmonkey? Це два покоління того самого інструмента. cloudmonkey на Python, встановлюваний через pip, не має випуску від 13 жовтня 2021 року, а опис пакета сам відсилає до наступника. cmk — це порт мовою Go, який поширюється як єдиний бінарний файл, актуальна версія 6.5.0. Вони мають окремі каталоги конфігурації (~/.cmk), тож можуть співіснувати — але нові впровадження робіть виключно на cmk.

Звідки взяти ключ API і секретний ключ до WebDisk Cloud? Згенеруєте їх самостійно в панелі WebDisk Cloud, у налаштуваннях свого користувача. Там само знайдете адресу кінцевої точки API, яку вписуєте до профілю cmk. Ключі мають рівно ті права, які має ваш обліковий запис.

Як користуватися cmk у CI, не залишаючи ключів у файлі? Ключ і секрет тримайте у захищених і замаскованих змінних своєї системи CI, а каталог ~/.cmk/ допишіть до .gitignore і ніколи не пакуйте його до образу контейнера. Для автоматики заведіть окремий обліковий запис або окремий проєкт із мінімальною роллю — ключ не має вужчих прав, ніж обліковий запис, до якого належить. Образ контейнера з cmk закріпіть на конкретному тегу; latest на Docker Hub має вже кілька років.

Які параметри обов'язкові в deploy virtualmachine? Від CloudStack 4.21 формально лише serviceofferingid і zoneid — шаблон став необов'язковим, бо машину можна відтворити також із тому або знімка. У 4.20 і старших templateid обов'язковий. На практиці подаєте ще networkids, name і keypair. Остаточну відповідь для вашої хмари дає cmk deploy virtualmachine -h, запущене після попереднього cmk sync.

Команда повернула jobid і нічого більше. Що далі? Це означає, що у вас вимкнене asyncblock. Опитайте завдання командою cmk query asyncjobresult jobid=<UUID> і перевірте поле jobstatus: 0 — це робота триває, 1 — успіх, 2 — помилка. Типове set asyncblock true робить так, що cmk чекає за вас і показує лише результат; верхньою межею є тоді set timeout, типово 1800 секунд.

Чи створю через cmk кластер Kubernetes? Так. У WebDisk Cloud послуга кластерів доступна — перевірите це командою cmk list kubernetessupportedversions, а подробиці пропозиції описує сторінка Kubernetes. Формально create kubernetescluster вимагає лише name і zoneid, але на практиці подаєте також kubernetesversionid, serviceofferingid і size; масштабування — це cmk scale kubernetescluster id=<UUID> size=5. Самим кластером зсередини ви керуєте, звісно, через kubectl, а декларативно ззовні — через Cluster API. На інших CloudStack доступність цієї послуги залежить від оператора.

curl, cmk, Terraform чи Ansible — коли який? curl лише тоді, коли зневаджуєте шар підпису або ваша мова не має живого клієнта. cmk — для запитів, разових операцій і швидких скриптів. Ansible — коли налаштовуєте машини імперативно в плейбуках. Terraform — коли середовище має бути описане в репозиторії та відтворюване з нуля. Усі чотири б'ють у ту саму кінцеву точку з тими самими правами — ви обираєте форму роботи, а не рівень доступу.

Почніть з одного запиту

Найдешевший перший крок — це не міграція процесів до скриптів, а одна команда: завантажте бінарний файл, перевірте контрольну суму, задайте профіль, зробіть cmk sync і випишіть свої машини до CSV. За чверть години знатимете, чи термінал пасує до вашого способу роботи — а п'ятничний конвеєр перетвориться на цикл із цієї статті, який можна переглянути в репозиторії та запустити з планувальника. Панель лишається там, де вона справді добра: біля консолі машини, під час першого огляду й при операціях, які робите раз.

За WebDisk Cloud стоїть Mazura sp. z o.o., суб'єкт польського права: дані залишаються в Європі, а підтримка відповідає польською. Якщо оцінюєте витрати, конфігурації Cloud PAYG починаються від €6 нетто на місяць за Small (2 vCPU, 4 GB RAM, 50 GB NVMe і публічна IP-адреса) — станом на серпень 2026 року, а використання придбаних ресурсів, зокрема пропускної здатності, ми не донараховуємо. Напишіть нам, якщо хочете обговорити сценарій автоматизації.