snap lxd что это

Запуск snap внутри LXD контейнера.

Введение

Команды проектов LXD и AppArmor работали над решением поддержки профилей AppArmor внутри LXD контейнеров. С последними ядрами в Ubuntu, наконец-то, появилась возможность поставить программу в snap пакете внутри LXD. Пакеты snap, как многим стало известно, новый путь дистрибьюции ПО напрямую из апстрима с целым рядом функций безопасности, обёрнутые вокруг пакетов так, что они не смогут помешать работе друг друга или причинить вред системе.

Требования

Самый простой путь увидеть совместную работу технологий:

Установка snap пакета nextcloud

Теперь можно узнать IP адрес, чтобы браузером зайти и увидеть веб интерфейс.
lxc list nextcloud

Установка snap пакета LXD внутри LXD контейнера

Заходим внутрь контейнера lxc exec lxd bash
Внутри контейнера инициализируем и настраиваем «внутренний» lxd.
root@lxd:

# lxd.lxc launch images:archlinux arch

Теперь у нас есть LXD последней версии внутри LXD контейнера хоста и там внутри запущен ArchLinux. Помните, что LXD поставлен через snap технологию и использует канал edge, что подразумевает частое обновление новых версий, возможно несколько раз в день.

Вывод

Здорово что пакеты snap можно нормально использовать внутри контейнера LXD. На производстве теперь можно поднять сотни различных контейнеров, связать сетью как нужно, настроить лимиты на ресурсы с помощью LXD и начать ставить софт прямиком от их апстрима через технологию snap.

Если вы заметите расхождение в работе «snap внутри LXD» или «snap напрямую в хосте», то гляньте вывод dmesg на предмет строк DENIED, которые показывают что AppArmor запрещает что-то для данного snap.

Как правило это симптом того, что есть баг в AppArmor самом или в том, как snapd генерирует профиль AppArmor при установке пакета. Если столкнётесь с проблемами, то можете отписать на канале #snappy irc.freenode.net или оформить баг launchpad.net/snappy/+filebug

Контейнеры против виртуализации.

Источник

Установка и использование Snap-пакетов в Ubuntu 18.04

Dec 2, 2018 · 4 min read

Введение

Snap (или Snappy) — это система развертывания программ и управления пакетами, созданная Canonical. Эти пакеты чаще называют «снепами». Для работы с ними используется утилита «snapd», встроенная в ряд дистрибутивов Linux и позволяющая дистрибутивно-независимо развертывать программы на более высоком уровне.

Snapd — это REST API демон, служащий для управления snap-пакетами. Пользователи взаимодействуют с ним с помощью клиента snap, который входит в тот же пакет. Вы можете установить любое приложение на Linux-десктоп, сервер, облако или устройство.

Вам понадобится

GNU/Linux дистрибутив u и некоторые базовые знания о работе в командной строке. В данном руководстве вы узнаете, как настроить и использовать snap-команды.

Установка системы Snap

Если у вас установлена Ubuntu 16.04 LTS (Xenial Xerus) или более поздние версии, включая Ubuntu 18.04 LTS (Bionic Beaver), то вам ничего не надо делать. Snap установлен по умолчанию и готов к работе. Соответственно, если у вас установлена более ранняя версия или системы Snap нет по каким-то другим причинам, то сначала установите ее, а затем приступайте к работе.

Установку можно осуществить с помощью следующих команд:

Работа с системой Snap

snapd настроен и готов к использованию!

Поиск snap-приложений/пакетов

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

Установка snap-приложений

Вы можете установить любые приложения/пакеты, доступные в формате snap, выполнив следующую команду:

Также можно указать конкретный канал, из которого вы хотите установить приложение. Канал — это snap-концепция, которая позволяет переключаться между разными каналами snap-приложений.

Запуск установленных snap-пакетов

Также его можно запустить через команду:

Просмотр списка установленных приложений

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

Обновление установленных snap-приложений/пакетов

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

Чтобы посмотреть, какие обновления snap-пакетов готовы к установке, выполните следующую команду:

Возврат к более ранней версии snap-приложений/пакетов

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

Такая команда вернет необходимую версию snap-пакета и данные, соответствующие ПО. Если предыдущая версия snap-пакета получена из другого канала, она все равно установится, и канал останется прежним.

Удаление snap-приложений/пакетов

Если вы хотите избавиться от снепов, удалите snap-пакет с помощью следующей команды:

Эта команда удалит приложение, все ее зависимости во время выполнения и связанные пользовательские данные. Если снеп запущен, команда сначала закроет его и затем удалит.

Включение и выключение snap-приложений/пакетов

Если вы хотите временно остановить работу снепа, просто отключите его и снова включите тогда, когда потребуется.

Список запущенных служб

Перезапуск, запуск и приостановление snap-служб

Все службы, необходимые для работы снепов, будут перезагружены по умолчанию:

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

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

Конфигурации snap set и get

Некоторые снепы, например, работающие в фоновом режиме, выставляют параметры конфигурации, которые можно изменить.

Выставленные параметры конфигурации можно посмотреть с помощью установленного снепа. Введите команду snap get

Чтобы изменить параметры конфигурации, задайте команду «snap set»:

Скачивание и установка snap-приложений offline

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

Заключение

Хотя данная система все еще разрабатывается, и доступно не так много snap-приложений/пакетов, тем не менее, она является одной из лучших систем управления ПО. Snap становится все популярнее, особенно благодаря таким настойчивым методам Canonical.

Источник

Установка и использование Snap-пакетов в Ubuntu 18.04

Введение

Snap (или Snappy) — это система развертывания программ и управления пакетами, созданная Canonical. Эти пакеты чаще называют «снепами». Для работы с ними используется утилита «snapd», встроенная в ряд дистрибутивов Linux и позволяющая дистрибутивно-независимо развертывать программы на более высоком уровне.

Snapd — это REST API демон, служащий для управления snap-пакетами. Пользователи взаимодействуют с ним с помощью клиента snap, который входит в тот же пакет. Вы можете установить любое приложение на Linux-десктоп, сервер, облако или устройство.

Вам понадобится

GNU/Linux дистрибутив u и некоторые базовые знания о работе в командной строке. В данном руководстве вы узнаете, как настроить и использовать snap-команды.

Установка системы Snap

Если у вас установлена Ubuntu 16.04 LTS (Xenial Xerus) или более поздние версии, включая Ubuntu 18.04 LTS (Bionic Beaver), то вам ничего не надо делать. Snap установлен по умолчанию и готов к работе. Соответственно, если у вас установлена более ранняя версия или системы Snap нет по каким-то другим причинам, то сначала установите ее, а затем приступайте к работе.

Установку можно осуществить с помощью следующих команд:

Работа с системой Snap

snapd настроен и готов к использованию!

Поиск snap-приложений/пакетов

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

Установка snap-приложений

Вы можете установить любые приложения/пакеты, доступные в формате snap, выполнив следующую команду:

Также можно указать конкретный канал, из которого вы хотите установить приложение. Канал — это snap-концепция, которая позволяет переключаться между разными каналами snap-приложений.

Запуск установленных snap-пакетов

Также его можно запустить через команду:

Просмотр списка установленных приложений

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

Обновление установленных snap-приложений/пакетов

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

Чтобы посмотреть, какие обновления snap-пакетов готовы к установке, выполните следующую команду:

Возврат к более ранней версии snap-приложений/пакетов

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

Такая команда вернет необходимую версию snap-пакета и данные, соответствующие ПО. Если предыдущая версия snap-пакета получена из другого канала, она все равно установится, и канал останется прежним.

Удаление snap-приложений/пакетов

Если вы хотите избавиться от снепов, удалите snap-пакет с помощью следующей команды:

Эта команда удалит приложение, все ее зависимости во время выполнения и связанные пользовательские данные. Если снеп запущен, команда сначала закроет его и затем удалит.

Включение и выключение snap-приложений/пакетов

Если вы хотите временно остановить работу снепа, просто отключите его и снова включите тогда, когда потребуется.

Список запущенных служб

Перезапуск, запуск и приостановление snap-служб

Все службы, необходимые для работы снепов, будут перезагружены по умолчанию:

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

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

Конфигурации snap set и get

Некоторые снепы, например, работающие в фоновом режиме, выставляют параметры конфигурации, которые можно изменить.

Выставленные параметры конфигурации можно посмотреть с помощью установленного снепа. Введите команду snap get

Чтобы изменить параметры конфигурации, задайте команду «snap set»:

Скачивание и установка snap-приложений offline

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

Заключение

Хотя данная система все еще разрабатывается, и доступно не так много snap-приложений/пакетов, тем не менее, она является одной из лучших систем управления ПО. Snap становится все популярнее, особенно благодаря таким настойчивым методам Canonical.

Источник

Изоляция сред разработки с помощью контейнеров LXD

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

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

Конфигурация на примере Ubuntu 20.04.

Размышления о вариантах и причинах приведены в конце статьи.

1. Установка LXD

В Ubuntu 20.04 LXD больше не доступен для установки как deb пакет, только через snap:

После установки нужно выполнить инициализацию:

Единственный параметр который я меняю, это storage bakend — я использую dir как самый простой. Так как снимки и копии я не использую, то предупреждения в документации меня не пугают:

Similarly, the directory backend is to be considered as a last resort option.
It does support all main LXD features, but is terribly slow and inefficient as it can’t perform
instant copies or snapshots and so needs to copy the entirety of the instance’s storage every time.

2. Настройка профиля LXD

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

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

Создание контейнера на базе образа images:ubuntu/20.04 :

Доступ к рутовому шелу контейнера:

Установлю Firefox и VS Code (из репозитория по инструкции):

Включу контейнер для наглядности

Бонус! Довольно просто пробросить GPU в контейнер для того, чтобы запускаемые в нем приложения могли пользоваться графической картой. Для этого нужно:

4. Использование контейнера

В том случае, если контейнер еще не запущен, нужно его запустить:

Запуск VS Code от имени не привилегированного пользователя ubuntu:

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

Я не выключаю запущенных контейнеров вручную, так как не вижу в этом особого смысла — ограничиваюсь закрытием окон запущенных приложений.

5. Заключение

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

Я пробовал разные средства для изоляции сред разработки:

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

Источник

Базовые возможности 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: Добавил информацию о экспорте контейнеров

Источник