5. Погляд розробника системних образів
Параметри за замовчуванням і узагальнення¶
Досі наша подорож зосереджувалася на налаштуванні окремих екземплярів під час завантаження за допомогою user-data. У цьому розділі ми змінимо нашу точку зору на точку зору конструктора іміджу. Тобто, хтось, хто створює та підтримує «золоті образи», що слугують шаблонами для інших віртуальних машин.
Наша мета — створити нове, власне зображення з власними вбудованими правилами та налаштуваннями за замовчуванням. Це включає два ключові процеси:
- Налаштування системних налаштувань за замовчуванням: Зміна конфігурації
cloud-initвсередині самого образу. - Узагальнення образу: Використання таких інструментів, як
cloud-init cleanтаvirt-sysprep, для видалення всіх даних, специфічних для машини, та підготовки образу до клонування.
1) Створення середовища для налаштування системи¶
Для початку нам потрібен запущений екземпляр базового зображення хмари, який ми можемо змінити. Ми завантажимо цю віртуальну машину без надання будь-яких користувацьких даних, щоб отримати чисту систему.
# Create a disk image for our new template
qemu-img create -f qcow2 -o size=10G golden-image-template.qcow2
# Boot the base image using virt-install
virt-install --name golden-image-builder \
--memory 2048 --vcpus 2 \
--disk path=golden-image-template.qcow2,format=qcow2 \
--cloud-init none --os-variant rockylinux10 --import
# Connect to the console and log in as the default 'rocky' user
virsh console golden-image-builder
2. Загальносистемна конфігурація за допомогою cloud.cfg.d¶
У нашій запущеній віртуальній машині ми тепер можемо налаштувати конфігурацію cloud-init для всієї системи. Ніколи не слід редагувати головний файл /etc/cloud/cloud.cfg безпосередньо. Правильне, безпечне для оновлення місце для налаштувань – це каталог /etc/cloud/cloud.cfg.d/. cloud-init зчитує всі файли .cfg тут в алфавітному порядку після основного cloud.cfg, що дозволяє вам змінювати значення за замовчуванням.
Практичний досвід: встановлення налаштувань зображення за замовчуванням для золотого кольору¶
Давайте запровадимо політику для нашого золотого образу: ми вимкнемо автентифікацію за паролем, встановимо нового користувача за замовчуванням і забезпечимо постійне встановлення базового набору пакетів.
-
Створення власного файлу конфігурації: Усередині віртуальної машини створіть
/etc/cloud/cloud.cfg.d/99-custom-defaults.cfg. Префікс99-гарантує, що він буде зчитуватися останнім.sudo cat <<EOF > /etc/cloud/cloud.cfg.d/99-custom-defaults.cfg # Golden Image Customizations # Define a new default user named 'admin' system_info: default_user: name: admin sudo: ["ALL=(ALL) NOPASSWD:ALL"] shell: /bin/bash # Enforce key-based SSH authentication ssh_pwauth: false # Ensure a baseline of packages is always installed packages: - htop - vim-enhanced EOF
Вимкнення певних модулів
Надійний метод безпеки полягає у повному вимкненні певних модулів cloud-init. Наприклад, щоб запобігти використанню runcmd будь-яким користувачем, ви можете додати наступний код до вашого власного файлу .cfg. Це накаже cloud-init запускати порожній список модулів на завершальному етапі.
yaml cloud_final_modules: []
3. Узагальнення зображення¶
Наша віртуальна машина тепер містить нашу власну конфігурацію, а також унікальні ідентифікатори машин (такі як /etc/machine-id) та ключі хоста SSH. Перш ніж ми зможемо його клонувати, нам потрібно видалити ці дані в процесі, який називається узагальнення.
Спосіб 1: cloud-init clean (всередині віртуальної машини)¶
cloud-init надає вбудовану команду для цієї мети.
-
Виконайте
cloud-init clean: З віртуальної машини виконайте наступну команду, щоб видалити дані, що стосуються екземпляра.sudo cloud-init clean --logs --seed!!! note "У розділі
cloud-init clean --seed"``` Ця команда видаляє унікальне початкове значення, яке `cloud-init` використовує для ідентифікації екземпляра, змушуючи його запускатися з нуля під час наступного завантаження. Вона **не** видаляє ваші власні конфігурації у `/etc/cloud/cloud.cfg.d/`. Цей крок є важливим для створення справді універсального шаблону. ``` -
Негайно вимкніть: Після очищення негайно вимкніть віртуальну машину.
sudo poweroff
Спосіб 2: virt-sysprep (з хоста)¶
Ще більш ретельним, стандартним для галузі інструментом є virt-sysprep. Ви можете запустити це з вашого хост-комп'ютера на диску вимкненої віртуальної машини. Він виконує всі дії команди cloud-init clean та багато іншого, такі як очищення історії команд, видалення тимчасових файлів та скидання файлів журналів.
-
Переконайтеся, що віртуальна машина вимкнена.
-
Запустіть
virt-sysprepз вашого хоста:sudo virt-sysprep -a golden-image-template.qcow2
Після завершення процесу узагальнення файл диска (golden-image-template.qcow2) стане вашим новим образом Golden.
Правила іменування еталонних образів
Гарною практикою є давати вашим еталонним образам описові назви, що включають назву ОС та номер версії, наприклад, rocky10-base-v1.0.qcow2. Це допомагає з контролем версій та управлінням інфраструктурою.
4. Верифікація еталонного образу¶
Давайте перевіримо наш новий образ, завантаживши новий екземпляр з нього без будь-яких user-data.
-
Створіть новий диск віртуальної машини з нашого золотого образу:
qemu-img create -f qcow2 -F qcow2 -b golden-image-template.qcow2 test-instance.qcow2 -
Завантажте тестовий екземпляр:
virt-install --name golden-image-test --cloud-init none ... -
Перевірка: Підключіться до консолі (
virsh console golden-image-test). Запит на вхід має бути для користувачаadmin, а неrocky. Після входу в систему ви також можете перевірити встановленняhtopза допомогою (rpm -q htop). Це підтверджує, що ваші вбудовані налаштування за замовчуванням працюють.
Що далі¶
Тепер ви навчилися створювати стандартизовані шаблони, запилюючи значення за замовчуванням разом із загальносистемною конфігурацією cloud-init та належним чином узагальнюючи їх для клонування. У наступному розділі ми розглянемо важливі навички усунення несправностей, коли cloud-init поводиться неналежним чином.
Author: Wale Soyinka
Contributors: Steven Spencer, Ganna Zhyrnova