The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Выпуск системы управления контейнерами LXC 5.0

17.06.2022 23:34

Компания Canonical опубликовала релиз инструментария для организации работы изолированных контейнеров LXC 5.0, предоставляющий runtime, подходящий как для запуска контейнеров с полным системным окружением, близких к виртуальным машинам, так и для выполнения непривилегированных контейнеров отдельных приложений (OCI). LXC относится к низкоуровневым инструментариям, работающим на уровне отдельных контейнеров. Для централизованного управления контейнерами, развёрнутыми в кластере из нескольких серверов, на базе LXC развивается система LXD. Ветка LXC 5.0 отнесена к выпускам с длительной поддержкой, обновления для которых формируются в течение 5 лет. Код LXC написан на языке Си и распространяется под лицензией GPLv2.

В состав LXC входит библиотека liblxc, набор утилит (lxc-create, lxc-start, lxc-stop, lxc-ls и т.п.), шаблоны для построения контейнеров и набор биндингов для различных языков программирования. Изоляция осуществляется при помощи штатных механизмов ядра Linux. Для изоляции процессов, сетевого стека ipc, uts, идентификаторов пользователей и точек монтирования используется механизм пространств имён (namespaces). Для ограничения ресурсов применяются cgroups. Для понижения привилегий и ограничения доступа задействованы такие возможности ядра, как профили Apparmor и SELinux, политики Seccomp, Chroots (pivot_root) и capabilities.

Основные изменения:

  • Осуществлён переход c autotools на сборочную систему Meson, которая также используется для сборки таких проектов, как X.Org Server, Mesa, Lighttpd, systemd, GStreamer, Wayland, GNOME и GTK.
  • Добавлены новые опции для настройки cgroup - lxc.cgroup.dir.container, lxc.cgroup.dir.monitor, lxc.cgroup.dir.monitor.pivot и lxc.cgroup.dir.container.inner, которые позволяют явно определить пути cgroup для контейнера, процесса мониторинга и вложенных иерархий cgroup.
  • Добавлена поддержка пространства имён для времени (time namespaces) для привязки к контейнеру отдельного состояния системных часов, позволяющего использовать в контейнере своё время, отличное от системного. Для настройки предложены опции lxc.time.offset.boot и lxc.time.offset.monotonic, позволяющие определить для контейнера смещение относительно основных системных часов.
  • Для виртуальных ethernet-адаптеров (Veth) реализована поддержка VLAN. Для управления VLAN предложены опции: veth.vlan.id для задания основного VLAN и veth.vlan.tagged.id для привязки дополнительных тегированных VLAN.
  • Для виртуальных ethernet-адаптеров добавлена возможность настройки размера очередей приёма и передачи при помощи новых опций veth.n_rxqueues и veth.n_txqueues.


  1. Главная ссылка к новости (https://discuss.linuxcontainer...)
  2. OpenNews: Выпуск инструментария управления контейнерами LXC и LXD 4.0
  3. OpenNews: Уязвимость в runc и LXC, затрагивающая Docker и другие системы контейнерной изоляции
  4. OpenNews: Выпуск cистемы управления контейнерной виртуализацией Docker 20.10
  5. OpenNews: Уязвимость в LXC, позволяющая получить доступ к файлам вне контейнера
  6. OpenNews: Выпуск системы управления контейнерами LXD 5.0
Лицензия: CC-BY
Тип: Программы
Короткая ссылка: https://opennet.ru/57371-lxc
Ключевые слова: lxc, container
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (47) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.8, Аноним (8), 04:50, 18/06/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +7 +/
    > Осуществлён переход c autotools на сборочную систему Meson

    Почему на этот любительский треш без документации (точнее - с документацией за деньги, во как) вместо стандартного CMake? Они любят трудности и неудобства?

     
     
  • 2.15, Аноним (15), 07:13, 18/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    https://mesonbuild.com/Manual.html

    Этого же вполне хватает.

     
  • 2.20, Анонимуска (?), 09:01, 18/06/2022 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Потому что CMake -- отстойная хрень, а не стандарт.
     
     
  • 3.26, Аноним (26), 10:24, 18/06/2022 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Отстойная хрень - это мезон, ибо не умеет в автопакетировагие и автоматический поиск зависимостей в системе. Всё ручками кодить нужно вместо использования батареек. Ещё более отстойная хрень - это autotools.
     
     
  • 4.29, llolik (ok), 11:57, 18/06/2022 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > не умеет в автопакетировагие

    Не очень и нужно, для системы сборки, как-минимум. Не сказать что cpack сильно гибкий. В meson есть поддержка install_script, что позволяет писать скрипты пакетирования и запускать их после установки. Т.е. префиксом инсталлируешь в нужный каталог и автоматом запускаешь указанный скрипт, который уже пакетит как ты там напишешь.

    > автоматический поиск зависимостей в системе

    цитируя документацию




    Dependency detection method

    You can use the keyword method to let Meson know what method to use when searching for the dependency. The default value is auto. Additional methods are pkg-config, config-tool, cmake, builtin, system, sysconfig, qmake, extraframework and dub.


    Мало? В том числе, как написано, можно использовать и систему поиска cmake, если он установлен, конечно.

    Вообще, meson и не пытается доминировать. Он может использовать систему поиска пакетов cmake, можно использовать проекты cmake, как сабпроджекты (пробовал, работает и конвертирует успешно, местами ценой небольшой правки специфических мест).

    > Всё ручками кодить нужно вместо использования батареек

    Ну не знаю. Пробовал на одних и тех же собственных пет-проектах и cmake и meson. Получается ± одинаково, но meson читать и понимать проще.

     
  • 4.30, Аноним (30), 13:51, 18/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Где почитать про CMake, чтобы стало понятно, почему он лучше?
     
  • 4.60, anonymous (??), 17:30, 20/06/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > не умеет в автопакетировагие

    О, ужас! Микроскоп не умеет закручивать саморезы.

     

  • 1.10, Аноним (10), 05:44, 18/06/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Кто-нибудь это использует? Почему выбрали это, а не докер?
     
     
  • 2.12, n00by (ok), 07:07, 18/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Разработчики Calculate Linux представили новый дистрибутив Calculate Container Desktop Xfce, предназначенный для запуска рабочего стола в LXC-контейнере.
    ... на одном ПК можно организовать несколько рабочих мест, распределив ресурсы компьютера между ними. Образ

    https://opennet.ru/48279-lxc

    Позже отказались от такой экономии на железе, если правильно помню, из-за каких-то проблем с LXC.

     
     
  • 3.14, Аноним (15), 07:11, 18/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Сантехник Иванов ремонтировал кухонный смеситель прессом на 500 тон. Что-то пошло не так)

    Вот так и разработчики кальки.

     
  • 2.13, Аноним (15), 07:09, 18/06/2022 [^] [^^] [^^^] [ответить]  
  • +6 +/
    LXC и Docker как гребля и бокс. И то, и другое спорт, но такой разный.
     
  • 2.17, Роман (??), 07:35, 18/06/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Всё еще бывает нужда представить изолированное окружение схожее с полноценной системой (условно виртуалку) и управлять этим соответственно из такой парадигмы (например бэкапы целиком, выдаление cpu/ram/disk size) - этакие легкие виртуалки (VE в терминах OpenVZ). Скорее всего почти всё можно сделать и через набор docker compose + swarm, но уйдет больше времени.
     
     
  • 3.24, Stanislavvv (?), 09:56, 18/06/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Делал подобное в докере (для запуска в имеющемся сварме). На запуск уйдёт на полчаса-час больше, но есть нюанс: сеть в lxc и docker устроена по-разному, отчего может быть больно. Но вообще - для lxc-подобного со своими (не заранее подготовленными) образами проще использовать голый runc, возможно даже частично выключив изоляцию, если это приемлемо.
     
     
  • 4.50, Роман (??), 02:14, 19/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Я конечно больше про LXD, чем про голый LXC.

    > Делал подобное в докере (для запуска в имеющемся сварме). На запуск уйдёт
    > на полчаса-час больше,

    Не думаю что это оценка для вообще всех случаев справедлива. Для каких-то конкретных может быть, но там вероятно и вообще тогда VE/VM парадигма лишняя by design.

    >но есть нюанс: сеть в lxc и docker
    > устроена по-разному, отчего может быть больно.

    Не уверен про macvlan, но dhcp/routed было бы странно заводить на докере вообще. Поведение Сети там для разных сценариев задумана.

    >Но вообще - для lxc-подобного
    > со своими (не заранее подготовленными) образами проще использовать голый runc, возможно
    > даже частично выключив изоляцию, если это приемлемо.

    Тут мысль не понял, раскроете? Особенно про изоляцию - зачем её отключать если половина задачи в изоляции и есть, вторая половина в управлении.

     
  • 2.23, microcoder (ok), 09:53, 18/06/2022 [^] [^^] [^^^] [ответить]  
  • +6 +/
    > Кто-нибудь это использует?

    Да.

    > Почему выбрали это, а не докер?

    1. Докер это контейнеризация приложений (один докер = одно приложение), а LXC контейнеризация целого специального дистрибутива.

    2. Докер слишком сложен, нагружен и не гибок. LXC - ничего лишнего. :)

     
     
  • 3.31, Аноним (30), 13:55, 18/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    LXC может работать без SELinux?
     
     
  • 4.49, Аноним (49), 23:37, 18/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Конечно же может.
     
  • 4.57, qrKot (?), 08:04, 20/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    более того, в подавляющем количестве случаев именно что без него и работает. Это канониклы, а в убунте apparmor, нету нам SELinux
     
  • 3.33, Аноним (30), 13:56, 18/06/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Какие зависимости у LXC?
     
     
  • 4.64, _hide_ (ok), 09:45, 21/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, в принципе, ядро и утилиты.
    Для LXD посложнее.
     
  • 2.28, Аноним (28), 11:49, 18/06/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    В docker нельзя поменять ограничения IO для уже созданного контейнера, у lxc это просто config файл.
     
     
  • 3.38, Аноним (38), 17:23, 18/06/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да даже то что до докер под крылом частной компании это уже плохо и не свободно. Хотя LXC из под крыла Каноникла ни чем не лучше.  
     
     
  • 4.40, llolik (ok), 17:33, 18/06/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Хотя LXC из под крыла Каноникла

    C LXD не перепутал?

     
     
  • 5.43, Аноним (38), 18:43, 18/06/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это путаешь квадратное и птицей. Каноникл единственный спонсор linux container project.  
     
     
  • 6.46, llolik (ok), 19:21, 18/06/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Это путаешь квадратное и птицей. Каноникл единственный спонсор linux container project.

    Оказывается да, я не прав. Всегда знал, что LXD Canonical нагородили поверх LXC, но не знал, что LXC - это тоже их разработка.

     
  • 2.61, anonymous (??), 17:32, 20/06/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это скорее альтернатива openvz, фряшечным джейлам и солярочным зонам, чем докеру.
     

  • 1.27, Аноним (27), 11:21, 18/06/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Самые правильные контейнеры!
     
     
  • 2.32, Аноним (30), 13:55, 18/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Нужно? Годно?
     
     
  • 3.35, Аноним (38), 16:47, 18/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Нужный велосипед, который решает архитектурную проблемы всего этого вашего Лин-у-пса.  
     
     
  • 4.45, Аноним (30), 19:06, 18/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Без SELinux работает? Какие зависимости в целом?
     
     
  • 5.58, qrKot (?), 08:06, 20/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    конечно работает, это канониклы, нету у них SELinux

    В целом зависимости: cgroups, namespaces

     
     
  • 6.59, Аноним (30), 14:33, 20/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Хорошо.

    >канониклы

    Ни о чём не говорит, а может быть даже минус: GTK4, systemd, продолжать не буду.

     
  • 2.47, hohax (?), 21:42, 18/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    openvz правильнее, только они всё профукали.
     

  • 1.34, Аноним (38), 16:46, 18/06/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Лучше бы сразу придумали как в NixOS или придумали что-то своё. Если бы линукс не тырил структуру приложение из Unix, а придумал что-то своё всем было был лучше. И не нужны были бы всё это контейнеры в докере в виртуалке в гипервизорве в облаке.  
     
     
  • 2.36, Аноним (36), 17:12, 18/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    NixOS был бы номер один, если бы не пытался через свой велосипед рулить конфигами ПО. Тем более не всё настроики можно через этот велосипед сделать. Приходится и там, и в стандартных конфигах ПО вносить корректировки. Тот ещё зоопарк.
     
     
  • 3.37, Аноним (38), 17:20, 18/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Для того чтобы это сделать было достаточно чьей то воли ли наоборот воли так не делать. Можно же было сделать по человечески.  
     
  • 3.41, Аноним (49), 18:20, 18/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Не понял, в чём проблема с конфигами у тебя. Никто не заставляет никсом конфиги генерировать. Положил файл рядом с кодом, сослался на него, дальше никс сам всё сделает. Мало файла — сделай шаблон. Мало шаблонов — целая система сборки под рукой, можно хоть джигу станцевать, хоть из другой репы взять нужные файлы и разложить куда надо. Без Никсоса ты чем конфиги по серверам раскидываешь? Ансиблом-паппетом-шефом? Или как локалхостный васян, вручную правишь по ssh?
     
     
  • 4.48, Анончик (?), 23:34, 18/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    >> Или как локалхостный васян, вручную правишь по ssh?

    Зачем на локалхосте вручную править конфиги по ssh?
    Или у настоящего админа все должно быть по сети, даже секс?

     
  • 4.52, Аноним (36), 04:53, 19/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Ты не понял, пакетный менеджер не должен рулить конфигами ПО Собрали пакет, пол... большой текст свёрнут, показать
     
  • 2.39, Аноним (39), 17:26, 18/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Контейнеры это не только пространства имён файловой системы, есть ещё сеть, CPU, ввод-вывод, память, NixOS собирающий пакеты в разных каталогах с этим не поможет.
     
     
  • 3.42, Аноним (38), 18:40, 18/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Так и штатными инструментами ос можно ограничивать ресурсы тем же cpulimit но сделать всё это правильно или хотя бы удобно было бы совсем не лишним.  
     
     
  • 4.63, Аноним (63), 19:00, 20/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Можно, именно это и делают системы контейнеризации docker, lxc и т.п., в NixOS ничего этого нет.
     
  • 4.65, Oxyd76 (?), 11:01, 25/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Всё это уж сто лет как встроено в systemd (cgroups, namespaces, capablities - основа основ systemd). А для таких вот изолированных "контейнеров" есть systemd-nspawn и система сборки образов "уровня ОС" (с почти любым произвольным дистром и инит системой внутре) mkosi для него . Никаких сторонних зависимостей типа runc. А приложеньку, как в дохере, вообще одной командой можно в контейнер упихуять, с пробросом сетевизмов и этим вот всем. На гитхабе даже кубер c nspawn контейнерами в бэке делали https://github.com/kinvolk/kube-spawn.
     
  • 3.44, Аноним (44), 18:48, 18/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Пространства имён и прочее реализованы в ядре. Что осталось, так это именно собрать root fs.
     
     
  • 4.62, Аноним (63), 18:58, 20/06/2022 [^] [^^] [^^^] [ответить]  
  • +/
    А причём тут NixOS?
     

  • 1.51, Ддд (?), 03:33, 19/06/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Lxc  это изолированный кусок ОС как zones в солярке. Выглядит как виртуалка куда можно зайти и выйти. Хорошая штука для девопса
     
  • 1.53, Аноним (-), 09:04, 19/06/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Отличная штука! Намного приятнее этих докеров-шмокеров.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2022 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру