102.6 Урок 1

Сертифікат:

LPIC-1

Версія:

5.0

Розділ:

102 Установка Linux та керування пакунками

Тема:

102.6 Linux як гостьова ОС при віртуалізації

Урок:

1 з 1

Вступ

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

Вступ до віртуалізації

Віртуалізація — це технологія, яка дозволяє програмній платформі, яка називається гіпервізор, запускати процеси, які містять повністю емульовану комп’ютерну систему. Гіпервізор відповідає за управління ресурсами фізичного обладнання, які можуть використовуватися окремими віртуальними машинами. Ці віртуальні машини називаються гостями гіпервізора. Віртуальна машина має багато аспектів фізичного комп’ютера, емульованого програмно, наприклад BIOS-системи та контролери жорсткого диска. Віртуальна машина часто використовує образи жорстких дисків, які зберігаються як окремі файли, і має доступ до оперативної пам’яті та ЦП хост-машини через програмне забезпечення гіпервізора. Гіпервізор розділяє доступ до апаратних ресурсів хост-системи між гостями, таким чином дозволяючи кільком операційним системам працювати на одній хост-системі.

Гіпервізори для Linux, які використовуються частіше за все, наступні:

Xen: Xen — це гіпервізор типу 1 з відкритим вихідним кодом. Це означає, що він не залежить від базової операційної системи. Гіпервізор такого типу відомий як гіпервізор на голому металі, оскільки комп’ютер може завантажуватися безпосередньо на основі гіпервізору.
KVM: Віртуальна машина ядра (Kernel Virtual Machine) — це модуль ядра Linux для віртуалізації. KVM є гіпервізором як типу 1, так і типу 2, тому що, хоча для роботи йому потрібна загальна операційна система Linux, він може працювати як гіпервізор ідеально завдяки інтеграції з запущеною системою Linux. Віртуальні машини, розгорнуті за допомогою KVM, використовують демон libvirt і пов’язані програмні утиліти для створення та керування.
VirtualBox: Популярний настільний застосунок, який дозволяє легко створювати віртуальні машини та керувати ними. Oracle VM VirtualBox вважається кросплатформним і працює на Linux, macOS та Microsoft Windows. Оскільки для роботи VirtualBox потрібна базова операційна система, це гіпервізор типу 2.

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

Типи віртуальних машин

Існує три основних типи віртуальних машин: повністю віртуалізований гість, паравіртуалізований гість та гібридний гість.

Повністю віртуалізований: Всі інструкції, які очікується виконувати гостьовою операційною системою, повинні мати можливість виконуватися в рамках повністю віртуалізованої встановленої операційної системи. Причина цього полягає в тому, що в гостьову систему не встановлюються додаткові програмні драйвери для перекладу інструкцій на імітаційне або реальне обладнання. Повністю віртуалізований гість (або HardwareVM) не знає, що це запущений екземпляр віртуальної машини. Для того, щоб цей тип віртуалізації працював на обладнанні на базі x86, у системі, де встановлено гіпервізор, повинні бути ввімкнені розширення процесора Intel VT-x або AMD-V. Це можна зробити у меню конфігурації мікропрограми BIOS або UEFI.
Паравіртуалізований: Паравіртуалізований гість (або PVM) — це той, де гостьова операційна система знає, що це запущений екземпляр віртуальної машини. Ці типи гостей використовуватимуть модифіковане ядро та спеціальні драйвери (відомі як гостьові драйвери), які допоможуть гостьовій операційній системі використовувати програмні та апаратні ресурси гіпервізора. Продуктивність паравіртуалізованого гостя часто краща, ніж повністю віртуалізованого через переваги, які надають ці програмні драйвери.
Гібридний: Паравіртуалізація та повна віртуалізація можуть бути поєднані, щоб дозволити немодифікованим операційним системам отримувати майже рідну продуктивність введення-виведення за допомогою паравіртуалізованих драйверів у повністю віртуалізованих операційних системах. Паравіртуалізовані драйвери містять драйвери накопичувачів і мережевих пристроїв із покращеною продуктивністю дискового та мережевого введення-виведення.

Платформи віртуалізації часто надають пакетні гостьові драйвери для віртуалізованих операційних систем. KVM використовує драйвери з проекту Virtio, тоді як Oracle VM VirtualBox використовує Guest Extensions, доступний із завантажуваного файлу образу ISO CD-ROM.

Приклад віртуальної машини `libvirt`

Ми розглянемо приклад віртуальної машини, яка керується libvirt і використовує гіпервізор KVM. Віртуальна машина часто складається з групи файлів, насамперед файлу XML, який визначає віртуальну машину (наприклад, її апаратну конфігурацію, підключення до мережі, можливості відображення тощо) та пов’язаного файлу образу жорсткого диска, який містить встановлену операційну систему та її програмне забезпечення.

Спочатку давайте розглянемо приклад XML-файлу конфігурації для віртуальної машини та її мережевого середовища:

$ ls /etc/libvirt/qemu
total 24
drwxr-xr-x 3 root root 4096 Oct 29 17:48 networks
-rw------- 1 root root 5667 Jun 29 17:17 rhel8.0.xml

Note

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

Зверніть увагу, що існує каталог під назвою networks. Цей каталог містить файли визначення (також з використанням XML), що створюють конфігурації мережі, які можуть використовувати віртуальні машини. Цей гіпервізор використовує лише одну мережу, тому існує лише один файл визначення, що містить конфігурацію для сегмента віртуальної мережі, який будуть використовувати ці системи.

$ ls -l /etc/libvirt/qemu/networks/
total 8
drwxr-xr-x 2 root root 4096 Jun 29 17:15 autostart
-rw------- 1 root root  576 Jun 28 16:39 default.xml
$ sudo cat /etc/libvirt/qemu/networks/default.xml
<!--
WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE
OVERWRITTEN AND LOST. Changes to this xml configuration should be made using:
  virsh net-edit default
or other application using the libvirt API.
-->

<network>
  <name>default</name>
  <uuid>55ab064f-62f8-49d3-8d25-8ef36a524344</uuid>
  <forward mode='nat'/>
  <bridge name='virbr0' stp='on' delay='0'/>
  <mac address='52:54:00:b8:e0:15'/>
  <ip address='192.168.122.1' netmask='255.255.255.0'>
    <dhcp>
      <range start='192.168.122.2' end='192.168.122.254'/>
    </dhcp>
  </ip>
</network>

Це визначення включає приватну мережу класу C і емульований апаратний пристрій, який виконує роль маршрутизатора для цієї мережі. Існує також діапазон IP-адрес гіпервізора для використання з реалізацією сервера DHCP, які можна призначити віртуальним машинам, що використовують цю мережу. Наведена конфігурація мережі також використовує трансляцію мережевих адрес (NAT) для пересилання пакетів в інші мережі, такі як локальна мережа гіпервізора.

Розглянемо файл визначення віртуальної машини Red Hat Enterprise Linux 8 (розділи, що заслуговують на особливу увагу, виділені жирним шрифтом):

$ sudo cat /etc/libvirt/qemu/rhel8.0.xml
<!--
WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE
OVERWRITTEN AND LOST. Changes to this xml configuration should be made using:
  virsh edit rhel8.0
or other application using the libvirt API.
-->

<domain type='kvm'>
  <name>rhel8.0</name>
  <uuid>fadd8c5d-c5e1-410e-b425-30da7598d0f6</uuid>
  <metadata>
    <libosinfo:libosinfo xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0">
      <libosinfo:os id="http://redhat.com/rhel/8.0"/>
    </libosinfo:libosinfo>
  </metadata>
  <memory unit='KiB'>4194304</memory>
  <currentMemory unit='KiB'>4194304</currentMemory>
  <vcpu placement='static'>2</vcpu>
  <os>
    <type arch='x86_64' machine='pc-q35-3.1'>hvm</type>
    <boot dev='hd'/>
  </os>
  <features>
    <acpi/>
    <apic/>
    <vmport state='off'/>
  </features>
  <cpu mode='host-model' check='partial'>
    <model fallback='allow'/>
  </cpu>
  <clock offset='utc'>
    <timer name='rtc' tickpolicy='catchup'/>
    <timer name='pit' tickpolicy='delay'/>
    <timer name='hpet' present='no'/>
  </clock>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>destroy</on_crash>
  <pm>
    <suspend-to-mem enabled='no'/>
    <suspend-to-disk enabled='no'/>
  </pm>
  <devices>
    <emulator>/usr/bin/qemu-system-x86_64</emulator>
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/libvirt/images/rhel8'/>
      <target dev='vda' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/>
    </disk>
    <controller type='usb' index='0' model='qemu-xhci' ports='15'>
      <address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/>
    </controller>
    <controller type='sata' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/>
    </controller>
    <controller type='pci' index='0' model='pcie-root'/>
    <controller type='pci' index='1' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='1' port='0x10'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0' multifunction='on'/>
    </controller>
    <controller type='pci' index='2' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='2' port='0x11'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x1'/>
    </controller>
    <controller type='pci' index='3' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='3' port='0x12'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x2'/>
    </controller>
    <controller type='pci' index='4' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='4' port='0x13'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x3'/>
    </controller>
    <controller type='pci' index='5' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='5' port='0x14'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x4'/>
    </controller>
    <controller type='pci' index='6' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='6' port='0x15'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x5'/>
    </controller>
    <controller type='pci' index='7' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='7' port='0x16'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x6'/>
    </controller>
    <controller type='virtio-serial' index='0'>
      <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0'/>
    </controller>
    <interface type='network'>
      <mac address='52:54:00:50:a7:18'/>
      <source network='default'/>
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
    </interface>
    <serial type='pty'>
      <target type='isa-serial' port='0'>
        <model name='isa-serial'/>
      </target>
    </serial>
    <console type='pty'>
      <target type='serial' port='0'/>
    </console>
    <channel type='unix'>
      <target type='virtio' name='org.qemu.guest_agent.0'/>
      <address type='virtio-serial' controller='0' bus='0' port='1'/>
    </channel>
    <channel type='spicevmc'>
      <target type='virtio' name='com.redhat.spice.0'/>
      <address type='virtio-serial' controller='0' bus='0' port='2'/>
    </channel>
    <input type='tablet' bus='usb'>
      <address type='usb' bus='0' port='1'/>
    </input>
    <input type='mouse' bus='ps2'/>
    <input type='keyboard' bus='ps2'/>
    <graphics type='spice' autoport='yes'>
      <listen type='address'/>
      <image compression='off'/>
    </graphics>
    <sound model='ich9'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x1b' function='0x0'/>
    </sound>
    <video>
      <model type='virtio' heads='1' primary='yes'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/>
    </video>
    <redirdev bus='usb' type='spicevmc'>
      <address type='usb' bus='0' port='2'/>
    </redirdev>
    <redirdev bus='usb' type='spicevmc'>
      <address type='usb' bus='0' port='3'/>
    </redirdev>
    <memballoon model='virtio'>
      <address type='pci' domain='0x0000' bus='0x05' slot='0x00' function='0x0'/>
    </memballoon>
    <rng model='virtio'>
      <backend model='random'>/dev/urandom</backend>
      <address type='pci' domain='0x0000' bus='0x06' slot='0x00' function='0x0'/>
    </rng>
  </devices>
</domain>

Цей файл визначає ряд апаратних налаштувань, які використовуються цим гостем, наприклад, кількість оперативної пам’яті, яку йому буде призначено, кількість ядер ЦП від гіпервізора, до яких гість матиме доступ, файл образу жорсткого диска, який пов’язаний з цим гостем (у розділі disk), його можливостями відображення (через протокол SPICE) і доступом гостя до USB-пристроїв, а також емулятору клавіатури та миші.

Приклад дискового сховища віртуальної машини

Образ жорсткого диска цієї віртуальної машини знаходиться за адресою /var/lib/libvirt/images/rhel8. Сам образ диска на цьому гіпервізорі нижче:

$ sudo ls -lh /var/lib/libvirt/images/rhel8
-rw------- 1 root root 5.5G Oct 25 15:57 /var/lib/libvirt/images/rhel8

Поточний розмір цього образу диска займає лише 5,5 ГБ місця на гіпервізорі. Однак гостьова операційна система бачить диск розміром 23,3 ГБ, про що свідчать вихідні дані наступної команди на запущеній віртуальній машині:

$ lsblk
NAME          MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
vda           252:0    0 23.3G  0 disk
├─vda1        252:1    0    1G  0 part /boot
└─vda2        252:2    0 22.3G  0 part
  ├─rhel-root 253:0    0   20G  0 lvm  /
  └─rhel-swap 253:1    0  2.3G  0 lvm  [SWAP]

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

COW: Копіювання під час запису (також відоме як thin-provisioning або sparse images) — це метод, за допомогою якого файл диску створюється з попередньо визначеною верхньою межею розміру. Розмір образу диска тільки збільшується, коли на диск записуються нові дані. Як і в попередньому прикладі, гостьова операційна система бачить попередньо визначений ліміт диска в 23,3 ГБ, але записала лише 5,5 ГБ даних у файл диска. Формат образу диска, який використовується для прикладу віртуальної машини, — це qcow2, який є форматом файлу QEMU COW.
RAW: Тип диску raw або full — це файл, для якого попередньо виділено весь простір. Наприклад, файл raw-образу диска розміром 10 ГБ займає 10 ГБ фактичного дискового простору гіпервізора. Цей стиль диску має переваги в продуктивності, оскільки весь необхідний дисковий простір уже існує, тому базовий гіпервізор може просто записувати дані на диск без зниження продуктивності від моніторингу образу диска, щоб переконатися, що він ще не досяг своєї межі, і збільшення розміру файлу в міру запису до нього нових даних.

Існують інші платформи керування віртуалізацією, такі як Red Hat Enterprise Virtualization та oVirt, які можуть використовувати фізичні диски як резервні місця зберігання операційної системи віртуальної машини. Ці системи можуть використовувати мережу зберігання даних (SAN, Storage Area Network) або мережні пристрої зберігання даних (NAS, Network Attached Storage) для запису своїх даних, а гіпервізор відстежує, які місця зберігання до яких віртуальних машин належать. Ці системи зберігання можуть використовувати такі технології, як керування логічними томами (LVM, Logical Volume Management), щоб збільшити або зменшити розмір дискового сховища віртуальної машини за потреби, а також допомогти у створенні знімків сховища та керування ними.

Робота з шаблонами віртуальних машин

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

Цей шаблон віртуальної машини пізніше можна було б скопіювати до нової гостьової системи. У цьому випадку нового гостя буде перейменовано, нова MAC-адреса буде створена для його мережевого інтерфейсу, а інші зміни можуть бути внесені залежно від його запланованого використання.

D-Bus ідентифікатор машини

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

Щоб перевірити, чи існує D-Bus ідентифікатор машини для запущеної системи, можна використати таку команду:

$ dbus-uuidgen --ensure

Якщо жодних повідомлень про помилки не відображається, значить, для системи існує ідентифікатор. Щоб переглянути поточний D-Bus ідентифікатор машини, виконайте наступне:

$ dbus-uuidgen --get
17f2e0698e844e31b12ccd3f9aa4d94a

Рядок тексту, який відображається, є поточним ідентифікатором. Жодні дві системи Linux, що працюють на гіпервізоре, не повинні мати однаковий D-Bus ідентифікатор машини.

D-Bus ідентифікатор машини розташований за адресою /var/lib/dbus/machine-id і символічно пов’язаний з /etc/machine-id. Не рекомендується змінювати цей ідентифікатор у запущеній системі, оскільки система може стати нестабільною і давати збої. Якщо дві віртуальні машини мають однаковий D-Bus ідентифікатор машини, виконайте наведену нижче процедуру, щоб створити новий:

$ sudo rm -f /etc/machine-id
$ sudo dbus-uuidgen --ensure=/etc/machine-id

У випадку, якщо /var/lib/dbus/machine-id не є символьним посиланням на /etc/machine-id, потрібно буде видалити /var/lib/dbus/machine-id.

Розгортання віртуальних машин у хмарі

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

Оцінюючи розгортання системи Linux у середовищі IaaS, адміністратор має бути обізнаним щодо декількох ключових елементів:

Обчислювальні екземпляри: Багато постачальників хмарних послуг стягують тарифи на основі «обчислювальних екземплярів» або того, скільки часу ЦП буде використовувати ваша хмарна інфраструктура. Ретельне планування того, скільки часу на обробку насправді знадобиться застосункам, допоможе керувати витратами на хмарне рішення.

Обчислювальні екземпляри також часто посилаються на кількість віртуальних машин, підготовлених у хмарному середовищі. Знову ж таки, більше екземплярів систем, які працюють одночасно, також впливають на загальний процесорний час, за який організація буде платити.
Блочне сховище: Хмарні постачальники також мають різні рівні блочного сховища, доступні для організації. Деякі пропозиції просто призначені як мережеве сховище для файлів на базі Інтернету, а інші пропозиції стосуються зовнішнього сховища хмарної віртуальної машини для хостингу файлів.

Вартість таких пропозицій буде відрізнятися залежно від обсягу сховища, що використовується, та швидкості зберігання в центрах обробки даних постачальника. Швидший доступ до сховища, як правило, коштує дорожче, і, навпаки, дані «в стані спокою» (як у архівному сховищі) часто дешевші.
Мережа: Одним з основних компонентів роботи з постачальником хмарних рішень є те, як буде налаштована віртуальна мережа. Багато постачальників послуг IaaS матимуть певну форму веб-утиліт, які можна використовувати для проектування та впровадження різних мережевих маршрутів, підмереж і конфігурацій міжмережного екрана. Деякі з них навіть нададуть рішення DNS, щоб загальнодоступні FQDN (повні доменні імена) можна було призначити вашим системам з доступом до Інтернет. Існують навіть «гібридні» рішення, які можуть підключити існуючу локальну мережеву інфраструктуру до хмарної інфраструктури за допомогою VPN (віртуальна приватна мережа), таким чином, пов’язуючи дві інфраструктури разом.

Безпечний доступ до гостьових систем у хмарі

Найпоширенішим методом доступу до віддаленого віртуального гостя на хмарній платформі є використання програмного забезпечення OpenSSH. У системі Linux, яка знаходиться в хмарі, буде запущений сервер OpenSSH, а адміністратор використовуватиме клієнт OpenSSH із спільними ключами, попередньо налаштованими, для віддаленого доступу.

Адміністратор запустить на виконання таку команду:

$ ssh-keygen

і буде дотримуватися підказок, щоб створити пару відкритих і приватних ключів SSH. Закритий ключ залишається в локальній системі адміністратора (зберігається в ~/.ssh/), а відкритий ключ копіюється до віддаленої хмарної системи, точно так само, як і при роботі з мережевими машинами в корпоративній локальній мережі.

Далі адміністратор запускає наступну команду:

$ ssh-copy-id -i <public_key> user@cloud_server

Це скопіює публічний ключ SSH із щойно створеної пари ключів на віддалений хмарний сервер. Відкритий ключ буде записано у файлі ~/.ssh/authorized_keys хмарного сервера та встановлені відповідні дозволи на файл.

Note	Якщо в каталозі `~/.ssh/` є лише один файл відкритого ключа, то опцію `-i` можна опустити, оскільки команда `ssh-copy-id` за замовчуванням використовуватиме файл відкритого ключа в каталозі (зазвичай файл, що закінчується розширенням `.pub`).

Деякі постачальники хмарних послуг автоматично створюють пару ключів, коли підготовлена нова система Linux. Потім адміністратору потрібно буде завантажити приватний ключ для нової системи від постачальника хмари та зберегти його у своїй локальній системі. Зауважте, що дозволи для ключів SSH мають бути 0600 для приватного ключа і 0644 для відкритого ключа.

Попереднє налаштування хмарних систем

Утиліта cloud-init - це корисний інструмент, який спрощує розгортання хмарної віртуальної машини. Ця команда разом із пов’язаними файлами конфігурації та попередньо визначеним образом віртуальної машини не залежить від виробника і дає змогу розгорукти гостьову систему Linux у багатьох постачальників IaaS. Використовуючи текстові файли YAML (YAML Ain’t Markup Language), адміністратор може попередньо налаштувати параметри мережі, вибір програмного пакету, конфігурацію ключа SSH, створення облікового запису користувача, локальні налаштування, а також багато інших параметрів для швидкого створення нових систем.

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

Синтаксис файлу YAML, який використовується з cloud-init, називається cloud-config. Ось зразок файлу cloud-config:

#cloud-config
timezone: Africa/Dar_es_Salaam
hostname: test-system

# Update the system when it first boots up
apt_update: true
apt_upgrade: true

# Install the Nginx web server
packages:
 - nginx

Зверніть увагу, що у верхньому рядку немає пробілу між символом хеша (#) і словом cloud-config.

Note	Команда `cloud-init` призначений не тільки для віртуальних машин. Набір інструментів `cloud-init` також можна використовувати для попереднього налаштування контейнерів (наприклад, контейнерів LXD Linux) перед розгортанням.

Контейнери

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

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

Note	Для Linux доступні численні контейнерні технології, такі як Docker, Kubernetes, LXD/LXC, systemd-nspawn, OpenShift тощо. Впровадження пакету програмного забезпечення контейнера виходить за рамки іспиту LPIC-1.

Контейнери використовують механізм контролю груп (більш відомий як cgroups) у ядрі Linux. Cgroup — це спосіб виділити системні ресурси, такі як пам’ять, час процесора, а також пропускну здатність диска та мережі для окремого застосунку. Адміністратор може використовувати cgroups безпосередньо для встановлення обмежень системних ресурсів для застосунку або групи застосунків, які можуть існувати в межах однієї cgroup. По суті, це те, що контейнерне програмне забезпечення робить для адміністратора, а також надає інструменти, які спрощують керування та розгортання cgroups.

Note	Наразі знання щодо cgroup не є обов’язковими для складання іспиту LPIC-1. Концепція cgroup згадується тут, щоб кандидат мав принаймні деякі базові знання про те, як застосунок відокремлюється з метою використання системних ресурсів.

Вправи до посібника

Які розширення ЦП необхідні апаратній платформі на базі x86, яка запускатиме повністю віртуалізовані гостьові системи?
Який тип віртуалізації, ймовірно, використовуватиме критично важливий сервер, який вимагатиме найшвидшої продуктивності?
Дві віртуальні машини, клоновані з одного шаблону і які використовують D-Bus, працюють нестабільно. Вони обидві мають окремі імена хостів і налаштування конфігурації мережі. Яка команда буде використана, щоб визначити, чи мають віртуальні машини різні ідентифікатори машини D-Bus?

Дослідницькі вправи

Виконайте наступну команду, щоб перевірити, чи у вашій системі вже ввімкнено розширення ЦП для запуску віртуальної машини (ваші результати можуть відрізнятися залежно від вашого ЦП):

grep --color -E "vmx|svm" /proc/cpuinfo

Залежно від результату ви можете виділити vmx (для процесорів з підтримкою Intel VT-x) або svm (для процесорів з підтримкою AMD SVM). Якщо ви не отримали результатів, зверніться до інструкцій BIOS або UEFI, щоб увімкнути віртуалізацію для вашого процесора.
Якщо ваш процесор підтримує віртуалізацію, перегляньте документацію вашого дистрибутиву щодо запуску гіпервізора KVM.
- Встановіть необхідні пакунки для запуску гіпервізора KVM.
- Якщо ви використовуєте графічне середовище, рекомендується також встановити програму virt-manager, яка надає графічні можливості, які можна використовувати під час встановлення KVM. Це допоможе встановити і керувати віртуальними машинами.
- Завантажте ISO-образ дистрибутива Linux на ваш вибір і, дотримуючись документації вашого дистрибутиву, створіть нову віртуальну машину, використовуючи цей ISO.

Підсумки

У цьому уроці ми розглянули концептуальні основи віртуальних машин і контейнерів, а також те, як ці технології можна використовувати з Linux.

Ми ознайомилися з такими командами:

dbus-uuidgen: Використовується для перевірки та перегляду DBus-ідентифікатора системи.
ssh-keygen: Використовується для створення пари відкритих і приватних ключів SSH для використання під час доступу до віддалених хмарних систем.
ssh-copy-id: Використовується для копіювання загального ключа SSH системи до віддаленої системи для полегшення віддаленої автентифікації.
cloud-init: Використовується для допомоги в конфігурації та розгортанні віртуальних машин і контейнерів у хмарному середовищі.

Відповіді на вправи до посібника

Які розширення ЦП необхідні апаратній платформі на базі x86, яка запускатиме повністю віртуалізовані гостьові системи?

VT-x для процесорів Intel або AMD-V для процесорів AMD
Який тип віртуалізації, ймовірно, використовуватиме критично важливий сервер, який вимагатиме найшвидшої продуктивності?

Операційна система, яка використовує паравіртуалізацію, таку як Xen, в якості гостьової операційної системи може краще використовувати доступні їй апаратні ресурси за допомогою програмних драйверів, призначених для роботи з гіпервізором.
Дві віртуальні машини, клоновані з одного шаблону і які використовують D-Bus, працюють нестабільно. Вони обидві мають окремі імена хостів і налаштування конфігурації мережі. Яка команда буде використана, щоб визначити, чи мають віртуальні машини різні ідентифікатори машини D-Bus?

dbus-uuidgen --get

Відповіді до дослідницьких вправ

Виконайте наступну команду, щоб перевірити, чи у вашій системі вже ввімкнено розширення ЦП для запуску віртуальної машини (ваші результати можуть відрізнятися залежно від вашого ЦП): grep --color -E "vmx|svm" /proc/cpuinfo. Залежно від результату ви можете виділити vmx (для процесорів з підтримкою Intel VT-x) або svm (для процесорів з підтримкою AMD SVM). Якщо ви не отримали результатів, зверніться до інструкцій BIOS або UEFI, щоб увімкнути віртуалізацію для вашого процесора.

Результати будуть відрізнятися залежно від вашого ЦП. Ось приклад виведення комп’ютера на процесорі Intel з розширеннями віртуалізації, включеними у мікропрограмі UEFI:
```
$ grep --color -E "vmx|svm" /proc/cpuinfo
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp md_clear flush_l1d
```
Якщо ваш процесор підтримує віртуалізацію, перегляньте документацію вашого дистрибутиву щодо запуску гіпервізора KVM.
- Встановіть необхідні пакунки для запуску гіпервізора KVM.
  
  Це буде відрізнятися залежно від вашого дистрибутиву, але ось деякі відправні моменти:
  
  Ubuntu — https://help.ubuntu.com/lts/serverguide/libvirt.html
  
  Fedora — https://docs.fedoraproject.org/en-US/quick-docs/getting-started-with-virtualization/
  
  Arch Linux — https://wiki.archlinux.org/index.php/KVM
- Якщо ви використовуєте графічне середовище, рекомендується також встановити програму virt-manager, яка надає графічні можливості, які можна використовувати під час встановлення KVM. Це допоможе встановити і керувати віртуальними машинами.
  
  Знову ж таки, це буде відрізнятися залежно від дистрибутиву. Приклад з використанням Ubuntu виглядає так:
  $ sudo apt install virt-manager
- Завантажте ISO-образ дистрибутива Linux на ваш вибір і, дотримуючись документації вашого дистрибутиву, створіть нову віртуальну машину, використовуючи цей ISO.
  
  З цим завданням легко справляється пакунок virt-manager. Однак віртуальну машину можна створити з командного рядку за допомогою команди virt-install. Спробуйте обидва методи, щоб зрозуміти, як розгортаються віртуальні машини.