что такое lxd это обязательный вопрос

Введение.

Последние 6 месяцев Серж Халлин (Serge Hallyn), Тихо Андерсен (Tycho Andersen), Чак Шорт (Chuck Short), Райн Харпер (Ryan Harper) и Стефан Грабе (Stéphane Graber) активно работали над проектом LXD.

Ubuntu 15.04, который выйдет 23 апреля 2015 года, будет обладать в своих репозиториях LXD 0.7. Хоть это и первые шаги данной технологии, но для экспериментов она готова. Для производственного использования ещё нужно потрудиться над ней.

Что такое LXD?

Последний бесшовно интегрируется в инфраструктуру OpenStack и позволяет управлять контейнерами подобно виртуальным машинам.

Почему LXD?

LXC за 7 лет своего развития превратилась из кучки ограниченных инструментов для изоляции чуть лучше чем chroot в стабильный набор инструментов, стабильную библиотеку и активное сообщество пользователей и разработчиков.

За эти годы было добавлено много дополнительных фичей безопасности в ядро линукс и LXC их поддерживает. Всё это время разработчики видели интерес людей к данной технологии и решили создать LXD на плечах LXC, с открытым API и набором привязок для языков программирования (bindings).

Разработчики давно хотят сделать несколько больших изменений:

Как LXD соотносится с LXC, Docker, Rocket и другими проектами?

LXD базируется на LXC и находится на его вершине. Используется LXC API, чтобы с помощью REST API скрыть детали работы и дать пользователю более простой и надёжный механизм. LXD фокусируется на контейнерах с системами (system container managers), то есть внутри работает полноценная операционная система на базе линукс. С точки зрения дизайна LXD не волнует что работает в контейнере.

Это отличает LXD от Docker или Rocket, которые позиционируют себя как менеджеры приложений-в-контейнере (application container managers). Но нет ничего плохого в использовании LXD для создания полноценного контейнера, который будет ограничен в ресурсах по вашему требованию и в рамках безопасности, а потом использовать любой механизм дистрибьюции приложений.

Начало работы с LXD.

Самый простой способ попробовать LXD на своём ноутбуке или десктопе это использование инструмента командной строки.

Команда lxc позволит взаимодействовать с одним или несколькими LXD, но по умолчанию идёт работа только с локальными. Для упрощения первого старта вы можете добавить публичный LXD сервер https://images.linuxcontainers.org:8443
Это сервер, хранящий только образы и доступный только для чтения. Вы можете получить список образов, хранящиеся на нём, скопировать себе интересующий вас образ и запустить его в контейнере.

lxc remote add images images.linuxcontainers.org
lxc image list images:
lxc launch images:ubuntu/trusty/i386 ubuntu-32

«remote» начинает указывать на «images» сервера images.linuxcontainers.org. Затем вы смотрите список на сервере, который выведет ASCII таблицу

Затем запускаете локально контейнер ubuntu-32, так как он будет скачан и запущен. Последующие старты контейнера будут мгновенными, так как образ уже будет храниться локально. Синтаксис » :» используется повсеместно в lxc, если его не указывать, то будет подразумеваться local.

Так как есть запущенный контейнер с Убунту, то можно посмотреть статус и IP: lxc list

Что дальше?

Вышеописанное не является полным руководством, так как простой старт показан на единственной машине. LXD раскрывается, когда вы удалённо манипулируете контейнерами на разных узлах: создаёте, перемещаете, копируете и так далее. LXD поддерживает живую миграцию, снимки, профили конфигурации, прокидывание устройств внутрь контейнера и многое другое. Вскоре будет по аналогии с циклом статей про LXC написан цикл статей о возможностях LXD. LXD очень юный проект, но его поддерживают разработчики LXC.

Адреса, пароли, явки.

Теперь пару слов от меня лично.

Разработчик Тихо Андерсен рассказывает о LXD.

Источник

Управление контейнерами с LXD

Продолжаем наш цикл статей о контейнеризации. Если первые две статьи (1 и 2) были посвящены теории, то сегодня мы поговорим о вполне конкретном инструменте и об особенностях его практического использования. Предметом нашего рассмотрения будет LXD (сокращение от Linux Container Daemon), созданный канадцем Стефаном Грабе из компании Canonical.

Имя создателя LXD хорошо известно в профессиональном сообществе: он также является одним из авторв другого популярного контейнерного решения — LXC. Собственно, LXD представляет собой надстройку над LXC, которая упрощает работу с контейнерами и добавляет широкий спектр новых возможностей.

В рамках этой статьи мы ограничимся лишь кратким введением в LXD: сравним его с Docker, приведём инструкцию по установке и настройке, а также продемонстрируем базовые возможности управления контейнерами.

LXD и Docker

LXD — инструмент относительно новый: первая версия вышла в свет в 2014 году, когда Docker уже получил широкое распространение и хорошо зарекомендовал себя на практике.
Как и Docker, LXD функционирует на базе LXC.

При этом cфера применения у двух инструментов совершенно разная: если Docker предназначен для запуска в контейнерах приложений, то LXD — для запуска полноценных операционных систем.

С помощью LXD можно создавать даже не контейнеры в буквальном смысле этого слова, а легковесные виртуальные машины. Чтобы подчеркнуть этот момент и одновременно указать на отличие от других инструментов контейнеризации, авторы многих публикаций называют LXD словом lightvisor (на русский язык его уже переводят как «легковизор»).

В публикациях Canonical отмечается, что LXD-контейнеры могут работать в 10 раз быстрее, чем традиционные виртуальные машины на базе KVM.

В LXD предпринята попытка решить целый ряд проблем, с которыми приходится сталкиваться при работе с другими инструментами контейнеризации: продуман механизм динамического управления ресурсами, расширены возможности миграции контейнеров (в том числе и в режиме реального времени), устранены проблемы безопасности. По сравнению с Docker у LXD гораздо шире возможности переконфигурации контейнеров.

LXD оснащён открытым API; имеются клиенты для различных языков программирования. Создан плагин для OpenStack, позволяющий управлять контейнерами с помощью клиента Nova.

Установка и настройка

Здесь и далее мы будем описывать особенности работы c LXD на материале Ubuntu 16.04. В этой ОС LXD включён в официальные репозитории и устанавливается стандартным способом:

Стефан Грабе в своей статье рекомендует в качестве бэкенда для хранения контейнеров использовать файловую систему ZFS. Чтобы работать с ZFS, нужно установить соответствующие пакеты:

Если ZFS вам по тем или иным причинам не подходит, вы можете воспользоваться BTRFS или LVM (подробнее об этом см. здесь).
По завершении установки выполним команду:

Программа настройки задаст несколько простых вопросов, после чего всё будет сконфигурировано автоматически. Подробнее об особенностях настройки LXD можно прочитать в этой статье.

Создание контейнера

Все контейнеры в LXD создаются на базе образов. Образы можно получить как из локального, так и из удалённого репозитория. Просмотрим список доступных репозиториев:

Для первого знакомства с LXD вполне подойдёт локальный репозиторий (local). Запустим в контейнере ОС Ubuntu 16.04:

В результате выполнения этой команды LXD создаст на базе указанного образа контейнер и запустит его.

Запустить в этом контейнере командную оболочку можно с помощью команды:

Если нужно просто создать контейнер, но не запускать его, достаточно выполнить команду:

Для последующего запуска и остановки контейнера используются команды lxc start и lxc stop.

LXC предоставляет хорошие возможности для управления контейнерами «на лету». Вот так, например, можно поместить созданный на основном хосте файл внутрь контейнера:

Можно совершить и обратную операцию — загрузить файл из контейнера на основной хост:

Можно и редактировать файлы в контейнере напрямую:

Основные команды для создания и запуска контейнеров мы уже рассмотрели; желающих узнать больше отсылаем к подробной статье Стефана Грабе.

Управление ресурсами

Управление изолированными окружениями немыслимо без контроля ресурсов: мы должны предоставить контейнеру достаточное количество ресурсов для работы и в то же время быть уверенными в том, что контейнер не будет потреблять лишних ресурсов, нарушая тем самым работу остальной системы.

В LXD можно выделять контейнерам ресурсы при помощи специального набора команд:

Более подробно почитать об управлении ресурсами можно в этой статье.

Просмотреть статистику потребления ресурсов для контейнера можно с помощью простой команды:

Работа со снапшотами

В LXD имеется возможность создания снапшотов и восстановления контейнеров из снапшотов. Посмотрим, как это работает на практике (пример взят из интерактивного туториала LXD).

Внесём некоторые изменения в уже созданный нами контейнер container1:

Сделаем снапшот этого контейнера и назовём его, например, new:

Попробуем что-нибудь «поломать» в нашем первом контейнере:

Поcле этого запустим в нём в нём командную оболочку:

Выполним команду exit и вернёмся на основной хост. Восстановим работу контейнера container1 из снапшота:

Запустим командную оболочку в восстановленном контейнере:

Всё работает так же, как раньше!

В приведённом выше примере мы рассмотрели так называемые stateless-снапшоты В LXD есть и другой тип снапшотов — stateful, в которых сохраняется текущее состояние всех процессов в контейнере. Со stateful-снапшотами связаны ряд интересных и полезных функций.

Чтобы создавать stateful-снапшоты, нам понадобится установить программу CRIU(CheckPoint/Restore in Userspace). C её помощью можно сохранить текущее состояние всех процессов, а затем восстановить их хоть на текущей, хоть на другой машине.
В Ubuntu 16.04 утилита CRIU устанавливается при помощи стандартного менеджера пакетов:

После этого можно переходить к созданию снапшотов:

В некоторых ситуациях такие снапшоты могут оказаться очень полезными. Представим себе, например, что нам нужно перезагрузить сервер, на котором запущены один или несколько контейнеров. Чтобы после перезагрузки не запускать всё заново, а продолжить с прерванного места, достаточно выполнить:

На базе stateful-снапшотов реализован механизм «живой» миграции контейнеров, который пока что находится в несколько «сыром» состоянии.

Заключение

LXD представляет собой удобную систему управления контейнерами, обладающую целым рядом полезных функций. Надеемся, что проект LXD будет успешно развиваться и займёт достойное место в ряду современных инструментов контейнеризации.

Если у вас есть практический опыт использования LXD — добро пожаловать в комментарии.
Если вы по тем или иным причинам не можете комментировать посты здесь — добро пожаловать в наш корпоративный блог.
Естественно, в рамках одной статьи рассказать обо всех функциях LXD вряд ли возможно. Для желающих узнать больше приводим несколько полезных ссылок:

Источник

LXD 2.0: Введение в LXD [1/12].

Первая, вводная статья от Стефана Грабера, который расскажет о диковинном звере LXD. Рекомендуется тем, кто отличает контейнер от виртуальной машины.

Что такое LXD?

Как LXD соотносится с Docker/Rkt?

LXD фокусируется на системных контейнерах, которые ещё называют инфраструктурные контейнеры. То есть LXD манипулирует контейнерами с полноценной Linux системой внутри так же, как вы бы работали с системой, поставленной на чистое железо или в виртуальную машину. Традиционные системы управления конфигурациями и развёртывания приложений могут использовать LXD так же, как и в обычном использовании на физическом оборудовании, виртуальной или облачных средах.

В противоположность этому, Docker фокусируется на минималистичных, мимолётных контейнерах, которые обычно не обновляют или переконфигурируют, а вероятнее всего будут заменены целиком. Это делает Docker и подобные проекты ближе к механизму развёртывания приложений, чем к инструментам управления машинами.

Эти две модели не являются взаимоисключающими. Вы можете использовать LXD для предоставления полноценной Linux системы и ваши пользователи внутри контейнера могут с помощью Docker ставить нужный им софт.

Почему LXD?

Работа с LXC показала, что он обеспечивает прекрасным набором низкоуровневого инструментария и библиотеками для создания и управления контейнерами. Однако, такой инструмент не всегда дружественен к пользователю и требует от него много первоначальных знаний для понимания как это всё работает. Поддержание обратной совместимости со старыми контейнерами и методами развёртывания так же не даёт использовать некоторые настройки безопасности LXC по умолчанию и требует от пользователя ручной правки.

Основные компоненты LXD.

Есть целый ряд компонент, из которых состоит LXD и они видны в структуре каталогов, в клиенте командной строки и в самом API.

Контейнеры. Containers.

Снимки. Snapshots.

Снимки контейнера неизменны в том смысле, что их нельзя вам модифицировать, кроме переименования, уничтожения или восстановления. Стоит отметить, что поскольку сохраняется всё состояние контейнера, то фактически вы обладаете концепцией ‘stateful’ снимков. Это даёт возможность откатить контейнер, включая состояние его CPU и памяти.

Образы. Images.

LXD основан на использовании образов. Все контейнеры созданы из образов. Образы обычно представляют собой какой-либо чистый Linux дистрибутив, подобно тем что вы используете в виртуальной машине или в облачных средах.

Возможно публиковать (publish) контейнер, делая из него образ, который уже используется локальными или удалёнными LXD хостами.

Образы однозначно идентифицируются своими sha256 хэшами и вы можете ссылаться, используя его целиком или часть. Так как набирать длинные хэши не удобно для пользователя, то каждый образ имеет свойства, помогающее его легко найти в хранилище. Псевдоним (alias) из уникальной строки пользователя может быть дан хэшу образа.

LXD идёт с 3 преднастроенными удалёнными хранилищами образов:

Образы с удалённых серверов автоматически кэшируются демоном LXD и хранятся некоторое время, по умолчанию 10 дней. Дополнительно LXD автоматически обновляет используемые вами образы, если не указано иное, так что самая свежая версия образа доступна вам локально.

Профили. Profiles.

Профили предоставляют механизм определения конфигурации контейнера и доступных ему устройств в одном месте и возможность применять профиль к любому количеству контейнеров.

Контейнеры могут иметь несколько профилей, применённых к нему. При построении окончательной конфигурации, известной как expanded, профиля применяются в порядке определения, перекрывая-перезаписывая совпадающие опции и устройства. Любая локальная конфигурация применяется в конце, затирая абсолютно всё, что шло из профиля.

LXD идёт с 2 преднастроенными профилями:

Удалёнка. Remotes.

По умолчанию определены:

Можно добавлять любое количество удалённых LXD хостов: анонимных в случае публичных серверов с образами или с аутентификацией для управления контейнерами.

Безопасность. Security.

Одним из аспектов при построении LXD было создание безопасных контейнеров, позволяющих запуск современных, немодифицированных Linux дистрибутивов.

Основные функции безопасности:

Вместо того чтобы заставлять пользователя напрямую заниматься безопасностью через параметры, как это делается в LXC, в LXD реализован «конфигурационный язык», который абстрагирует большинство параметров, делая дружественный шаг к пользователю. Для примера, можно легко попросить LXD пробросить устройство хоста внутрь контейнера, без ручного вмешательства при создании major/minor номеров устройства и обновлении политик cgroup.

Связь в LXD защищается TLS 1.2 с ограниченным набором шифров.

REST API.

Всё в LXD делается через REST API. Нет других способов взаимодействия между клиентом и демоном. REST API может быть доступен через локальный unix сокет, требуя только членства в группе для проверки подлинности, или через HTTPS, используя сертификат при аутентификации.

Структура REST API соответствует описанным выше компонентам, проста и понятна.

Когда требуется сложная схема взаимодействия, LXD может разговаривать через websockets. Это используется в интерактивной консоли, миграции контейнера и при уведомлениях о событии.

С LXD 2.0 идёт стабильный API 1.0, в рамках которого не будет нарушаться обратная совместимость. В будущем будут добавлены дополнительные расширения API.

Масштабирование.

LXD предоставляет хороший инструмент командной строки, но он не предназначен для управления тысячами контейнеров на множестве хостов. Для таких случаев используйте плагин nova-lxd в OpenStack, чтобы управлять контейнерами подобно виртуальными машинами. Это позволит вам воспользоваться уже OpenStack API для управления сетью, хранилищами, балансировкой нагрузкой и т.д.

Источник

Базовые возможности LXD — системы контейнеров в Linux

LXD — это системный менеджер контейнеров следующего поколения, так гласит источник. Он предлагает пользовательский интерфейс, похожий на виртуальные машины, но использующий вместо этого контейнеры Linux.

Ядро LXD — это привилегированный демон (сервис запущенный с правами root), который предоставляет REST API через локальный unix сокет, а также через сеть, если установлена соответствующая конфигурация. Клиенты, такие как инструмент командной строки поставляемый с LXD посылают запросы через этот REST API. Это означает, что независимо от того, обращаетесь ли вы к локальному хосту или к удаленному, все работает одинаково.

В этой статье мы не будем подробно останавливаться на концепциях LXD, не будем рассматривать все доступные возможности изложенные в документации в том числе реализацию в последних версиях LXD поддержки виртуальных машин QEMU параллельно с контейнерами. Вместо этого мы узнаем только базовые возможности управления контейнерами — настроим пулы хранилищ, сеть, запустим контейнер, применим лимиты на ресурсы, а также рассмотрим как использовать снепшоты, чтобы вы смогли получить базовое представление о LXD и использовать контейнеры в Linux.

Для получения полной информации следует обратиться к официальному источнику:

Навигация

Инсталляция LXD ^

Прежде чем мы приступим к инсталляции пакета в системе, разберемся с именованием в проекте LXD, чтобы в дальнейшем у нас не было путаницы так как до проекта LXD была реализация проекта LXC одним и тем же автором-разработчиком.

Итак, проект LXD включает в себя два основных бинарных файла:

Следующим шагом мы приступим к инсталляции пакета в системе и для этого предлагаю рассмотреть установку на основе двух популярных дистрибутивов и их производных — Ubuntu и Arch Linux. Инсталляция в Ubuntu немного отличается от классической, так как пакет устанавливается как snap-пакет и файловые пути к структуре проекта LXD будут отличаться от тех, что приведены в этой статье, но я думаю вас не затруднит разобраться с этим самостоятельно.

Инсталляция LXD в дистрибутивах Ubuntu ^

В дистрибутиве Ubuntu 19.10 пакет lxd имеет трансляцию на snap-пакет:

Это значит, что будут установлены сразу два пакета, один системный, а другой как snap-пакет. Установка двух пакетов в системе может создать некоторую проблему, при которой системный пакет может стать сиротой, если удалить snap-пакет менеджером snap-пакетов.

Найти пакет lxd в snap-репозитории можно следующей командой:

Запустив команду list можно убедится, что пакет lxd еще не установлен:

Убедимся, что пакет установлен как snap-пакет:

Инсталляция LXD в дистрибутивах Arch Linux ^

Для установки пакета LXD в системе необходимо запустить следующие команды, первая — актуализирует список пакетов в системе доступных в репозитории, вторая — непосредственно установит пакет:

После установки пакета, для управления LXD обычным пользователем, его необходимо добавить в системную группу lxd :

Убедимся, что пользователь user1 добавлен в группу lxd :

Если группа lxd не видна в списке, тогда нужно активировать сессию пользователя заново. Для этого нужно выйти и зайти в систему под этим же пользователем.

Активируем в systemd загрузку сервиса LXD при старте системы:

Проверяем статус сервиса:

Инициализация LXD ^

Прежде чем использовать контейнеры необходимо выполнить инициализацию основных компонент LXD — виртуальную сеть и хранилище в котором будут хранится файлы контейнера, образов и другие файлы. В этом нам поможет мастер инициализации, который инициализирует компоненты после того как мы ответим на его вопросы.

Обзор хранилища LXD (Storage) ^

В этом разделе мы только ознакомимся с хранилищем в LXD, а инициализировать его мы будем немного позже с помощью мастера инициализации.

Хранилище (Storage) состоит из одного или нескольких Storage Pool который использует одну из поддерживаемых файловых систем такие как ZFS, BTRFS, LVM или обычные директории. Каждый Storage Pool разделяется на тома (Storage Volume) которые содержат образы, контейнеры или данные для других целей.

Следующая команда выводит на экран список всех Storage Pool в LXD хранилище:

Для просмотра списка всех Storage Volume в выбранном Storage Pool служит команда lxc storage volume list :

Также, если для Storage Pool при создании была выбрана файловая система BTRFS, то получить список Storage Volume или subvolumes в интерпретации BTRFS можно с помощью инструментария этой файловой системы:

Выбор файловой системы для Storage Pool ^

Во время инициализации LXD задаёт несколько вопросов, среди которых будет определение типа файловой системы для дефолтного Storage Pool. По умолчанию для него выбирается файловая система BTRFS. Поменять на другую ФС после создания будет невозможно. Для выбора ФС предлагается таблица сравнения возможностей:

Инициализация основных компонент LXD ^

Итак, у нас всё готово для инициализации LXD. Запустите команду вызова мастера инициализации lxd init и введите ответы на вопросы после знака двоеточия так как показано в примере ниже или измените их согласно вашим условиям:

Создание дополнительного Storage Pool ^

Итак, до создания Storage Pool необходимо определить loopback-файл или существующий раздел в вашей файловой системе который он будет использовать. Для этого, мы создадим и будем использовать файл который ограничим размером в 10GB:

Подключим loopback-файл в свободное loopback-устройство:

Следующая команда создает новый Storage Pool в LXD на основе только что подготовленного loopback-файла. LXD отформатирует loopback-файл /mnt/work/lxd/hddpool.img в устройстве /dev/loop1 под файловую систему BTRFS:

Выведем список всех Storage Pool на экран:

Увеличение размера Storage Pool ^

После создания Storage Pool, при необходимости, его можно расширить. Для Storage Pool основанном на файловой системе BTRFS выполните следующие команды:

Автовставка loopback-файла в слот loopback-устройства ^

У нас есть одна небольшая проблема, при перезагруке системы хоста, файл /mnt/work/lxd/hddpool.img «вылетит» из устройства /dev/loop1 и сервис LXD упадет при загрузке так как не увидит его в этом устройстве. Для решения этой проблемы нужно создать системный сервис который будет вставлять этот файл в устройство /dev/loop1 при загрузке системы хоста.

Создадим unit файл типа service в /etc/systemd/system/ для системы инициализации SystemD:

После рестарта хостовой системы проверяем статус сервиса:

Безопасность. Привилегии контейнеров ^

Так как все процессы контейнера фактически исполняются в изоляции на хостовой системе используя его ядро, то для дополнительной защиты доступа процессов контейнера к системе хоста LXD предлагает привилегированность процессов, где:

Привилегированные контейнеры — это контейнеры в которых процессы с UID и GID соответствуют тому же владельцу, что и на хостовой системе. Например, процесс запущенный в контейнере с UID равным 0 имеет все те же права доступа, что и процесс хостовой системы с UID равным 0. Другими словами, root пользователь в контейнере обладает всеми правами не только в контейнере, но и на хостовой системе если он сможет выйти за пределы изолированного пространства имен контейнера.

По умолчанию, вновь создаваемые контейнеры имеют статус непривилегированных и поэтому мы должны определить SubUID и SubGID.

Создадим два конфигурационных файла в которых зададим маску для SubUID и SubGID соответственно:

Для применения изменений, сервис LXD должен быть рестартован:

Создание виртуального коммутатора сети ^

Следующая схема демонстрирует как коммутатор (сетевой мост, bridge) объединяет хост и контейнеры в сеть:

Контейнеры могут взаимодействовать посредством сети с другими контейнерами или хостом на котором эти контейнеры обслуживаются. Для этого необходимо слинковать виртуальные сетевые карты контейнеров с виртуальным коммутатором. В начале создадим коммутатор, а сетевые интерфейсы контейнера будут слинкованы в последующих главах, после того как будет создан сам контейнер.

Проверяем список сетевых устройств доступных LXD:

Также, убедится в создании сетевого устройства можно с помощью штатного стредства Linux-дистрибутива — ip link или ip addr :

Профиль конфигурации ^

Каждый контейнер в LXD имеет свою собственную конфигурацию и может расширять её с помощью глобально декларируемых конфигураций которые называются профилями конфигурации. Применение профилей конфигурации к контейнеру имеет каскадную модель, следующий пример демонстрирует это:

Выведем на экран список всех доступных профилей конфигурации:

Редактирование профиля ^

Профиль конфигурации по умолчанию default не имеет конфигурации сетевого интерфейса и все вновь создаваемые контейнеры не получают сеть. Для них необходимо создавать отдельными командами локальные сетевые интерфейсы, но мы можем создать в профиле конфигурации глобальный сетевой интерфейс который будет разделяться между всеми контейнерами использующими этот профиль. Таким образом, сразу после команды создания нового контейнера он получит сеть с доступом в интернет. При этом, нет ограничений, мы всегда можем позже создать локальный сетевой интерфейс для контейнера если будет в этом необходимость и/или удалить интерфейс из профиля.

Следующая команда добавит в профиль конфигурации устройство eth0 типа nic присоединяемого к сети lxdbr0 :

Важно отметить, что так как мы фактически добавили устройство в профиль конфигурации, то если бы мы указали в устройстве статический IP адрес, то все контейнеры которые будут применять этот профиль разделят один и тот же IP адрес. Если есть необходимость создать контейнер с выделенным для контейнера статическим IP адресом, тогда следует создать конфигурацию сетевого устройства на уровне контейнера (локальная конфигурация) с параметром IP адреса, а не на уровне профиля.

В этом профиле мы можем увидеть, что для всех вновь создаваемых контейнеров будут созданы два устройства (devices):

Создание новых профилей ^

Для использования ранее созданных Storage Pool контейнерами, создадим профиль конфигурации ssdroot в котором добавим устройство типа disk с точкой монтирования / (root) использующее ранее созданное Storage Pool — ssdpool :

Проверяем профили конфигурации:

Репозиторий образов ^

Контейнеры создаются из образов которые являются специально собранными дистрибутивами не имеющие ядра Linux. Поэтому, прежде чем запустить контейнер, он должен быть развернут из этого образа. Источником образов служит локальный репозиторий в который образы загружаются из внешних репозиториев.

Удаленные репозитории образов ^

По умолчанию LXD настроен на получение образов из трёх удаленных источников:

Например, репозиторий ubuntu: имеет следующие образы:

Для вывода списка образов доступна фильтрация. Следующая команда выведет список всех доступных архитектур дистрибутива AlpineLinux:

Локальный репозиторий образов ^

Управление образами в репозитории производится следующими методами:

Копируем образ в локальный репозиторий из глобального images: :

Выведем список всех образов доступных сейчас в локальном репозитории local: :

Конфигурация LXD ^

Кроме интерактивного режима, LXD поддерживает также неинтерактивный режим установки конфигурации, это когда конфигурация задается в виде YAML-файла, специального формата, который позволяет установить всю конфигурацию за один раз, минуя выполнения множества интерактивных команд которые были рассмотрены выше в этой статье, в том числе конфигурацию сети, создание профилей конфигурации и т.д. Здесь мы не будем рассматривать эту область, вы можете самостоятельно ознакомится с этим в документации.

Следующая интерактивная команда lxc config которую мы рассмотрим, позволяет устанавливать конфигурацию. Например, для того, чтобы загруженные образы в локальный репозиторий не обновлялись автоматически из глобальных репозиториев, мы можем включить это поведение следующей командой:

Создание и управление контейнером ^

Для создания контейнера служит команда lxc init которой передаются значения репозиторий:образ и затем желаемый идентификатор для контейнера. Репозиторий может быть указан как локальный local: так и любой глобальный. Если репозиторий не указан, то по умолчанию, для поиска образа используется локальный репозиторий. Если образ указан из глобального репозитория, то в начале образ будет загружен в локальный репозиторий, а затем использован для создания контейнера.

Выполним следующую команду чтобы создать наш первый контейнер:

Разберем по порядку ключи команды которые мы здесь используем:

Запускаем контейнер, который начинает запускать init-систему дистрибутива:

Также, можно воспользоваться командой lxc launch которая позволяет объединить команды lxc init и lxc start в одну операцию.

Проверяем состояние контейнера:

Проверяем конфигурацию контейнера:

Установка статического IP адреса ^

Если мы попытаемся установить IP адрес для сетевого устройства eth0 командой lxc config device set alp предназначенной для конфигурации контейнера, то мы получим ошибку которая сообщит, что устройство не существует потому что устройство eth0 которое используется контейнером принадлежит профилю default :

Мы можем конечно установить статический IP адрес для eth0 устройства в профиле, но он будет един для всех контейнеров которые этот профиль будут использовать. Поэтому, добавим выделенное для контейнера устройство:

Затем следует рестартовать контейнер:

Доступ к контейнеру ^

Для выполнения команд в контейнере, напрямую, минуя сетевые соединения, служит команда lxc exec которая выполняет команды в контейнере без запуска системной оболочки. Если вам нужно выполнить команду в оболочке, используя shell паттерны, такие как переменные, файловые перенаправления (pipe) и т.д., то необходимо явно запускать оболочку и передавать команду в качестве ключа, например:

Также, возможно запустить интерактивный режим оболочки, а после завершить сеанс выполнив hotkey CTRL+D :

Управление ресурсами контейнера ^

В LXD можно управлять ресурсами контейнера при помощи специального набора конфигурации. Полный список конфигурационных параметров контейнера можно найти в документации.

Ограничение ресурсов RAM (ОЗУ) ^

Параметр limits.memory ограничивает объём RAM доступный для контейнера. В качестве значения указывается число и один из доступных суффиксов.

Зададим контейнеру ограничение на объём RAM равный 256 MB:

Также, существуют другие параметры для ограничения памяти:

Команда lxc config show позволяет вывести на экран всю конфигурацию контейнера, в том числе примененное ограничение ресурсов которое было установлено:

Ограничение ресурсов CPU (ЦП) ^

Для ограничения ресурсов ЦП существует несколько типов ограничений:

Ограничение дискового пространства ^

После установки, в параметре devices.root.size мы можем убедится в установленном ограничении:

Для просмотра используемых квот на диск мы можем получить из команды lxc info :

Не смотря на то, что мы установили ограничение для корневого устройства контейнера в 2GB, системные утилиты такие как df не будут видеть это ограничение. Для этого мы проведем небольшой тест и выясним как это работает.

Создадим 2 новых одинаковых контейнера в одном и том же Storage Pool (hddpool):

В одном из контейнеров создадим файл размером 1GB:

Убедимся, что файл создан:

Если мы посмотрим во втором контейнере, проверим существование файла в том же самом месте, то этого файла не будет, что ожидаемо, так как контейнеры создаются в своих собственных Storage Volume в этом же Storage Pool:

Но давайте сравним значения которые выдает df на одном и другом контейнерах:

Устройство /dev/loop1 смонтированное как корневой раздел является Storage Pool которое эти контейнеры используют, поэтому они разделяют его объём на двоих.

Статистика потребления ресурсов ^

Просмотреть статистику потребления ресурсов для контейнера можно с помощью команды:

Работа со снепшотами ^

В LXD имеется возможность создания снепшотов и восстановления из них состояния контейнера.

Чтобы создать снепшот, выполните следующую команду:

Восстановить контейнер из снепшота можно командой lxc restore указав контейнер для которого будет произведено восстановление и псевдоним снепшота:

Следующая команда служит для удаления снепшота. Обратите внимание, что синтаксис команды не похож на все остальные, здесь необходимо указать прямой слеш после имени контейнера. Если слеш опустить, то команда удаления снепшота интерпретируется как команда удаления контейнера!

В приведённом выше примере мы рассмотрели так называемые stateless-снепшоты. В LXD есть и другой тип снепшотов — stateful, в которых сохраняется текущее состояние всех процессов в контейнере. Со stateful-снепшотами связаны ряд интересных и полезных функций.

Удаление контейнера ^

После того как мы убедились, что состояние контейнера стало STOPPED, его можно удалить из Storage Pool:

Экспорт контейнеров ^

Чтобы вы не утратили плоды своих трудов в контейнерах, в LXD предусмотрена команда экспорта контейнера:

Что ещё? ^

UPDATE 10.04.2020 15:00: Добавил навигацию
UPDATE 11.04.2020 06:00: Исправил ошибки в тексте благодаря ребятам отписавшимся в личку. Спасибо огромное!
UPDATE 11.04.2020 07:30: Добавил информацию в раздел «Инсталляция LXD»
UPDATE 11.04.2020 08:40: Немного реорганизовал разделы, подправил и дополнил текст
UPDATE 14.04.2020 16:10: Добавил информацию о экспорте контейнеров

Источник