Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Выпуск инструментариев управления контейнерами LXC 6.0, Incus 6.0 и LXD 5.21.1"	+/–
Сообщение от opennews (??), 04-Апр-24, 10:21
Сообщество Linux Containers опубликовало релиз инструментария для организации работы изолированных контейнеров LXC 6.0, предоставляющий   runtime, подходящий как для  запуска контейнеров с полным системным окружением, близких к виртуальным машинам, так и для выполнения непривилегированных контейнеров отдельных приложений (OCI). LXC относится к низкоуровневым инструментариям, работающим на уровне отдельных контейнеров. Для  централизованного управления контейнерами, развёрнутыми в кластере из нескольких серверов, на базе LXC развиваются системы Incus и LXD. Ветка LXC 6.0 отнесена к выпускам с длительной поддержкой, обновления для которых формируются в течение 5 лет (до 2029 года). Код LXC написан на языке Си и распространяется под лицензией GPLv2... Подробнее: https://www.opennet.me/opennews/art.shtml?num=60922
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 04-Апр-24, 10:21	+4 +/–
Кто пользует LXD или Incus, могу посоветовать веб-морду: https://github.com/PenningLabs/lxconsole Дело субъективное, конечно. Для меня удобно. Данный проект разрабатывается в ответ на стагнацию LXDWare Dashboard (он был на PHP, а этот на Python). Лицензия AGPL-3.0.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #3, #7, #17

2. Сообщение от Аноним (2), 04-Апр-24, 10:39	+/–
Народ, посоветуйте контейнер сервера gitea настроенной и работающей CI/CD.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #4, #8, #51

3. Сообщение от anonymplusplus (?), 04-Апр-24, 10:42	+/–
Ни картинок, ни документации. Кажется оно совсем еще бета.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #5, #26

4. Сообщение от Аноним (1), 04-Апр-24, 10:45	+6 +/–
Это вам скорее в реестре Docker'a надо искать. Incus и LXD скорее про "контейнеры, которые чувствуются как вируталки" (упрощённо и грубо говоря), это больше system-контейнеры, а не application-контейнеры. Вообще тут можно подискутировать, ибо грань весьма условная. Но в случае с Incus тут скорее сценарии вроде: создать контейнер и 1) ручками сделать всё так же, как если бы это была виртуалка. или 2) использовать cloud-init для автоматизации. Можно ещё экспортировать контейнер с готовым и развёрнутым приложением, как вы хотите, но… В таком случае я бы всё же порекомендовал посмотреть на Docker.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #10

5. Сообщение от Аноним (1), 04-Апр-24, 10:47	+1 +/–
> Кажется оно совсем еще бета. Верно, они и не скрывают, прямо в ReadMe написано: > This software is currently in BETA TESTING Всё равно это скорее вспомогательный инструмент для внутреннего использования в своей инфраструктуре, который наружу не будет выставляться.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

6. Сообщение от microcoder (ok), 04-Апр-24, 10:49	+/–
Вообще-то Incus 6.0 только анонсировали, нет никакого выпуска. Сейчас выпуск версии только 0.7
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #9

7. Сообщение от microcoder (ok), 04-Апр-24, 10:50	+/–
Да, хорошая морда, главное на человеческом Python написана
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

8. Сообщение от microcoder (ok), 04-Апр-24, 10:52	+1 +/–
Контейнеров с настроенными приложениями в официальных репах нету. В репах только "голые" ОС. Самому нужно ставить, настраивать, а потом можно и экспортнуть и поделиться с кем-то. Может есть где в инете другие репозитории? Но доверия всё равно кним нет, не известно какие закладки туда понапихали. Так что лучше всё самому делать, с чистого листа.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #16

9. Сообщение от Аноним (1), 04-Апр-24, 10:53	+/–
В репозитории уже есть, а вот новость на их форуме стала 404. https://github.com/lxc/incus/releases/tag/v6.0.0
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #11, #61

10. Сообщение от microcoder (ok), 04-Апр-24, 10:55	+2 +/–
> использовать cloud-init для автоматизации. Поковырялся я с этим Г.. ))) Нет уж, спасибо, не надо. Очень много гемора на простых вещах. Не может выполнить последовательность сценариев. Точнее может, но через костыли, навороты в виде мерджей (какой кошмар, в 21 веке то!) Так что лучше по старинке, Bash наше всё.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #12

11. Сообщение от microcoder (ok), 04-Апр-24, 10:58	+1 +/–
Мдаа.. Хрень какая-то. Не понятно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

12. Сообщение от Аноним (1), 04-Апр-24, 11:01	+2 +/–
Ну, моё дело только сказать о технической возможности. А что будут использовать джентельмены – каждый сам решает. Для каких-то простых настроек и примитивных автоматизаций может быть вполне ок. Можно в профиль для новых контейнеров записать конфиг cloud-init с чем-нибудь типовым, типа как SSH-ключ прописать. Можно сильно не придираться, это просто как пример. У меня ещё был специфический сценарий с запуском эфемерных контейнеров, когда надо было запустить из готового образа изолированное окружение с конкретным пользовательским скриптом. Вот там cloud-init вполне подошёл для автоматизации всего этого безумства.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #13

13. Сообщение от microcoder (ok), 04-Апр-24, 11:08	+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-...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #14

14. Сообщение от Аноним (1), 04-Апр-24, 11:12	+1 +/–
> Проблема в том, что параметр 'cloud-init.user-data' может быть только один для всех применяемых профилей настроек к контейнеру, так как это концепция такая каскадная перекрывать параметры предыдущих параметров. Поддерживаю. Это серьёзный недостаток, сильно уменьшающий полезность cloud-init. Сам искал способы определить несколько конфигов cloud-init в разных профилях и наткнулся на то же самое… Хотя казалось бы, такая возможность звучала бы логично, она прямо таки напрашивается.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #15

15. Сообщение от microcoder (ok), 04-Апр-24, 11:14	+1 +/–
Да, да, да! Прямо серьёзный недостаток который уже несколько лет не могут решить. Ссылку на обсуждение оставил выше.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14

16. Сообщение от Аноним (2), 04-Апр-24, 11:28	+1 +/–
Понимаю, но я так сильно устал от этого.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #18, #19

17. Сообщение от r2d0 (?), 04-Апр-24, 11:45	+5 +/–
Так каниникл свой ui продвигает и он уже включен в поставку lxd. https://github.com/canonical/lxd-ui
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #21, #27, #75

18. Сообщение от microcoder (ok), 04-Апр-24, 11:47	+/–
Спасли бы сценарии в профилях. Профилями конфигураций можно было бы делиться. Так, можно было бы хотя бы посмотреть визуально на код инициализации и не обнаружить там зло-кода. Но... Сейчас это проблематично, профили ограничены. У меня своя есть разработка на Bash, с "ядром" скрипта который принимает bash сценарии как plug-in's и выполняет их. В ядре реализованы вспомогательные базовые функции. А плагины это ничто иное как упрощённые bash-сценарий установки контейнера и его инициализация. В этом случае нет никаких ограничений, для домашнего использования вполне годиться. Плагинами можно делиться. Для коммерции тут думать надо, так как скорее всего небезопасно будет выполнять такие плагины на чистом Bash.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16

19. Сообщение от microcoder (ok), 04-Апр-24, 12:00	+/–
Еще можно на Python'e реализовать выполнение сценариев, а сценарии могут быть в декларативной разметке YAML, к примеру. Будет безопасно и практично. Надо озадачиться такой задачей, а то что-то cloud-init мне совсем не нравится )))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #22

20. Сообщение от Аноним (20), 04-Апр-24, 12:21	–1 +/–
Магазин приложений в формате OCI где-либо имеется? Для примера, поискал Firefox в OCI, не нашлось.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #33

21. Сообщение от Аноним (21), 04-Апр-24, 13:11	+/–
Сколько лет использую сначала чистый lxc, потом lxd для управления и никогда не знал, что есть официальная морда Блин, пойду смотреть, вдруг и правда удобно Спасибо, добрый аноним
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #24

22. Сообщение от Аноним (21), 04-Апр-24, 13:13	+1 +/–
Ты придумал ансибл На пайтоне, с ямлом Все как ты просишь
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #25, #55

24. Сообщение от microcoder (ok), 04-Апр-24, 13:28	+2 +/–
> Сколько лет использую сначала чистый lxc, потом lxd для управления и никогда > не знал, что есть официальная морда Эта морда появилась совсем недавно
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21

25. Сообщение от microcoder (ok), 04-Апр-24, 13:33	+/–
> Ты придумал ансибл Там вроде как нет поддержки LXD/Incus :) А так тоже вариант был бы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #30

26. Сообщение от Аноним (26), 04-Апр-24, 13:40	+/–
А там не нужно ни одно, ни другое. На тебе картинки, если так сильно хочется: https://www.itzgeek.com/how-tos/linux/ubuntu-how-tos/manage-...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #32

27. Сообщение от Аноним (26), 04-Апр-24, 13:43	+2 +/–
Установка только снапом? Спасибо, ешьте сами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #29

29. Сообщение от Аноним (32), 04-Апр-24, 14:05	+4 +/–
Если что, в Incus всё завезли без снапа, даже этот GUI: https://github.com/zabbly/incus?tab=readme-ov-file#setting-u...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27

30. Сообщение от Аноним (32), 04-Апр-24, 14:09	+1 +/–
> Там вроде как нет поддержки LXD/Incus :) https://docs.ansible.com/ansible/2.9/modules/lxd_container_m...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #31

31. Сообщение от microcoder (ok), 04-Апр-24, 14:19	+/–
>> Там вроде как нет поддержки LXD/Incus :) > https://docs.ansible.com/ansible/2.9/modules/lxd_container_m... Хмм.. Спасибо! Поизучаю
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30

32. Сообщение от Аноним (32), 04-Апр-24, 14:37	+/–
> Last updated Jul 18, 2016 > Ubuntu 16.04
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

33. Сообщение от Аноним (33), 04-Апр-24, 14:55	–1 +/–
И не найдешь! Таким ивращением никто в здравом уме не будет страдать. Если нужна изоляция, то возьми flatpak версию  https://flathub.org/apps/org.mozilla.firefox
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #52

34. Сообщение от andreyche (?), 04-Апр-24, 14:57	+1 +/–
А в чем разница между Incus и lxc ?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #36, #40

36. Сообщение от Аноним (32), 04-Апр-24, 16:30	+/–
Прям в новости написано: > LXC относится к низкоуровневым инструментариям, работающим на уровне отдельных контейнеров. Для централизованного управления контейнерами, развёрнутыми в кластере из нескольких серверов, на базе LXC развиваются системы Incus и LXD. LXC – то что работает "внутри", непосредственно рулит контейнерами на низком уровне. LXD и Incus – работают поверх LXC, на основе него. С их помощью можно сделать всё то же самое, что и напрямую с LXC, но гораздо удобнее и организованно. Это, весьма грубо говоря, примерно как libcontainer и Docker (сравнение не очень правильное, но наверное поможет чуть лучше понять, как относятся LXC и LXD/Incus).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #38, #56

38. Сообщение от microcoder (ok), 04-Апр-24, 17:11	–1 +/–
Всё не так :)) Путаница эта давно идёт и никак не заканчивается, поэтому команда 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, второй поддерживаетеся сообществом и пока существенной разницы между ними нет. Есть ньюансы, но они не большие.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #39, #41, #49

39. Сообщение от Аноним (32), 04-Апр-24, 17:51	+/–
> 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).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38 Ответы: #42, #43

40. Сообщение от Аноним (40), 04-Апр-24, 17:54	+/–
Здесь о том, кто создал, как и почему https://www.opennet.me/opennews/art.shtml?num=59556
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34

41. Сообщение от Аноним (32), 04-Апр-24, 17:55	+1 +/–
> отвязались от liblxc Ну или они действительно отвязались, но документацию не обновили… Но пока не увидел иного, буду придерживаться точки зрения из документации.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38

42. Сообщение от microcoder (ok), 04-Апр-24, 18:29	+/–
>> 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.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #44, #46

43. Сообщение от microcoder (ok), 04-Апр-24, 18:38	+/–
> Ну и финальный аккорд касательно "отвязались от liblxc", тут вы прямо таки > не правы: https://linuxcontainers.org/incus/docs/main/explanation/inst.../ >> Containers are implemented through the use of liblxc (LXC). Перевод дословный: Контейнеры были реализованы через использование liblxc. Что это значит? Какие контейнеры? Чьи? Мои? Или в репозитории образов? Что здесь имеют ввиду под контейнерами - я не знаю. Возможно старая документация которую некому поддержать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #45, #47

44. Сообщение от Аноним (32), 04-Апр-24, 18:46	+1 +/–
Прямо по вашей же ссылке "пойдём на сайт убунты и посмотрим на эту страницу вниз" пишут: > 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)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #48

45. Сообщение от Аноним (32), 04-Апр-24, 18:47	+/–
Там достаточно ясно написано. В LXD/Incus мы можем создавать instanc'ы, а они могут быть двух типов: либо контейнер, либо виртуальная машина. Первый вариант реализован поверх LXC. Второй вариант – поверх QEMU.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43

46. Сообщение от Аноним (32), 04-Апр-24, 18:57	+/–
Называется «отвязались от liblxc»: https://github.com/lxc/incus/blob/main/internal/server/insta...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42

47. Сообщение от Аноним (32), 04-Апр-24, 18:59	+/–
> Контейнеры были реализованы через использование 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.     ... }
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43 Ответы: #53

48. Сообщение от microcoder (ok), 04-Апр-24, 19:05	+/–
Да, надо признать я нашёл такой пакет у себя: >[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)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44 Ответы: #50

49. Сообщение от Аноним (32), 04-Апр-24, 19:05	+/–
> 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. Куда ни посмотреть, я не могу найти ни одного подтверждения вашей версии. Если у вас есть ссылки, где описано именно то что вы рассказываете, то поделитесь, пожалуйста. Тема действительно запутанная, и из-за названий, и со всеми этими форками…
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38

50. Сообщение от Аноним (32), 04-Апр-24, 19:07	+/–
> Поэтому всё же надо различать: Да, я именно об этом я изначально и говорил. > Он просто ничего не знает о контейнерах. Тоже всё правильно, потому что ими управляет LXD/Incus. У них и есть функционал для миграции из "чистого" LXC на LXD/Incus. Но внутри остаётся именно LXC-бэкенд.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48 Ответы: #54

51. Сообщение от Anonim (??), 04-Апр-24, 19:13	+/–
В proxmox есть вот такой настроенный контейнер: https://www.turnkeylinux.org/gitea
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

52. Сообщение от Аноним (20), 04-Апр-24, 19:19	+/–
В Генте flatpak не заходит. Проще LXC поднять.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33

53. Сообщение от microcoder (ok), 04-Апр-24, 19:24	+/–
Хорошо. Теперь я понял лучше. Значит получается следующее: 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 * Мда...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47 Ответы: #57

54. Сообщение от microcoder (ok), 04-Апр-24, 19:29	+/–
Так это о том, о чём я и писал изначально в посте https://www.opennet.me/openforum/vsluhforumID3/133307.html#38 Просто единственное, я не знал, что они ещё не отвязались от старого проекта. Но сути это не меняет. Сейчас есть 3 проекта и их надо "разделять". P.S. Спасибо за беседу. Теперь стало более яснее.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50

55. Сообщение от Хочу стать девопсом пусть меня научат (?), 04-Апр-24, 21:00	+/–
Ansible - это вчерашний день там, где есть более совершенные специализированные инструменты типа K8S. В случае с LXD/Incus - это декларативные портянки в стиле docker-compose: https://github.com/bravetools/bravetools https://mottainaici.github.io/lxd-compose-docs/docs/tutorial/ А из графических шляп ещё есть LXDWare: https://lxdware.com/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #58, #60

56. Сообщение от Хочу стать девопсом пусть меня научат (?), 04-Апр-24, 21:04	+/–
LXD/Incus - это кластерный оркестратор LXC контейнеров и libvirt виртуалок, - т.е. прямая замена для проксьмоськса. Но намного лучше, потому что можно запустить и на Devuan и на Alpine, где системднища и в помине нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36

57. Сообщение от Хочу стать девопсом пусть меня научат (?), 04-Апр-24, 21:07	+/–
Разве Incus - это не форк LXD? IMHO Incus от LXD концептуально ничем не отличается, только деталями реализации и лицензированием.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53 Ответы: #59

58. Сообщение от microcoder (ok), 04-Апр-24, 21:22	+/–
> Ansible - это вчерашний день там, где есть более совершенные специализированные инструменты > типа K8S. > В случае с LXD/Incus - это декларативные портянки в стиле docker-compose: > https://github.com/bravetools/bravetools О! Это уже интересно! Монстра Ansible не хочется познавать
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55

59. Сообщение от microcoder (ok), 04-Апр-24, 21:28	+/–
> Разве Incus - это не форк LXD? Форк LXD, так у меня и написано в предыдущем посте. Смотрите внимательнее: > 3) Incus - Форк LXD
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57

60. Сообщение от Аноним (60), 04-Апр-24, 22:00	+1 +/–
Чтобы начать с Ansible достаточно только "apt install openssh-server python" и задать пароли пользователей (или SSH ключи). Минут 5-15, и - всё, можно писать код и запускать! Где не хватает Yaml, можно модуль на Питоне. Чтобы сделать K8s... нужен кластер разновсякого софта и сборочная платформа образов, плюс репозитарий артефактов. Примерно по сложности как замутить Linux From Scratch и поддерживать. И тооолько потооом можно начать писать аналог кода управления. А если не хватает Yaml, то уууу... сколько ещё вджобывать и вджобывать придётся. Сравнили тут воробья с стаей орлов...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55 Ответы: #64, #72

61. Сообщение от Минона (ok), 04-Апр-24, 22:51	+/–
Открывается нормально. v6.0.0 Latest Compare @stgraber stgraber released this 04 Apr 03:34 · 5 commits to main since this release   v6.0.0     714bcc5
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #62

62. Сообщение от microcoder (ok), 04-Апр-24, 23:16	+/–
> Открывается нормально. Сейчас уже открывается. Раньше не открывалось
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #61

63. Сообщение от Анонимус3000 (?), 04-Апр-24, 23:58	+/–
> Для взаимодействия с systemd через D-Bus задействована отдельная библиотека libdbus-1 вместо libsystemd Вот что бекдор в xz животворящий делает!
Ответить | Правка | Наверх | Cообщить модератору

64. Сообщение от DevOops (?), 05-Апр-24, 11:30	+/–
Так ли сложно поставить кластер K0S, для начала хотя бы одноузловой? Проблема с Ansible лишь в том, что он недостаточно декларативен, и при сколько-нибудь заметной сложности проекта (тысячи строк кода инфры для десятков и сотен взаимосвязанных узлов для обеспечения достаточной интегрированности разных частей этого проекта придётся писать свой собственный K8S уже на Ansible. Не проще ли (на много порядков) воспользоваться готовым K8S?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60 Ответы: #65, #68

65. Сообщение от Аноним (65), 05-Апр-24, 14:53	+/–
Ты не поверишь, но на многих проектах k8s просто избыточен и достаточно трех виртуалок и руления при помощи ансибла Слушай, ну вот есть проект у проекта есть виртуалка продакшена, виртуалка дева(она же резерв для продакшена, в смысле что на ней есть все что бы им выступить, но все погашено от прода, это резерв) и виртуалка с тг-ботом(да, отдельная целая виртуалка, так надо) Есть Gitea+CI/CD, откуда осуществляется выливка, есть мониторинги и прочее Но зачем нам тут кубер? Куда его тут привинчивать и зачем? У нас цель, что бы все работало и в случае смерти(болезни мешающей работать, посадки в концлагерь и т.д.) того кто поддерживает(называй хоть админом, хоть дево-псом, хоть SRE и сбоку бантик) это смог быстро подхватить другой человек, не вникая в приколы кубера и что там куда завернуто, да на какую дупу провернуто
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64

68. Сообщение от User (??), 05-Апр-24, 15:15	+/–
Эммм... а ничего, что вы оркестратор с системой управления конфигурациями сравниваете?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64 Ответы: #71

71. Сообщение от Система разности потенциалов (?), 05-Апр-24, 18:43	–1 +/–
А ничего, что Ansible SCM настолько универсален, что на нём некоторые велосипедисты умудряются оркестировать? Хорошо это или нет? Ответ дан выше, тем у кого полная автоматизация HA - им нужен K8S с автоскейлингом и многими другими современными фишками. А у недоразвитых колхозников есть резервный сервер в чулане, который они поднимают ансиблом, если конечно к моменту поднятия не поломается что-то во внешних зависимостях. Но ведь остаются даже и такие траглодиты, которые вообще ставят с помощью пакетных менеджеров типа apt, dnf и т.п., причём тогда, когда у них умер сервер ...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68

72. Сообщение от Система разности потенциалов (?), 05-Апр-24, 18:49	+1 +/–
> Минут 5-15, и - всё, можно писать код и запускать! Где не хватает Yaml, можно модуль на Питоне. "Минут 5-15, и - всё," (c) Можно писать заявление на увольнение, потому что в apt репозитории оказались свежие поломанные пакеты, например, с кривыми зависимостями, или пропал линк до репозитория. И твои 5-15 минут превратились в 5-15 часов, а то и вовсе в 5-15 дней ... Или у тебя локальная aptly копия? Ну ладно, продолжай пердолинг, но таки нормальный админ освоил бы хотя бы Docker с заранее собранными и протестированным своими кастом контеёнерами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60

75. Сообщение от ilya (??), 07-Ноя-24, 21:58	+/–
аж до 0.12 версии додвинул....
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема