Repository at ChSTU: Автоматизація розгортання openstack на базі віртуалізації vmware

Please use this identifier to cite or link to this item: https://er.chdtu.edu.ua/handle/ChSTU/10073
Title:	Автоматизація розгортання openstack на базі віртуалізації vmware
Authors:	Рудаков, Костянтин Сергійович Ободовський, Артем Володимирович
Keywords:	автоматизація розгортання, OpenStack, VMware vSphere, VMware ESXi, vCenter, хмарна інфраструктура, віртуалізація, Infrastructure as Code, Packer, Terraform, Ansible, GitLab CI/CD, Ceph, приватна хмара, оркестрація інфраструктури, конфігураційне управління, автоматизоване налаштування, масштабованість, відтворюваність конфігурацій
Issue Date:	Jun-2026
Abstract:	У кваліфікаційній роботі розроблено та реалізовано автоматизоване рішення для розгортання й управління хмарною інфраструктурою на базі платформи OpenStack у середовищі віртуалізації VMware vSphere з використанням розподіленої системи зберігання даних Ceph. Проведено аналіз наявних засобів автоматизації розгортання OpenStack та платформ управління віртуалізацією, обґрунтовано вибір технологій і інструментів для реалізації системи. Розглянуто принципи віртуалізації, інфраструктури як коду та безперервної інтеграції й доставки. Розроблено архітектуру автоматизованого розгортання, що охоплює підготовку образів віртуальних машин за допомогою Packer, створення віртуальних ресурсів із використанням Terraform, конфігурацію сервісів OpenStack засобами Ansible та автоматизацію процесів через GitLab CI/CD. Передбачено інтеграцію основних сервісів OpenStack, зокрема Keystone, Glance, Nova і Neutron, із системою зберігання Ceph. Запропонований підхід забезпечує повторюваність конфігурацій, зменшення кількості ручних операцій, скорочення часу розгортання та спрощення масштабування інфраструктури. Практичне значення роботи полягає у можливості застосування розробленого рішення для автоматизованого створення, налаштування та супроводу приватних хмарних середовищ у корпоративному й державному секторах.
URI:	https://er.chdtu.edu.ua/handle/ChSTU/10073
Appears in Collections:	123 Комп’ютерна інженерія (Спеціалізовані комп’ютерні системи)
Files in This Item:
File	Description	Size	Format
Б_123_2026_Ободовський.pdf Restricted Access		2.06 MB	Adobe PDF	View/Open Request a copy
Show full item record
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ 
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ 
ФАКУЛЬТЕТ ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ І СИСТЕМ 
КАФЕДРА РОБОТОТЕХНІКИ ТА СПЕЦІАЛІЗОВАНИХ 
КОМП’ЮТЕРНИХ СИСТЕМ 
ПОЯСНЮВАЛЬНА ЗАПИСКА 
до кваліфікаційної роботи 
освітнього ступеня «бакалавр» 
Автоматизація ро-згортання OpenStack на базі 
на тему: 
віртуалізації VMware 
 
 
 
 
Виконав здобувач вищої освіти 4 курсу, 
 групи СКС-2207 
 спеціальності 123 Комп’ютерна 
 інженерія 
 Артем ОБОДОВСЬКИЙ 
 (ім’я та ПРІЗВИЩЕ) 
Керівник Костянтин РУДАКОВ 
 (ім’я та ПРІЗВИЩЕ) 
Рецензент  
 (ім’я та ПРІЗВИЩЕ) 
  
Захист дозволяю:   
зав. кафедри, д.т.н., професор   Валентина ЛУКАШЕНКО 
 (підпис)  (ім’я та ПРІЗВИЩЕ) 
 
 
 
Черкаси 2026 
ЗМІСТ 
ПЕРЕЛІК УМОВНИХ СКОРОЧЕНЬ ................................................................ 4 
ВСТУП ................................................................................................................. 6 
ЗАГАЛЬНА ХАРАКТЕРИСТИКА РОБОТИ .................................................... 8 
РОЗДІЛ 1 АНАЛІЗ ІСНУЮЧИХ СИСТЕМ.................................................... 16 
1.1 Огляд аналогів Openstack ....................................................................... 16 
1.2 Огляд аналогів VCenter ........................................................................... 17 
Висновки до першого розділу ...................................................................... 21 
РОЗДІЛ 2 АНАЛІЗ ІНСТРУМЕНТІВ РОЗРОБКИ ТА РЕАЛІЗАЦІЇ 
ПРОГРАМНОГО ПРОДУКТУ ......................................................................... 24 
2.1 Віртуалізація та хостинг: ESXi, vCenter, Ubuntu.................................. 24 
2.2 Система контролю версій GitLab ........................................................... 26 
2.3 Інфраструктура як код ............................................................................. 27 
2.4 CI/CD пайплайни ..................................................................................... 29 
2.5. Сховище................................................................................................... 29 
2.6 Сервіси Openstack.................................................................................... 30 
Висновки до другого розділу ....................................................................... 33 
РОЗДІЛ 3 ОПИС ПРОГРАМНОЇ РЕАЛІЗАЦІЇ .............................................. 35 
3.1 Архітектура та принцип роботи проєкту .............................................. 35 
3.2 Ланцюжок автоматизації......................................................................... 42 
3.3. Ролі та їхня взаємодія ............................................................................. 43 
3.4 Переваги обраного підходу .................................................................... 44 
Висновки до третього розділу ...................................................................... 45 
РОЗДІЛ 4 РОБОТА КОРИСТУВАЧА З ПРОГРАМНОЮ СИСТЕМОЮ .... 47 
2 
Висновки до четвертого розділу .................................................................. 55 
ВИСНОВКИ ....................................................................................................... 57 
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ ......................................................... 59 
Додаток А  Автоматизація розгортання та управління хмарною 
інфраструктурою OpenStack на базі VMware ESXi та vCenter з 
використанням Packer і Ansible (Програмний код) ........................................ 63 
 
3 
ПЕРЕЛІК УМОВНИХ СКОРОЧЕНЬ 
API (Application Programming Interface) – інтерфейс прикладного 
програмування, що забезпечує взаємодію між програмними модулями або 
зовнішніми сервісами. 
Ansible – система автоматизації налаштування серверів, управління 
конфігурацією та розгортання програмного забезпечення. 
Ceph – децентралізована система зберігання даних, яка надає блочне, 
об’єктне та файлове сховище. 
CI/CD (Continuous Integration / Continuous Deployment) – підхід до 
автоматизації інтеграції змін у коді, тестування та розгортання 
інфраструктури. 
Glance – компонент OpenStack для управління образами віртуальних машин. 
Horizon – веб-інтерфейс адміністратора й користувача OpenStack. 
Kolla-Ansible – фреймворк для розгортання OpenStack у контейнерах з 
використанням Docker і Ansible. 
Keystone – модуль автентифікації та авторизації в OpenStack. 
Load Balancer – балансувальник навантаження, що забезпечує доступність 
сервісів через розподіл запитів між серверами. 
MariaDB-Galera – кластеризована система управління базами даних, що 
використовується для зберігання конфігурацій OpenStack. 
MON / MGR (Monitor / Manager) – компоненти Ceph для моніторингу стану 
кластера та управління. 
Neutron – мережевий сервіс OpenStack, що відповідає за створення і 
керування віртуальними мережами. 
Nova – обчислювальний сервіс OpenStack, який керує віртуальними 
машинами. 
OSD (Object Storage Daemon) – демон Ceph, що безпосередньо відповідає за 
зберігання даних на дисках. 
4 
OpenStack – платформа відкритого коду для створення хмарної 
інфраструктури рівня IaaS (інфраструктура як сервіс). 
Packer – інструмент для автоматизації створення образів віртуальних машин. 
Prometheus – система збору метрик і моніторингу стану компонентів. 
RabbitMQ – брокер повідомлень, що використовується OpenStack для 
передачі даних між компонентами. 
RBD (RADOS Block Device) – блочне сховище Ceph, що використовується 
модулями OpenStack для зберігання даних. 
Terraform – інструмент управління інфраструктурою як кодом, який 
дозволяє автоматизувати створення хмарних ресурсів. 
VM (Virtual Machine) – віртуальна машина, що виконується на фізичному 
сервері за допомогою гіпервізора. 
vCenter – централізована платформа управління інфраструктурою VMware. 
vMotion – технологія VMware, що дозволяє мігрувати запущені віртуальні 
машини між фізичними хостами без простою. 
VIP (Virtual IP Address) – віртуальна IP-адреса, що представляє групу 
серверів для забезпечення відмовостійкого доступу до сервісів. 
5 
ВСТУП 
Інформаційні технології дедалі активніше інтегруються у критично 
важливі галузі економіки, серед яких особливе місце займає енергетичний 
сектор, що характеризується високими вимогами до надійності, 
безперервності функціонування та інформаційної безпеки. У контексті 
глобальної цифрової трансформації підприємства стикаються з 
необхідністю впровадження сучасних ІТ-рішень, здатних забезпечити 
гнучкість, масштабованість і адаптивність інфраструктури до динамічних 
змін навантаження та зовнішніх умов. Особливої актуальності набуває 
використання хмарних технологій, які дозволяють ефективно управляти 
обчислювальними ресурсами, оптимізувати витрати та підвищити рівень 
автоматизації бізнес-процесів. 
Серед різних моделей хмарних обчислень значну увагу привертають 
приватні хмари, що забезпечують підвищений рівень контролю над даними, 
відповідність вимогам регуляторів і можливість гнучкого налаштування 
середовища відповідно до специфіки підприємства. У цьому контексті 
особливої ваги набувають платформи з відкритим вихідним кодом, зокрема 
OpenStack, яка є де-факто стандартом для побудови приватних та гібридних 
хмарних середовищ. Водночас, у корпоративному секторі широко 
використовується віртуалізаційна інфраструктура на базі VMware vSphere, 
що забезпечує високий рівень стабільності, зрілі інструменти управління та 
підтримку критично важливих навантажень. 
Поєднання цих технологій відкриває нові можливості для створення 
гібридних інфраструктур, однак супроводжується суттєвою складністю 
розгортання та конфігурації. Традиційні підходи, що передбачають ручне 
налаштування компонентів системи, поступово втрачають ефективність 
через значну кількість взаємозалежних етапів, високий ризик 
конфігураційних помилок та складність відтворення середовища. У таких 
6 
умовах ключовим напрямком розвитку стає впровадження концепцій 
Infrastructure as Code та автоматизації процесів розгортання, що дозволяє 
формалізувати інфраструктуру у вигляді декларативних описів і забезпечити 
її швидке, надійне та повторюване створення. 
Автоматизація розгортання хмарних платформ передбачає 
використання сучасних інструментів оркестрації та конфігураційного 
управління, таких як Ansible або Terraform, які дозволяють реалізувати 
повний цикл створення інфраструктури – від ініціалізації віртуальних 
ресурсів до налаштування сервісів та мережевої взаємодії. Такий підхід 
суттєво зменшує час введення системи в експлуатацію, підвищує її 
стабільність і спрощує процес супроводу. Крім того, автоматизація є 
основою для впровадження практик DevOps та CI/CD у сфері управління 
інфраструктурою, що відповідає сучасним тенденціям розвитку ІТ-галузі. 
Розробка та дослідження автоматизованих систем розгортання 
хмарних платформ на базі поєднання OpenStack і VMware є актуальним 
науково-практичним завданням, що відповідає сучасним тенденціям 
розвитку інформаційних технологій. Такий підхід дозволяє підвищити 
ефективність управління інфраструктурою, забезпечити її масштабованість 
та надійність, а також створити основу для подальшого розвитку 
інтелектуальних та автономних ІТ-систем як у державному, так і в 
корпоративному секторі. 
7 
ЗАГАЛЬНА ХАРАКТЕРИСТИКА РОБОТИ 
Актуальність теми. Актуальність теми зумовлена стрімким 
розвитком хмарних технологій та зростанням ролі автоматизації у 
побудові сучасних ІТ-інфраструктур, особливо в умовах підвищених 
вимог до надійності, безпеки та безперервності функціонування 
інформаційних систем. У світовій практиці розгортання хмарних 
середовищ активно використовуються як пропрієтарні рішення, зокрема 
VMware vSphere, так і платформи з відкритим кодом, серед яких провідне 
місце займає OpenStack. Кожен із підходів має свої переваги та 
обмеження, що обумовлює необхідність їх комплексного аналізу та 
інтеграції. 
Платформа VMware забезпечує високий рівень зрілості, 
стабільності та розвинені інструменти адміністрування, що робить її 
стандартом де-факто у корпоративному середовищі. Водночас її 
використання пов’язане з високою вартістю ліцензування та обмеженою 
гнучкістю у контексті кастомізації. Натомість OpenStack надає широкі 
можливості масштабування, гнучку архітектуру та незалежність від 
постачальника, однак характеризується складністю розгортання та 
експлуатації, що потребує високої кваліфікації персоналу і значних 
часових витрат при ручному налаштуванні. 
Аналіз існуючих підходів показує, що традиційні методи 
розгортання інфраструктури, засновані на ручному конфігуруванні, не 
відповідають сучасним вимогам до швидкості, відтворюваності та 
надійності. Відомі рішення частково вирішують ці проблеми за рахунок 
використання засобів автоматизації, таких як Ansible чи Terraform, однак 
у більшості випадків вони орієнтовані або на окремі компоненти 
інфраструктури, або на використання в межах однієї технологічної 
платформи без урахування специфіки інтеграції OpenStack і VMware. 
8 
Серед дослідників, які працюють у напрямі хмарних обчислень, 
автоматизації інфраструктури та розгортання OpenStack у віртуалізованих 
середовищах VMware vSphere, можна відзначити: 
Шейн Макінтош (Shane McIntosh): Дослідник у галузі якості 
програмного забезпечення та DevOps, відомий роботами, пов’язаними з 
аналізом CI/CD процесів у великих open-source екосистемах, зокрема 
OpenStack. 
Хідеакі Хата (Hideaki Hata): Вчений, який займається 
дослідженнями у сфері автоматизації тестування та стабільності CI/CD-
пайплайнів у хмарних платформах. 
Марія Кіль (Maria Kihl): Експерт у галузі хмарних обчислень та 
оркестрації застосунків у розподілених і федеративних середовищах. 
Ларс Ларссон (Lars Larsson): Дослідник розподілених систем і 
мультихмарних інфраструктур, зосереджений на питаннях 
автоматизованої оркестрації. 
Парт Ядав (Parth Yadav): Дослідник cloud-native підходів, який 
працює над інтеграцією OpenStack із сучасними інструментами 
оркестрації та автоматизації. 
Основні роботи, що представляють окремі аспекти досліджень у 
галузі автоматизації хмарної інфраструктури: 
• "Cross-Project Flakiness: A Case Study of the OpenStack Ecosystem" 
авторства Shane McIntosh та Hideaki Hata. 
• "FedApp: a Research Sandbox for Application Orchestration in 
Federated Clouds using OpenStack" авторства Maria Kihl та Lars 
Larsson. 
• "KupenStack: Kubernetes based Cloud Native OpenStack" авторства 
Parth Yadav та Vipin Kumar Rathi. 
• "Leveraging OpenStack and Ceph for a Controlled-Access Data Cloud" 
авторства Evan F. Bollig та Graham T. Allan. 
9 
• "OpenStack Operations Guide" авторства Tom Fifield, Diane Fleming, 
Anne Gentle та ін. 
Особливої актуальності дана проблема набуває в Україні, де 
підприємства та державні установи знаходяться у процесі активної 
цифровізації та модернізації ІТ-інфраструктури. В умовах обмежених 
ресурсів, необхідності забезпечення кіберстійкості та незалежності від 
зовнішніх постачальників технологій важливим є створення ефективних, 
гнучких і економічно обґрунтованих рішень. Використання 
автоматизованих підходів до розгортання приватних хмар дозволяє 
суттєво знизити витрати на впровадження та експлуатацію систем, 
підвищити швидкість їх розгортання, а також забезпечити стандартизацію 
та контроль якості конфігурацій. 
Крім того, з урахуванням сучасних викликів, пов’язаних із 
забезпеченням безперервності роботи критичної інфраструктури, 
особливого значення набуває можливість швидкого відновлення ІТ-
систем після збоїв або кібератак. Автоматизація розгортання 
інфраструктури забезпечує відтворюваність середовища та значно 
скорочує час відновлення, що є критично важливим для енергетичного 
сектору та інших стратегічних галузей економіки України. 
Таким чином, тема автоматизації розгортання OpenStack на базі 
віртуалізації VMware є актуальною як з наукової, так і з практичної точки 
зору. Вона спрямована на вирішення важливої прикладної задачі 
підвищення ефективності управління ІТ-інфраструктурою, зниження 
витрат та забезпечення технологічної незалежності, що має суттєве 
значення для подальшого розвитку цифрової економіки України. 
Зв'язок роботи з науковими програмами, планами, темами. Тема 
роботи відповідає основним напрямам науково-дослідної та освітньої 
діяльності закладу вищої освіти, в якому вона виконується, зокрема в 
частині розвитку інформаційних технологій, хмарних обчислень, 
10 
віртуалізації та автоматизації ІТ-інфраструктури. Дослідження 
узгоджується з навчальними дисциплінами, пов’язаними з 
адмініструванням комп’ютерних систем і мереж, хмарними технологіями, 
DevOps-підходами та управлінням ІТ-проєктами. 
Обраний напрям роботи також відповідає сучасним науковим і 
прикладним дослідженням у сфері побудови та оптимізації хмарних 
середовищ на базі платформ OpenStack і VMware vSphere, що активно 
використовуються як у наукових дослідженнях, так і в корпоративному 
секторі. Результати роботи можуть бути інтегровані в подальші науково-
дослідні проєкти кафедри, пов’язані з автоматизацією інфраструктури, 
підвищенням ефективності використання обчислювальних ресурсів та 
впровадженням сучасних підходів до управління ІТ-системами. 
Таким чином, виконання роботи безпосередньо пов’язане з 
реалізацією наукових програм і тематик закладу освіти та спрямоване на 
розвиток актуального напряму досліджень у галузі інформаційних 
технологій. 
Мета і завдання дослідження. Метою кваліфікаційної роботи є 
розробка та реалізація повністю автоматизованого рішення для 
розгортання та управління хмарною інфраструктурою на базі платформи 
OpenStack, що функціонує поверх віртуалізаційного середовища VMware 
vSphere, із інтеграцією розподіленої системи зберігання даних Ceph. 
Запропонована система орієнтована на забезпечення повного безручного 
розгортання, конфігурації та масштабування кластера з використанням 
підходу Infrastructure as Code та сучасних інструментів автоматизації. 
Досягнення поставленої мети передбачає вирішення комплексу 
взаємопов’язаних завдань, що охоплюють аналітичний і практичний 
аспекти дослідження. У межах роботи проводиться аналіз існуючих 
підходів до автоматизації розгортання OpenStack у середовищах 
віртуалізації, визначаються їх обмеження, після чого проєктується 
11 
архітектура системи та реалізується відповідне програмно-
інфраструктурне рішення. 
Основні задачі, які необхідно вирішити для досягнення поставленої 
мети: 
• спроєктувати архітектуру системи з урахуванням вимог до високої 
доступності та масштабованості; 
• створити шаблони Packer для автоматичної підготовки віртуальних 
машин (controller, compute, storage); 
• розробити модулі Terraform для оркестрації віртуальної 
інфраструктури у vSphere та автоматизації мережевих і 
обчислювальних ресурсів; 
• реалізувати ролі Ansible для автоматизованого налаштування 
компонентів OpenStack (Keystone, Glance, Nova, Neutron тощо); 
• впровадити кластер Ceph для використання в якості бекенду 
зберігання блочних томів і образів; 
• налаштувати GitLab CI/CD для запуску повного циклу тестування, 
складання, розгортання та перевірки кластера. 
У результаті формується цілісна система автоматизованого 
розгортання хмарного середовища, яка забезпечує високу 
відтворюваність, скорочення часу впровадження та підвищення 
ефективності експлуатації інфраструктури. 
Об’єктом дослідження є процес автоматизованого розгортання та 
управління хмарною інфраструктурою на базі OpenStack у середовищі 
віртуалізації VMware vSphere. 
Предмет дослідження – автоматизація розгортання хмарної 
інфраструктури OpenStack на базі віртуалізаційної платформи VMware 
vSphere із використанням підходів Infrastructure as Code та засобів 
оркестрації і конфігураційного управління. 
12 
Методи дослідження. Для вирішення поставленої в роботі мети 
використовувались методи: декомпозиція процесу розгортання хмарної 
інфраструктури на окремі етапи з подальшою формалізацією у вигляді 
сценаріїв Infrastructure as Code; експериментальне розгортання та 
тестування кластера OpenStack у середовищі VMware vSphere з 
використанням Packer, Terraform та Ansible; інтеграційне тестування 
взаємодії компонентів системи та перевірка коректності їх конфігурації; 
вимірювання часу розгортання, відтворюваності та стабільності роботи 
системи з подальшим порівнянням ручного та автоматизованого підходів; 
валідація результатів шляхом повторного розгортання інфраструктури в 
ідентичних умовах. 
Наукова новизна одержаних результатів полягає у розробленні 
методу автоматизованого розгортання хмарної інфраструктури OpenStack 
у середовищі VMware vSphere, який базується на поєднанні підходу 
Infrastructure as Code та багаторівневої оркестрації процесів створення, 
конфігурації та масштабування ресурсів. 
У роботі запропоновано модель інтегрованого розгортання, що 
передбачає узгоджену взаємодію інструментів автоматизації на різних 
рівнях інфраструктури – від підготовки образів і створення віртуальних 
машин до конфігурації сервісів та інтеграції системи зберігання. На 
відміну від існуючих підходів, запропонована модель забезпечує повну 
відтворюваність середовища, зменшення кількості ручних операцій та 
підвищення узгодженості конфігурацій у гетерогенному середовищі 
віртуалізації. 
Також удосконалено підхід до організації процесу розгортання за 
рахунок впровадження конвеєра безперервної інтеграції та доставки, що 
дозволяє автоматизувати контроль цілісності інфраструктури, прискорити 
процес оновлення та забезпечити можливість багаторазового повторного 
розгортання з однаковими параметрами. Це створює основу для 
13 
підвищення ефективності управління хмарними системами та зниження 
впливу людського фактора. 
Практичне значення одержаних результатів полягає у доведенні 
теоретичних положень до рівня прикладного інженерного рішення, що 
забезпечує автоматизоване, відтворюване та масштабоване розгортання 
хмарної інфраструктури на базі OpenStack у середовищі VMware vSphere. 
Розроблене рішення дозволяє суттєво скоротити час підготовки 
інфраструктури, підвищити стабільність розгортання та мінімізувати вплив 
людського фактора за рахунок використання підходу Infrastructure as Code. 
У межах роботи реалізовано алгоритм автоматизованого розгортання, 
що охоплює повний життєвий цикл створення інфраструктури – від 
підготовки образів віртуальних машин до конфігурації сервісів та інтеграції 
системи зберігання. Запропоновано спосіб організації процесу розгортання 
із використанням інструментів Packer, Terraform та Ansible, що забезпечує 
узгодженість дій на різних рівнях інфраструктури та їх автоматичне 
виконання. 
Також розроблено структурну та функціональну схеми системи, які 
відображають взаємодію компонентів хмарного середовища, 
віртуалізаційної платформи та засобів автоматизації, а також визначають 
послідовність виконання процесів розгортання і конфігурації. Отримані 
результати можуть бути використані при створенні та модернізації 
приватних хмарних середовищ у корпоративному та державному секторі, 
зокрема для підвищення ефективності управління ІТ-інфраструктурою та 
забезпечення її надійності й масштабованості. 
Особистий внесок студента. Теоретичні результати дослідження, що 
виносяться на захист, отримані автором особисто. Результати прикладного 
характеру отримані за участю автора спільно з колективом співробітників 
ЧДТУ. 
14 
Апробація результатів роботи здійснювалась шляхом їх 
представлення та обговорення на наукових заходах. Основні положення та 
результати кваліфікаційної роботи доповідались і обговорювались на 
студентській науково-практичній конференції, що відбулася 21-23 квітня 
2026 року у місті Черкаси. Під час виступу було висвітлено підхід до 
автоматизації розгортання хмарної інфраструктури на базі OpenStack у 
середовищі VMware vSphere, а також отримано зауваження та рекомендації, 
які були враховані при подальшому доопрацюванні роботи. 
Публікації. За матеріалами роботи опублікована теза доповідей: 
Автоматизація розгортання OpenStack на базі віртуалізації VMware / 
А. В. Ободовський, К. С. Рудаков // Збірник тез доповідей студентської 
науково-практичної конференції ЧДТУ : 21-23 квітня 2026 р. [Електронний 
ресурс] / [упоряд. Мельник І.В.] ; М-во освіти і науки України, Черкас. держ. 
технол. ун-т. – Черкаси : ЧДТУ, 2026. – C.12-13. 
Структура та обсяг роботи. Бакалаврська робота складається з 
загальної характеристики роботи, трьох розділів, висновків, списку 
використаних джерел. Основний текст викладений на 62 сторінках, містить 
28 рисунків та 1 таблицю. Список використаних джерел складається з 37 
найменувань. 
15 
РОЗДІЛ 1 АНАЛІЗ ІСНУЮЧИХ СИСТЕМ 
1.1 Огляд аналогів Openstack 
Автоматизація розгортання OpenStack є критичним аспектом для 
забезпечення стабільності, повторюваності та ефективності побудови 
хмарної інфраструктури. Існує кілька альтернативних рішень, які 
дозволяють досягти цієї мети, кожне з яких має власну архітектурну 
філософію, рівень складності та гнучкість. 
1.1.1 OpenStack TripleO 
TripleO (OpenStack On OpenStack) – це офіційний проєкт OpenStack 
для розгортання, оновлення та управління OpenStack-кластером за 
допомогою самого ж OpenStack. TripleO використовує Heat, Ironic, Mistral 
та інші сервіси для автоматизації процесу встановлення [1]. 
Перевагою TripleO є повна інтеграція в екосистему OpenStack, 
підтримка великої кількості компонентів та готові шаблони для розгортання. 
Проте використання TripleO вимагає попереднього розгортання 
підготовчого OpenStack-кластеру, має складну архітектуру та високу криву 
навчання, що робить його менш гнучким для гібридних або невеликих 
середовищ. TripleO практично не підтримує VMware vSphere як хост-
платформу, що робить його непридатним у контексті даної роботи. 
1.1.2 OpenStack-Ansible 
OpenStack-Ansible є офіційним проєктом OpenInfra Foundation, що 
дозволяє розгортати компоненти OpenStack з використанням Ansible. На 
відміну від KollaAnsible, OpenStack-Ansible не використовує контейнери – 
замість цього сервіси розгортаються безпосередньо в системі, ізоляція 
досягається через LXCконтейнери. Рішення добре підходить для великих 
інфраструктур із підвищеними вимогами до кастомізації. Серед недоліків – 
складність початкової конфігурації, висока крива навчання та більша 
складність оновлень порівняно з контейнеризованими підходами [1]. 
16 
1.1.3 DevStack 
DevStack – це інструмент, орієнтований на розробників і 
тестувальників, який дозволяє швидко розгорнути OpenStack у режимі "all-
in-one". Його основна перевага – швидкість і простота. Однак DevStack не 
підтримує сценарії високої доступності, не призначений для production-
середовищ і потребує повного redeploy при кожному перезавантаженні. Це 
виключає його зі списку придатних засобів для автоматизації розгортання в 
реальних інфраструктурних сценаріях [2]. 
1.1.4 Juju + MAAS 
Комбінація Juju (оркестратор від Canonical) та MAAS (Metal as a 
Service) дозволяє автоматизувати розгортання OpenStack на фізичних 
серверах. Juju використовує концепцію "charms" - шаблонів, які описують 
залежності та сценарії конфігурації компонентів. Цей підхід дає можливість 
швидко масштабувати кластери. Серед мінусів – жорстка прив’язка до 
екосистеми Canonical/Ubuntu, потреба в окремій інфраструктурі для MAAS, 
та менша популярність у спільноті порівняно з іншими рішеннями [2]. 
1.1.5 Fuel 
Fuel – це застарілий інструмент для розгортання OpenStack, який 
розроблявся компанією Mirantis. Він забезпечував GUI-інтерфейс для 
управління розгортанням, конфігурацією та моніторингом кластера. Хоча 
Fuel був популярним у минулому, він більше не підтримується й офіційно 
вважається deprecated. Сьогодні його не рекомендується використовувати 
для нових проєктів через відсутність оновлень і критичної підтримки [2]. 
1.2 Огляд аналогів VCenter  
Автоматизація розгортання OpenStack на базі VMware vSphere 
значною мірою залежить від системи управління віртуалізацією. VMware 
vCenter є стандартом галузі, однак існує низка інших рішень, що 
пропонують аналогічні функції [3]. 
17 
1.2.1 Proxmox VE 
Proxmox Virtual Environment (VE) є відкритим програмним рішенням 
для керування віртуалізацією на базі технологій KVM і LXC-контейнерів. 
Платформа має зручний веб-інтерфейс, забезпечує гнучке управління 
кластером, міграцію віртуальних машин у режимі реального часу, підтримує 
інтеграцію із розподіленими системами зберігання, такими як Ceph. 
Основною перевагою Proxmox є відкритий код та відсутність плати за 
ліцензії. Однак рішення не має нативної інтеграції з VMware vSphere, що 
робить його непридатним у контексті автоматизованого розгортання 
OpenStack на основі VMware, оскільки ця робота вимагає саме інтеграції з 
інфраструктурою vSphere [2]. 
 
Рис. 1.1. Proxmox VE  
1.2.2 Microsoft SCVMM 
Microsoft System Center Virtual Machine Manager (SCVMM) – це 
комерційне рішення для централізованого управління гіпервізорами, такими 
як Hyper-V, ESXi та XenServer. SCVMM інтегрується в екосистему Microsoft 
та має потужні інструменти для автоматизації та моніторингу ресурсів. До 
переваг можна віднести широкий функціонал автоматизації та 
18 
централізований підхід до управління інфраструктурою. Однак висока 
вартість ліцензій, складність конфігурації, а також часткова підтримка 
специфічних можливостей VMware vSphere робить це рішення не 
оптимальним для проєкту автоматизації OpenStack [9]. 
  
Рис. 1.2. Microsoft SCVMM  
1.2.3 oVirt / Red Hat Virtualization 
oVirt (і комерційний варіант – Red Hat Virtualization) – платформа на 
базі відкритого коду з використанням гіпервізора KVM. Цей продукт має 
зручний вебінтерфейс, підтримує кластеризацію, міграцію та розподілені 
системи зберігання даних (наприклад, Ceph або GlusterFS). Перевагами oVirt 
є відкритість, гнучкість та відносно низька вартість розгортання. Основний 
недолік полягає у відсутності інтеграції з VMware vSphere, що створює 
складнощі при автоматизації розгортання OpenStack саме у середовищах 
VMware. Саме тому, в контексті поточної роботи, використання oVirt є 
непрактичним [6]. 
19 
  
Рис. 1.3. Red Hat Virtualization 
1.2.4 Citrix Hypervisor (XenServer) 
Citrix Hypervisor (раніше XenServer) побудований на гіпервізорі Xen і 
підходить для ресурсоємних навантажень, зокрема VDI та задач із 
використанням GPU [8]. Платформа підтримує live-міграцію, кластери 
високої доступності та розвинене керування ресурсами. Водночас вона 
поступається VMware vCenter за рівнем автоматизації та не має глибокої 
інтеграції з екосистемою vSphere, тому в межах цієї роботи не розглядається. 
  
Рис. 1.4. Citrix Hypervisor 
20 
1.2.5 Nutanix AHV 
Nutanix AHV – це гіперконвергентна платформа з власним 
гіпервізором AHV, яка дозволяє створювати та управляти віртуальними 
машинами через єдиний зручний інтерфейс Prism [7]. Вона забезпечує 
просте масштабування, високу доступність та надійність. Проте основним 
недоліком AHV є висока початкова вартість інфраструктури Nutanix, 
обмежена гнучкість налаштувань і практично повна відсутність інтеграції з 
VMware vSphere. Це робить Nutanix AHV непридатним рішенням для 
автоматизованого розгортання OpenStack у контексті VMware-орієнтованої 
інфраструктури. 
  
Рис. 1.5. Nutanix AHV 
Висновки до першого розділу 
Проведений аналіз існуючих рішень для автоматизованого 
розгортання OpenStack, а також альтернатив платформі VMware vSphere 
підтвердив наявність широкого спектра інструментів, що можуть 
застосовуватися для побудови хмарної інфраструктури (Таблиця 1.1). 
Водночас встановлено, що більшість із них мають обмеження, які 
21 
ускладнюють або роблять недоцільним їх використання у рамках 
поставленого завдання – автоматизованого розгортання OpenStack у 
середовищі VMware. 
 
Таблиця 1.1 
Порівняння характеристик існуючих рішень 
Підтримка CI/CD Рівень Гнучкість Актуальний 
Система 
VMware інтеграція автоматизації налаштування статус 
OpenStackTripleO –  Високий Низька Застаріле 
OpenStack-Ansible – Часткова Середній Висока Актуальне 
DevStack – – Низький Низька Тестова версія 
Juju + MAAS – Часткова Високий Висока Обмежене 
Kolla-Ansible   Високий Висока Актуальне 
 
Аналіз засобів автоматизації розгортання OpenStack, зокрема TripleO, 
OpenStack-Ansible, DevStack, Juju + MAAS та Fuel, показав, що кожен із них 
орієнтований на специфічні сценарії використання. TripleO 
характеризується складною архітектурою та високими вимогами до 
початкової інфраструктури. OpenStack-Ansible забезпечує гнучкість 
конфігурації, проте має значну складність впровадження. DevStack 
призначений виключно для тестових середовищ і не відповідає вимогам 
production. Juju + MAAS має жорстку прив’язку до екосистеми Ubuntu та 
підвищені вимоги до ресурсів, а Fuel є застарілим і не підтримується. 
Аналіз альтернативних платформ управління віртуалізацією, таких як 
Proxmox VE, Microsoft SCVMM, oVirt, Citrix Hypervisor та Nutanix AHV, 
також виявив низку обмежень. Зокрема, відсутність глибокої інтеграції з 
VMware, обмежені можливості автоматизації або значні витрати на 
впровадження не дозволяють ефективно використовувати ці рішення у 
межах досліджуваного підходу. 
У результаті проведеного аналізу обґрунтовано вибір комбінації 
VMware vCenter та Kolla-Ansible як базового рішення для автоматизованого 
22 
розгортання OpenStack. Такий підхід забезпечує інтеграцію з 
інфраструктурою VMware vSphere, спрощує процес конфігурації за рахунок 
використання контейнеризації, а також відповідає вимогам 
масштабованості, відмовостійкості та керованості, що є критичними для 
сучасних хмарних середовищ. 
На відміну від стандартного використання Kolla-Ansible, у даній 
кваліфікаційній роботі запропоновано комплексний підхід до автоматизації, 
який охоплює не лише конфігурацію сервісів OpenStack, а й повний 
життєвий цикл розгортання інфраструктури – від підготовки образів і 
створення віртуальних ресурсів до їх автоматизованого налаштування та 
інтеграції. Додаткове впровадження принципів Infrastructure as Code та 
CI/CD забезпечує повну відтворюваність середовища, зменшення кількості 
ручних операцій і можливість швидкого масштабування, що підвищує 
ефективність у порівнянні з типовими підходами розгортання. 
23 
РОЗДІЛ 2 АНАЛІЗ ІНСТРУМЕНТІВ РОЗРОБКИ ТА 
РЕАЛІЗАЦІЇ ПРОГРАМНОГО ПРОДУКТУ 
Другий розділ роботи присвячений опису та аналізу інструментів і 
технологій, які використовуються для автоматизації розгортання хмарної 
платформи OpenStack на базі віртуалізаційної інфраструктури VMware 
vSphere. Ці інструменти й технології розглядаються у трьох логічних блоках: 
засоби автоматизації створення та налаштування інфраструктури, генерації 
та підготовки шаблонних образів систем, а також інструменти 
контейнеризації компонентів OpenStack. 
2.1 Віртуалізація та хостинг: ESXi, vCenter, Ubuntu 
У роботі основну увагу приділено використанню віртуалізаційних 
рішень VMware, які забезпечують стабільність, надійність і високу 
продуктивність під час розгортання OpenStack [11]. Коректний вибір 
платформи хостингу є критично важливим, оскільки безпосередньо впливає 
на продуктивність, стійкість і безпеку всієї системи. Платформа VMware 
vSphere разом із гіпервізором ESXi надає гнучкі засоби керування 
віртуальними машинами та спрощує масштабування й супровід хмарної 
інфраструктури. Операційну систему Ubuntu обрано завдяки широкій 
підтримці компонентів OpenStack і стабільній роботі в ролі хост-системи. 
2.1.1 ESXi 
VMware ESXi є гіпервізором типу 1, що дозволяє створювати і 
керувати віртуальними машинами безпосередньо на апаратному рівні. ESXi 
надає високий рівень продуктивності, надійності та ефективності завдяки 
оптимізації апаратних ресурсів [10]. Його перевагами є мінімальні системні 
вимоги, безпека та висока ступінь ізоляції ресурсів між віртуальними 
машинами. Завдяки цим характеристикам, ESXi є ідеальним рішенням для 
створення стабільного базового шару для розгортання OpenStack. 
24 
 
Рис. 2.1. ESXi 
2.1.2 VMware vCenter 
VMware vCenter є централізованою системою управління, яка 
дозволяє ефективно керувати численними ESXi-хостами та віртуальними 
машинами [4]. vCenter забезпечує централізоване управління, моніторинг, 
автоматизацію завдань і високу доступність. Крім того, він забезпечує 
глибоку інтеграцію з іншими продуктами VMware, що дозволяє створювати 
складні й добре керовані хмарні середовища. Завдяки інтеграції з OpenStack, 
vCenter стає критично важливим інструментом, що значно спрощує 
адміністрування інфраструктури.  
  
Рис. 2.2. VMware vCenter 
25 
2.1.3 Ubuntu 
Ubuntu – це одна з найпоширеніших Linux-дистрибутивів, що широко 
використовується у хмарних рішеннях завдяки стабільності, простоті 
налаштування та активній підтримці спільноти [14]. Ubuntu має оптимальну 
сумісність з OpenStack, підтримує сучасні рішення для автоматизації 
розгортання та ефективно інтегрується з віртуалізаційними технологіями 
VMware. Вибір саме цієї ОС обумовлений її надійністю, простотою 
використання та значною кількістю доступних інструментів для 
адміністрування та моніторингу системи. 
2.2 Система контролю версій GitLab 
GitLab – це сучасна система контролю версій і комплексна платформа 
DevOps, яка об’єднує інструменти для управління вихідним кодом, 
автоматизації процесів безперервної інтеграції та доставки (CI/CD), а також 
засоби командної взаємодії та управління проєктами. Основою GitLab є 
підтримка розподіленої системи контролю версій Git, що забезпечує 
ефективну роботу з кодом, контроль змін, гілкування та можливість 
паралельної розробки [16]. Платформа підтримує як публічні, так і приватні 
репозиторії, що є особливо важливим у контексті розробки інфраструктури 
як коду, де зберігаються конфігураційні файли, сценарії автоматизації та 
шаблони розгортання. GitLab забезпечує механізми контролю доступу, аудит 
змін і управління правами користувачів, що підвищує безпеку та керованість 
процесу розробки. 
У контексті автоматизації розгортання OpenStack GitLab 
використовується як центральний елемент оркестрації процесів, що 
забезпечує узгоджену взаємодію між інструментами Packer, Terraform та 
Ansible. Це дозволяє реалізувати поетапне розгортання інфраструктури: 
створення базових образів, ініціалізацію віртуальних ресурсів, 
конфігурацію сервісів і перевірку їх працездатності. 
26 
Додатково GitLab надає інструменти для моніторингу виконання 
пайплайнів, зберігання артефактів, ведення журналів виконання та аналізу 
результатів, що значно спрощує процес налагодження та супроводу системи. 
Завдяки інтеграції всіх етапів життєвого циклу інфраструктури в єдиному 
середовищі забезпечується висока відтворюваність, прозорість і керованість 
процесів розгортання. 
  
Рис. 3.3. GitLab 
2.3 Інфраструктура як код 
2.3.1 Terraform 
Terraform є сучасним інструментом для автоматизованого створення та 
управління інфраструктурою у вигляді коду (Infrastructure as Code). Він 
дозволяє декларативно описати бажаний стан інфраструктури, після чого 
Terraform автоматично забезпечує відповідність реального стану описаному 
в конфігурації [15]. 
Terraform підтримує велику кількість провайдерів, зокрема VMware 
vSphere, що робить його ідеальним для автоматизації створення та 
конфігурації віртуальних машин, мережевих компонентів, сховищ тощо. 
27 
Перевагою Terraform є гнучкість, простота використання, висока швидкість 
розгортання та широкі можливості автоматизації, саме тому цей інструмент 
було обрано для автоматизації підготовки віртуальної інфраструктури для 
OpenStack.  
2.3.2 Packer 
Packer – це інструмент з відкритим вихідним кодом, призначений для 
автоматичного створення шаблонів віртуальних машин (образів). Він 
підтримує різні платформи, включаючи VMware vSphere. Packer дозволяє 
автоматизувати процес створення, налаштування та пакування образів 
операційних систем, забезпечуючи їхню повторюваність і стабільність [22]. 
Це суттєво спрощує процес автоматизації розгортання OpenStack, оскільки 
всі необхідні компоненти системи можна підготувати та протестувати 
заздалегідь. Основною перевагою Packer є його простота та сумісність з 
широким спектром інфраструктур, що значно зменшує витрати часу на 
налаштування та підтримку образів. 
2.3.3 Ansible 
Ansible – популярний інструмент автоматизації конфігурації та 
керування інфраструктурою. Головними перевагами Ansible є його простий 
синтаксис, ідемпотентність, безагентна архітектура та легкість інтеграції в 
CI/CD пайплайни [13]. Ansible дозволяє швидко та надійно конфігурувати 
велику кількість серверів, автоматизуючи встановлення та налаштування 
всіх необхідних компонентів OpenStack. Завдяки широкій спільноті та 
великій кількості готових ролей та модулів, він значно спрощує процес 
автоматизації складних і багатокомпонентних систем, якою є OpenStack. Ці 
фактори стали ключовими при виборі Ansible у контексті даної роботи. 
28 
2.4 CI/CD пайплайни 
2.4.1 Gitlab Runner 
GitLab Runner – це агент, який виконує завдання безперервної 
інтеграції та доставки (CI/CD) у середовищі GitLab [21]. Він дозволяє 
автоматизувати тестування, збирання та розгортання конфігураційних 
скриптів і застосунків. GitLab Runner підтримує різні виконавчі середовища, 
такі як Shell, Docker, Kubernetes, що робить його надзвичайно гнучким для 
інтеграції в різні інфраструктури. В даній роботі GitLab Runner 
використовується для автоматизації створення образів за допомогою Packer, 
виконання сценаріїв Ansible та запуску Terraform-скриптів. 
2.4.2 CI конфігурація (.gitlab-ci.yml) 
Файл .gitlab-ci.yml визначає конфігурацію CI/CD-процесу у GitLab. 
Він містить опис усіх завдань, етапів і сценаріїв, які повинні виконуватись 
при кожній зміні у репозиторії. Конфігурація дозволяє автоматично 
запускати перевірки синтаксису, збірку образів, деплой інфраструктури та 
оновлення компонентів OpenStack. Основною перевагою використання 
цього підходу є можливість автоматизації складних і повторюваних 
процесів, зменшення людського фактору та забезпечення стабільності та 
повторюваності розгортання.  
2.5. Сховище 
2.5.1 Ceph 
Ceph – це розподілена система зберігання даних з відкритим вихідним 
кодом, яка забезпечує високу доступність, масштабованість і 
відмовостійкість [27]. Ceph може виступати як блокове сховище, об'єктне 
сховище та мережева файлова система, що робить його ідеальним рішенням 
для інтеграції з OpenStack. Завдяки своїй архітектурі, Ceph забезпечує 
високу продуктивність та ефективне використання ресурсів, що є важливим 
для роботи великої хмарної інфраструктури. У цій роботі Ceph було обрано 
29 
для централізованого зберігання даних віртуальних машин та образів 
системи, що дозволяє ефективно керувати ресурсами зберігання у 
середовищі VMware vSphere. 
 
Рис. 2.4. .gitlab-ci.yml файл для Openstack проєкту 
2.6 Сервіси Openstack 
2.6.1 Nova 
Nova – це основний компонент OpenStack, що відповідає за створення, 
керування та підтримку життєвого циклу віртуальних машин [6]. Він 
взаємодіє з гіпервізором, таким як ESXi, через API, забезпечуючи ефективне 
управління обчислювальними ресурсами. Nova є ключовим сервісом для 
автоматизованого розгортання хмарної інфраструктури. 
30 
2.6.2 Horizon 
Horizon – це веб-інтерфейс управління OpenStack, що дозволяє 
користувачам керувати ресурсами хмари через простий та інтуїтивно 
зрозумілий графічний інтерфейс. Horizon забезпечує доступ до всіх 
основних функцій системи, включаючи управління віртуальними 
машинами, мережами та сховищами [9]. 
2.6.3 Neutron 
Neutron – сервіс OpenStack, який забезпечує мережеву інфраструктуру, 
включаючи маршрутизацію, управління IP-адресами, налаштування 
мережевих інтерфейсів, та створення віртуальних мереж. Завдяки Neutron 
можливо реалізовувати складні мережеві конфігурації для забезпечення 
ізоляції ресурсів користувачів [26]. 
2.6.4 Manila 
Manila – сервіс, який надає доступ до спільних файлових систем у 
середовищі OpenStack. Він дозволяє керувати мережею файлових сховищ, 
інтегрувати їх з різними гіпервізорами та забезпечує централізоване 
керування даними [26]. 
2.6.5 HAProxy 
HAProxy – програмне рішення, що реалізує балансування 
навантаження та забезпечує високу доступність сервісів OpenStack. Він 
дозволяє рівномірно розподіляти трафік між вузлами та забезпечує швидку 
реакцію у разі відмови одного з компонентів [25]. 
2.6.6 Keepalived 
Keepalived – це програмне забезпечення, яке дозволяє реалізувати 
віртуальний IP (VIP) та автоматичне перемикання між вузлами, 
забезпечуючи високу доступність ключових компонентів інфраструктури 
[24]. 
31 
2.6.7 MariaDB 
MariaDB – це популярна система управління базами даних, яка 
використовується в OpenStack для зберігання інформації про стан та 
конфігурацію компонентів хмарної інфраструктури [23]. 
2.6.8 Keystone 
Keystone – це сервіс управління ідентифікацією, який забезпечує 
авторизацію та аутентифікацію користувачів OpenStack, дозволяє керувати 
ролями та доступом до ресурсів [23]. 
2.6.9 Cinder 
Cinder – сервіс OpenStack, який забезпечує керування блоковими 
пристроями та дозволяє створювати, підключати та управляти віртуальними 
дисками для віртуальних машин [23]. 
2.6.10 FluentD 
FluentD – це система збору та агрегування логів, яка дозволяє 
ефективно централізовано збирати та аналізувати журнали роботи всіх 
компонентів OpenStack [11]. 
2.6.11 Memcached 
Memcached – це швидкий і легкий кеш-сервер, який використовується 
в OpenStack для зберігання тимчасових даних, забезпечуючи зменшення 
навантаження на основні сервіси [28]. 
2.6.12 Swift 
Swift – це об'єктне сховище OpenStack, яке забезпечує зберігання і 
масштабування великих обсягів даних, таких як образи, резервні копії та 
статичний контент [11]. 
32 
2.6.13 Skyline 
Skyline – це сучасний веб-інтерфейс нового покоління для OpenStack, 
що забезпечує покращений користувацький досвід і високу продуктивність 
[11]. 
2.6.14 Blazar 
Blazar – це сервіс резервування ресурсів OpenStack, який дозволяє 
планувати і резервувати обчислювальні потужності на задані періоди часу 
[22]. 
2.6.15 Masakari 
Masakari – це сервіс високої доступності, який автоматично відновлює 
роботу віртуальних машин у разі збою або неполадки вузла [29]. 
2.6.16 Trove 
Trove – це сервіс управління базами даних OpenStack, що дозволяє 
автоматично розгортати та керувати різними типами баз даних [6]. 
Висновки до другого розділу 
У цьому розділі проведено систематичний аналіз інструментів і 
технологій, що використовуються для автоматизації розгортання OpenStack 
у середовищі віртуалізації VMware vSphere. У результаті аналізу визначено 
повний стек засобів, необхідних для реалізації автоматизованого життєвого 
циклу інфраструктури – від створення віртуалізованого середовища до 
конфігурації та управління сервісами. 
Обґрунтовано вибір платформи VMware ESXi та vCenter як базового 
рівня віртуалізації, що забезпечує стабільність, ефективну ізоляцію ресурсів 
і централізоване управління. Визначено доцільність використання 
операційної системи Ubuntu LTS як уніфікованого середовища для 
розгортання компонентів інфраструктури завдяки її сумісності з 
інструментами автоматизації та підтримці OpenStack. 
33 
У ході дослідження встановлено ефективність використання GitLab як 
центрального елемента керування інфраструктурним кодом і CI/CD 
процесами, що забезпечує інтеграцію етапів розробки, тестування та 
розгортання. Показано доцільність застосування підходу Infrastructure as 
Code на основі Terraform, Packer та Ansible, які забезпечують автоматизацію 
створення, підготовки та конфігурації інфраструктури. 
Окремо обґрунтовано використання розподіленої системи зберігання 
Ceph, яка забезпечує масштабованість, відмовостійкість та інтеграцію зі 
службами OpenStack. Визначено набір ключових сервісів OpenStack, 
необхідних для побудови повноцінної хмарної платформи, а також засобів 
забезпечення високої доступності, що гарантують безперервність роботи 
системи. 
Таким чином, у розділі сформовано обґрунтований технологічний стек 
та архітектурні підходи, які забезпечують реалізацію автоматизованого, 
відтворюваного та масштабованого середовища розгортання OpenStack. 
Отримані результати є основою для подальшої розробки та реалізації 
системи автоматизації, що розглядається у наступних розділах 
кваліфікаційної роботи. 
34 
РОЗДІЛ 3 ОПИС ПРОГРАМНОЇ РЕАЛІЗАЦІЇ 
У цьому розділі детально розглянуто етапи реалізації інфраструктури 
– від розгортання базового рівня віртуалізації до побудови повноцінного 
приватного хмарного середовища на основі OpenStack з інтеграцією 
розподіленого сховища Ceph, автоматизованими процесами розгортання та 
використанням CI/CD. Описано послідовність створення середовища, що 
включає підготовку віртуалізованих ресурсів, формування шаблонів образів, 
оркестрацію інфраструктури та конфігурацію сервісів. 
Реалізація виконана з урахуванням сучасних практик DevOps і підходу 
Infrastructure as Code, що дозволяє формалізувати всі етапи розгортання у 
вигляді керованого коду. Це забезпечує високий рівень автоматизації, 
відтворюваність результатів, зменшення кількості ручних операцій і 
спрощення супроводу системи. Використання централізованого конвеєра 
CI/CD на базі GitLab дозволяє автоматизувати виконання сценаріїв 
розгортання, контроль змін та перевірку працездатності інфраструктури. 
Запропонований підхід забезпечує стабільність функціонування 
системи, гнучкість у налаштуванні та можливість швидкого масштабування 
хмарного середовища відповідно до змін навантаження та вимог 
користувачів. 
3.1 Архітектура та принцип роботи проєкту 
Основна задача – зібрати повноцінний OpenStack-кластер на базі 
VMware vSphere за допомогою набору автоматизаційних інструментів. Усі 
дії описані декларативно й запускаються з CI/CD-конвеєра, тож один 
запуск pipeline від «чистого» vCenter переводить інфраструктуру в готовий 
до експлуатації стан.  
35 
3.1.1 Шар віртуалізації 
Шар віртуалізації представлений ESXi-кластером під управлінням 
VMware vCenter 7, який забезпечує надійну, масштабовану та 
централізовану платформу для запуску і керування віртуальними 
машинами. Цей кластер виконує роль основного гіпервізора, на базі якого 
функціонують усі вузли OpenStack та Ceph. Завдяки технологіям VMware 
забезпечується висока доступність (HA), балансування навантаження 
(DRS), ефективний розподіл ресурсів, а також зручний моніторинг і 
адміністрування всіх елементів інфраструктури. Така архітектура дозволяє 
централізовано керувати апаратними ресурсами, значно підвищити 
відмовостійкість середовища та оперативно масштабувати інфраструктуру у 
разі зростання навантаження або зміни бізнес-вимог.  
3.1.2 Шар образів 
На рівні підготовки образів використовується Packer, який забезпечує 
автоматизоване створення уніфікованого «золотого» шаблону віртуальної 
машини на базі операційної системи Ubuntu 22.04 LTS. Сформований 
шаблон розміщується у сховищі шаблонів VMware Content Library, що 
дозволяє централізовано використовувати його для подальшого розгортання 
інфраструктури. 
У конфігурації Packer описано ресурс типу vsphere-iso, який 
відповідає за створення віртуальної машини безпосередньо у середовищі 
VMware vSphere. Початковий інсталяційний образ операційної системи 
завантажується за URL-адресою, що передається через змінну os_iso_url. 
Під час розгортання віртуальної машини застосовується механізм передачі 
конфігураційних даних через параметр cd_content, який дозволяє передати 
файли user-data та metadata для автоматизованого початкового налаштування 
системи (cloud-init). 
У процесі побудови образу виконується базова конфігурація 
операційної системи, встановлення необхідних пакетів та підготовка 
36 
середовища для подальшого використання у хмарній інфраструктурі. Після 
завершення всіх етапів налаштування Packer автоматично конвертує 
створену віртуальну машину у шаблон формату OVF, який зберігається у 
Content Library та використовується як стандартний образ для створення всіх 
вузлів інфраструктури. 
Такий підхід забезпечує стандартизацію середовища, скорочення часу 
розгортання та гарантує ідентичність конфігурації всіх віртуальних машин, 
що є критично важливим для автоматизованих і масштабованих хмарних 
систем. 
3.1.3 Шар інфраструктури 
Terraform розгортає віртуальні машини для control-plane, compute, 
storage, openstack-deployment, ceph-deployment, load-balancer і Моніторинг 
вузлів. Одночасно створюються мережі, DRS-правила і резервуються 
ресурси під майбутнє масштабування.  
Код створює віртуальну машину у VMware vSphere за допомогою 
Terraformресурсу типу vsphere_virtual_machine. Віртуальна машина 
налаштовується заздалегідь визначеними змінними, такими як назва, 
кількість процесорів, оперативної пам'яті та дискового простору. Вона 
використовує ідентифікатор гостьової ОС "ubuntu64Guest" і має активовану 
підтримку вкладеної віртуалізації з параметрами nested_hv_enabled, 
ept_rvi_mode та hv_mode. Код передбачає можливість додавання додаткових 
мережевих інтерфейсів через динамічні блоки dynamic "network_interface", 
які підключаються залежно від умовних змінних 
add_second_network_interface. Крім того, ресурс використовує готовий 
шаблон (template_uuid) як основу для створення машини. Після створення 
віртуальна машина проходить додаткову кастомізацію (customize), де 
задаються параметри операційної системи (наприклад, назва хоста та 
доменна зона). Окрім основного диску, який позначений як "Main", є 
можливість створення додаткового диску "Ceph-OSD-Disk", розмір якого 
37 
задається змінною. Цей диск має включену опцію тонкого виділення 
(thin_provisioned = true), що дозволяє ефективніше використовувати сховище 
у vSphere. Таким чином, даний Terraform-ресурс дозволяє автоматизувати і 
стандартизувати процес розгортання віртуальних машин у середовищі 
VMware vSphere, роблячи інфраструктуру гнучкою та керованою кодом. 
Щоб гарантувати створення storage-віртуальних машин саме на 
призначених для цього storage-блейдах, у vCenter було попередньо створено 
відповідні групи та застосовано правила розміщення. Після цього Terraform 
ініціює створення віртуальних машин та автоматизовано встановлює 
необхідні пакети на кожному сервері залежно від його призначення в 
інфраструктурі. 
Для вузлів типу control-plane, compute, балансувальників 
навантаження та систем моніторингу виконується базова установка 
системного оточення, включаючи критичні залежності та пакети, необхідні 
для забезпечення базової функціональності та взаємодії компонентів. 
На хості для OpenStack Deployment додатково встановлюються такі 
компоненти, як kolla-ansible, gitlab-runner та інші утиліти, необхідні для 
подальшого розгортання OpenStack. Саме цей вузол виконує роль 
Ansibleконтролера, звідки запускається процес повної автоматизації 
встановлення та конфігурації хмарної платформи. Він також інтегрується в 
CI/CD-процес як GitLab Runner, відповідальний за запуск пайплайнів. 
Аналогічно, на вузлі Ceph Deployment розгортаються компоненти 
Ansible, GitLab Runner та інші необхідні пакети. Цей сервер, як і OpenStack 
deployment-хост, бере участь у CI/CD-процесі, але вже як контролер для 
автоматизованого розгортання та налаштування кластеру зберігання даних 
на основі Ceph. 
На storage-вузлах передбачене окреме конфігурування: кожному 
серверу додається додатковий диск, спеціально виділений під Ceph-дані. На 
таких вузлах встановлюються лише ті компоненти, які необхідні для 
38 
функціонування Cephкластера. Усі ці дії також автоматизуються через 
Terraform, що забезпечує консистентність, повторюваність та 
стандартизовану інфраструктуру зберігання. 
3.1.4 Шар конфігурації 
Після завершення етапу розгортання обчислювальної інфраструктури 
виконується конфігурація компонентів системи за допомогою Ansible, що 
забезпечує автоматизоване налаштування як підсистеми зберігання, так і 
сервісів OpenStack. 
У межах налаштування Ceph виконується початкова ініціалізація 
кластера, включаючи розгортання та конфігурацію ключових компонентів – 
моніторів (MON) і менеджерів (MGR), які відповідають за керування станом 
кластера та його координацію. Далі здійснюється розгортання демонів 
зберігання (OSD), що забезпечують безпосереднє розміщення даних на 
дискових підсистемах. У процесі конфігурації створюються пули зберігання 
даних (зокрема volumes, backups, images, vms, manila) із налаштуванням 
параметрів автоматичного масштабування placement groups, що дозволяє 
адаптувати систему до змін навантаження. Додатково генеруються ключі 
доступу та keyrings для інтеграції зі службами OpenStack, після чого 
конфігураційні файли та ключі розповсюджуються на всі вузли кластера. 
Конфігурація OpenStack передбачає підготовку інфраструктури до 
розгортання сервісів, включаючи генерацію SSL-сертифікатів для 
забезпечення захищеного доступу до внутрішніх і зовнішніх точок 
підключення. Перед безпосереднім встановленням виконується перевірка 
готовності середовища за допомогою механізмів попереднього контролю 
(prechecks). Подальше розгортання сервісів здійснюється з використанням 
Kolla-Ansible і охоплює ключові компоненти системи, зокрема Keystone, 
Glance, Nova, Neutron, Horizon та інші. На завершальному етапі виконуються 
процедури post-deploy, що включають ініціалізацію сервісів, створення 
базових ресурсів і перевірку їхньої працездатності. 
39 
Застосування автоматизованого підходу до конфігурації забезпечує 
узгодженість налаштувань, зменшує ймовірність помилок і створює 
передумови для відтворюваності інфраструктури у різних середовищах. 
3.1.5 Шар сервісів 
На вузлі розгортання послідовно виконуються етапи автоматизованого 
деплойменту з використанням Kolla-Ansible, зокрема команди *certificates*, 
*bootstrap-servers*, *deploy* та *post-deploy*. На етапі *certificates* 
здійснюється генерація та розгортання сертифікатів для захищеної взаємодії 
компонентів. Етап *bootstrap-servers* забезпечує підготовку вузлів, 
включаючи встановлення необхідних залежностей та базову конфігурацію 
середовища. Під час виконання *deploy* відбувається розгортання сервісів 
OpenStack у вигляді контейнерів у середовищі Docker, що дозволяє 
ізолювати компоненти та спростити їх управління. Завершальний етап *post-
deploy* виконує додаткову ініціалізацію системи, включаючи створення 
ресурсів за замовчуванням, перевірку працездатності та підготовку 
середовища до експлуатації. У результаті формується повністю 
функціональний кластер OpenStack із розподіленими сервісами, які 
працюють у контейнеризованому середовищі. 
3.1.6 Шар спостереження 
Для забезпечення контролю стану інфраструктури та своєчасного 
виявлення відхилень реалізовано окремий шар моніторингу. На виділеному 
вузлі розгортаються компоненти системи спостереження, зокрема 
Prometheus для збору метрик, Grafana для їх візуалізації та Alertmanager для 
обробки та маршрутизації сповіщень. Додатково інтегруються 
спеціалізовані експортери та колектори метрик для сервісів Ceph та 
обчислювального компонента OpenStack – OpenStack Nova, що дозволяє 
отримувати детальну інформацію про стан ресурсів, навантаження та 
продуктивність системи. Такий підхід забезпечує централізований 
40 
моніторинг, підвищує прозорість функціонування інфраструктури та 
створює основу для побудови відмовостійких і самовідновлюваних систем. 
 
Рис. 3.1. Модель взаємодії сервісів OpenStack 
41 
  
Рис. 3.2. Модель роботи Ceph 
3.2 Ланцюжок автоматизації 
Packer пайплайн. Будь-яка зміна образу тригерить збірку, публікацію 
OVF. Terraform пайплайн. Створює віртуальні машини, встановлює базові 
пакети та налаштування для цих хостів. Remote state лежить у Gitlab.  
 
Рис. 3.3. Terraform CI 
Ceph Ansible пайплайн. Використовує динамічний inventory із 
Terraformstate, налаштовує ОС, Ceph і готує вузли до запуску kolla-ansible. 
42 
 
Рис. 3.4. Ceph Ansible CI 
Kolla-ansible пайплайн. На виділеному deployment-хості послідовно 
запускаються сертифікація, bootstrap і деплой OpenStack; фіналізує все 
скрипт postdeploy.  
 
Рис. 3.5. Kolla Ansible Openstack CI 
3.3. Ролі та їхня взаємодія 
У структурі хмари, розгорнутої за допомогою Kolla-Ansible, кожен тип 
вузла виконує чітко визначену роль. Вузли control-plane обслуговують 
критично важливі сервіси керування, включаючи MariaDB-Galera для 
зберігання стану системи, RabbitMQ як систему обміну повідомленнями між 
сервісами, а також OpenStackсервіси Keystone, Glance і Neutron. 
Обчислювальні функції покладено на computeвузли, які використовують 
драйвер nova-compute-vmware та забезпечують підтримку live migration за 
допомогою технології vMotion. Зберігання даних реалізовано через вузли 
storage, які включають компоненти Ceph OSD і MON. Ceph RBD 
використовується як блочне сховище для Cinder, Glance та інших сервісів 
OpenStack. 
43 
  
Рис. 3.6. Базова модель розгортання інфраструктури 
Окремий хост openstack-deployment відповідає за запуск Kolla-Ansible 
та зберігання всіх змінних, пов’язаних із конфігурацією кластеру. Для 
Cephінфраструктури використовується окремий ceph-deployment вузол, що 
виконує всі необхідні Ansible-playbook-и, ізольовано від продуктивних Ceph 
OSD, що забезпечує стабільність та відмовостійкість зберігання. 
Балансування навантаження реалізується за допомогою HAProxy у 
поєднанні з Keepalived, які разом забезпечують єдину віртуальну IP-адресу 
для всіх публічних ендпоїнтів OpenStack. Моніторинг усіх компонентів 
інфраструктури забезпечується за допомогою Prometheus, який 
інтегрований у розгортання.  
3.4 Переваги обраного підходу 
Використаний підхід демонструє високу ефективність завдяки своїй 
повторюваності: кластер може бути повністю відтворений з нуля за менш 
44 
ніж дві години завдяки автоматизованому CI/CD pipeline. Прозорість і аудит 
досягаються через чітку ізоляцію усіх компонентів у відповідних 
репозиторіях: для контейнерів, інфраструктури та конфігурації ведеться 
окреме управління версіями, що дозволяє легко контролювати зміни та 
підтримувати відповідність. В разі необхідності швидкого відкату до 
стабільної версії, достатньо змінити тег образу або версію Terraform-модуля, 
після чого заново запустити пайплайн, що гарантує повернення до 
працездатного стану системи. Масштабування системи не потребує значних 
зусиль: як додавання compute-вузлів, так і розширення пулів Ceph 
виконується автоматизовано на основі декларативного підходу до 
конфігурації, що підвищує ефективність адміністрування та розширення 
хмари.  
Таким чином, програмна реалізація базується на чітко розділених 
рівнях автоматизації: Packer формує образ, Terraform створює ресурси, 
Ansible налаштовує служби, а kolla-ansible розгортає сам OpenStack. Уся 
взаємодія проходить через GitLab CI/CD, що гарантує контрольовані зміни 
й одноманітне середовище для кожного розгортання.  
Висновки до третього розділу 
У третьому розділі кваліфікаційної роботи детально розглянуто етапи 
реалізації автоматизованої системи розгортання хмарної інфраструктури на 
базі OpenStack у середовищі VMware vSphere з інтеграцією Ceph. 
Продемонстровано, що використання сучасних DevOps-інструментів, 
зокрема Packer, Terraform, Ansible, Kolla-Ansible та GitLab, дозволяє 
реалізувати повністю автоматизований процес розгортання – від створення 
віртуальних машин до конфігурації та запуску сервісів у production-
середовищі. 
Застосування багаторівневої архітектури із поділом на шари 
віртуалізації, образів, інфраструктури, конфігурації та сервісів забезпечило 
45 
модульність системи, підвищену гнучкість та відтворюваність процесів 
розгортання. Такий підхід дозволив суттєво спростити адміністрування 
інфраструктури, а також забезпечити її ефективне масштабування 
відповідно до змін навантаження. 
Реалізований ланцюжок автоматизації на основі CI/CD забезпечує 
виконання повного циклу розгортання без ручного втручання, з контролем 
версій інфраструктурного коду та можливістю швидкого відновлення 
стабільного стану системи. Це підвищує надійність експлуатації та знижує 
ризик помилок, пов’язаних із людським фактором. 
Отримані результати підтверджують доцільність застосування 
комплексної автоматизації при побудові хмарних середовищ. Запропонована 
архітектура характеризується масштабованістю, відмовостійкістю та 
адаптивністю до змін вимог, що робить її придатною для використання у 
корпоративних і науково-дослідних ІТ-інфраструктурах. 
Таким чином, реалізована система відповідає сучасним вимогам до 
організації хмарних платформ і демонструє ефективність застосування 
підходу Infrastructure as Code у практичних сценаріях розгортання та 
управління інфраструктурою. 
46 
РОЗДІЛ 4 РОБОТА КОРИСТУВАЧА 
З ПРОГРАМНОЮ СИСТЕМОЮ 
Першим, що зустрічає користувач є логін сторінка OpenStack-у, де 
знаходиться форма, де користувач має заповнити логін та пароль. Стиль 
сайту лаконічний, виконаний в білому та червоному кольорах. 
 
Рис. 4.1. Логін сторінка 
Після заповнення даних для входу, користувач переходить до основної 
сторінки сервісу, де він бачить ліміти усіх сервісів та навігаційну панель. 
  
Рис. 4.2. Головна сторінка сервісу 
47 
«Admin» проєкт вибраний за замовченням. Проєкти можна 
створювати та під різні задачі. У бічній панелі користувач бачить доступні 
сервіси, що розділені тематично. OpenStack має велике різноманіття 
сервісів. Розглянемо функціонал на прикладі створення віртуальної машини 
з усіма відповідними ресурсами (мережа, підмережа, маршрутизатор та 
інші). Для створення віртуальної машини, користувачу потрібно виконати 
наступні дії: 
1. Створити мережу у розділі «Networks». Для створення мережі потрібно 
вказати її назву, вибрати чи вона має бути доступною для спільного 
користування та чи потрібно вмикати «Admin State». Також є можливість 
обрати «Availability Zone Hints» (Зони доступності, у яких може бути 
заплановано роботу агентів DHCP. Залишення цього параметра без 
значення еквівалентно вибору всіх зон доступності) та MTU 
(Максимальний блок передачі. Мінімальний - 68 байт для підмережі IPv4 
і 1280 байт для підмережі IPv6). 
 
Рис. 4.3. Форма для створення мережі 
2. Створити підмережу. Створити підмережу можна одразу при створенні 
самої мережі. Для цього потрібно перейти на розділ «Subnet» та 
заповнити наступні поля: назву підмережі, IP для неї та gateway IP. 
48 
  
Рис. 4.4. Форма для створення підмережі 
3. Створити маршрутизатор для мережі. У OpenStack маршрутизатор 
потрібен для полегшення зв'язку між різними мережами, в тому числі для 
доступу екземплярів у проектних мережах до зовнішніх мереж, таких як 
Інтернет. Для його створення необхідно перейти у розділ «Routers», 
вказати його назву та вказати зовнішню мережу. 
 
Рис. 4.5. Форма для створення маршрутизатору 
49 
4. Створити плаваючий IP. У OpenStack плаваючі IP-адреси необхідні для 
забезпечення зовнішнього доступу до віртуальних машин (ВМ) у 
хмарному середовищі. Вони надають публічну статичну IP-адресу, яку 
можна динамічно перепризначати різним ВМ, забезпечуючи високу 
доступність, відмовостійкість та обхід відмов. Без плаваючих IP-адрес 
доступ до віртуальних машин із зовнішнього світу або підтримка 
постійних публічних IP-адрес під час міграції віртуальних машин були б 
неможливими. Для створення потрібно просто вказати назву та вибрати 
Pool, з якого виділиться адреса. 
 
Рис. 4.6. Форма для створення плаваючої IP-адреси 
5. Створити віртуальну машину. Для її створення потрібно перейти у розділ 
Compute (Instances) та вибрати «Launch Instance». При створенні нової 
віртуальної машини, потрібно зробити наступне: 
a. У першому розділі «Details» потрібно вказати назву, кількість 
віртуальних машин та зону доступу, у якій буде створено ресурс. 
50 
 
Рис. 4.7. Форма для створення нової віртуальної машини. Розділ «Details» 
b. Після цього, у розділі «Source» потрібно вказати Джерело екземпляра. 
Це шаблон, який використовується для створення віртуальної машини. 
Користувач може використовувати зображення, знімок екземпляра, 
том або знімок тома (якщо увімкнено). Є також можливість 
використовувати постійне сховище, створивши новий том. Також 
потрібно визначити розмір диску для нової ВМ. 
 
Рис. 4.8. Форма для створення нової віртуальної машини. Розділ «Source»  
51 
c. Наступним кроком користувач має обрати кількість ресурсів (CPU, 
RAM, Disk) для віртуальної машини. Варіанти вибору (flavors) 
визначаються адміністратором. Кожен flavor представляє собою 
заздалегідь налаштовану конфігурацію ресурсів. При виборі 
конфігурації необхідно керуватись специфікою задач, які буде 
виконувати віртуальна машина. Для простих завдань достатньо 
меншої кількості ресурсів (наприклад, конфігурація «mini» з одним 
VCPU та 1 GB RAM). Для задач, які передбачають роботу з 
інтенсивними обчисленнями, великими обсягами даних чи 
підвищеними вимогами до продуктивності, рекомендується вибирати 
більш потужні flavors з більшим обсягом пам’яті та процесорних 
ресурсів. 
 
Рис. 4.9. Форма для створення нової віртуальної машини. Розділ «Flavor» 
d. Після того, як користувач обрав ресурси для нової віртуальної 
машини, потрібно вказати мережу, в якій вона буде створена. 
52 
 
Рис. 4.10. Форма для створення нової віртуальної 
машини. Розділ «Networks» 
e. Наступним кроком є вибір групи захисту. У OpenStack групи безпеки 
мають вирішальне значення для мережевої безпеки, виконуючи роль 
віртуальних брандмауерів, які контролюють трафік до і з віртуальних 
машин. Вони визначають, який вхідний і вихідний трафік дозволено, 
підвищуючи безпеку хмарного середовища і запобігаючи 
несанкціонованому доступу. 
 
Рис. 4.11. Форма для створення нової віртуальної 
машини. Розділ «Security Groups» 
53 
f. Обрати SSH Keypair для доступу до віртуальної машини. Тут є опція 
обрати існуючу, створити нову або імпортувати зі свого локального 
сховища SSH Keypair. 
 
Рис. 4.12. Форма для створення нової віртуальної 
машини. Розділ «Key Pair» 
g. Configuration. Також є можливість використати customization script, що 
виконається при старті віртуальної машини. Для цього потрібно 
завантажити cloud-config файл  
  
Рис. 4.13. Форма для створення нової віртуальної 
машини. Розділ «Configuration»  
54 
h. Launch Instance. Після того, як усі поля заповнені, користувач може 
створити ВМ, натиснувши кнопку «Launch Instance».  
  
Рис. 4.14. Створена віртуальна машина 
Висновки до четвертого розділу 
У четвертому розділі кваліфікаційної роботи розглянуто практичні 
аспекти взаємодії користувача з реалізованою хмарною платформою на базі 
OpenStack. Описано повний цикл створення віртуального середовища – від 
авторизації користувача до розгортання віртуальної машини з 
налаштуванням мережевої інфраструктури, включаючи створення мережі, 
підмережі, маршрутизатора та призначення плаваючої IP-адреси. 
Особливу увагу приділено веб-інтерфейсу OpenStack Horizon, який 
забезпечує зручний доступ до функціоналу системи та дозволяє виконувати 
складні операції управління інфраструктурою без використання командного 
рядка або API. За допомогою Horizon користувач отримує можливість 
керувати обчислювальними ресурсами, мережевими налаштуваннями, 
правилами безпеки та доступами в межах окремих проєктів. 
Покрокове виконання операцій супроводжується ілюстративними 
матеріалами, що підтверджують зручність використання системи та логічну 
послідовність дій при роботі з хмарною інфраструктурою. Це дозволяє 
знизити поріг входу для користувачів і спростити процес адміністрування. 
Отримані результати демонструють, що реалізована система 
забезпечує повноцінну взаємодію користувача з хмарним середовищем – від 
базових операцій управління ресурсами до розгортання складних сервісів. 
55 
Завдяки використанню стандартів OpenStack платформа характеризується 
масштабованістю, гнучкістю та можливістю адаптації до різних сценаріїв 
використання – як у невеликих інфраструктурах, так і в корпоративному 
середовищі. 
56 
ВИСНОВКИ 
У процесі виконання кваліфікаційної роботи було комплексно 
досліджено та реалізовано автоматизовану систему розгортання хмарної 
інфраструктури на базі OpenStack у середовищі VMware vSphere з 
інтеграцією Ceph. Робота охоплює повний життєвий цикл побудови 
інфраструктури – від аналізу предметної області та існуючих рішень до 
проєктування, реалізації та практичної перевірки функціонування системи. 
У першому розділі було визначено мету, завдання та предмет 
дослідження, а також обґрунтовано актуальність автоматизації розгортання 
хмарних середовищ у контексті сучасних вимог до гнучкості, 
масштабованості та відмовостійкості ІТ-інфраструктур. Проведений аналіз 
показав доцільність використання підходу Infrastructure as Code як основи 
для побудови керованих і відтворюваних систем. 
У другому розділі здійснено порівняльний аналіз існуючих рішень для 
автоматизації розгортання OpenStack та альтернатив платформ віртуалізації. 
Встановлено, що більшість із них мають обмеження щодо інтеграції, 
складності впровадження або масштабованості. На основі цього 
обґрунтовано вибір технологічного стеку, який включає VMware vSphere як 
базову платформу віртуалізації та Kolla-Ansible як інструмент 
контейнеризованого розгортання OpenStack. 
У третьому розділі детально описано архітектуру та процес реалізації 
системи автоматизації. Побудовано багаторівневу модель інфраструктури з 
поділом на шари віртуалізації, образів, інфраструктури, конфігурації, 
сервісів і моніторингу. Реалізація виконана з використанням сучасних 
DevOps-інструментів, зокрема Packer, Terraform, Ansible, Kolla-Ansible та 
GitLab. Запропонований підхід забезпечує повну автоматизацію процесів – 
від підготовки образів і створення віртуальних ресурсів до конфігурації 
сервісів і перевірки їх працездатності. 
57 
У четвертому розділі розглянуто практичні аспекти взаємодії 
користувача з реалізованою системою. Показано можливості управління 
інфраструктурою через веб-інтерфейс OpenStack Horizon, що забезпечує 
зручний доступ до ресурсів хмари та спрощує виконання типових операцій 
без необхідності використання командного рядка. 
У межах роботи було на практиці застосовано та вдосконалено 
навички автоматизації інфраструктури, проєктування складних систем і 
використання сучасних DevOps-підходів. Реалізовано повністю 
автоматизований процес розгортання, при якому запуск CI/CD-конвеєра 
після внесення змін у репозиторій ініціює повний цикл створення, 
налаштування та перевірки інфраструктури. Такий підхід забезпечує високу 
повторюваність, прозорість і контрольованість процесів. 
Розроблена система характеризується модульною структурою, що 
передбачає розділення функціональних ролей між вузлами керування, 
обчислювальними ресурсами, підсистемою зберігання та вузлами 
розгортання. Це дозволяє забезпечити масштабованість, спростити 
адміністрування та реалізувати можливість швидкого відновлення системи 
або її окремих компонентів. 
У результаті виконання кваліфікаційної роботи створено ефективне, 
відмовостійке та масштабоване середовище для розгортання хмарної 
платформи OpenStack, яке може бути використане як основа для побудови 
приватних або гібридних хмар у корпоративних і науково-дослідних ІТ-
системах. Запропонований підхід підтверджує ефективність застосування 
концепції Infrastructure as Code та сучасних засобів автоматизації для 
побудови складних інформаційних інфраструктур. 
58 
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ 
1. McIntosh S., Hata H. Cross-Project Flakiness: A Case Study of the OpenStack 
Ecosystem // arXiv preprint. 2026. URL: https://arxiv.org/abs/2602.09311 
2. Kihl M., Larsson L. FedApp: a Research Sandbox for Application 
Orchestration in Federated Clouds using OpenStack // arXiv preprint. 2021. 
URL: https://arxiv.org/abs/2109.01480 
3. Yadav P., Rathi V. K. KupenStack: Kubernetes based Cloud Native OpenStack 
// arXiv preprint. 2021. URL: https://arxiv.org/abs/2106.02956 
4. Bollig E. F., Allan G. T. Leveraging OpenStack and Ceph for a Controlled-
Access Data Cloud // arXiv preprint. 2018. URL: 
https://arxiv.org/abs/1807.08657 
5. Fifield T., Fleming D., Gentle A. та ін. OpenStack Operations Guide. 
Sebastopol: O’Reilly Media, 2014. URL: 
https://docs.openstack.org/operations-guide/ 
6. Morris K. Infrastructure as Code: Managing Servers in the Cloud. Sebastopol: 
O’Reilly Media, 2016. URL: 
https://www.oreilly.com/library/view/infrastructure-as-
code/9781491924358/ 
7. Brikman Y. Terraform: Up and Running. Sebastopol: O’Reilly Media, 2017. 
URL: https://www.oreilly.com/library/view/terraform-up-
and/9781491977071/ 
8. Geerling J. Ansible for DevOps. 2015. URL: 
https://www.ansiblefordevops.com/ 
9. Erl T., Puttini R., Mahmood Z. Cloud Computing: Concepts, Technology & 
Architecture. Upper Saddle River: Prentice Hall, 2013. URL: 
https://www.pearson.com/en-us/subject-catalog/p/cloud-computing-
concepts-technology-architecture/P200000003022 
59 
10. Solberg M. OpenStack for Architects. Birmingham: Packt Publishing, 2015. 
URL: https://www.packtpub.com/product/openstack-for-
architects/9781784394905 
11. Про хмарні послуги: Закон України від 17.02.2022 р. № 2075-IX 
[Електронний ресурс]. – Режим доступу: 
https://zakon.rada.gov.ua/laws/show/207520 (дата звернення: 01.06.2025).  
12. ITGLOBAL.com.  Міграція  із  VMware  в  OpenStack 
[Електронний ресурс]. – 2019. – URL: 
https://itglobal.com/ruru/company/blog/migration-vmware-vs-openstack/ 
(дата звернення: 12.04.2026).  
13. Ansible Documentation [Електронний ресурс]. – Red Hat, 2023. – URL: 
https://docs.ansible.com (дата звернення: 20.04.2026).  
14. Brikman Y. Terraform: Up and Running – Writing Infrastructure as Code. 3rd 
ed. – Sebastopol : O’Reilly Media, 2022. – 460 p. – (Книга).  
15. Bumgardner V. K. C. OpenStack in Action. – Shelter Island : Manning 
Publications, 2016. – 385 p. – (Книга).  
16. Cavanaugh S. Using Ansible and Packer, From Provisioning to Orchestration 
[Електронний ресурс] // Red Hat Blog. – 03.10.2022. – URL: 
https://www.redhat.com/en/blog/ansible-and-packer-why-they-are-better-
together (дата звернення: 23.04.2026).  
17. Ceph Documentation [Електронний ресурс]. – Ceph Foundation, 2023. – 
URL: https://docs.ceph.com (дата звернення: 24.04.2026).  
18. Ciptaningtyas H. T., Hariadi R. R., Husni M., Ghozali Kh., Sholikah R. W., 
Setyadharma I. M. D. OpenStack Implementation using Multinode 
Deployment Method for Private Cloud Computing Infrastructure 
[Електронний ресурс] // Proc. of 2023 IEEE Int. Seminar on Intelligent 
Technology and Its Applications (ISITIA 2023). – IEEE, 2023. – (Матеріали 
конференції).  
60 
19. Create a custom OpenStack image with Packer [Електронний ресурс]. – 
OVHcloud, 2018. – URL: https://help.ovhcloud.com/csm/en-public-cloud-
computepacker-openstack-builder (дата звернення: 01.04.2026).  
20. Garcia M. Full Stack Automation with Ansible and OpenStack [Електронний 
ресурс] // Red Hat Blog. – 13.10.2016. – URL: 
https://www.redhat.com/en/blog/full-stack-automation-ansible-and-
openstack (дата звернення: 01.04.2026).  
21. GitLab CI/CD Documentation [Електронний ресурс]. – GitLab, 2024. – 
URL: https://docs.gitlab.com/ee/ci (дата звернення: 01.05.2026).  
22. Humble J., Farley D. Continuous Delivery: Reliable Software Releases 
through Build, Test, and Deployment Automation. – Boston : Addison-
Wesley, 2010. – 463 p. – (Книга).  
23. Islam M. OpenStack Automation with Ansible [Електронний ресурс] //  
24. Analog  Devices  –  Technical  Articles.  –  01.09.2019.  –  
25. URL: https://www.analog.com/en/technical-articles/openstack-automation-
withansible.html (дата звернення: 10.04.2026).  
26. Kim G., Humble J., Debois P., Willis J. The DevOps Handbook: How to 
Create World-Class Agility, Reliability, and Security in Technology 
Organizations. – Portland : IT Revolution Press, 2016. – 480 p. – (Книга).  
27. Meijer B., Hochstein L., Moser R. Ansible: Up and Running – Automating 
Configuration Management and Deployment the Easy Way. 3rd ed. – 
Sebastopol : O’Reilly Media, 2022. – 448 p. – (Книга).  
28. Mell P., Grance T. The NIST Definition of Cloud Computing [Електронний 
ресурс] // NIST Special Publication 800-145. – Gaithersburg (MD) : NIST, 
2011. – URL: 
https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-
145.pdf (дата звернення: 10.04.2026).  
29. Morris K. Infrastructure as Code: Dynamic Systems for the Cloud Age. 2nd 
ed. – Sebastopol : O’Reilly Media, 2021. – 427 p. – (Книга).  
61 
30. OpenStack  Documentation  [Електронний  ресурс].  –  
31. OpenInfra Foundation, 2023. – URL: https://docs.openstack.org (дата 
звернення: 18.04.2026).  
32. Packer Documentation [Електронний ресурс]. – HashiCorp, 2023. – URL: 
https://developer.hashicorp.com/packer/docs (дата звернення: 18.04.2026).  
33. Self-service and Automation Using OpenStack for VMware vSphere 
[Електронний ресурс] : White Paper. – Platform9, 2017. –  
34. URL: https://platform9.com/media/self-service-and-automation-using-
openstack-forvmware-vsphere.pdf (дата звернення: 21.04.2026).  
35. Terraform Documentation [Електронний ресурс]. – HashiCorp, 2023. – 
URL: https://developer.hashicorp.com/terraform/docs (дата звернення: 
01.04.2026).  
36. VMware vSphere Product Documentation [Електронний ресурс]. – 
VMware, 2023. – URL: https://docs.vmware.com/en/VMware-vSphere (дата 
звернення: 22.04.2026).  
37. Vogel A., Griebler D., Maron C. A. F., Schepke C., Fernandes L. G. Private 
IaaS Clouds: A Comparative Analysis of OpenNebula, CloudStack and 
OpenStack [Електронний ресурс] // Proc. of 24th Euromicro Int. Conf. on 
Parallel, Distributed and Network-Based Processing (PDP 2016). – IEEE, 
2016. – (Матеріали конференції).
62 
Додаток А  
Автоматизація розгортання та управління хмарною інфраструктурою 
OpenStack на базі VMware ESXi та vCenter з використанням Packer і 
Ansible (Програмний код) 
Openstack/compute/modules/compute/main.tf  
data "template_cloudinit_config" "netplan" {   count = 
var.prepare_bridge ? 1 : 0  
  
  gzip          = false   base64_encode = false  
   part {  
    filename     = "50-cloud-init.yaml"     content_type = 
"text/cloud-config"     content      = <<EOF #cloud-config users:  
- default   - name: administrator     gecos: Cloud Administrator     
sudo: ALL=(ALL) NOPASSWD:ALL     lock_passwd: false     shell: 
/bin/bash chpasswd:   list: |     administrator:Admin123!  
  expire: false ssh_pwauth: true   
hostname: ${var.vsphere_compute_vm_name} create_hostname_file: true  
 packages:  
- openvswitch-switch  
- bridge-utils  write_files:  
- path: /etc/sysctl.d/99-kolla.conf     permissions: "0644"     
content: |       net.ipv4.ip_forward = 1       net.bridge.bridge-nf-
call-iptables = 1       net.bridge.bridge-nf-call-ip6tables = 1  
  
- path: /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg     
permissions: "0644"     content: |       network:  
        config: disabled  
  
- path: /etc/netplan/100-local.yaml     permissions: "0644"     
content: |       network:         version: 2         renderer: 
networkd         ethernets:           ens192:  
            dhcp4: true           ens224:  
            dhcp4: false             optional: true  
 runcmd:  
- [ sh, -xc, "nmcli device set ens192 managed no || true" ]   - [ 
sh, -xc, "apt-get update && apt-get -y dist-upgrade" ]  
- [ sh, -xc, "modprobe br_netfilter" ]  
- [ sh, -xc, "sysctl --system" ]  
 network: version: 2  
  renderer: networkd   ethernets:     ens192:  
      dhcp4: true       set-name: ens192     ens224:  
      dhcp4: false       optional: true  
EOF  
  }  
}   
resource "vsphere_virtual_machine" "vm" {   name                 = 
var.vsphere_compute_vm_name   resource_pool_id     = 
var.resource_pool_id # 
data.vsphere_compute_cluster.cluster.resource_pool_id  
  datastore_cluster_id = 
data.vsphere_datastore_cluster.datastore_cluster.id   num_cpus             
= var.vsphere_cpu_count   cpu_reservation      = 0 
#var.vsphere_cpu_count   num_cores_per_socket = 
var.num_cores_per_socket   memory               = 
var.vphere_memory_size   memory_reservation   = 0 
#var.vphere_memory_size   guest_id             = "ubuntu64Guest"  
  
  nested_hv_enabled = true   ept_rvi_mode      = "on"   hv_mode           
= "hvOn"  
  
  network_interface {  
    network_id = data.vsphere_network.network.id  
  }  
  
dynamic "network_interface" {  
    for_each = var.prepare_bridge ? [1] : []     content {  
      network_id = data.vsphere_network.network.id  
    }  
  }    clone {  
    template_uuid = data.vsphere_virtual_machine.template.id  
     customize {       linux_options {  
        host_name = var.vsphere_compute_vm_name  
        domain    = "${var.vsphere_compute_vm_name}.${var.dns_zone}"  
      }  
      network_interface {}  
  
      dynamic "network_interface" {         for_each = 
var.prepare_bridge ? [1] : []         content {}  
      }  
    }  
  }  
  
  # Inject the cloud-init DHCP netplan   extra_config = 
var.prepare_bridge ? {  
    "guestinfo.userdata"          =  
base64encode(data.template_cloudinit_config.netplan.0.rendered)  
    "guestinfo.userdata.encoding" = "base64"  
  } : {}    disk {  
    label            = "Main"  
    size             = var.vsphere_disk_size     thin_provisioned = 
true  
  }   
  dynamic "disk" {  
    for_each = var.add_empty_disk ? [1] : []     content {       
label = "Ceph-OSD-Disk"       size  = var.additional_disk_size       
# eagerly_scrub    = false       thin_provisioned = false       
unit_number      = 1  
    }  
  }  
}   
resource "null_resource" "prepare_bridge_cleanup" {   count = 
var.prepare_bridge ? 1 : 0  
   triggers = {  
    vm_id    = vsphere_virtual_machine.vm.id  
    userdata = data.template_cloudinit_config.netplan[0].rendered  
64 
  }    connection {     type        = "ssh"  
    host        = vsphere_virtual_machine.vm.default_ip_address     
user        = "ubuntu"  
    private_key = file(var.private_key_filename)  
  }   
  provisioner "remote-exec" {     inline = [  
      "sudo rm -f /etc/netplan/99-netcfg-vmware.yaml",  
      "sudo netplan generate",  
      "sudo netplan apply",  
    ]  
  }  
}  
  
  
  
Openstack/compute/compute.tf  
locals {   node_pools = {     deployment = {       count  = 1  
      cpu    = var.openstack_deployment_node_cpu       memory = 
var.openstack_deployment_node_memory  
    }     ceph = {       count  = 1  
      cpu    = var.openstack_ceph_deployment_node_cpu       memory = 
var.openstack_ceph_deployment_node_memory  
    }     controlplane = {  
      count  = var.openstack_controlplane_nodes_count       cpu    = 
var.openstack_controlplane_nodes_cpu       memory = 
var.openstack_controlplane_nodes_memory  
    }     workers = {  
      count  = var.openstack_worker_nodes_count       cpu    = 
var.openstack_worker_nodes_cpu       memory = 
var.openstack_worker_nodes_memory  
    }     storage = {       count  = 
var.openstack_storage_nodes_count       cpu    = 
var.openstack_storage_nodes_cpu       memory = 
var.openstack_storage_nodes_memory  
    }  
    loadbalancer = {  
      count  = var.openstack_loadbalancer_nodes_count       cpu    = 
var.openstack_loadbalancer_nodes_cpu       memory = 
var.openstack_loadbalancer_nodes_memory  
    }     monitoring = {  
      count  = var.openstack_monitoring_nodes_count       cpu    = 
var.openstack_monitoring_nodes_cpu       memory = 
var.openstack_monitoring_nodes_memory  
    }  
  }  
}   
resource "vsphere_resource_pool" "pools" {   for_each = 
local.node_pools  
  
  name                    = "openstack-${each.key}-pool"   
parent_resource_pool_id = each.key == "storage" ? 
data.vsphere_compute_cluster.openstack_storage_cluster.resource_pool
_id : data.vsphere_compute_cluster.cluster.resource_pool_id  
  
  cpu_reservation = each.value.count * each.value.cpu * 2600   
cpu_share_level = "normal"  
65 
  
  memory_reservation = each.value.count * each.value.memory   
memory_share_level = "normal"  
}   
module "openstack_deployment_node" {   source = "./modules/compute"   
vsphere_compute_vm_name = "openstack-deployment-host"  
  
  vsphere_template_path = var.vsphere_template_path  
  
  vsphere_datastore_cluster    = var.vsphere_datastore_cluster   
vsphere_compute_cluster_name = var.vsphere_compute_cluster_name  
  
  resource_pool_id = vsphere_resource_pool.pools["deployment"].id  
  
  vsphere_network_name = var.vsphere_network_name   datacenter_name      
= var.datacenter_name  
  
  vphere_memory_size   = var.openstack_deployment_node_memory   
vsphere_cpu_count    = var.openstack_deployment_node_cpu   
num_cores_per_socket = var.openstack_deployment_node_cpu_num_cores   
vsphere_disk_size    = var.openstack_deployment_node_disk_size  
  
  dns_zone = var.vsphere_dns_zone  
}  
module "openstack_ceph_deployment_node" {   source = 
"./modules/compute"  
  
  vsphere_compute_vm_name = "openstack-ceph-deployment-node"  
  
  vsphere_template_path = var.vsphere_template_path  
  
  vsphere_datastore_cluster    = var.vsphere_datastore_cluster   
vsphere_compute_cluster_name = var.vsphere_compute_cluster_name  
  
  resource_pool_id = vsphere_resource_pool.pools["ceph"].id  
  
  vsphere_network_name = var.vsphere_network_name  
  datacenter_name      = var.datacenter_name  
  
  vphere_memory_size   = var.openstack_ceph_deployment_node_memory   
vsphere_cpu_count    = var.openstack_ceph_deployment_node_cpu   
num_cores_per_socket = 
var.openstack_ceph_deployment_node_cpu_num_cores   vsphere_disk_size    
= var.openstack_ceph_deployment_node_disk_size  
  
  dns_zone = var.vsphere_dns_zone  
}   
module "openstack_controlplane_nodes" {   source = 
"./modules/compute"  
  
  count = var.openstack_controlplane_nodes_count  
  
  vsphere_compute_vm_name = "openstack-controlplane-${count.index + 
1}"  
  
66 
  vsphere_template_path = var.vsphere_template_path  
  
  vsphere_datastore_cluster    = var.vsphere_datastore_cluster   
vsphere_compute_cluster_name = var.vsphere_compute_cluster_name  
  
  resource_pool_id = vsphere_resource_pool.pools["controlplane"].id  
  
  # meta_data = module.cloud_init_controlplanes.*.metadata_rendered   
# user_data = module.cloud_init_controlplanes.*.userdata_rendered  
  
  vsphere_network_name = var.vsphere_network_name   datacenter_name      
= var.datacenter_name  
  
  vphere_memory_size   = var.openstack_controlplane_nodes_memory   
vsphere_cpu_count    = var.openstack_controlplane_nodes_cpu   
num_cores_per_socket = 
var.openstack_controlplane_nodes_cpu_num_cores   vsphere_disk_size    
= var.openstack_controlplane_nodes_disk_size  
  
  dns_zone = var.vsphere_dns_zone  
}   
module "openstack_worker_nodes" {   source = "./modules/compute"  
  
  count = var.openstack_worker_nodes_count  
  
  vsphere_compute_vm_name = "openstack-worker-${count.index + 1}"  
  
  vsphere_template_path = var.vsphere_template_path  
  
  vsphere_datastore_cluster    = var.vsphere_datastore_cluster   
vsphere_compute_cluster_name = var.vsphere_compute_cluster_name  
  
  resource_pool_id = vsphere_resource_pool.pools["workers"].id  
  
  vsphere_network_name = var.vsphere_network_name   datacenter_name      
= var.datacenter_name  
  
  vphere_memory_size   = var.openstack_worker_nodes_memory   
vsphere_cpu_count    = var.openstack_worker_nodes_cpu   
num_cores_per_socket = var.openstack_worker_nodes_cpu_num_cores   
vsphere_disk_size    = var.openstack_worker_nodes_disk_size  
  
  dns_zone = var.vsphere_dns_zone  
  
  prepare_bridge       = true  
  private_key_filename = var.private_key_filename  
}  
  
module "openstack_storage_nodes" {   source = "./modules/compute"  
  
  count = var.openstack_storage_nodes_count  
  
  vsphere_compute_vm_name = "openstack-storage-${count.index + 1}"  
  
  vsphere_template_path = var.vsphere_template_path  
67 
  
  resource_pool_id = vsphere_resource_pool.pools["storage"].id  
  
  vsphere_datastore_cluster    = "Openstack-Storage" # 
var.vsphere_datastore_cluster  
  vsphere_compute_cluster_name = "Openstack-Storage" # 
var.vsphere_compute_cluster_name  
  
  vsphere_network_name = var.vsphere_network_name   datacenter_name      
= var.datacenter_name  
  
  vphere_memory_size   = var.openstack_storage_nodes_memory   
vsphere_cpu_count    = var.openstack_storage_nodes_cpu   
num_cores_per_socket = var.openstack_storage_nodes_cpu_num_cores   
vsphere_disk_size    = var.openstack_storage_nodes_disk_size  
  
  dns_zone = var.vsphere_dns_zone  
  
  add_empty_disk       = true   additional_disk_size = 1000  
}   
module "openstack_loadbalancer_nodes" {   source = 
"./modules/compute"  
  
  count = var.openstack_loadbalancer_nodes_count   
vsphere_compute_vm_name = "openstack-loadbalancer-${count.index + 
1}"  
  
  vsphere_template_path = var.vsphere_template_path  
  
  vsphere_datastore_cluster    = var.vsphere_datastore_cluster   
vsphere_compute_cluster_name = var.vsphere_compute_cluster_name  
  resource_pool_id             = 
vsphere_resource_pool.pools["loadbalancer"].id  
  
  vsphere_network_name = var.vsphere_network_name   datacenter_name      
= var.datacenter_name  
  
  vphere_memory_size   = var.openstack_loadbalancer_nodes_memory   
vsphere_cpu_count    = var.openstack_loadbalancer_nodes_cpu   
num_cores_per_socket = 
var.openstack_loadbalancer_nodes_cpu_num_cores   vsphere_disk_size    
= var.openstack_loadbalancer_nodes_disk_size  
  
  dns_zone = var.vsphere_dns_zone  
  
  prepare_bridge       = true  
  private_key_filename = var.private_key_filename  
}   
module "openstack_monitoring_nodes" {   source = "./modules/compute"  
  
  count = var.openstack_monitoring_nodes_count  
  
  vsphere_compute_vm_name = "openstack-monitoring-${count.index + 
1}"  
  
68 
  vsphere_template_path = var.vsphere_template_path  
  
  vsphere_datastore_cluster    = var.vsphere_datastore_cluster   
vsphere_compute_cluster_name = var.vsphere_compute_cluster_name   
resource_pool_id             = 
vsphere_resource_pool.pools["monitoring"].id  
  
  vsphere_network_name = var.vsphere_network_name   datacenter_name      
= var.datacenter_name  
  
  vphere_memory_size   = var.openstack_monitoring_nodes_memory   
vsphere_cpu_count    = var.openstack_monitoring_nodes_cpu   
num_cores_per_socket = var.openstack_monitoring_nodes_cpu_num_cores   
vsphere_disk_size    = var.openstack_monitoring_nodes_disk_size  
  
  dns_zone = var.vsphere_dns_zone  
}   
data "vsphere_datacenter" "datacenter" {   name = 
var.datacenter_name  
}   
data "vsphere_compute_cluster" "cluster" {   name          = 
var.vsphere_compute_cluster_name   datacenter_id = 
data.vsphere_datacenter.datacenter.id  
}  
data "vsphere_compute_cluster" "openstack_storage_cluster" {   name          
= "Openstack-Storage"  
  datacenter_id = data.vsphere_datacenter.datacenter.id  
}  
resource "vsphere_compute_cluster_vm_anti_affinity_rule" 
"openstack_anti_affinity"  
{  
  name               = "openstack-nodes-anti-affinity"   
compute_cluster_id = data.vsphere_compute_cluster.cluster.id  
  
  virtual_machine_ids = concat(  
    [module.openstack_deployment_node.vm_id],     
[module.openstack_ceph_deployment_node.vm_id],     
module.openstack_controlplane_nodes.*.vm_id,     
module.openstack_worker_nodes.*.vm_id,     
module.openstack_loadbalancer_nodes.*.vm_id,     
module.openstack_monitoring_nodes.*.vm_id,  
  )   
  mandatory = true  
}  
Openstack/compute/deployment_host_ceph.tf resource "gitlab_user_runner" 
"ceph_runner" {   runner_type = "project_type"   project_id  = 
var.project_id  
  
  tag_list = ["ceph"]   untagged = false  
  
  description = "ceph runner"  
} locals {    ##Tools  
  deploy_script_ceph_tools = 
file("${path.module}/config/ceph_tools.sh")  
  
69 
  ## Gitlab Runner  
  deploy_script_install_gitlab_runner_ceph = 
templatefile("${path.module}/config/gitlab-runner.sh", {     
registration_token = gitlab_user_runner.ceph_runner.token     
gitlab_host        = var.gitlab_base_url  
  })  
  
  ## Hosts for ceph host   write_files_ceph = [  
    {  
      path        = "/etc/hosts"       permissions = "0644"       
owner       = "root:adm"  
      content = base64encode(templatefile("config/hosts.tpl", {         
controlplane_hosts = formatlist("%s %s", 
module.openstack_controlplane_nodes.*.vm_ip, 
module.openstack_controlplane_nodes.*.vm_name)         worker_hosts       
= formatlist("%s %s",  
module.openstack_worker_nodes.*.vm_ip, 
module.openstack_worker_nodes.*.vm_name)         storage_hosts      
= formatlist("%s %s",  
module.openstack_storage_nodes.*.vm_ip, 
module.openstack_storage_nodes.*.vm_name)         loadbalancer_hosts 
= formatlist("%s %s", module.openstack_loadbalancer_nodes.*.vm_ip, 
module.openstack_loadbalancer_nodes.*.vm_name)         
monitoring_hosts   = formatlist("%s %s", 
module.openstack_monitoring_nodes.*.vm_ip, 
module.openstack_monitoring_nodes.*.vm_name)  
        self_name          = 
module.openstack_ceph_deployment_node.vm_name  
      }))  
    },     {  
      path        = "/home/ubuntu/ceph/ceph_hosts"       permissions 
= "0644"       owner       = "ubuntu:ubuntu"  
      content = base64encode(templatefile("config/ceph_hosts.tpl", {         
storage_hosts      = formatlist("%s", 
module.openstack_storage_nodes.*.vm_name)         storage_ips        
= formatlist("%s", module.openstack_storage_nodes.*.vm_ip)         
keyring_targets    =  
concat(["${module.openstack_deployment_node.vm_name}"], 
module.openstack_worker_nodes[*].vm_name)  
        keyring_target_ips = 
concat(["${module.openstack_deployment_node.vm_ip}"], 
module.openstack_worker_nodes[*].vm_ip)  
      }))  
    }  
  ]  
  
  deploy_script_etc_hosts_ceph =  
templatefile("${path.module}/config/write_files.sh", {     
write_files = local.write_files_ceph  
  })  
  
  ##PREPARE CEPH DEPLOYMENT HOST   
prepare_ceph_deploy_script_deployment = 
file("${path.module}/config/prepare_ceph_deployment.sh")  
}   
70 
resource "null_resource" "install_ceph_gitlab_runner" {   triggers = 
{     data = jsonencode(merge(  
      {  
        deploy = local.deploy_script_install_gitlab_runner_ceph         
host   = module.openstack_ceph_deployment_node.vm_ip  
      }  
    ))  
  }    connection {     type        = "ssh"     user        = 
"ubuntu"  
    host        = module.openstack_ceph_deployment_node.vm_ip     
private_key = file(var.private_key_filename)     agent       = true  
  }   
  provisioner "file" {  
    content     = local.deploy_script_install_gitlab_runner_ceph     
destination = "${local.deploy_home_dir}/install.sh"  
  }  
  provisioner "remote-exec" {  
    inline = [  
      "chmod +x ${local.deploy_home_dir}/install.sh",  
      "sudo ${local.deploy_home_dir}/install.sh",  
      # "rm -f ${local.deploy_home_dir}/install.sh",  
    ]  
  }  
}   
resource "null_resource" "install_ceph_tools" {   triggers = {     
data = jsonencode(merge(  
      {  
        deploy = local.deploy_script_ceph_tools         host   = 
module.openstack_ceph_deployment_node.vm_ip  
      }  
    ))  
  }    connection {     type        = "ssh"     user        = 
"ubuntu"  
    host        = module.openstack_ceph_deployment_node.vm_ip     
private_key = file(var.private_key_filename)     agent       = true  
  }   
  provisioner "file" {  
    content     = local.deploy_script_ceph_tools     destination = 
"${local.deploy_home_dir}/tools.sh"  
  }  
  provisioner "remote-exec" {     inline = [  
      "chmod +x ${local.deploy_home_dir}/tools.sh",  
      "sudo ${local.deploy_home_dir}/tools.sh",  
      # "rm -f ${local.deploy_home_dir}/tools.sh",  
    ]  
  }  
}   
resource "null_resource" "deployment_etc_host_ceph" {   triggers = {     
data = jsonencode(merge(  
      {  
        deploy = local.deploy_script_etc_hosts_ceph         host   = 
module.openstack_ceph_deployment_node.vm_ip  
      }  
    ))  
  }    connection {     type        = "ssh"     user        = 
"ubuntu"  
71 
    host        = module.openstack_ceph_deployment_node.vm_ip     
private_key = file(var.private_key_filename)     agent       = true  
  }   
  provisioner "file" {  
    content     = local.deploy_script_etc_hosts_ceph     destination 
= "${local.deploy_home_dir}/write_files.sh"  
  }  
  provisioner "remote-exec" {     inline = [  
      "chmod +x ${local.deploy_home_dir}/write_files.sh",  
      "sudo ${local.deploy_home_dir}/write_files.sh",  
    ]  
  }   
  depends_on = [  
    null_resource.install_tools  
  ] }  
resource "null_resource" "prepare_ceph_deployment" {   triggers = {     
data = jsonencode(merge(  
      {  
        deploy = local.prepare_ceph_deploy_script_deployment         
hosts  = module.openstack_ceph_deployment_node.vm_ip  
      }  
    ))  
  }    connection {     type        = "ssh"     user        = 
"ubuntu"  
    host        = module.openstack_ceph_deployment_node.vm_ip     
private_key = file(var.private_key_filename)     agent       = true  
  }   
  provisioner "file" {  
    content     = local.prepare_ceph_deploy_script_deployment     
destination =  
"${local.deploy_home_dir}/prepare_ceph_deploy_script_deployment.sh"  
  }  
  provisioner "remote-exec" {     inline = [  
      "chmod +x  
${local.deploy_home_dir}/prepare_ceph_deploy_script_deployment.sh",  
      
"${local.deploy_home_dir}/prepare_ceph_deploy_script_deployment.sh",       
# "rm -f ${local.deploy_home_dir}/install.sh",  
    ]  
  }   
  depends_on = [  
    null_resource.deployment_etc_host_ceph  
  ]  
}  
  
Openstack/compute/deployment_host_openstack.tf  
resource "gitlab_user_runner" "openstack_runner" {   runner_type = 
"project_type"   project_id  = var.project_id  
  
  tag_list = ["openstack"]   untagged = false  
  
  description = "openstack runner"  
} locals {  
  deploy_home_dir = "/home/ubuntu"  
   ##Tools  
  runcmd_tools        = []   final_runcmd_tools  = []  
72 
  deploy_script_tools = file("${path.module}/config/tools.sh")  
  
  ## Gitlab Runner  
  runcmd_install_gitlab_runner       = []   
final_runcmd_install_gitlab_runner = []   
deploy_script_install_gitlab_runner =  
templatefile("${path.module}/config/gitlab-runner.sh", {     
registration_token = gitlab_user_runner.openstack_runner.token     
gitlab_host        = var.gitlab_base_url  
  })  
  
  ## Registry  
  runcmd_registry       = []   final_runcmd_registry = []  
  deploy_script_registry = 
templatefile("${path.module}/config/registry.sh", {     
registry_port      = "4000"     registry_bind_host = "0.0.0.0"  
  })  
  
  ## Kolla Ansible  
  runcmd_kolla_ansible        = []   final_runcmd_kolla_ansible  = 
[]  
  deploy_script_kolla_ansible = file("${path.module}/config/kolla-
ansible.sh")   
  ## Hosts for deployment host   write_files = [  
    {  
      path        = "/etc/hosts"       permissions = "0644"       
owner       = "root:adm"  
      content = base64encode(templatefile("config/hosts.tpl", {         
controlplane_hosts = formatlist("%s %s", 
module.openstack_controlplane_nodes.*.vm_ip, 
module.openstack_controlplane_nodes.*.vm_name)         worker_hosts       
= formatlist("%s %s",  
module.openstack_worker_nodes.*.vm_ip, 
module.openstack_worker_nodes.*.vm_name)         storage_hosts      
= formatlist("%s %s",  
module.openstack_storage_nodes.*.vm_ip, 
module.openstack_storage_nodes.*.vm_name)         loadbalancer_hosts 
= formatlist("%s %s", module.openstack_loadbalancer_nodes.*.vm_ip, 
module.openstack_loadbalancer_nodes.*.vm_name)         
monitoring_hosts   = formatlist("%s %s", 
module.openstack_monitoring_nodes.*.vm_ip, 
module.openstack_monitoring_nodes.*.vm_name)  
        self_name          = 
module.openstack_deployment_node.vm_name  
      }))  
    },     {  
      path        = "/etc/kolla/multinode"       permissions = 
"0644"       owner       = "ubuntu:ubuntu"  
      content = base64encode(templatefile("config/multinode.tpl", {         
controlplane_hosts = formatlist("%s", 
module.openstack_controlplane_nodes.*.vm_name)         worker_hosts       
= formatlist("%s", module.openstack_worker_nodes.*.vm_name)         
storage_hosts      = formatlist("%s", 
module.openstack_storage_nodes.*.vm_name)         network_hosts      
= formatlist("%s", module.openstack_loadbalancer_nodes.*.vm_name)         
73 
monitoring_hosts   = formatlist("%s", 
module.openstack_monitoring_nodes.*.vm_name)  
      }))  
    },     {  
      path        = "/etc/kolla/config/fluentd/output/99-forward-to-
cls.conf"       permissions = "0644"       owner       = 
"ubuntu:ubuntu"  
      content = base64encode(templatefile("config/fluentd/output/99-
forward-tocls.conf", {  
        controlplane_hosts = formatlist("%s", 
module.openstack_controlplane_nodes.*.vm_name)         worker_hosts       
= formatlist("%s", module.openstack_worker_nodes.*.vm_name)         
storage_hosts      = formatlist("%s", 
module.openstack_storage_nodes.*.vm_name)         network_hosts      
= formatlist("%s", module.openstack_loadbalancer_nodes.*.vm_name)         
monitoring_hosts   = formatlist("%s", 
module.openstack_monitoring_nodes.*.vm_name)  
}))  
    }  
  ]   
  deploy_script_etc_hosts = 
templatefile("${path.module}/config/write_files.sh", {     
write_files = local.write_files  
  })  
  
}   
resource "null_resource" "install_gitlab_runner" {   triggers = {  
    data = jsonencode(merge(  
      {  
        deploy = local.deploy_script_install_gitlab_runner         
host   = module.openstack_deployment_node.vm_ip  
      }  
    ))  
  }   
  connection {     type        = "ssh"     user        = "ubuntu"  
    host        = module.openstack_deployment_node.vm_ip     
private_key = file(var.private_key_filename)     agent       = true  
  }   
  provisioner "file" {  
    content     = local.deploy_script_install_gitlab_runner     
destination = "${local.deploy_home_dir}/install.sh"  
  }  
  provisioner "remote-exec" {     inline = [  
      "chmod +x ${local.deploy_home_dir}/install.sh",  
      "sudo ${local.deploy_home_dir}/install.sh",  
      # "rm -f ${local.deploy_home_dir}/install.sh",  
    ]  
  }  
}   
resource "null_resource" "install_tools" {   triggers = {     data = 
jsonencode(merge(  
      {  
        deploy = local.deploy_script_tools         host   = 
module.openstack_deployment_node.vm_ip  
      }  
    ))  
74 
  }    connection {     type        = "ssh"     user        = 
"ubuntu"  
    host        = module.openstack_deployment_node.vm_ip     
private_key = file(var.private_key_filename)     agent       = true  
  }   
  provisioner "file" {  
    content     = local.deploy_script_tools     destination = 
"${local.deploy_home_dir}/tools.sh"  
  }  
  provisioner "remote-exec" {     inline = [  
      "chmod +x ${local.deploy_home_dir}/tools.sh",  
"sudo ${local.deploy_home_dir}/tools.sh",  
      # "rm -f ${local.deploy_home_dir}/tools.sh",  
    ]  
  }  
}   
resource "null_resource" "install_registry" {   triggers = {     
data = jsonencode(merge(  
      {  
        deploy = local.deploy_script_registry         host   = 
module.openstack_deployment_node.vm_ip  
      }  
    ))  
  }    connection {     type        = "ssh"     user        = 
"ubuntu"  
    host        = module.openstack_deployment_node.vm_ip     
private_key = file(var.private_key_filename)     agent       = true  
  }   
  provisioner "file" {  
    content     = local.deploy_script_registry     destination = 
"${local.deploy_home_dir}/registry.sh"  
  }  
  provisioner "remote-exec" {     inline = [  
      "chmod +x ${local.deploy_home_dir}/registry.sh",  
      "sudo ${local.deploy_home_dir}/registry.sh",       # "rm -f 
${local.deploy_home_dir}/deploy.sh",  
    ]  
}    depends_on = [     null_resource.install_tools  
  ]  
}   
resource "null_resource" "install_kolla_ansible" {   triggers = {     
data = jsonencode(merge(  
      {  
        deploy = local.deploy_script_kolla_ansible         host   = 
module.openstack_deployment_node.vm_ip  
      }  
    ))  
  }    connection {     type        = "ssh"     user        = 
"ubuntu"  
    host        = module.openstack_deployment_node.vm_ip     
private_key = file(var.private_key_filename)     agent       = true  
  }   
  provisioner "file" {  
    content     = local.deploy_script_kolla_ansible     destination 
= "${local.deploy_home_dir}/kolla-ansible.sh"  
  }  
75 
  provisioner "remote-exec" {     inline = [  
      "chmod +x ${local.deploy_home_dir}/kolla-ansible.sh",  
"sudo ${local.deploy_home_dir}/kolla-ansible.sh",  
      # "rm -f ${local.deploy_home_dir}/deploy.sh",  
      "sudo echo ${var.packer_key_base_64} | base64 -d > 
/etc/kolla/packer_key",  
      "sudo chmod 600 /etc/kolla/packer_key",  
    ]  
  }   
  depends_on = [  
    null_resource.install_tools  
  ]  
}   
resource "null_resource" "deployment_etc_host" {   triggers = {  
    data = jsonencode(merge(  
      {  
        deploy = local.deploy_script_etc_hosts         host   = 
module.openstack_deployment_node.vm_ip  
      }  
    ))  
  }   
  connection {     type        = "ssh"     user        = "ubuntu"  
    host        = module.openstack_deployment_node.vm_ip     
private_key = file(var.private_key_filename)     agent       = true  
  }   
  provisioner "file" {  
    content     = local.deploy_script_etc_hosts     destination = 
"${local.deploy_home_dir}/write_files.sh"  
  }  
provisioner "remote-exec" {  
    inline = [  
      "chmod +x ${local.deploy_home_dir}/write_files.sh",  
      "sudo ${local.deploy_home_dir}/write_files.sh",  
    ]  
  }    depends_on = [     null_resource.install_tools  
  ] }  
vsphere-templates/ubuntu-22.04/ubuntu.pkr.hcl  
packer {   required_plugins {     vsphere = {       version = ">= 
0.0.1"  
      source  = "github.com/hashicorp/vsphere"  
    }  
  }  
}   
source "vsphere-iso" "ubuntu" {   vcenter_server      = 
var.vsphere_server   host                = var.vsphere_host   
username            = var.vsphere_username   password            = 
var.vsphere_password   insecure_connection = "true"   datacenter          
= var.vsphere_datacenter   datastore           = 
var.vsphere_datastore   cluster             = var.vsphere_cluster  
  
  CPUs                 = var.cpu_num   cpu_cores            = 
var.cpu_cores RAM                  = var.mem_size   RAM_reserve_all      
= true   disk_controller_type = ["pvscsi"]   guest_os_type        = 
var.vsphere_guest_os_type   iso_checksum         = 
var.os_iso_checksum   iso_url              = var.os_iso_url   
cd_content = {  
76 
    "/meta-data" = file("${var.cloudinit_metadata}")     "/user-
data" = file("${var.cloudinit_userdata}")  
  }   cd_label = "cidata"  
   network_adapters {     network      = var.vsphere_network     
network_card = "vmxnet3"  
  }    storage {  
    disk_size             = var.disk_size     disk_thin_provisioned 
= true  
  }   
  vm_name             = var.vsphere_vm_name   convert_to_template = 
"true"   communicator        = "ssh"   ssh_username        = 
var.ssh_username   #ssh_password           = var.ssh_password   
ssh_private_key_file   = var.ssh_private_key_file   ssh_timeout            
= "120m"   ssh_handshake_attempts = "100000000"  
  
  boot_order       = "disk,cdrom,floppy"   boot_wait        = "3s"  
boot_command     = var.boot_command  
  shutdown_command = "echo '${var.ssh_password}' | sudo -S -E 
shutdown -P now"   shutdown_timeout = "15m"  
  
  configuration_parameters = {     "disk.EnableUUID" = "true"  
  }  
}  build {  
  sources = ["source.vsphere-iso.ubuntu"]  
  
  provisioner "shell" {  
    execute_command = "echo '${var.ssh_password}' | {{.Vars}} sudo -
S -E bash  
'{{.Path}}'"     environment_vars = [  
      "BUILD_USERNAME=${var.ssh_username}",  
    ]  
    scripts           = var.shell_scripts     expect_disconnect = 
true  
  }  
  
} 
77
ChSTU repository

ChSTU repository preserves and enables easy and open access to all types of digital content including text, images, moving images, mpegs and data sets
