Компания Canonical опубликовала релиз менеджера контейнеров LXD 5.0 и виртуальной ФС LXCFS 5.0. Код LXD написан на языке Go и распространяется под лицензией Apache 2.0. Ветка 5.0 отнесена к выпускам с длительной поддержкой - обновления будут формироваться до июня 2027 года...Подробнее: https://www.opennet.me/opennews/art.shtml?num=57006
Чем lxd лучше docker?
всем
Всем
Это разные вещи.
С позиции ядра - одинаковые. Это как резьбовое соединение - хочешь ключом крути, хочешь гайковертом, хочешь плоскогубцами.
То есть ты хочешь доказать что ключ, гайковерт и плоскогубцы — это одно и то же или зачем ты это написал?
> То есть ты хочешь доказать что ключ, гайковерт и плоскогубцы — это
> одно и то же или зачем ты это написал?Если задача закрутить гайку - таки да, все три варианта ведут к одному результату. С достаточно маргинальными нюансами. Но тут мало ли, вдруг вы 10 000 гаек в день крутить хотели?! Тогда вам вообще конвейер и промышленный робот уместнее.
Я тебя не понял.
>То есть ты хочешь доказать что ключ, гайковерт и плоскогубцы — это одно и то жеНо иногда их заменяет универсальный инструмент - зубило и молоток.
> Это разные вещи.На самом деле, достаточно близкие. Скорее разная культура.
Сложившаяся вокруг докера культура больше заточена на эффективность - минимальные накладные расходы, максимальную простоту и быстроту развертывания. Поэтому там и дедупликация слоев через оверлейные ФС, и отказ от выполнения в контейнере целой системы с кучей лишних сервисов (что, скорее, best practice, чем железное правило), и развитый инструментарий сборки и распространения образов, и развертывание контейнера одной командой.
LXC скорее несет наследие культуры OpenVZ, когда контейнеры были "легкой альтернативой виртуалкам". Это, в свою очередь, порождено эпохой, когда не было Intel-VT и AMD-V, виртуализация несла довольно серьезный оверхед по CPU. (В современных реалиях более-менее ощутимую выгоду контейнеров перед виртуалками можно почувствовать разве что на дисковом IO и, в некоторых ситуациях, на скорости сети.) Отсюда и подход к контейнерам, как к виртуалкам - запускать там полноценную систему и полноценно админить ее. Рационально рассуждая, есть случаи, когда это оправдано - например, оставшиеся с 90-х годов прошлого века shared hosting-и, когда нужно много условно-независимых систем с LAMP+FTP+SSH, и при этом нужно предельно скроить по дисковому пространству. Платой за это будет высокая уязвимость к компрометации системы в целом - абсолютное большинство рутовых дыр ядра в последние годы не просто не сдерживаются "контейнерными" технологиями, а наоборот, активно их используют.
Докер изолирует процессы а lxd целые оси
Разве он не с контейнерами работает? Или я что-то путаю?
> Или я что-то путаю?Или ты что-то путаешь.
Запуская "целую ось" как изолированный процесс...
Это другое (с) :))
как группу помеченных процессов
> Докер изолирует процессы а lxd целые осиДокером тоже можно изолировать целую ось.
Просто по итогам большого опыта эксплуатации, даже индеец Зоркий Глаз заметил, что запихивать в контейнер целую ось - оверхед, как минимум, для прода.
Докер ? Да фиолетово докер это или подман лишь бы кибер это понимал.
У них свой, нескучный кубик.
Чем грузины!
> Чем lxd лучше docker?В docker для обновления системы надо уничтожать контейнеры и образ.
В lxc apt update & apt upgrade этого достаточно.
Короче, docker это для фиксированного не изменяемого окружения.
Lxc для контейнеров с длительной поддержкой.
Два разных подхода для разных типов задач. Например для баз данных в продаже docker это плохая идея, особенно в kubernetis. Lxc для баз данных вполне себе адекватный сервис. Докер контейнеры не чинят
не обновляют, их поднимаютзаново. В lxc контейнеры чинят обычным порядком.
> Два разных подхода для разных типов задач. Например для баз данных в продаже docker это плохая идея, особенно в kubernetis. Lxc для баз данных вполне себе адекватный сервис.Подобная реплика с головой выдает, что с контейнерами вы не знакомы.
Или вы.
То что в разрабы используют сервера дБ в докер не говорит что это полезно для прода. Для разработки это полезно, легко и приятно.
Но в проде ДБ лучше оставить тем кто умеет в ДБ много, сильно и долго и это точно не докер.
БД в LXC тоже плохая идея.
Обоснуйте свою ТЗ, пожалуйста.
Для начала объясните, чем БД в LXC принципиально отличается от БД в докере.
> Для начала объясните, чем БД в LXC принципиально отличается от БД в докере.контейнер для ядра в обоих случаях будет одинаковый, то есть с позиции ядра ничем. Но есть нюансы в цене вопроса.
Вы разработчик, вы работаете с тестовой БД. Для этой БД данные не представляют ценности, они тестовые. Ну рухнул контейнер, да и йух с ним, рестартанул и работаешь дальше. Нет большой разницы как рестартанули контейнер в ручную или это сделал kubernetis.
А вот когда БД на production это совсем другое дело, там данные большая ценность. Там БД должна работать непрерывно, длительное время. Нельзя просто перезапустить сервер с бд. А когда сервер работает длительное время его надо время от времени обновлять. И когда у Вас это все дело в докере вам нужно "всего лишь" грохнуть сервер с БД в смысле уничтожить полностью контейнер и запустить новый. Для службы эксплуатации этот "всего лишь" это трындец на всю голову. В общем это очень дорогая и рискованная операция. Когда у Вас контейнер запущен через LXD вам не надо уничтожать контейнер, обновление большинства файлов вообще не затрагивает работу БД, все можно сделать без остановки сервиса.
Так что БД в докере, что LXC для ядра разницы нет, а для сисадмина разница огромная, юридически значимая, при сильном желании могут и статью из УК подтянуть, был бы человек хороший. Вот такая вот диспозиция.
То есть вы считаете, что
1. В докеровском контейнере нельзя произвести обновление системы?
2. Что какой-нибудь сервера постгреса или мускуля можно обновить, не перезапуская его?
> В докеровском контейнере нельзя произвести обновление системы?Обе системы и докер и lxc делают одинаковые контейнеры и обновлять их можно.
Но суть подхода докера в том чтобы не обновлять систему, а держать её такой как задумал разработчик, не изменной. Цель подхода докера максимально убрать человека из процесса эксплуатации системы. И контейнеры из образа создают пачками, их стоимость ничтожна, контейнер это процесс с обвязкой, главное не забыть их перезапускать если упадёт, а перезапускать можно поручить системе без участия человека. Kubernetis и есть такая перезапускалка с необходимыми причиндалами. Докер это " Живи ярко, умри молодым "
Lxd это противоположный подход. Контейнер это лёгкая виртуалка. Непрерывность работы этой виртуалки поддерживают, чем дольше, тем лучше, и при необходимости таскают по кластеру между хостами. Lxd это " И жили они долго, счастливо и умерли в один день". Но для этого нужен сисадмин с зарплатой налогами и отпуском.
> Что какой-нибудь сервера постгреса или мускуля можно обновить, не перезапуская его?
Можно и нужно.
Сервер это сервисы с громоздкой обвязкой. И в обвязке тоже есть обновление и довольно много. Например поменялась либа в питоне. Или fgrep улучшили. Это никак не затрагивает работу БД. Такие изменения прилетают примерно раз в месяц. Можно спокойно обновить сервер не останавливая работу базы. А можно не останавливая работу базы перетащить её на другой хост кластера, основательно обновлением перетряхнуть предыдущий хост и вернуть базу обратно без остановки. Этим собственно и занимается lxd.
> Сервер это сервисы с громоздкой обвязкой. И в обвязке тоже есть обновление и довольно много. Например поменялась либа в питоне. Или fgrep улучшили. Это никак не затрагивает работу БД. Такие изменения прилетают примерно раз в месяц. Можно спокойно обновить сервер не останавливая работу базы.Возникает вопрос - а зачем в системе, где живет БД, присутствуют какие-то программы и библиотеки, не связанные с работой БД? И зачем их обновлять, если это в 99% случаев никак не повлияет на работу в БД?
И главное - как вы будете обновлять
1. Сам сервер БД
2. Библиотеки, которые он использует?
3. Ядро (теоретически, можно решить миграцией, но на практике, обновления безопасности время от времени приводят к изменению ABI, так что миграция в пролете)?> А можно не останавливая работу базы перетащить её на другой хост кластера
Ну, удачи смигрировать терабайт-другой данных "туда-сюда". (Мы же не вордпресс условного Васи говорим, а про прод какой-никакой?)
> Lxd это противоположный подход. Контейнер это лёгкая виртуалка. Непрерывность работы этой виртуалки поддерживают, чем дольше, тем лучше, и при необходимости таскают по кластеру между хостами. Lxd это " И жили они долго, счастливо и умерли в один день". Но для этого нужен сисадмин с зарплатой налогами и отпуском.
В итоге мы пришли к тому, что вся эта непрерывность - просто накопление проблем с безопасностью в основном сервере, для которого и был задуман контейнер, но зато обновление всего, что в контейнере нафиг не нужно.
И нет, для этого не нужен полноценный сисадмин, хватит и студента за еду. Тысячу раз сделать apt update && apt upgrade (причем без практической пользы) - не сильно интеллектуальный труд.
>Возникает вопрос - а зачем в системе, где живет БД, присутствуют какие-то программы и библиотеки, не связанные с работой БД?Эти библиотеки связаны с работой дистрибутива системы в целом. Есть такие люди - мантейнеры, они владеют темой, задайте вопрос им.
> И зачем их обновлять, если это в 99% случаев никак не повлияет на работу в БД?
Единичные обновления не повлияют, но потом будет большой геморрой искать проблему обновления в большущей пачке изменений. Так что тут гораздо разумнее сделать несколько маленьких безопасных шагов, чем потом широко шагнуть, порвать штаны и плюхнуться в лужу.
> Ну, удачи смигрировать терабайт-другой данных "туда-сюда".
"Терабайт другой" нагруженной базы держат в кластере. Миграции узла кластера это нормально и штатно. Если база не нагружена и её можно остановить, то с миграцией вообще нет проблем.
> Тысячу раз сделать apt update && apt upgrade (причем без практической пользы) - не сильно интеллектуальный труд.
Тысячу раз сделать apt update && apt upgrade не сложно, это поручают скриптам, тут даже студент не нужен. Администраторам платят за то что они обеспечивают работоспособность системы после этой тысячи раз. И эта задача требует и интеллекта и инженерной подготовки и других качеств.
> Но в проде ДБ лучше оставить тем кто умеет в ДБ много, сильно и долго и это точно не докер.Нет, не лучше. «Те» — обычные люди. Допускают ошибки, болеют, невнимательны из-за проблем в личной жизни. А главное, после подстройки под конкретные параметры нагрузки, человеку там делать нечего. BCP давно задокументированы и автоматизированы. Бэкапы, репликация, поднятие и удаление реплик в зависимости от нагрузки — для чего именно там нужен человек? Всё это формализованный автоматизированный процесс. Те, кто «умеет в ДБ» нужны для контроля — реагировать на алерты, на которые невозможно среагировать автоматически, увидеть и упредить необходимость следующего цикла подстройки под изменившуюся нагрузку, иными словами, для принятия высокоуровневых решений. И докер — а скорее, k8s — тут нужны только для малоинтересных решённых проблем: на каком именно сервере запустить, какие диски куда прокинуть, сеть, полиси, доступ. Ну не вручную же это всё делать, ей-богу. Не 2001 на дворе.
Кто-нибудь пробовал прикрутить lxcfs к systemd-nspawn?
я пробовал, врачи потом неделю откачивали
> Кто-нибудь пробовал прикрутить lxcfs к systemd-nspawn?Точно так же, как и с докером - монтируется /var/lib/lxcfs/proc/xxx в /proc/xxx (где xxx=cpuinfo,meminfo,stats,...).
Отличный софт, заработал мне много денег с минимальным оверхедом, а с новым мажорным релизом, чую, заработает ещё на поддержке старых клиентов. От души спасибо разработчикам LXD/LXC за хлеб, масло и икру.
> заработал мне много денегСам пользуюсь, без регистраций и смс.
Ты иронизируешь, а я не шучу между тем. Морда для LXD пока что мой самый эффективный бизнес в долларах за час работы. Кнопка «get vps» + бэкэнд ~пятьсот строк на cljs, хостится на убунтах. Написал за неделю, ещё неделю отлавливал мелкие баги и рихтовал кнопку. За четыре года продал это добро шесть раз, только логотипы менял в шапке. Поддержки почти никакой не требует, там ломаться нечему. Документация примерно за год эксплуатации сама написалась, про остальное клиенты пишут пару раз в год, в основном просят подкрутить ram/cpu/disk в темплейтах, но с такими объёмами это не работа. Настроить unattended upgrade на убунте любой эникей может, а остальное скриптом мониторится. Раз в квартал трачу рабочий день на обновления версий библиотек. Апдейты раздаю прямо c гитхаба. Так что из затрат только моё время и электричество для компа, а клиенты платят за «саппорт» каждый месяц. Жить с этих денег нельзя, конечно, но большую часть ипотеки покрывает и времени почти не тянет, всяко легче.
Зачем все это если есть Hyper-V?
кто-то использует UI для lxd? какой