The OpenNET Project / Index page

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

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


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

Оглавление

Выпуск инструментариев управления контейнерами LXC 6.0, Incus 6.0 и LXD 5.21.1, opennews (??), 04-Апр-24, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


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

4. "Выпуск инструментариев управления контейнерами LXC 6.0, Incu..."  +5 +/–
Сообщение от Аноним (1), 04-Апр-24, 10:45 
Это вам скорее в реестре Docker'a надо искать.

Incus и LXD скорее про "контейнеры, которые чувствуются как вируталки" (упрощённо и грубо говоря), это больше system-контейнеры, а не application-контейнеры. Вообще тут можно подискутировать, ибо грань весьма условная.

Но в случае с Incus тут скорее сценарии вроде: создать контейнер и
1) ручками сделать всё так же, как если бы это была виртуалка.
или
2) использовать cloud-init для автоматизации.

Можно ещё экспортировать контейнер с готовым и развёрнутым приложением, как вы хотите, но… В таком случае я бы всё же порекомендовал посмотреть на Docker.

Ответить | Правка | Наверх | Cообщить модератору

10. "Выпуск инструментариев управления контейнерами LXC 6.0, Incu..."  +2 +/–
Сообщение от microcoder (ok), 04-Апр-24, 10:55 
> использовать cloud-init для автоматизации.

Поковырялся я с этим Г.. ))) Нет уж, спасибо, не надо. Очень много гемора на простых вещах. Не может выполнить последовательность сценариев. Точнее может, но через костыли, навороты в виде мерджей (какой кошмар, в 21 веке то!) Так что лучше по старинке, Bash наше всё.

Ответить | Правка | Наверх | Cообщить модератору

12. "Выпуск инструментариев управления контейнерами LXC 6.0, Incu..."  +2 +/–
Сообщение от Аноним (1), 04-Апр-24, 11:01 
Ну, моё дело только сказать о технической возможности. А что будут использовать джентельмены – каждый сам решает.

Для каких-то простых настроек и примитивных автоматизаций может быть вполне ок. Можно в профиль для новых контейнеров записать конфиг cloud-init с чем-нибудь типовым, типа как SSH-ключ прописать. Можно сильно не придираться, это просто как пример.

У меня ещё был специфический сценарий с запуском эфемерных контейнеров, когда надо было запустить из готового образа изолированное окружение с конкретным пользовательским скриптом. Вот там cloud-init вполне подошёл для автоматизации всего этого безумства.

Ответить | Правка | Наверх | Cообщить модератору

13. "Выпуск инструментариев управления контейнерами LXC 6.0, Incu..."  +1 +/–
Сообщение от microcoder (ok), 04-Апр-24, 11:08 
Да, для простых профилей сгодиться. Проблема в том, что параметр `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ообщить модератору

14. "Выпуск инструментариев управления контейнерами LXC 6.0, Incu..."  +1 +/–
Сообщение от Аноним (1), 04-Апр-24, 11:12 
> Проблема в том, что параметр 'cloud-init.user-data' может быть только один для всех применяемых профилей настроек к контейнеру, так как это концепция такая каскадная перекрывать параметры предыдущих параметров.

Поддерживаю. Это серьёзный недостаток, сильно уменьшающий полезность cloud-init. Сам искал способы определить несколько конфигов cloud-init в разных профилях и наткнулся на то же самое… Хотя казалось бы, такая возможность звучала бы логично, она прямо таки напрашивается.

Ответить | Правка | Наверх | Cообщить модератору

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

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

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

18. "Выпуск инструментариев управления контейнерами LXC 6.0, Incu..."  +/–
Сообщение от microcoder (ok), 04-Апр-24, 11:47 
Спасли бы сценарии в профилях. Профилями конфигураций можно было бы делиться. Так, можно было бы хотя бы посмотреть визуально на код инициализации и не обнаружить там зло-кода. Но... Сейчас это проблематично, профили ограничены.

У меня своя есть разработка на Bash, с "ядром" скрипта который принимает bash сценарии как plug-in's и выполняет их. В ядре реализованы вспомогательные базовые функции. А плагины это ничто иное как упрощённые bash-сценарий установки контейнера и его инициализация. В этом случае нет никаких ограничений, для домашнего использования вполне годиться. Плагинами можно делиться. Для коммерции тут думать надо, так как скорее всего небезопасно будет выполнять такие плагины на чистом Bash.

Ответить | Правка | Наверх | Cообщить модератору

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

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

25. "Выпуск инструментариев управления контейнерами LXC 6.0, Incu..."  +/–
Сообщение от microcoder (ok), 04-Апр-24, 13:33 
> Ты придумал ансибл

Там вроде как нет поддержки LXD/Incus :) А так тоже вариант был бы.

Ответить | Правка | Наверх | Cообщить модератору

30. "Выпуск инструментариев управления контейнерами LXC 6.0, Incu..."  +1 +/–
Сообщение от Аноним (32), 04-Апр-24, 14:09 
> Там вроде как нет поддержки LXD/Incus :)

https://docs.ansible.com/ansible/2.9/modules/lxd_container_m...

Ответить | Правка | Наверх | Cообщить модератору

31. "Выпуск инструментариев управления контейнерами LXC 6.0, Incu..."  +/–
Сообщение от microcoder (ok), 04-Апр-24, 14:19 
>> Там вроде как нет поддержки LXD/Incus :)
> https://docs.ansible.com/ansible/2.9/modules/lxd_container_m...

Хмм.. Спасибо! Поизучаю

Ответить | Правка | Наверх | Cообщить модератору

55. "Выпуск инструментариев управления контейнерами LXC 6.0, Incu..."  +/–
Сообщение от Хочу стать девопсом пусть меня научат (?), 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/

Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

58. "Выпуск инструментариев управления контейнерами LXC 6.0, Incu..."  +/–
Сообщение от microcoder (ok), 04-Апр-24, 21:22 
> Ansible - это вчерашний день там, где есть более совершенные специализированные инструменты
> типа K8S.
> В случае с LXD/Incus - это декларативные портянки в стиле docker-compose:
> https://github.com/bravetools/bravetools

О! Это уже интересно! Монстра Ansible не хочется познавать

Ответить | Правка | Наверх | Cообщить модератору

60. "Выпуск инструментариев управления контейнерами LXC 6.0, Incu..."  +1 +/–
Сообщение от Аноним (60), 04-Апр-24, 22:00 
Чтобы начать с Ansible достаточно только "apt install openssh-server python" и задать пароли пользователей (или SSH ключи). Минут 5-15, и - всё, можно писать код и запускать! Где не хватает Yaml, можно модуль на Питоне.

Чтобы сделать K8s... нужен кластер разновсякого софта и сборочная платформа образов, плюс репозитарий артефактов. Примерно по сложности как замутить Linux From Scratch и поддерживать. И тооолько потооом можно начать писать аналог кода управления. А если не хватает Yaml, то уууу... сколько ещё вджобывать и вджобывать придётся.

Сравнили тут воробья с стаей орлов...

Ответить | Правка | К родителю #55 | Наверх | Cообщить модератору

64. "Выпуск инструментариев управления контейнерами LXC 6.0, Incu..."  +/–
Сообщение от DevOops (?), 05-Апр-24, 11:30 
Так ли сложно поставить кластер K0S, для начала хотя бы одноузловой?

Проблема с Ansible лишь в том, что он недостаточно декларативен, и при сколько-нибудь заметной сложности проекта (тысячи строк кода инфры для десятков и сотен взаимосвязанных узлов для обеспечения достаточной интегрированности разных частей этого проекта придётся писать свой собственный K8S уже на Ansible. Не проще ли (на много порядков) воспользоваться готовым K8S?

Ответить | Правка | Наверх | Cообщить модератору

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

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

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

72. "Выпуск инструментариев управления контейнерами LXC 6.0, Incu..."  +/–
Сообщение от Система разности потенциалов (?), 05-Апр-24, 18:49 
> Минут 5-15, и - всё, можно писать код и запускать! Где не хватает Yaml, можно модуль на Питоне.

"Минут 5-15, и - всё," (c)

Можно писать заявление на увольнение, потому что в apt репозитории оказались свежие поломанные пакеты, например, с кривыми зависимостями, или пропал линк до репозитория.
И твои 5-15 минут превратились в 5-15 часов, а то и вовсе в 5-15 дней ...


Или у тебя локальная aptly копия? Ну ладно, продолжай пердолинг, но таки нормальный админ освоил бы хотя бы Docker с заранее собранными и протестированным своими кастом контеёнерами.

Ответить | Правка | К родителю #60 | Наверх | Cообщить модератору

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

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

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




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

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