| |
| |
| 3.5, Аноним (1), 10:47, 04/04/2024 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Кажется оно совсем еще бета.
Верно, они и не скрывают, прямо в ReadMe написано:
> This software is currently in BETA TESTING
Всё равно это скорее вспомогательный инструмент для внутреннего использования в своей инфраструктуре, который наружу не будет выставляться.
| | |
|
| |
| 3.21, Аноним (21), 13:11, 04/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
Сколько лет использую сначала чистый lxc, потом lxd для управления и никогда не знал, что есть официальная морда
Блин, пойду смотреть, вдруг и правда удобно
Спасибо, добрый аноним
| | |
| |
| 4.24, microcoder (ok), 13:28, 04/04/2024 [^] [^^] [^^^] [ответить]
| +2 +/– |
 > Сколько лет использую сначала чистый lxc, потом lxd для управления и никогда
> не знал, что есть официальная морда
Эта морда появилась совсем недавно
| | |
|
|
|
| 1.2, Аноним (2), 10:39, 04/04/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Народ, посоветуйте контейнер сервера gitea настроенной и работающей CI/CD.
| | |
| |
| 2.4, Аноним (1), 10:45, 04/04/2024 [^] [^^] [^^^] [ответить]
| +5 +/– | |
Это вам скорее в реестре Docker'a надо искать.
Incus и LXD скорее про "контейнеры, которые чувствуются как вируталки" (упрощённо и грубо говоря), это больше system-контейнеры, а не application-контейнеры. Вообще тут можно подискутировать, ибо грань весьма условная.
Но в случае с Incus тут скорее сценарии вроде: создать контейнер и
1) ручками сделать всё так же, как если бы это была виртуалка.
или
2) использовать cloud-init для автоматизации.
Можно ещё экспортировать контейнер с готовым и развёрнутым приложением, как вы хотите, но… В таком случае я бы всё же порекомендовал посмотреть на Docker.
| | |
| |
| 3.10, microcoder (ok), 10:55, 04/04/2024 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> использовать cloud-init для автоматизации.
Поковырялся я с этим Г.. ))) Нет уж, спасибо, не надо. Очень много гемора на простых вещах. Не может выполнить последовательность сценариев. Точнее может, но через костыли, навороты в виде мерджей (какой кошмар, в 21 веке то!) Так что лучше по старинке, Bash наше всё.
| | |
| |
| 4.12, Аноним (1), 11:01, 04/04/2024 [^] [^^] [^^^] [ответить]
| +2 +/– | |
Ну, моё дело только сказать о технической возможности. А что будут использовать джентельмены – каждый сам решает.
Для каких-то простых настроек и примитивных автоматизаций может быть вполне ок. Можно в профиль для новых контейнеров записать конфиг cloud-init с чем-нибудь типовым, типа как SSH-ключ прописать. Можно сильно не придираться, это просто как пример.
У меня ещё был специфический сценарий с запуском эфемерных контейнеров, когда надо было запустить из готового образа изолированное окружение с конкретным пользовательским скриптом. Вот там cloud-init вполне подошёл для автоматизации всего этого безумства.
| | |
| |
| 5.13, microcoder (ok), 11:08, 04/04/2024 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Да, для простых профилей сгодиться. Проблема в том, что параметр '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-user-vendor-data/7
| | |
| |
| 6.14, Аноним (1), 11:12, 04/04/2024 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Проблема в том, что параметр 'cloud-init.user-data' может быть только один для всех применяемых профилей настроек к контейнеру, так как это концепция такая каскадная перекрывать параметры предыдущих параметров.
Поддерживаю. Это серьёзный недостаток, сильно уменьшающий полезность cloud-init. Сам искал способы определить несколько конфигов cloud-init в разных профилях и наткнулся на то же самое… Хотя казалось бы, такая возможность звучала бы логично, она прямо таки напрашивается.
| | |
| |
| 7.15, microcoder (ok), 11:14, 04/04/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
Да, да, да! Прямо серьёзный недостаток который уже несколько лет не могут решить. Ссылку на обсуждение оставил выше.
| | |
|
|
|
|
|
| 2.8, microcoder (ok), 10:52, 04/04/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
Контейнеров с настроенными приложениями в официальных репах нету. В репах только "голые" ОС. Самому нужно ставить, настраивать, а потом можно и экспортнуть и поделиться с кем-то. Может есть где в инете другие репозитории? Но доверия всё равно кним нет, не известно какие закладки туда понапихали. Так что лучше всё самому делать, с чистого листа.
| | |
| |
| |
| 4.18, microcoder (ok), 11:47, 04/04/2024 [^] [^^] [^^^] [ответить]
| +/– | |
Спасли бы сценарии в профилях. Профилями конфигураций можно было бы делиться. Так, можно было бы хотя бы посмотреть визуально на код инициализации и не обнаружить там зло-кода. Но... Сейчас это проблематично, профили ограничены.
У меня своя есть разработка на Bash, с "ядром" скрипта который принимает bash сценарии как plug-in's и выполняет их. В ядре реализованы вспомогательные базовые функции. А плагины это ничто иное как упрощённые bash-сценарий установки контейнера и его инициализация. В этом случае нет никаких ограничений, для домашнего использования вполне годиться. Плагинами можно делиться. Для коммерции тут думать надо, так как скорее всего небезопасно будет выполнять такие плагины на чистом Bash.
| | |
| 4.19, microcoder (ok), 12:00, 04/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
Еще можно на Python'e реализовать выполнение сценариев, а сценарии могут быть в декларативной разметке YAML, к примеру. Будет безопасно и практично. Надо озадачиться такой задачей, а то что-то cloud-init мне совсем не нравится )))
| | |
| |
| |
| 6.25, microcoder (ok), 13:33, 04/04/2024 [^] [^^] [^^^] [ответить]
| +/– | |
> Ты придумал ансибл
Там вроде как нет поддержки LXD/Incus :) А так тоже вариант был бы.
| | |
| |
| 7.58, microcoder (ok), 21:22, 04/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
> Ansible - это вчерашний день там, где есть более совершенные специализированные инструменты
> типа K8S.
> В случае с LXD/Incus - это декларативные портянки в стиле docker-compose:
> https://github.com/bravetools/bravetools
О! Это уже интересно! Монстра Ansible не хочется познавать
| | |
| 7.60, Аноним (60), 22:00, 04/04/2024 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Чтобы начать с Ansible достаточно только "apt install openssh-server python" и задать пароли пользователей (или SSH ключи). Минут 5-15, и - всё, можно писать код и запускать! Где не хватает Yaml, можно модуль на Питоне.
Чтобы сделать K8s... нужен кластер разновсякого софта и сборочная платформа образов, плюс репозитарий артефактов. Примерно по сложности как замутить Linux From Scratch и поддерживать. И тооолько потооом можно начать писать аналог кода управления. А если не хватает Yaml, то уууу... сколько ещё вджобывать и вджобывать придётся.
Сравнили тут воробья с стаей орлов...
| | |
| |
| |
| 9.65, Аноним (65), 14:53, 05/04/2024 [^] [^^] [^^^] [ответить] | +/– | Ты не поверишь, но на многих проектах k8s просто избыточен и достаточно трех вир... большой текст свёрнут, показать | | |
| 9.68, User (??), 15:15, 05/04/2024 [^] [^^] [^^^] [ответить] | +/– | Эммм а ничего, что вы оркестратор с системой управления конфигурациями сравни... текст свёрнут, показать | | |
|
|
|
|
|
|
|
|
| 1.6, microcoder (ok), 10:49, 04/04/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Вообще-то Incus 6.0 только анонсировали, нет никакого выпуска. Сейчас выпуск версии только 0.7
| | |
| |
| |
| 3.61, Минона (ok), 22:51, 04/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
 Открывается нормально.
v6.0.0 Latest
Compare
@stgraber stgraber released this 04 Apr 03:34
· 5 commits to main since this release
v6.0.0
714bcc5
| | |
|
|
| 1.20, Аноним (20), 12:21, 04/04/2024 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Магазин приложений в формате OCI где-либо имеется? Для примера, поискал Firefox в OCI, не нашлось.
| | |
| |
| 2.36, Аноним (32), 16:30, 04/04/2024 [^] [^^] [^^^] [ответить]
| +/– | |
Прям в новости написано:
> LXC относится к низкоуровневым инструментариям, работающим на уровне отдельных контейнеров. Для централизованного управления контейнерами, развёрнутыми в кластере из нескольких серверов, на базе LXC развиваются системы Incus и LXD.
LXC – то что работает "внутри", непосредственно рулит контейнерами на низком уровне.
LXD и Incus – работают поверх LXC, на основе него. С их помощью можно сделать всё то же самое, что и напрямую с LXC, но гораздо удобнее и организованно.
Это, весьма грубо говоря, примерно как libcontainer и Docker (сравнение не очень правильное, но наверное поможет чуть лучше понять, как относятся LXC и LXD/Incus).
| | |
| |
| 3.38, microcoder (ok), 17:11, 04/04/2024 [^] [^^] [^^^] [ответить]
| +/– | |
Всё не так :))
Путаница эта давно идёт и никак не заканчивается, поэтому команда 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, второй поддерживаетеся сообществом и пока существенной разницы между ними нет. Есть ньюансы, но они не большие.
| | |
| |
| 4.39, Аноним (32), 17:51, 04/04/2024 [^] [^^] [^^^] [ответить] | +/– | Вы уверены На сайте Incus пишут Вот тут явно пишут, что Incus зависит от LXC ... большой текст свёрнут, показать | | |
| |
| |
| 6.44, Аноним (32), 18:46, 04/04/2024 [^] [^^] [^^^] [ответить] | +/– | Прямо по вашей же ссылке пойдём на сайт убунты и посмотрим на эту страницу вниз... большой текст свёрнут, показать | | |
| |
| 7.48, microcoder (ok), 19:05, 04/04/2024 [^] [^^] [^^^] [ответить]
| +/– | |
Да, надо признать я нашёл такой пакет у себя:
>[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)
| | |
| |
| 8.50, Аноним (32), 19:07, 04/04/2024 [^] [^^] [^^^] [ответить] | +/– | Да, я именно об этом я изначально и говорил Тоже всё правильно, потому что ими ... текст свёрнут, показать | | |
|
|
|
| 5.43, microcoder (ok), 18:38, 04/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
> Ну и финальный аккорд касательно "отвязались от liblxc", тут вы прямо таки
> не правы: https://linuxcontainers.org/incus/docs/main/explanation/instances/
>> Containers are implemented through the use of liblxc (LXC).
Перевод дословный: Контейнеры были реализованы через использование liblxc. Что это значит? Какие контейнеры? Чьи? Мои? Или в репозитории образов? Что здесь имеют ввиду под контейнерами - я не знаю. Возможно старая документация которую некому поддержать.
| | |
| |
| 6.45, Аноним (32), 18:47, 04/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
Там достаточно ясно написано. В LXD/Incus мы можем создавать instanc'ы, а они могут быть двух типов: либо контейнер, либо виртуальная машина. Первый вариант реализован поверх LXC. Второй вариант – поверх QEMU.
| | |
| |
| 7.53, microcoder (ok), 19:24, 04/04/2024 [^] [^^] [^^^] [ответить]
| +/– | |
Хорошо. Теперь я понял лучше. Значит получается следующее:
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 *
Мда...
| | |
|
|
|
| 4.41, Аноним (32), 17:55, 04/04/2024 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> отвязались от liblxc
Ну или они действительно отвязались, но документацию не обновили… Но пока не увидел иного, буду придерживаться точки зрения из документации.
| | |
| 4.49, Аноним (32), 19:05, 04/04/2024 [^] [^^] [^^^] [ответить] | +/– | Ваша версия не сходится с тем, что по документации LXD и Incus явно зависят от l... большой текст свёрнут, показать | | |
|
| 3.56, Хочу стать девопсом пусть меня научат (?), 21:04, 04/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
LXD/Incus - это кластерный оркестратор LXC контейнеров и libvirt виртуалок, - т.е. прямая замена для проксьмоськса. Но намного лучше, потому что можно запустить и на Devuan и на Alpine, где системднища и в помине нет.
| | |
|
|
| 1.63, Анонимус3000 (?), 23:58, 04/04/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
> Для взаимодействия с systemd через D-Bus задействована отдельная библиотека libdbus-1 вместо libsystemd
Вот что бекдор в xz животворящий делает!
| | |
|
