Конвейер Devops, часть 1: как организовать рабочее место и настроить облако из KVM+libvirt
В этой серии статей Олег Филон, ментор Эйч Навыки, рассказывает, как прийти к крутому CI/CD пайплайну. Сегодня разбираемся, как девопсу настроить свое рабочее место.
1К открытий7К показов
Открываем серию материалов о том, как устроен конвейер DevOps и как шаг за шагом построить полный CI/CD пайплайн. Мы разберем ключевые инструменты, которые помогают автоматизировать разработку, тестирование и развертывание приложений. Сегодня на повестке — развертывание собственного облака с помощью KVM и libvirt.
О минимальных требованиях и поддержке виртуализации
Сейчас популярная тема на Youtube — Home Lab, или домашняя сеть с кучей компьютерного и сетевого оборудования, часто в выделенном помещении вроде серверной. И один из самых известных блогеров в этом направлении — Jeff Geerling, вот его GitHub. У меня, кстати, тоже есть небольшой блог — здесь можно почитать статьи, а здесь — посмотреть код на Гитхабе.
Однако наша цель гораздо скромнее — мы будем строить на обычном ПК или ноутбуке персональное облако, используя KVM-модуль из ядра Linux и набор утилит libvirt и qemu. Сразу определимся с минимальными требованиями к железу, чтобы попробовать руками всё обсуждаемое.
Мой рабочий ноут — китайский Chuwi GemiBook Plus с процессором Intel N100, 4 ядра, 16GB памяти, nvme диск на 960GB — вполне справляется с такими задачами.
Сразу объяснюсь за невольную рекламу дешёвых китайских ноутов: я не сразу выбрал этот 200-евро-бук. У меня в домашней сети есть несколько SBC (single board computer) на arm64 и risc-V — опыт весьма интересный. Во-первых, Линукс на таких экзотических компьютерах сильно отличается от обычных ПК. Во-вторых, я стал ценить не абстрактные BogoMIPS из dmesg, а реальный отклик в повседневной работе: веб, YouTube, билды приложений. Неудобств нет, а TDP (thermal design power) — 2-5W.
Как и многие из вас, я беспокоюсь, что оставляю углеродный след, но нельзя сравнивать мой Intel 10W N100 и процессор, который греется как утюг, но для глажки бесполезен, и даже наоборот, требует себя охлаждать — сначала мощными кулерами, а в жаркую погоду ещё и кондиционерами с весьма низким КПД. Короче, ваш компьютер справится с 2-3 виртуалками без проблем. Но на всякий случай проверьте, что аппаратная виртуализация поддерживается процессором.
Установить связку KVM+libvirt можно во многие дистрибутивы Linux. Не будем, однако, спешить, а выполним полезную подготовительную работу. Моя основная ОС уже много лет — Ubuntu. В ней есть удобный инсталятор, новые релизы каждые полгода и LTS (Long Term Support) для тех, кто предпочитает стабильность. Есть ещё бесплатный на 5 машин Ubuntu Pro с патчами безопасности в дополнительном репо. Но главная фича, из-за которой я не меняю дистрибутив — поддержка файловой системы ZFS. Вот о ней и поговорим.
Лирическое отступление: что такое ZFS и в чем ее прикол
ZFS — самая сложная из многочисленных ФС. Она является дефолтной во FreeBSD и не только, а также в дистрибутиве Proxmox, который использует OpenZFS. Разница между Open и просто ZFS в лицензии. Оригинальная лицензия не была свободной. Переписывание многих модулей и библиотек, чтобы эту ФС можно было включить в ядро Linux, заняло много лет. В Ubuntu, начиная c версии 20.04, уже можно выбрать ZFS как опцию при установке. Кратко перечислю, что нам даёт ZFS:
- Встроенное шифрование диска, не нужны никакие LUKS и танцы с бубном.
- Модные контейнерные OverlayFS, виртульные диски формата QCOW2, используют COW (copy-on-write). ZFS это тоже умеет, можно сказать, она оптимизирована для контейнеров и ВМ.
- Замечательная фича — встроенный RAIDZ. В моём Proxmox сервере 8 портов SATA, мощный корпус со стойкой на 8 HD. Купил 7 штук одинаковых 4TB дисков, добавил в пул raidZ, в итоге 24TB довольно шустрого хранилища.
- Можно забыть как кошмарный сон мучения с mdadm, lvm2. Партишены увеличиваются без всякой суеты с PV/VG/LV. Впрочем, XFS это тоже умеет, поговорим позже и о ней.
На будущее: виртуализация никак не привязана к файловой системе, можно использовать то, что уже есть, в том числе и привычный дистрибутив. Буду рассказывать, однако, только об установке на Ubuntu.
Готовимся к установке KVM+libvirt
По умолчанию libvirt создаёт внутреннюю сеть на виртуальном устройстве в режиме nat. Для единственного хоста это не так важно, виртуалка доступна, но полезно настроить плоскую сеть, где ВМ будет иметь свой IP-адрес и физический хост.
Для этого сделаем заранее на хостовой машине виртуальное устройство br0 и будем привязывать виртуалки к этому устройству. Cеть в обычном десктопном Ubuntu настраивается сервисом NetworkManager:
- через графический интерфейс,
- через утилиту интерфейса командной строки nmcli,
- через nmtui с текстовым интерфейсом.
Для серверных конфигураций документация рекомендует netplan. В случае сервера необходимо присваивать хостовым машинам статические IP-адреса вплоть до того, что Proxmox — гораздо более мощный сервер виртуальных машин с возможностью кластеризации, миграции ВМ, ceph и так далее. Он отказался от NetworkManager и требует наличия ethernet порта.
Мы же хотим сохранить удобство десктопной OS и добавить серверные возможности, поэтому будем использовать пакет netplan.io, который вполне совместим с NetworkManager. Вот пример конфигурации для хостовой машины, создающий на физическом ethernet устройстве виртуальный интерфейс br0:
Создав файл /etc/netplan/01-br0.yaml, сначала проверим его корректность: sudo netplan try /etc/netplan/01-br0.yaml, и если Configuration accepted, применяем его: sudo netplan apply .... Посмотрим, что у нас с сетью. Должно быть что-то похожее на это:
Во второй строке вывода стоит мой eth0, который является физическим интерфейсом, он активен (link state UP), но адреса не имеет. В последней строке мой br0, который выступает виртуальным интерфейсом с правильным статическим адресом. Более того, если мы посмотрим настройки с помощью brctl из пакета bridge-utils, то увидим что у нас появился полноценный бридж:
Подготовка к установке KVM+libvirt завершена, возвращаемся к документу с сайта https://sysguides.com/. Для Ubuntu это команда:
На первых порах удобно прибегнуть к десктопному приложению virt-manager, позволяющему создавать, запускать, управлять виртуальными машинами. Под капотом прячется много низкоуровневых утилит, поэтому рано или поздно придётся познакомиться и с libvirt-clients, и с qemu-utils, и с guestfs-tools.
Разворачиваем виртуальные машины
Теперь можем попробовать создать первые виртуалки. Первым делом, как рекомендовано, добавим себя в группу libvirt, чтобы иметь возможность управлять виртуальными машинами, и настроим ACL на каталог, где хранятся образы виртуальных машин:
Самый простой и знакомый способ создания виртуальной машины — использовать iso-образ. Установка будет напоминать сотни раз пройденные шаги: скачать образ, указать путь к нему, задать имя виртуальной машины, количество оперативной памяти, выделить ядра процессора и так далее.
Расскажу чуть подробнее про пару новых опций для virt-manager. Во-первых, это использование настроенного ранее виртуального интерфеса br0. Во-вторых, формат виртуального диска QCOW2. Вот, например, настройки одной из моих виртуалок:
Здесь показаны 4 размера:
- ls -lh видимый размер файла имиджа;
- du -BM занимаемое место на диске, qemu-img info выдаёт его внутренние параметры, в частности: virtual size — 10 GiB; реальный размер файла disk size — 5.11 GiB.
Это возможности того самого COW (copy-on-write). Виртуальный размер — тот, что мы указали при создании ВМ, а реальный размер файла — сколько фактически места занято на диске. Внутри ВМ мы будем видеть эту разницу как свободное место, и оно также остаётся свободным на хостовой ФС. Можно заказывать размер диска с запасом, QCOW2-формат не займёт место, пока оно не потребуется под данные внутри ВМ.
Тут бы надо приложить десяток картинок, но оставляю вам шанс догадаться самим, или поискать инструкцию с картинками. В итоге должно получиться что-то вроде этого:
Общий вид virt-manager со списком ВМ на 2 хостах:
Десктопное приложение virt-manager — не единственный способ создания ВМ. Можно (и иногда удобнее) использовать командную строку и соответствующие утилиты. Также установить ВМ из готового образа в формате для libvirt/qemu. Например, для релиза 14.2 FreeBSD всё, что заканчивается на .qcow2.xz, raw.xz — это образы для libvirt/qemu. После скачивания и проверки контрольных сумм выполним команды:
Предположим, вы успешно создали одну или несколько ВМ, проверили их в графическом режиме или настроили ключи для ssh. Настало время навести порядок с DNS.
У меня раздавал адреса и имена роутер от провайдера. Удобнее настроить на вашем основном компе сервис dnsmasq, который включается первым и по умолчанию всегда доступен. Он умеет также dhcp, так что в одном конфиге сможем сразу задавать и IP-адреса, и имена ВМ. Вот часть моего конфига:
MAC-адреса присваиваются в virt-manager, адреса до 99 оставил под WiFi; со 100 до 200 виртуалки с отдельными диапазонами для каждого хоста; адреса с 201 по 254 — «железные» хосты, то есть реальные устройства. Напомню, после каждой правки конфига сервис dnsmasq надо рестартовать.
Если в будущем ваше персональное облако разрастётся, рекомендую обратить внимание на китайский KVM-свитч 4K HDMI USB KVM Switch. В этом случае KVM означает Keyboard Video Mouse — переключатель для управления несколькими компьютерами с одного комплекта устройств. Это сокращение как нельзя кстати для нашей темы.
Мы разобрали, как развернуть персональное облако DevOps с помощью KVM и libvirt. В следующей статье рассмотрим Fedora Core дистрибутив и инструмент mise — удобную альтернативу pyenv и другим менеджерам версий.
1К открытий7К показов
NVIDIA открыла весь исходный код PhysX, включая GPU-ядра на CUDA — теперь разработчики могут свободно использовать продвинутую физику
Разбираемся, когда на собеседовании пора делать ctrl+alt+del и выходить.
Разработчик Microsoft Мао Пачеко обнаружил, что GitHub Copilot вернул ему его же код, включая ошибки и странные названия переменных. Это вызвало у него экзистенциальный кризис: можно ли доверять ИИ-ассистентам, если они просто копируют уже существующие решения
Сравнение AWS Fargate и EC2 для управления контейнерами: какой инструмент лучше подходит для вашего проекта. В этом решили разобраться авторы блога Pulumi