Компания Canonical опубликовала релиз инструментария для организации работы изолированных контейнеров LXC 5.0, предоставляющий runtime, подходящий как для запуска контейнеров с полным системным окружением, близких к виртуальным машинам, так и для выполнение непривилегированных контейнеров отдельных приложений (OCI). LXC относится к низкоуровневым инструментариям, работающим на уровне отдельных контейнеров. Для централизованного управления контейнерами, развёрнутыми в кластере из нескольких серверов, на базе LXC развивается система LXD. Ветка LXC 5.0 отнесена к выпускам с длительной поддержкой, обновления для которых формируются в течение 5 лет. Код LXC написан на языке Си и распространяется под лицензией GPLv2...Подробнее: https://www.opennet.me/opennews/art.shtml?num=57371
> Осуществлён переход c autotools на сборочную систему MesonПочему на этот любительский треш без документации (точнее - с документацией за деньги, во как) вместо стандартного CMake? Они любят трудности и неудобства?
https://mesonbuild.com/Manual.htmlЭтого же вполне хватает.
Потому что CMake -- отстойная хрень, а не стандарт.
Отстойная хрень - это мезон, ибо не умеет в автопакетировагие и автоматический поиск зависимостей в системе. Всё ручками кодить нужно вместо использования батареек. Ещё более отстойная хрень - это autotools.
> не умеет в автопакетировагиеНе очень и нужно, для системы сборки, как-минимум. Не сказать что cpack сильно гибкий. В meson есть поддержка install_script, что позволяет писать скрипты пакетирования и запускать их после установки. Т.е. префиксом инсталлируешь в нужный каталог и автоматом запускаешь указанный скрипт, который уже пакетит как ты там напишешь.
> автоматический поиск зависимостей в системе
цитируя документацию
Dependency detection methodYou 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 читать и понимать проще.
Где почитать про CMake, чтобы стало понятно, почему он лучше?
> не умеет в автопакетировагиеО, ужас! Микроскоп не умеет закручивать саморезы.
Кто-нибудь это использует? Почему выбрали это, а не докер?
Разработчики Calculate Linux представили новый дистрибутив Calculate Container Desktop Xfce, предназначенный для запуска рабочего стола в LXC-контейнере.
... на одном ПК можно организовать несколько рабочих мест, распределив ресурсы компьютера между ними. ОбразПозже отказались от такой экономии на железе, если правильно помню, из-за каких-то проблем с LXC.
Сантехник Иванов ремонтировал кухонный смеситель прессом на 500 тон. Что-то пошло не так)Вот так и разработчики кальки.
LXC и Docker как гребля и бокс. И то, и другое спорт, но такой разный.
Всё еще бывает нужда представить изолированное окружение схожее с полноценной системой (условно виртуалку) и управлять этим соответственно из такой парадигмы (например бэкапы целиком, выдаление cpu/ram/disk size) - этакие легкие виртуалки (VE в терминах OpenVZ). Скорее всего почти всё можно сделать и через набор docker compose + swarm, но уйдет больше времени.
Делал подобное в докере (для запуска в имеющемся сварме). На запуск уйдёт на полчаса-час больше, но есть нюанс: сеть в lxc и docker устроена по-разному, отчего может быть больно. Но вообще - для lxc-подобного со своими (не заранее подготовленными) образами проще использовать голый runc, возможно даже частично выключив изоляцию, если это приемлемо.
Я конечно больше про LXD, чем про голый LXC.> Делал подобное в докере (для запуска в имеющемся сварме). На запуск уйдёт
> на полчаса-час больше,Не думаю что это оценка для вообще всех случаев справедлива. Для каких-то конкретных может быть, но там вероятно и вообще тогда VE/VM парадигма лишняя by design.
>но есть нюанс: сеть в lxc и docker
> устроена по-разному, отчего может быть больно.Не уверен про macvlan, но dhcp/routed было бы странно заводить на докере вообще. Поведение Сети там для разных сценариев задумана.
>Но вообще - для lxc-подобного
> со своими (не заранее подготовленными) образами проще использовать голый runc, возможно
> даже частично выключив изоляцию, если это приемлемо.Тут мысль не понял, раскроете? Особенно про изоляцию - зачем её отключать если половина задачи в изоляции и есть, вторая половина в управлении.
> Кто-нибудь это использует?Да.
> Почему выбрали это, а не докер?
1. Докер это контейнеризация приложений (один докер = одно приложение), а LXC контейнеризация целого специального дистрибутива.
2. Докер слишком сложен, нагружен и не гибок. LXC - ничего лишнего. :)
LXC может работать без SELinux?
Конечно же может.
более того, в подавляющем количестве случаев именно что без него и работает. Это канониклы, а в убунте apparmor, нету нам SELinux
Какие зависимости у LXC?
Ну, в принципе, ядро и утилиты.
Для LXD посложнее.
В docker нельзя поменять ограничения IO для уже созданного контейнера, у lxc это просто config файл.
Да даже то что до докер под крылом частной компании это уже плохо и не свободно. Хотя LXC из под крыла Каноникла ни чем не лучше.
> Хотя LXC из под крыла КанониклаC LXD не перепутал?
Это путаешь квадратное и птицей. Каноникл единственный спонсор linux container project.
> Это путаешь квадратное и птицей. Каноникл единственный спонсор linux container project.Оказывается да, я не прав. Всегда знал, что LXD Canonical нагородили поверх LXC, но не знал, что LXC - это тоже их разработка.
Это скорее альтернатива openvz, фряшечным джейлам и солярочным зонам, чем докеру.
Самые правильные контейнеры!
Нужно? Годно?
Нужный велосипед, который решает архитектурную проблемы всего этого вашего Лин-у-пса.
Без SELinux работает? Какие зависимости в целом?
конечно работает, это канониклы, нету у них SELinuxВ целом зависимости: cgroups, namespaces
Хорошо.>канониклы
Ни о чём не говорит, а может быть даже минус: GTK4, systemd, продолжать не буду.
> Хорошо.
>>канониклы
> Ни о чём не говорит, а может быть даже минус: GTK4, systemd,
> продолжать не буду.Переформулируйте, пожалуйста, я ничего не понял. При чем тут минус, ГТК4 и системД.
Чуть-чуть пояснений: Канониклы - это Canonical, разработчики Ubuntu. В Ubuntu и Debian'е SELinux нет, там AppArmor, т.е. SELinux'а в зависимостях LXC5.0, разрабатываемого изначально на дистрибутиве без SELinux'а однозначно нет. Я об этом говорил.
Кстати, GTK4 и systemd в зависимостях тоже не числится, если вы об этом. Тащить графический тулкит в зависимости консольной управлялке контейнерной изоляцией никто не будет, а systemd, в целом, происходящему ортогональна.
openvz правильнее, только они всё профукали.
Лучше бы сразу придумали как в NixOS или придумали что-то своё. Если бы линукс не тырил структуру приложение из Unix, а придумал что-то своё всем было был лучше. И не нужны были бы всё это контейнеры в докере в виртуалке в гипервизорве в облаке.
NixOS был бы номер один, если бы не пытался через свой велосипед рулить конфигами ПО. Тем более не всё настроики можно через этот велосипед сделать. Приходится и там, и в стандартных конфигах ПО вносить корректировки. Тот ещё зоопарк.
Для того чтобы это сделать было достаточно чьей то воли ли наоборот воли так не делать. Можно же было сделать по человечески.
Не понял, в чём проблема с конфигами у тебя. Никто не заставляет никсом конфиги генерировать. Положил файл рядом с кодом, сослался на него, дальше никс сам всё сделает. Мало файла — сделай шаблон. Мало шаблонов — целая система сборки под рукой, можно хоть джигу станцевать, хоть из другой репы взять нужные файлы и разложить куда надо. Без Никсоса ты чем конфиги по серверам раскидываешь? Ансиблом-паппетом-шефом? Или как локалхостный васян, вручную правишь по ssh?
>> Или как локалхостный васян, вручную правишь по ssh?Зачем на локалхосте вручную править конфиги по ssh?
Или у настоящего админа все должно быть по сети, даже секс?
Ты не понял, пакетный менеджер не должен рулить конфигами ПО. Собрали пакет, пользователь установил и только он может производить необходимые операции над ПО, а не пакетный менеджер, тем более с велосипедом в виде options. Как пользователь будет производиться необходимые операции не имеет значения, главное это делает он сам.Поэтому я считаю, что подход Nix, Guix, отчасти Debian с его бесконечными "я сам решу за пользователя" в корне неправильным. В Debian так вообще приколы бывают. Установил пакет А, через год установил пакет Б, а он при установке залез в директории, которые появились после установки пакета А, и внёс изменения в конфиги файлов из пакета А. Так при установке пакета не имеющего ничего общего с apache он может и меняет mpm последнему. Event поменять без ведома пользователя на prefork. Да за такое по рукам нужно бить.
Контейнеры это не только пространства имён файловой системы, есть ещё сеть, CPU, ввод-вывод, память, NixOS собирающий пакеты в разных каталогах с этим не поможет.
Так и штатными инструментами ос можно ограничивать ресурсы тем же cpulimit но сделать всё это правильно или хотя бы удобно было бы совсем не лишним.
Можно, именно это и делают системы контейнеризации docker, lxc и т.п., в NixOS ничего этого нет.
Всё это уж сто лет как встроено в systemd (cgroups, namespaces, capablities - основа основ systemd). А для таких вот изолированных "контейнеров" есть systemd-nspawn и система сборки образов "уровня ОС" (с почти любым произвольным дистром и инит системой внутре) mkosi для него . Никаких сторонних зависимостей типа runc. А приложеньку, как в дохере, вообще одной командой можно в контейнер упихуять, с пробросом сетевизмов и этим вот всем. На гитхабе даже кубер c nspawn контейнерами в бэке делали https://github.com/kinvolk/kube-spawn.
Пространства имён и прочее реализованы в ядре. Что осталось, так это именно собрать root fs.
А причём тут NixOS?
Lxc это изолированный кусок ОС как zones в солярке. Выглядит как виртуалка куда можно зайти и выйти. Хорошая штука для девопса
Отличная штука! Намного приятнее этих докеров-шмокеров.