Сообщество Linux Containers опубликовало релиз инструментария для организации работы изолированных контейнеров LXC 6.0, предоставляющий runtime, подходящий как для запуска контейнеров с полным системным окружением, близких к виртуальным машинам, так и для выполнения непривилегированных контейнеров отдельных приложений (OCI). LXC относится к низкоуровневым инструментариям, работающим на уровне отдельных контейнеров. Для централизованного управления контейнерами, развёрнутыми в кластере из нескольких серверов, на базе LXC развиваются системы Incus и LXD. Ветка LXC 6.0 отнесена к выпускам с длительной поддержкой, обновления для которых формируются в течение 5 лет (до 2029 года). Код LXC написан на языке Си и распространяется под лицензией GPLv2...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=60922
Кто пользует LXD или Incus, могу посоветовать веб-морду:
https://github.com/PenningLabs/lxconsoleДело субъективное, конечно. Для меня удобно. Данный проект разрабатывается в ответ на стагнацию LXDWare Dashboard (он был на PHP, а этот на Python). Лицензия AGPL-3.0.
Ни картинок, ни документации. Кажется оно совсем еще бета.
> Кажется оно совсем еще бета.Верно, они и не скрывают, прямо в ReadMe написано:
> This software is currently in BETA TESTING
Всё равно это скорее вспомогательный инструмент для внутреннего использования в своей инфраструктуре, который наружу не будет выставляться.
А там не нужно ни одно, ни другое. На тебе картинки, если так сильно хочется:
https://www.itzgeek.com/how-tos/linux/ubuntu-how-tos/manage-...
> Last updated Jul 18, 2016
> Ubuntu 16.04
Да, хорошая морда, главное на человеческом Python написана
Так каниникл свой ui продвигает и он уже включен в поставку lxd.
Сколько лет использую сначала чистый lxc, потом lxd для управления и никогда не знал, что есть официальная морда
Блин, пойду смотреть, вдруг и правда удобно
Спасибо, добрый аноним
> Сколько лет использую сначала чистый lxc, потом lxd для управления и никогда
> не знал, что есть официальная мордаЭта морда появилась совсем недавно
Установка только снапом? Спасибо, ешьте сами.
Если что, в Incus всё завезли без снапа, даже этот GUI:https://github.com/zabbly/incus?tab=readme-ov-file#setting-u...
аж до 0.12 версии додвинул....
Народ, посоветуйте контейнер сервера gitea настроенной и работающей CI/CD.
Это вам скорее в реестре Docker'a надо искать.Incus и LXD скорее про "контейнеры, которые чувствуются как вируталки" (упрощённо и грубо говоря), это больше system-контейнеры, а не application-контейнеры. Вообще тут можно подискутировать, ибо грань весьма условная.
Но в случае с Incus тут скорее сценарии вроде: создать контейнер и
1) ручками сделать всё так же, как если бы это была виртуалка.
или
2) использовать cloud-init для автоматизации.Можно ещё экспортировать контейнер с готовым и развёрнутым приложением, как вы хотите, но… В таком случае я бы всё же порекомендовал посмотреть на Docker.
> использовать cloud-init для автоматизации.Поковырялся я с этим Г.. ))) Нет уж, спасибо, не надо. Очень много гемора на простых вещах. Не может выполнить последовательность сценариев. Точнее может, но через костыли, навороты в виде мерджей (какой кошмар, в 21 веке то!) Так что лучше по старинке, Bash наше всё.
Ну, моё дело только сказать о технической возможности. А что будут использовать джентельмены – каждый сам решает.Для каких-то простых настроек и примитивных автоматизаций может быть вполне ок. Можно в профиль для новых контейнеров записать конфиг cloud-init с чем-нибудь типовым, типа как SSH-ключ прописать. Можно сильно не придираться, это просто как пример.
У меня ещё был специфический сценарий с запуском эфемерных контейнеров, когда надо было запустить из готового образа изолированное окружение с конкретным пользовательским скриптом. Вот там cloud-init вполне подошёл для автоматизации всего этого безумства.
Да, для простых профилей сгодиться. Проблема в том, что параметр `cloud-init.user-data` может быть только один для всех применяемых профилей настроек к контейнеру, так как это концепция такая каскадная перекрывать параметры предыдущих параметров. То есть, если есть в каждом из профилей свой `cloud-init.user-data`, например в профилях `--profile=media --profile=firefox`, то мерджа не будет никакого, отработает `cloud-init.user-data` из последнего профиля, то есть из `--profile=firefox`.Таким образом это сильно затрудняет оптимальную организацию кода инициализации контейнера и приводит к поддержке дублирующего кода во всех профилях. Можно конечно через костыли настроить мердж, но он тоже ограничен всего двумя параметрами вместо одного. Тоже ограничения. Плюс сам мердж кода на стороне cloud-init софта не идеален, может содержать ошибки и т.д. Получается наслоение сложности которое может порождать огромное количество багов на пустом месте.
Так что по мне так лучше Bash сценарии.
https://discuss.linuxcontainers.org/t/how-to-merge-profiles-...
> Проблема в том, что параметр 'cloud-init.user-data' может быть только один для всех применяемых профилей настроек к контейнеру, так как это концепция такая каскадная перекрывать параметры предыдущих параметров.Поддерживаю. Это серьёзный недостаток, сильно уменьшающий полезность cloud-init. Сам искал способы определить несколько конфигов cloud-init в разных профилях и наткнулся на то же самое… Хотя казалось бы, такая возможность звучала бы логично, она прямо таки напрашивается.
Да, да, да! Прямо серьёзный недостаток который уже несколько лет не могут решить. Ссылку на обсуждение оставил выше.
Контейнеров с настроенными приложениями в официальных репах нету. В репах только "голые" ОС. Самому нужно ставить, настраивать, а потом можно и экспортнуть и поделиться с кем-то. Может есть где в инете другие репозитории? Но доверия всё равно кним нет, не известно какие закладки туда понапихали. Так что лучше всё самому делать, с чистого листа.
Понимаю, но я так сильно устал от этого.
Спасли бы сценарии в профилях. Профилями конфигураций можно было бы делиться. Так, можно было бы хотя бы посмотреть визуально на код инициализации и не обнаружить там зло-кода. Но... Сейчас это проблематично, профили ограничены.У меня своя есть разработка на Bash, с "ядром" скрипта который принимает bash сценарии как plug-in's и выполняет их. В ядре реализованы вспомогательные базовые функции. А плагины это ничто иное как упрощённые bash-сценарий установки контейнера и его инициализация. В этом случае нет никаких ограничений, для домашнего использования вполне годиться. Плагинами можно делиться. Для коммерции тут думать надо, так как скорее всего небезопасно будет выполнять такие плагины на чистом Bash.
Еще можно на Python'e реализовать выполнение сценариев, а сценарии могут быть в декларативной разметке YAML, к примеру. Будет безопасно и практично. Надо озадачиться такой задачей, а то что-то cloud-init мне совсем не нравится )))
Ты придумал ансибл
На пайтоне, с ямлом
Все как ты просишь
> Ты придумал ансиблТам вроде как нет поддержки LXD/Incus :) А так тоже вариант был бы.
> Там вроде как нет поддержки LXD/Incus :)https://docs.ansible.com/ansible/2.9/modules/lxd_container_m...
>> Там вроде как нет поддержки LXD/Incus :)
> https://docs.ansible.com/ansible/2.9/modules/lxd_container_m...Хмм.. Спасибо! Поизучаю
Ansible - это вчерашний день там, где есть более совершенные специализированные инструменты типа K8S.В случае с LXD/Incus - это декларативные портянки в стиле docker-compose:
https://github.com/bravetools/bravetools
https://mottainaici.github.io/lxd-compose-docs/docs/tutorial/
А из графических шляп ещё есть LXDWare: https://lxdware.com/
> Ansible - это вчерашний день там, где есть более совершенные специализированные инструменты
> типа K8S.
> В случае с LXD/Incus - это декларативные портянки в стиле docker-compose:
> https://github.com/bravetools/bravetoolsО! Это уже интересно! Монстра Ansible не хочется познавать
Чтобы начать с Ansible достаточно только "apt install openssh-server python" и задать пароли пользователей (или SSH ключи). Минут 5-15, и - всё, можно писать код и запускать! Где не хватает Yaml, можно модуль на Питоне.Чтобы сделать K8s... нужен кластер разновсякого софта и сборочная платформа образов, плюс репозитарий артефактов. Примерно по сложности как замутить Linux From Scratch и поддерживать. И тооолько потооом можно начать писать аналог кода управления. А если не хватает Yaml, то уууу... сколько ещё вджобывать и вджобывать придётся.
Сравнили тут воробья с стаей орлов...
Так ли сложно поставить кластер K0S, для начала хотя бы одноузловой?Проблема с Ansible лишь в том, что он недостаточно декларативен, и при сколько-нибудь заметной сложности проекта (тысячи строк кода инфры для десятков и сотен взаимосвязанных узлов для обеспечения достаточной интегрированности разных частей этого проекта придётся писать свой собственный K8S уже на Ansible. Не проще ли (на много порядков) воспользоваться готовым K8S?
Ты не поверишь, но на многих проектах k8s просто избыточен и достаточно трех виртуалок и руления при помощи ансибла
Слушай, ну вот есть проект у проекта есть виртуалка продакшена, виртуалка дева(она же резерв для продакшена, в смысле что на ней есть все что бы им выступить, но все погашено от прода, это резерв) и виртуалка с тг-ботом(да, отдельная целая виртуалка, так надо)
Есть Gitea+CI/CD, откуда осуществляется выливка, есть мониторинги и прочее
Но зачем нам тут кубер?
Куда его тут привинчивать и зачем?
У нас цель, что бы все работало и в случае смерти(болезни мешающей работать, посадки в концлагерь и т.д.) того кто поддерживает(называй хоть админом, хоть дево-псом, хоть SRE и сбоку бантик) это смог быстро подхватить другой человек, не вникая в приколы кубера и что там куда завернуто, да на какую дупу провернуто
Эммм... а ничего, что вы оркестратор с системой управления конфигурациями сравниваете?
А ничего, что Ansible SCM настолько универсален, что на нём некоторые велосипедисты умудряются оркестировать? Хорошо это или нет? Ответ дан выше, тем у кого полная автоматизация HA - им нужен K8S с автоскейлингом и многими другими современными фишками. А у недоразвитых колхозников есть резервный сервер в чулане, который они поднимают ансиблом, если конечно к моменту поднятия не поломается что-то во внешних зависимостях. Но ведь остаются даже и такие траглодиты, которые вообще ставят с помощью пакетных менеджеров типа apt, dnf и т.п., причём тогда, когда у них умер сервер ...
> Минут 5-15, и - всё, можно писать код и запускать! Где не хватает Yaml, можно модуль на Питоне."Минут 5-15, и - всё," (c)
Можно писать заявление на увольнение, потому что в apt репозитории оказались свежие поломанные пакеты, например, с кривыми зависимостями, или пропал линк до репозитория.
И твои 5-15 минут превратились в 5-15 часов, а то и вовсе в 5-15 дней ...
Или у тебя локальная aptly копия? Ну ладно, продолжай пердолинг, но таки нормальный админ освоил бы хотя бы Docker с заранее собранными и протестированным своими кастом контеёнерами.
В proxmox есть вот такой настроенный контейнер:
https://www.turnkeylinux.org/gitea
Вообще-то Incus 6.0 только анонсировали, нет никакого выпуска. Сейчас выпуск версии только 0.7
В репозитории уже есть, а вот новость на их форуме стала 404.
Мдаа.. Хрень какая-то. Не понятно.
Открывается нормально.
v6.0.0 Latest
Compare
@stgraber stgraber released this 04 Apr 03:34
· 5 commits to main since this release
v6.0.0714bcc5
> Открывается нормально.Сейчас уже открывается. Раньше не открывалось
Магазин приложений в формате OCI где-либо имеется? Для примера, поискал Firefox в OCI, не нашлось.
И не найдешь!Таким ивращением никто в здравом уме не будет страдать. Если нужна изоляция, то возьми flatpak версию https://flathub.org/apps/org.mozilla.firefox
В Генте flatpak не заходит. Проще LXC поднять.
А в чем разница между Incus и lxc ?
Прям в новости написано:> LXC относится к низкоуровневым инструментариям, работающим на уровне отдельных контейнеров. Для централизованного управления контейнерами, развёрнутыми в кластере из нескольких серверов, на базе LXC развиваются системы Incus и LXD.
LXC – то что работает "внутри", непосредственно рулит контейнерами на низком уровне.
LXD и Incus – работают поверх LXC, на основе него. С их помощью можно сделать всё то же самое, что и напрямую с LXC, но гораздо удобнее и организованно.Это, весьма грубо говоря, примерно как libcontainer и Docker (сравнение не очень правильное, но наверное поможет чуть лучше понять, как относятся LXC и LXD/Incus).
Всё не так :))Путаница эта давно идёт и никак не заканчивается, поэтому команда incus сделала фундаментальное изменение в проекте (обратно не совместимое), чтобы в том числе это исправить.
История эволюции Linux container'ов примерно следующая:
* LXC - Это какая-то древняя реализация контейнеров с реализацией библиотки liblxc
* LXD/LXC - это следующая эволюция в которой отвязались от liblxc, переписали всё на Go и сделали разделение проекта на серверную часть (LXD - Deamon) и клиентскую части (LXC - Client). Сервер, точнее демон, это ничто иное как RESTful API сервис принимающий запросы в JSON, клиент (LXC) это собственно клиент который генерирует запросы в JSON и отправляет их демону (серверу) и получает от него ответ. Примерно так.
* Incus это форк LXD/LXCЧем отличается LXD/LXC от Incus? Тем, что первый поддерживается командой Canonical, второй поддерживаетеся сообществом и пока существенной разницы между ними нет. Есть ньюансы, но они не большие.
> LXD/LXC - это следующая эволюция в которой отвязались от liblxc... клиентскую части (LXC - Client)...Вы уверены? На сайте Incus пишут:
> Incus is a container and virtual-machine manager. Based on LXC for containers...
> LXC is a well-known Linux container runtime that consists of tools, templates, and library and language bindings.Вот тут явно пишут, что Incus зависит от LXC: https://linuxcontainers.org/incus/docs/main/requirements/#lxc
> Incus requires LXC 5.0.0 or higher
Я считаю, что вы заблуждаетесь. LXC – не "клиент", а как раз таки бэкенд для контейнеров. Таким же образом, как и QEMU используется в качестве бэкенда для виртуальных машин в Incus/LXD.
А то что "клиентская" команда у них "lxc" называется, так на это не обращайте внимания, оно путает.
Ну и финальный аккорд касательно "отвязались от liblxc", тут вы прямо таки не правы: https://linuxcontainers.org/incus/docs/main/explanation/inst.../
> Containers are implemented through the use of liblxc (LXC).
>> LXD/LXC - это следующая эволюция в которой отвязались от liblxc... клиентскую части (LXC - Client)...
> Вы уверены? На сайте Incus пишут:Всё что вы написали, это именно та ВЕСКАЯ причина (просто космическая без приувеличения!) :) по которой следовало бы сделать fork :) Документация просто видимо не была корректно написана изначально и мир уже не исправить :) Я сам в шоке. Теперь всё по порядку:
> Вот тут явно пишут, что Incus зависит от LXC: https://linuxcontainers.org/incus/docs/main/requirements/#lxc
1) Видимо это следует воспринимать как LXD/LXC, так как никаких `liblxc` у меня нет в пакете и в системе тоже:
```
[dv@manjaro ~]$ pacman -Ql incus
incus /usr/lib/systemd/system/incus-user.service
incus /usr/lib/systemd/system/incus-user.socket
incus /usr/lib/systemd/system/incus.service
incus /usr/lib/systemd/system/incus.socket
incus /usr/lib/sysusers.d/incus.conf
```К слову, нужно понимать ещё и то, что раньше на этом сайте были разделы LXC, LXD. Сейчас Incus, LXC, а раздел LXD удалён. Видимо авторы решили называть LXD от Каноникал - LXC. Это просто проклятие какое-то с названиями!! ))))
Также, изначальный (древний как мамонт LXC) насколько мне известно ничего не знает о виртуальных машинах и в частности о QEMU. Этим он и отличается от LXD/LXC.
Также, указанная зависимость по указанной вами ссылке (Incus requires LXC 5.0.0 or higher) видимо указывает на пакет `lxcfs` от которой он зависим! Тут уже стоит принять таблетки от срыва ))) Потому как уже становится всё горячее! ))))
После того как авторы сайта linuxcontainers.org переформатировали сайт, теперь трудно сослаться где у них было указано, что LXD это Daemon, а LXC - client. Но пойдём на сайт убунты и посмотрим на эту страницу вниз:
https://documentation.ubuntu.com/lxd/en/latest/explanation/l.../
> To control LXD, you typically use two different commands: lxd and lxc.
то есть, вызовите справку `lxc --help` и узнаете, что это КЛИЕНТ для LXD:
https://documentation.ubuntu.com/lxd/en/latest/reference/man...
> А то что "клиентская" команда у них "lxc" называется, так на это не обращайте внимания, оно путает.
Вот в том то и дело, что нужно различать:
1) LXC (liblxc)
2) LXD/LXC (все клиентские команды будут начинаться с lxc, поэтому гуглить надо будет именно так)
3) IncusИ финальный ваш аккорд:
https://linuxcontainers.org/incus/docs/main/explanation/inst.../
Тут я прокоментировать не могу. Видимо документация не соответствует или что-то имеется ввиду другое, поскольку никаких liblxc в моей системе не было с LXD и нет с Incus.
Прямо по вашей же ссылке "пойдём на сайт убунты и посмотрим на эту страницу вниз" пишут:> Under the hood, LXD uses LXC to create and manage the containers.
Они явно пишут, что есть LXC, состоящий из утилит, библиотеки и прочего:
> LXC is a low-level user space interface for the Linux kernel containment features. It consists of tools (lxc-* commands), templates, and library and language bindings.
А есть LXD, который является альтернативой клиентским утилитам LXC, но внутри всё тот же LXC:
> LXD is a more intuitive and user-friendly tool aimed at making it easy to work with Linux containers. It is an alternative to LXC’s tools and distribution template system, with the added features that come from being controllable over the network. Under the hood, LXD uses LXC to create and manage the containers.
LXC-клиент, который идёт в комплекте к LXD, это просто способ взаимодействия с LXD, который уже использует LXC-бэкенд для контейнеров (или QEMU для ВМ).
Собственно, приведённые вами ссылки как раз таки подтверждают мою точку зрения, достаточно просто почитать.
У меня на openSUSE LXD зависит от liblxc. Как у вас там – не знаю (предположение пальцем в небо – вдруг там статически слинковано, ну кто знает).
> $ zypper --no-refresh info --requires lxd | grep lxc
> lxcfs
> lxcfs-hooks-lxc
> liblxc.so.1()(64bit)
Да, надо признать я нашёл такой пакет у себя:>[dv@manjaro ~]$ pacman -Ql lxc | grep liblxc
>lxc /usr/lib/liblxc.so
>lxc /usr/lib/liblxc.so.1
>lxc /usr/lib/liblxc.so.1.7.0Но управлять через него контейнеры не получится, во всяком случае у меня это не выходит. Он просто ничего не знает о контейнерах. Видимо да, не отвязались ещё от liblxc, но планы вроде как были.
В любом случае, проектом LXC не получится пользоваться в составе LXD, так как с LXD поставляется свой клиент LXC (C - как раз указывает на слово Client).
Поэтому всё же надо различать:
1) LXC (низкоуровневый, тот что с командами lxc-*)
2) LXD/LXC (который имеет демона и клиента lxc --help)
3) Incus (форк LXD, а не LXC)
> Поэтому всё же надо различать:Да, я именно об этом я изначально и говорил.
> Он просто ничего не знает о контейнерах.
Тоже всё правильно, потому что ими управляет LXD/Incus. У них и есть функционал для миграции из "чистого" LXC на LXD/Incus. Но внутри остаётся именно LXC-бэкенд.
Так это о том, о чём я и писал изначально в постеhttps://www.opennet.dev/openforum/vsluhforumID3/133307.html#38
Просто единственное, я не знал, что они ещё не отвязались от старого проекта. Но сути это не меняет. Сейчас есть 3 проекта и их надо "разделять".
P.S. Спасибо за беседу. Теперь стало более яснее.
Называется «отвязались от liblxc»:https://github.com/lxc/incus/blob/main/internal/server/insta...
> Ну и финальный аккорд касательно "отвязались от liblxc", тут вы прямо таки
> не правы: https://linuxcontainers.org/incus/docs/main/explanation/inst.../
>> Containers are implemented through the use of liblxc (LXC).Перевод дословный: Контейнеры были реализованы через использование liblxc. Что это значит? Какие контейнеры? Чьи? Мои? Или в репозитории образов? Что здесь имеют ввиду под контейнерами - я не знаю. Возможно старая документация которую некому поддержать.
Там достаточно ясно написано. В LXD/Incus мы можем создавать instanc'ы, а они могут быть двух типов: либо контейнер, либо виртуальная машина. Первый вариант реализован поверх LXC. Второй вариант – поверх QEMU.
> Контейнеры были реализованы через использование liblxc. Что это значит? Какие контейнеры?Вот такие: https://github.com/lxc/incus/blob/main/internal/server/insta...
// The LXC container driver.
type lxc struct {
...
c *liblxc.Container // Use d.initLXC() instead of accessing this directly.
...
}
Хорошо. Теперь я понял лучше. Значит получается следующее:1) Проект LXC (https://linuxcontainers.org/lxc/getting-started/)
2) Проект LXD/LXC который зависит от LXC и имеет СВОЙ КЛИЕНТ LXC (то есть два LXC с пользовательской стороны). Клиент с командами lxc-* который не работает с пользователем, но поставляется, и клиент lxc который работает с LXD. Таким образом это никак не отменяет, что LXC это клиент для LXD, тем более справка это подтверждает вызовом lxc --help
3) Incus - Форк LXD, кторый также поставляется с LXC, но со старым, низкоуровневым LXC, а не с тем, что поставлялся в LXD как клиент. Сейчас LXC это incus, а работа с демоном (lxd) превратилась в incus admin *
Мда...
Разве Incus - это не форк LXD? IMHO Incus от LXD концептуально ничем не отличается, только деталями реализации и лицензированием.
> Разве Incus - это не форк LXD?Форк LXD, так у меня и написано в предыдущем посте. Смотрите внимательнее:
> 3) Incus - Форк LXD
> отвязались от liblxcНу или они действительно отвязались, но документацию не обновили… Но пока не увидел иного, буду придерживаться точки зрения из документации.
> LXD/LXC - это следующая эволюция в которой отвязались от liblxcВаша версия не сходится с тем, что по документации LXD и Incus явно зависят от liblxc. Даже пусть доки устарели – если бы они изначально ещё в LXD ушли от liblxc, как вы описали, то и в самой документации изначально такого бы не было.
> Install Incus from source
>
> Follow these instructions if you want to build and install Incus from the source code.
>
> We recommend having the latest versions of liblxc (>= 5.0.0 required) available for Incus development. Additionally, Incus requires a modern Golang (see Go) version to work.Куда ни посмотреть, я не могу найти ни одного подтверждения вашей версии.
Если у вас есть ссылки, где описано именно то что вы рассказываете, то поделитесь, пожалуйста. Тема действительно запутанная, и из-за названий, и со всеми этими форками…
LXD/Incus - это кластерный оркестратор LXC контейнеров и libvirt виртуалок, - т.е. прямая замена для проксьмоськса. Но намного лучше, потому что можно запустить и на Devuan и на Alpine, где системднища и в помине нет.
Здесь о том, кто создал, как и почему
> Для взаимодействия с systemd через D-Bus задействована отдельная библиотека libdbus-1 вместо libsystemdВот что бекдор в xz животворящий делает!