Використання cloud-init з vSphere та openSUSE 15.4 - javascript.org.ua

Швидке розгортання серверів Linux для задоволення миттєвих потреб є суттю діяльності домашньої лабораторії, але ми витрачаємо багато часу на налаштування та конфігурацію машин відповідно до наших вимог.

Ще гірше, ми витрачаємо багато часу на підтримку їх належного стану та оновлення, і жодна з них не має привілею необмеженого часу для лабораторії.

Давайте розглянемо спосіб створення базового шаблону в vSphere 7 і налаштуємо машину для завантаження з такими параметрами, як ім’я хоста, IP-адреса, скрипти запуску тощо.

Створення шаблону віртуальної машини

Для початку давайте завантажимо свіжий ISO-образ установника операційної системи з opensuse.org. Оскільки це розгортання для домашньої лабораторії або серверів, я рекомендую використовувати мережевий образ — ми додамо все необхідне пізніше.

Завантажте ISO-образ на сховище даних. Цей крок дозволить процесу установки пройти без участі користувача, навіть якщо ви вимкнете клієнт:

Створіть віртуальну машину та надайте їй відповідне ім’я. Прикріпіть ISO-образ до сховища даних:

Завантажте машину з Linux. Під час запуску майстра інсталяції переконайтеся, що вибрано менеджер логічних томів (LVM2). Я помітив, що коли ви створюєте шаблон клонування, будь-який вибір розміру диска може здатися неправильним у розумінні власника програми, тому варто планувати на майбутнє.

Після завершення інсталяції відключіть віртуальний CD/DVD-привід! Якщо ви не зробите цього на спільній інфраструктурі, адміністраторам віртуальної інфраструктури буде важко працювати з віртуальною машиною — а в домашній лабораторії це будете ви. Встановлюйте хороші звички, щоб зробити користування простим і відповідальним.

Запустіть машину та використовуйте zypper для встановлення будь-яких пакетів чи ключів, які можуть знадобитися для адміністрування пристрою.
У домашній лабораторії сертифікати CA та SSH-ключі цілком підходять — але в корпоративному середовищі потрібно мати автоматизований, повторюваний спосіб управління довірою на випадок компрометації.

Після цього давайте встановимо cloud-init. Цей пакет програмного забезпечення надзвичайно корисний, але за замовчуванням не доступний в OpenSUSE Leap:

Після встановлення пакету переконайтеся, що він увімкнений за допомогою:

systemctl enable cloud-init cloud-init clean

Cloud-Init

Cloud-init — це проект, керований компанією Canonical, який стандартизує налаштування віртуальних машин при завантаженні, роблячи IaaS більш "хмарним", незалежно від місця розміщення. Він спроектований так, щоб отримувати конфігураційні дані з джерела даних і абстрагує специфічні налаштування з інших "хмар" для робочого навантаження IaaS (віртуальної машини) як консистентні інструкції.
Програмне забезпечення для налаштування буде використовувати ці джерела даних як "точки скиду", щоб перетворити специфічні для хмари інструкції (OVF, Azure, EC2) на загальну конфігурацію (Metadata, Userdata).

metadata повинно представляти системну конфігурацію робочого навантаження, таку як ім’я хосту, налаштування мережі та монтування.

userdata повинно представляти конфігурацію користувацького простору робочого навантаження, таку як плейбуки Ansible, SSH-ключі та скрипти першого запуску. З поточним станом я схиляюсь до використання автоматизації для реєстрації робочого навантаження в Ansible та виконання цієї конфігурації централізовано. Однак, це зручно, що цей рівень налаштувань надається — cloud-init може автоматично реєструватися з централізованими оркестраторами, такими як SaltStack і Puppet при старті.

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

Користувачів/Групи
Сертифікати CA
SSH-ключі
Імена хостів
Пакети/Репозиторії
Плейбуки Ansible
Зовнішні монтування (NFS)

VMware пропонує два джерела даних для робочих навантажень, розгорнутих на vSphere:

Нова RESTful API VMware має вбудовану документацію. Відкрийте інтерфейс vSphere, виберіть три крапки та виберіть "Developer Center":

На жаль, нове джерело метаданих від VMware, здається, не працює з цією версією дистрибутива. Згідно зі змінами в журналі Canonical, для розпізнавання нового джерела даних потрібна версія cloud-init 21.3+. Я протестував на OpenSUSE 15.4 (який постачається з cloud-init 21.
4) і отримав таку помилку:

# Нова функція в cloud-init визначила можливі джерела даних для # цієї системи як: # # [] # # Однак, використовувалося джерело даних: OVF # # # # У майбутньому cloud-init буде намагатися використовувати тільки ті # # джерела даних, які були ідентифіковані або спеціально налаштовані. # # Для отримання додаткової інформації дивіться # # https://bugs.launchpad.net/bugs/1669675 # # # # Якщо ви бачите це повідомлення, будь ласка, подайте баг до # # cloud-init за адресою # # https://bugs.launchpad.net/cloud-init/+filebug?field.tags=dsid # # Обов'язково вкажіть хмарного постачальника, на якому працює # # ваш екземпляр. # # # # Після того як ви подасте баг, ви можете вимкнути це попередження, запустивши # # ваш екземпляр із налаштуваннями cloud-config, або додавши цей вміст # # в /etc/cloud/cloud.cfg.d/99-warnings.

cfg
# # # # #cloud-config 
# # warnings:
# # dsid_missing_source: off
# *******************************************************

Щоб переглянути надані та застосовані metadata для системи, cloud-init надає наступний файл:

/run/cloud-init/instance-data.json

Щоб переглянути userdata для системи, використовуйте наступну команду:

cloud-init query userdata

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

Застосування шаблонів робочих навантажень

Примітка: ця функція доступна тільки на vSphere 7 та новіших версіях!

Ось як використовувати джерело даних OVF з vSphere та OpenSUSE.
Прапор disable_vmware_customization є директивою, яка функціонує як перемикач між джерелом метаданих та джерелом даних OVF. Додайте наступне до файлу /etc/cloud/cloud.cfg:

disable_vmware_customization: false
datasource: OVF
allow_raw_data: true
vmware_cust_file_max_wait: 25

Після встановлення вимкніть віртуальну машину. Клацніть правою кнопкою на ВМ та виберіть "Клонувати" -> "Клонувати як шаблон до бібліотеки":

Ця функція vCenter організує конвертацію в об'єкт шаблону та опублікує його до бібліотеки контенту в одному кроці.

Розгортання налаштованої машини

Наступний процес необхідно виконати через API бібліотеки контенту vCenter:

Встановлення API ключа сеансу (необхідна аутентифікація для точок доступу, які використовуються для розгортання)
Розгортання об’єкта бібліотеки контенту (/api/vcenter/vm-template/library-items/)
Знайти відповідну бібліотеку контенту
Знайти правильний елемент бібліотеки контенту
Знайти елемент бібліотеки контенту через API vsphere (ID для використання в команді розгортання)
Знайти кластер vSphere
Знайти папку vSphere
Знайти сховище даних vSphere
Розгорнути елемент бібліотеки контенту
Зачекати, поки розгортання не завершиться, періодично перевіряючи, чи завершено
Знайти віртуальну машину. Попередній виклик API відповідає 200 OK, а Postman зручно відображає час операції!
Застосувати налаштування гостя
Запустити ВМ

Щоб повторити цю лабораторну роботу, внизу цього посту буде надано середовище Postman та колекцію.

Postman як потужна платформа для навчання інженерів

Postman надає потужну платформу для навчання інженерів, які не знайомі з певним API, розширюючи можливості, які може мати HTTP-клієнт. Автоматизовані процеси зазвичай є дуже лаконічними і не пояснюють ефективно кожен крок і поведінку. Щоб імпортувати цю колекцію та середовище, завантажте файли та імпортуйте їх:

Середовища Postman будуть налаштовувати змінні для використання колекціями.

Я впорядкував колекцію Postman за порядком виконання. Останній етап налаштування поверне код 204, якщо операція буде успішною, з порожнім тілом. Щоб перевірити, чи правильно застосовано конфігурацію, перейдіть до конкретної ВМ у vCenter і перегляньте розділ Моніторинг -> Події для події типу "Переналаштування ВМ". Якщо ви побачите завдання на правильній ВМ, запустіть її, і ви побачите наступне:

Поради з налагодження/виправлення помилок

Цей процес дещо непрозорий і може здатися трохи заплутаним на початку. Ось кілька ключових моментів для налагодження та методи їх вирішення:

URI vSphere /vm/guest/customization поверне лише код 204, якщо працює належним чином.
При пошуку ресурсів, Content Library і Templates повертаються як UUID без опису. Для збігу з іменами виконуйте запит GET на окремі об'єкти або використовуйте API пошуку.
Всі інші ресурси (datastore, ім'я ВМ) перераховуються за їх MOB-ім'ям, наприклад, domain-c1008.
Збережіть відповідь від операції розгортання, оскільки в ній міститься ID ВМ, коли операція завершиться.
Налаштування ВМ можна застосувати лише до ВМ, яка знаходиться в стані ВИМКНЕНА, і налаштування не відбудеться, поки ВМ не буде запущено.
## Виправлення проблем з налаштуванням після завантаження

Виправлення проблем з налаштуванням після завантаження можна здійснити, переглянувши метадані (/run/cloud-init/) або перевіривши журнали в наступних місцях:

/var/log/ /var/log/vmware/imc journalctl -xe systemctl restart cloud-init

Класичний метод "очищення та перезапуску" також є дуже корисним:

cloud-init clean -l -s systemctl restart cloud-init

Нарешті, після успішної конфігурації хоста, я б рекомендував вимкнути cloud-init, щоб уникнути подальших налаштувань. Це так само просто можна зробити за допомогою плейбуку Ansible:

systemctl disable cloud-init

Оригінально опубліковано на https://blog.engyak.co.

Перекладено з: Using cloud-init with vSphere and openSUSE 15.4