Компания Canonical опубликовала релиз инструментария для организации работы изолированных контейнеров LXC 4.0, менеджера контейнеров LXD 4.0 и виртуальной ФС LXCFS 4.0 для симуляции в контейнерах /proc, /sys и виртуализированного представления cgroupfs для дистрибутивов без поддержи пространств имён для cgroup. Ветка 4.0 отнесена к выпускам с длительной поддержкой, обновления для которых формируются в течение 5 лет...Подробнее: https://www.opennet.me/opennews/art.shtml?num=52679
Чем LXC лучше docker?
проще
для простого и понятного примера, попробуй запусти в одном Docker-контейнере Nginx, PHP-FPM, MySQL и Postfix. да, в одном контейнере а не в 4 разных, что будут по TCP/IP друг с другом общаться и все впятером гадить в syslog что крутится в 5-м. в LXC это делается как в любой стандартной OS, ибо служит для изоляции (контейнер) OS, в то время как Docker для изоляции приложения
что ты несешь, как настроишь, туда и будут "гадить", все, что может lxc, может и docker, но не наоборот
> для простого и понятного примера, попробуй запусти в одном Docker-контейнере Nginx, PHP-FPM,
> MySQL и Postfix.к сожалению, примерно 2/3 хлама, поставляемого в виде докер-образов именно так и сделаны. Включая, как ни смешно, docker registry.
Ты еще забыл добавить в эту кучку мусора самодельную наколеночную замену init (да, да - что-то ведь должно весь этот мусор последовательно запускать) и cron (ибо ниасиляторы не могут настоящий, а периодические процессы таки им иногда нужны)А теперь попробуй корректно такой "контейнер" остановить по docker stop. "ой, база побилась" ? Ну, вот так у обезьянок - всё. Естественно, и от докерной автоматики, перезапускающей если упало, таким образом успешно избавляются, docker daemon умеет перезапускать только entrypoint, а не всю внутреннююю мусоруку.
Еще очень модно при старте что-нибудь скачать из интернета и покомпилять - потому что макака не смогла это запихнуть куда надо, в dockerfile.
Сколько макакам ни долбили что докер вовсе не предназначен быть эмулятором для запуска операционной системы целиком, это средство изоляции отдельной программы - даже нарочно наделав им грабель (любимый макакой systemd просто так внутри не запускается) - ничего не помогает. Включая макак, работавших в самом докере - еще раз см регистри.
Но, к сожалению, поляна, как обычно, загажена - ни про какое lxc макака и не слышала, и не умеет, и уметь не хочет.
При этом как раз все, что умеет делать докер, lxc тоже умеет. Включая и не ограничиваясь частичной изоляцией - без громождения прослоек overlay одной поверх другой.
мне то ты зачем про это пишешь, да ещё в таком количестве? я применение Docker знаю, и где надо и возможно - пользуюсь им без лишних уродливых костылей, именно для изоляции приложения (к примеру RabbitMQ кластер, что деплоится автоматом со всеми необходимыми настройками из Dockerfile). где надо больше чем может Docker без костылей - пользуюсь LXC. где надо ещё больше - KVM. и всё прекрасно работает, жалоб нет, костылей избегаю
Очень хорошо настраивал в одном контейнере Haproxy, Zotonic (т.е. Erlang VM), PostgreSQL и OpenSSH. Контейнер лепил сам из голого Alpine.
А что, у меня должны были возникнуть какие-то проблемы?
Кроме того что ты идиот (догадайся сам почему), проблем никаких.
> Кроме того что ты идиот (догадайся сам почему), проблем никаких.То есть, кроме оскорблений, сказать нечего. Чего-то такого я и ожидал.
а что тебе ещё сказать? тем-более ты сам говоришь что ожидал подобного. а вот скажи, ожидаешь не от понимания ли что всё-таки используешь Docker не по назначению?
> используешь Docker не по назначениюА я и математический анализ не по назначению использовать могу - согну проволоку в форме интеграла и достану ключи из унитаза.
Если контейнер с 512МБ ОЗУ стОит примерно на треть дороже, чем контейнер с 256МБ, а контейнер с 1ГБ ОЗУ стОит немного более чем наполовину дороже, чем контейнер с 256МБ, то как раз таки надо быть идиотом, чтобы платить за 4 контейнера вместо одного.
тяжело тебе, ещё и кризис с коронавирусом. соболезнования
> тяжело тебе, ещё и кризис с коронавирусом. соболезнованияЕсли у тебя есть возможность тратить деньги своего работодателя, не считая их, я за тебя рад, но учти одну простую вещь - долго такое счастье не длится.
Зачем вам вообще Docker, если вы во главу угла ставите дешевизну хостинга?Для массового автоматизированного развёртывания есть Ansible, Chef, Puppet - можно настроить много виртуалок со всем необходимым внутри каждой виртуалки.
Идея Docker в том, чтобы внутри него держать одно ПРИЛОЖЕНИЕ, а не всю нужную ему лабуду в придачу.
Вы используете инструмент не по назначению, просто потому что это модно, при этом пытаетесь сэкономить деньги. С головой что-то явно не так.
Не только дешевизну. Крупные хостеры (Амазон, Гугл, Диджитал Оушн) за каким-то хреном требуют телефон, а мне не хочется привязывать свой телефон к сервисам организации, равно как и заморачиваться с покупкой корпоративной симки. ИБМ вообще в РФ не работает, некоторые принимали оплату с карты только по пайпал, который с какого-то хрена подвесил мою учётку. Поверьте, мне пришлось перерыть достаточно большой объём выдачи гугла, прежде чем остановился на hyper.sh, царствие ему небесное.
Да, я много где читал, что в одном контейнере докера должно быть одно приложение, но нигде не было внятного и убедительного объяснения почему. Заодно всегда деликатно обходится вопрос о накладных расходах при обмене данными между контейнерами.
Ну, а после того, как hyper.sh сдулся (а также сдувались облачные сервисы вендоров систем видеонаблюдения, умного дома и т.д.), я решил вообще на подобные сервисы забить и всё своё держать при себе.
> Да, я много где читал, что в одном контейнере докера должно быть одно приложение, но нигде не было внятного и убедительного объяснения почему. Заодно всегда деликатно обходится вопрос о накладных расходах при обмене данными между контейнерами.Представь себе внутрикорпоративный продукт собственного производства. Бизнес заказывает функции, разработчики делают, админы деплоят и админят. Такие программы могут быть условно говоря двух типов: монолитные и микросервисные. Монолитное приложение - это одна большая программа выполняемая на одном большом хосте или ВМ. Все её модули и она сама находятся в оперативной памяти и выполняются на одном процессоре. Это очень быстро и удобно. Чтобы сделать такую софтину отказоустойчивой и сбалансировать её нагрузку тебе нужно создать вторую третью и т. д. сущность и поставить балансировщик. В зависимости от типа запросов к приложению наличия или отсутствия клиент-серверных привязок в рамках сессий или потоков датаграмм ты настроишь свои балансировщики на 2-ом, 4-ом или 7-ом уровне. Таким образом это приложение может быть горизонтально смасштабировано по количеству соединений, но что если сессии пользователей сложны и один пользователь может нагрузить узел так, что ресурсов не хватит? Это ахиллесова пята монолитных приложений, они имеют потолок и часто упираются в невозможность вертикального масштабирования узла. Например, если монолитная корпоративная соплекуха требует 24 ядра и 128 ГБ оперативной памяти на одном узле, то "подкинуть ресурсов" на гипервизоре будет трудно, если на одном физическом CPU у вас предел в 128. Докидывание пары гигабайт с соседнего сокета только замедлит приложение еще сильнее, а если показать виртуалке не 24 ядра, а например 2 сокета по 12 ядер, то производительность приложения будет завесеть от того приучили этот монолит к многопроцессорности или оно на это смотрит глазами ядра ОС... в общем это печально и это предел.
Логичным способом будет разделить функционал приложения на 2 части. Например из 146 функций мы возьмём 40 и положим на первый сервер приложений (например фронтенд) а оставшиеся 106 перевалим на бекенд и свяжем их через API, которое сами и напишем. Сделаем HA/LB и получим уже что-то более производительное без покупки баснословно дорогого железа или тончайших системных оптимизаций (бизнесу начхать на академические упражнения им работать надо). И вот так и будем жить пока 106 на бекенде не превратится в 206 и снова всё повторится. Далее разрубим тьолстый бекенд на 2, потом на 3 и потом....
И вот потом начнётся следующая проблема. Полный граф взаимодействия всех типов серверов приложений порождает сложность в сопровождении, мониторинге производительности, обновлении и изменении функционала. Каждый раз добавляя новые вершины в этот граф сложность системы вырастает нелинейно и те самые сетевые издержки начинают стремительно ухудшать производительность автоматизированной системы в целом.
Вот тут нам и подходит микросервисная архитектура. Каждый модуль каждого приложения мы положим в отдельный контейнер и сделаем так, что обмен информацией будет происходить не по цепочке запросов а в очередях брокера кластеризованной шины данных, как бы соединяющих все эти маленькие контейнеры с микросервисами (самодостаточными функциональными модулями решающие простую задачу и отдающиеся по API).
Красиво и элегантно микросервисная архитектура выглядит тогда, когда сверху над ней есть автоматизация CI/CD, чтобы не человек (админ) занимался установками, а это делали разработчики по своим расписаниям. Чтобы и тесты и мониторинг всё автоматически поднималось, создавалось и работало без помощи админа, который занимается железной инфраструктурой и общими вопросами.
Над вами тут смеются, потому что вы используете докер, как средство админства, в то время как это средство разработчиков, которые избавляются от вас как от админа при разработке своих задач =) по факту нет, конечно, им требуется еще и вся инфраструктура, чтобы оно работало, просто своими автоматизациями занимаются сами.
Если нужен хостинг, то докеры вам не нужны, вам нужны контейнеры или виртуалки. Запихивать в докер 1001 приложение и еще и настраивать какое-то взаимодействие между ними - это всё назло кондуктору, куплю билет - пойду пешком.
Если мы говорим о производительности, то в условиях однопроцессорного сервера потенциально бесконечной мощности (оно не существует в объективной реальности) монолитная архитектура всегда выигрывает по производительности, потому что нет никаких межсущностных API, прослоек в виде сети, всё работает напрямую вызывая функцию по имени из соседнего блока оперативной памяти. В реальности никаких бесконечных мощностей не будет и уперевшись в проблемы вертикального масштабирования, микросервисная архитектура будет выигрывать по соотношению производительность к стоимости владения. Кстати, обратите внимание, как процениваются облака и сравните с проценкой традиционного хостинга. А еще в реальности микросервисная архитектура может быть вредна (маленькое приложение разнесли на кучу еще более мелких в условиях плохой сети), не возможна (куча легаси монолитного вендорспецифичного софта), дорога (когда покупаются все контейнеры в облаках) и вообще это всё вопросы не вашего ума дела, это за вас решат разработчики корпоративного софта.
То есть, для "правильного" использования Докера приложение должно было быть написано под Докер. В моём случае этого нет, разнесение Haproxy, EVM с Zotonic'ом и PgSQL по разным контейнерам ничего из описанных плюшек не дало бы - собственно, об этом я уже писал.
Мой сервис - это не Гугл, и не Фейсбук, и не Нетфликс, и не Нью-Йоркская фондовая биржа, и не Свифт, и не что-то подобное. Городить "правильный" пучок контейнеров - это была бы просто стрельба из пушки по воробьям.
Контейнеры типа докера тут не нужно использовать вообще. Контейнеры ОС типа LXC у контейнерного хостера тут могут быть использованы и то только если хочется, можно ВМ.Просто есть матчасть, которую надо знать. В линуксах нету setup.exe, а людям этого очень хочется. Авторы, чтобы пользователь быстро установил и поднять демку у себя на локалхосте, предлагают как попало собраный самими авторами контейнер. Даже в документации пишут, что это "getting started", зачастую не указывая, что в проде так использовать докеры нельзя, ведь это само собой разумеющаяся истина. Но есть русские малограмотные админы, которые по английски-то даже не понимают, которые про докер что-то слышали и знают, что это контейнер и вот и получается то что получается. На венеде это "скачать бесплатно без смс на высокой скорости вишмастер_сетап.ехе". На линуксах это "скачать бесплатно без смс на высокой скорости вишмастер_докер.имг"
Правильная установка Zotonic бывает в двух вариантах:
1. Без HA. Вогнать всё на одну разнесчастную виртуалку ну или максимум базу отцепить, чтобы за ресурсы не дрались.
2. С HA. Тогда нужна Haproxy, keepalived, zotonic/evm, postgresql в режиме мастер-слейв репликации.
Если стоимость простоя сервиса для бизнеса ниже стоимости оплаты за кучу сущностей HA, значит бизнесу это не надо.
... просто докер тут лишний от слова совсем.
извини, но DO - самая бомжацкая помойка из всех возможных. буквально хостинг от Сифона и Бороды. про фирму твою (где нет CIO, CTO и т.п.) тоже всё понял - проект твой и его воплощение тоже подстать. я не с целью обидеть тебя лично. вопросов больше не имею
Идиота в зеркале увидишь.
и правда удобно? и не беда что файлы той-же базы PostgreSQL приходится держать где-то вне контейнера чтоб не исчезли при его рестарте? мигрировать с сервера на сервер такой контейнер с внешними файлами удобно? выкатывать новый для HA? а новые ключи для доступа по SSH как добавляешь? неужели руками? уже и не спрашиваю про новых пользователей кому надо дать доступ в твой контейнер. чего только не выдумают люди чтоб оправдать свою лень и нежелание узнавать что-то простое и полезное (в данном случае LXC)
> файлы той-же базы PostgreSQL приходится держать где-то вне контейнераВольюм примонтирован. Работает. Не должен?
> мигрировать с сервера на серверВот хз, мигрировал ли мой контейнер с одного физического сервера на другой - я его залил на хостинг, поднял и оставил работать.
> выкатывать новый для HAКакой нахрен HA? Ты не знаешь мой юзкейс, а берёшься судить. Zotonic не умеет работать с пулом серверов БД, он коннектится одному серверу при старте и дальше работает с ним. Если поднять отдельный контейнер с haproxy, который будет раскидывать трафик на несколько инстансов Zotonic'а, каждому из них нужен свой Pg, а это означает мультимастер репликацию, которая сейчас в Pg делается только костылями разной степени уродливости. Для настоящей HA нужно серьёзно допилить Zotonic, чтобы он писал только в мастер, а для чтения выбирал слейва из пула, при этом имел бы возможность на ходу переключаться на нового мастера. Можно, конечно, иметь один Pg на несколько Zotonic'ов, но это нихрена никакой не HA, к тому же производительность всей системы упрётся в производительность Pg.
> новые ключи для доступа по SSHНеактуально.
неправильный выбор технологий снизу и доверху впечатляет, полное отсутствие HA в принципе тоже. Docker там где нужен бы LXC, PostgreSQL (религия?) без всяких оснований вместо MySQL (Percona). HAProxy то для чего? SSH понятно тебе нужен, чтоб логи смотреть и процессами управлять, т.к. хостинг твой для бомжей (4 контейнера уже дорого) и видно даже лог твоего контейнера не отображает никаким образом (за дополнительную плату). надеюсь это dev или staging, за подобный production мучительно и долго убивал бы из рогатки клюквой. попадались мне такие проекты по наследству от всеразличных самоделкиных - смеялся и плакал, восхищаясь бесконечной глупости. даже поставил на столе портретик Эйнштейна
Дай-ка угадаю, ты когда-то прочёл одну-единственную хаутушку и с тех пор она завладела твоими мыслями и не отпускает ни на мгновенье, и всё, что тебе попадается, ты переделываешь по тому самому, одному-единственному когда-то прочитанному рецепту.
А что касается подхода "заплати лишнее за ненужное, а то я буду на тебя смотреть как на бомжа" - уместна для "бутика", где торгуют вьетнамским барахлом под видом эксклюзивного хот-кутюр из Парижа.
это эмоции, таблеточки принимай как доктор предписал и смотри себе цветные сны про Париж и бутики. сейчас по весне много вашего брата повылезло, со всякими отклонениями
Вам с такими взглядами о единственно возможном способе использования технологий сами знаете куда надо?
возможно. но по крайней мере я не надеваю сапоги на голову руками что растут из ягодиц, как это делает YetAnotherOnanym, и не хвалюсь этим здесь и где бы то ни было
А ещё я иногда орехи гантелей колю, когда лень тащиться на кухню за орехоколом. Падай в обморок, ты шокирован :))
Так-то можно и скриншоты в ексель вставлять, чтобы потом переслать по почте. Не удивлюсь, что и у таких вещей есть юзкейс, и многие так делают. Просто на техническом форуме фу таким быть.
> Так-то можно и скриншоты в ексель вставлять, чтобы потом переслать по почте.
> Не удивлюсь, что и у таких вещей есть юзкейс, и многие
> так делают. Просто на техническом форуме фу таким быть.С учётом того, насколько отвратительный дефолтный просмотрщик изображений в б-жественной десяточке - не удивлюсь, если кто-то использует такую схему.
Те кто посылает скриншоты в екселе, не используют стандартный просмотрщик десяточки.У них есть ACDSee =)
> Zotonic не умеет работать с пулом серверов БД, он коннектится одному серверу при старте и дальше работает с ним. Если поднять отдельный контейнер с haproxy, который будет раскидывать трафик на несколько инстансов Zotonic'а, каждому из них нужен свой Pg, а это означает мультимастер репликацию, которая сейчас в Pg делается только костылями разной степени уродливости. Для настоящей HA нужно серьёзно допилить Zotonic, чтобы он писал только в мастер, а для чтения выбирал слейва из пула, при этом имел бы возможность на ходу переключаться на нового мастера.Подозреваю, вы плохо читали. http://docs.zotonic.com/en/latest/developer-guide/getting-st...
Да у них там есть докер, который пригоден для ознакомительных целей. В прод его нельзя. Вот тут они заботливо помогли с начальной точкой для организации приложения http://docs.zotonic.com/en/latest/developer-guide/docker.html обратите внимание что контейнеров уже 2.То что фреймворк работает с одной точкой подключения к базе - это вообще не проблема. Точнее, это не проблема фреймворка. Вам нужен repmgr или pgpool чтобы построить докерезированный кластер постгреса. Эта задача со звёздочкой, потому что постгрес и отказоустойчивость... это каждый сам должен для себя делать. Докер тут скорее мешает, а не помогает. Собственно mysql-то почему популярен. Сколько его не ругай, а вот для таких задач он и создан.
Ну и самое главное. Хапрокся в отдельном контейнере... а на чём у вас там крутятся все эти контейнеры, что у вас ингресс-балансировку нужно изобретать как велосипед в отдельном контейнере... не важно. Видимо контейнерной среды нету толком никакой... В любом варианте, всё это прекрасно делается даже в форме:
2х haproxy+keepalived
2x zotonic
2-3x postgresql
Можно то же самое с мускулем, можно в докере, можно без. Вы себе все проблемы с HA сами придумали, особенно про костыли разной степени уродливости. Докер же поможет автоматизировать костылестроение.> Можно, конечно, иметь один Pg на несколько Zotonic'ов, но это нихрена никакой не HA, к тому же производительность всей системы упрётся в производительность Pg.
Это как раз HA, это просто не LB. Балансировка соединений к базе - это вообще другая история. Это всегда делается ради производительности, а производительность LB на операциях UPDATE/DELETE в случае с LB на postgresql всегда оставляет желать лучшего. Оно медленнее чем одна нода в виду того, что такое постгрес, для чего он нужен и почему его не используют на таких задачах как CMS те, у кого есть задачи по высокой нагрузке. Если у приложения есть задача по балансировке колоссального наплыва пользовательских запросов, причем многие из которых могут что-то удалять или обновлять, то вон она какая Apache Cassandra есть.
http://zotonic.com/page/620/proven-and-powerful-database
Вот тут они пишут про то что 99.9% сайтов это не надо. Что как бы поясняет, для чего и для каких нагрузок эта штука. И про то что у них куча функций средствами RDBMS. Выбор в пользу постгреса у них тоже зачётный =)
Это я к тому что для Zotonic вам не нужен LB никогда. Если вам стал нужен LB вам нужно выбросить Zotonic. Сидеть при этом без HA, потому что нету LB из коробки, как-то странно...
> Подозреваю, вы плохо читали. http://docs.zotonic.com/en/latest/developer-guide/getting-st...Читал, причём внимательно. Только это у Вас доки на версию 1.0 (ветка master на гитхабе), у меня ветка 0.x, которая считается stable, доки на неё - http://docs.zotonic.com/en/stable/developer-guide/docker.html.
> Да у них там есть докерВот только на тот момент не работал он нифига. М.б. дело в этом https://github.com/zotonic/zotonic/issues?q=1930, или в этом https://github.com/zotonic/zotonic/issues?q=1950 - хз, мне проще было слепить контейнер с чистого альпина (или с официального докеровского эрланга, не помню уже), чем файлить исью и ждать, пока его пофиксят.
> Вам нужен repmgr
> или pgpool чтобы построить докерезированный кластер постгреса. Эта задача со звёздочкой,
> потому что постгрес и отказоустойчивость... это каждый сам должен для себя
> делать. Докер тут скорее мешает, а не помогает.Вот не буду врать - не заморачивался с кластером постгреса. Когда-то посмотрел в сторону Postgres-XC (он же -XL, он же -X2) от Коити Судзуки, но тогда даже до тыканья палочкой не дошло.
> Ну и самое главное. Хапрокся в отдельном контейнере... а на чём у
> вас там крутятся все эти контейнеры, что у вас ингресс-балансировку нужно
> изобретать как велосипед в отдельном контейнере...Haproxy выполнял только ssl-offloading. Не было там никакого распараллеливания )))
> не важно. Видимо контейнерной среды
> нету толком никакой...Ага ))) Мне нужно было просто запустить свою приблуду где-то, где она будет доступна извне. Для этого я просто подобрал хостинг, который умеет гонять докеровские контейнеры.
Понимаю, что у профессиональных микроскопистов вызывает страдание рассказ о том, как я когда-то забил микроскопом пару гвоздей, но что ж делать, если микроскоп у одного продавца оказался дешевле и удобнее для забивания гвоздей, чем молоток у другого.
> Понимаю, что у профессиональных микроскопистов вызывает страдание рассказ о том, как я когда-то забил микроскопом пару гвоздей, но что ж делать, если микроскоп у одного продавца оказался дешевле и удобнее для забивания гвоздей, чем молоток у другого.Скорее жалость к человеку с ограниченными умственными возможностями, который ни постгрес не освоил, ни докер не понял, ни хостинг нормальный не смог найти за нормальную цену, про HA сочиняет небылицы и еще и кичится собственным невежеством, будто так и надо, с опломбом, дескать, "какие тут проблемы?", а когда люди ему грубо говорят "идиот", обижается на оскорбления...
Я тут отвечаю длинными постами, чтобы другие болезные не начитались вашей дурости. Вас только медикаментами править. Приходилось иногда таких вот сразу на собеседованиях отсекать, причём не только ввиду полного непрофессионализма, но также и вопиющей неадекватности
Вооот, ещё очередной страдалец отметился.
> с опломбомЕщё с каким!
апломбом, но в остальном согласен
В чем проблема это сделать? Берешь любой менеджер процессов и вперед. Да можешь хость systemd взять.
например в том, что ты явно никогда даже не пытался.> Да можешь хость systemd взять.
можешь, только работать он - внезапно, не будет.
> например в том, что ты явно никогда даже не пытался.нет ты
> только работать он - внезапно, не будет.будет
запускаешь supervisord в качестве pid 1 и все остальные Nginx, PHP-FPM, MySQL и Postfix — через его конфиг. Нет никаких проблем.
systemd по всем параметрам лучше
до момента docker stop, ага, почти нет.
А что мешает сделать так, чтобы они будучи в разных контейнерах общались не по TCP/IP, а через pipe?
у lxc есть unprivileged containers для запуска контейнеров без рута (хотя в lxd их поддержку, емнип, не завезли)
Всё завезли - security.privileged
https://linuxcontainers.org/lxd/docs/master/instances
гораздо стабильнее и сделано не через жопу
обоснуй
LXD запускает контейнер как виртуальную машину развернутую из образа и сохраняет измененное состояние контейнера между запусками (стартами контейнера), тогда как докер разворачивает контейнер налету из образа, а при остановке его уничтожает, т.е. не хранит его состояние между запусками. Все данные нужно выносить биндингами на хост или куда нибудь еще за пределы контейнера если нужно что-то сохранить, например логи сервисов или файлы БД MySQL который крутится в контейнере. Возможно докер можно настроить как LXD, но не интересовался такими подробностями. Соответственно, для файлов которые растут в контейнере, в том числе для файлов баз данных можно применить квоты на объёмы дискового пространства на уровне контейнера или дискового устройства контейнера (можно создать для /home одно устройство, для /var другое и т.д.) который располагается в томе BTRFS или другой ФС которая предоставляется на выбор при создании хранилища для контейнера. В докере придётся что-то мутить с этим, я не знаю как просто также сделать как в LXD.LXD эксплуатирует QEMU, что позволят управлять в одном флаконе как контейнерами, так и полноценными виртуальными машинами. Можно хоть Windows 10 развернуть как виртуальную машину и управлять этой машиной унифицированными инструментами (клиетом LXD).
LXD является сервисом REST API, поэтому есть возможность создавать свои собственные запросы для управления контейнерами сторонними клиентами, например, через curl или создать свой web-клиент или использовать готовый.
В LXD нет никакого dockerfile, не нужно изучать и запоминать лишние слои абстракций для запуска контейнера, так как LXD хранит состояние контейнера при перезапуске. Например, для открытия TCP портов в контейнере нужно это явно прописать в докерфайле изучив тонкости этой премудрости, тогда как в LXD это делается штатными инструментами дистрибутива из которого развернут этот контейнер.
Docker можно запустить в контейнере LXD :)
В дополнении, LXD может запускать контейнеры в непривелегированном режиме, это когда внутренний пользователь, например root имеет UID=0, но для хоста на котором крутится этот контейнер внутренний root будет равным UID + SubUID = 1000000, и таким образом, если root сможет "выйти" из контейнера, то на хосте он не будет иметь привелегии root.Есть ли такое в Docker?
> В дополнении, LXD может запускать контейнеры в непривелегированном режимесколько раз уже этот "непривелегированный режим" сам по себе вел к local root? ;-)
Потому что на самом деле он очень даже привиллегированный - это юникс, детка, хотя бы еще отчасти, не рут не может делать массу вещей - поэтому вся размазня с uid mapping призвана замазать тот факт, что на деле у тебя при этом появляется сто рутов, и на каждой их операции система вынуждена пристально вглядываться "этот рут - тут рут, или надо его обломать?" - разумеется, подобная схема лажала и будет лажать, где-нибудь да ошибаясь в проверках.> Есть ли такое в Docker?
к счастью, нет. Можно запускать контейнер вообще от обычного пользователя, просто не оставляя внутри средств поднятия полномочий, и дополнительно некоторые capabilities выключены из коробки даже для контейнеров, работающих от рута. Именно так оно и было задумано - докер писали как изоляцию одной задачи, насмешка над bsd jail, а не эмулятора в эмуляторе в эмуляторе.
Нет рута - нет проблемы root escape. К сожалению, макаки так не умеют, 90% мусора с докерхаба не от рута не работают.
> сколько раз уже этот "непривелегированный режим" сам по себе вел к local root?
> это юникс, деткаЭто важное замечание. Ничего совершенного нет, в том числе и сам kernel Linux не избавлен от дыр :) Баги приложений никто не отменял, но по дизайну - local root не допустим в "непривелегированном" режиме.
> к счастью, нет.
Ок
в докере такое (userns) есть
> тогда как докер разворачивает контейнер налету из образа, а при остановке его уничтожает, т.е.
> не хранит его состояние между запускамитут тебя тоже обманули - контейнер может быть персистентным, и сохраняться при остановке.
Небольшая проблема в том, что если, опять, макака завела внутри целиком эмулятор операционной системы вместо одной задачи, причем задача ДОЛЖНА уметь корректно завершать работу по сигналу извне, docker stop выглядит не как shutdown, а как обрубание питания на ходу.
Собственно, настоящий системный shutdown точно так же выглядит, это init снабжен кучей хитрой механики, плавно останавливающей демонов, в правильном порядке и дожидаясь завершения их работы.
Но внутри докера нет такого init ;-) и, главное, места под него не предусмотрено. Каждый макак чуть поумнее типового вынужден сам себе изобретать - причем докер ему тут не помогает, а мешает. Например, в докерфайле нельзя задать таймаут шатдауна, отличающийся от дефолта. И если у тебя там что-то сложное, что просто так не выключить - остается только писать жалобные просьбы в документации - "останавливайте, пожалуйста docker exec stop, или хотя бы docker -t 20000 stop, иначе я за базу не ручаюсь".А система с нескучным restapi у нас называется k8s + openshift
> Например, для открытия TCP портов в контейнере нужно это явно прописать в докерфайле
не, не нужно. Так было задумано, когда-то давно, когда хотели чтобы докерфайл был единственным и законченным хранилищем всей метаинфы, что именно может понадобиться этой задаче.
Это все сломали и выбросили еще на ранних этапах, вместе с persistent volumes и volume-from, точнее, объявили немодно-deprecated, и понаписали сверху еще две разных обертки, ни одну из которых тоже не доделали - некогда, смузи киснет, макака, задрав обос...ный хвост уже убежала в другой прожект.
Спасибо, что пояснили некоторые моменты, я за докер брался несколько лет назад, не пошло - выкинул его и взял LXD :)> макак
Кто это такой, что за зверёк? :)
> > макак
> Кто это такой, что за зверёк? :)нах настолько зазвездился что начал говорить о себе в третьем лице
раньше у нас их в сухумском обезьянопитомнике разводили, опыты по заражению чумой ставить - а потом как-то стало негуманно считаться, и их всех произвели в "разработчики". Теперь вот - чума, и вдобавок докер.
Какие страсти творятся в Сухум )) Был я у вас в 2016 - чудесный город, мне понравился, даже гопники налетевшие толпой понравились ))
в 16м вроде уже не было обезьян в питомнике. А доскер с системдой активно развились. Совпадение? Не думаю!
> Но внутри докера нет такого init ;-) и, главное, места под него
> не предусмотрено.А чем тебя tini не устраивает?
Например, что он ничего не сможет сделать, если ему прилетит SIGTERM от docker stop. Никакой возможности задержать окончательный sigkill если это руками не предусмотрительно попросил набиравший
> Например, что он ничего не сможет сделать, если ему прилетит SIGTERM от
> docker stop. Никакой возможности задержать окончательный sigkill если это руками не
> предусмотрительно попросил набиравшийНууу, это обходимая проблема.
нет. Это вот в доскере не решается вообще никак в принципе. Баг дизайна.
Ну или сознательный tradeoff (типа и нехрен всякие postgresы запускать таким образом, это ни разу не stateless ограниченное приложение, для которых, типа, изобретали докер), только я не верю что ляпатели на игогошечке хоть иногда бывали в сознании.Судя по остальным оставшимся от них кучкам.
Например, что он ничего не сможет сделать, если ему прилетит SIGTERM от docker stop. Никакой возможности задержать окончательный sigkill если это руками не предусмотрительно попросил набиравший stop - не завезли.
> LXD
> Все данные нужно выносить биндингами на хост или куда нибудь еще за пределы контейнера если нужно что-то сохранитьА ты правильно понимаешь lxd/lxc?
Цитата взята из того места где говорил о докере, однако в LXC тоже можно выносить данные за пределы стораджа контейнера, а внтури монтировать как дисковое устройство.
> Цитата взята из того места где говорил о докере,Видимо я не распарсил. Ок.
Docker — контейнер приложений (application container), LXC/LXD/OpenVZ — системные контейнеры (system container). Сделаны по-разному и для разного.Пересекаются технологически, но не идеологически. Docker не подходит и не предназначен для контейнеров с большим количеством демонов, как и не подходит LXC/Jail для запуска одной единственной программы, предварительно установив туда всю ОС.
Мне гораздо чаще приходится запускать полноценные контейнеры, и я выбираю для этого LXD (и иногда systemd-nspawn/machined). Возможно, некоторые не знают о разнице подходов, и пытаются адаптировать неподходящий, но известный им инструмент (docker) под их задачу, что можно видеть по куче статей в интернете, где решают проблему init 1 в docker.
Systemd не работает в Docker.
Также см. https://www.linux.org.ru/forum/general/15607470
> Systemd не работает в Docker.Это же из-за проблем с правами просходит. В LXC должно быть также? Под капотом же одно и то же.
LXD это не контейнеры это тулза для управления lxc и kvm теперь.
> systemd не работает в dockerвсе прекрасно работает
network.type=phys
В частности тем, что есть в 32-разрядных дистрибутивах. Можео на старый сервер поставить.
Чем оно лучше flatpak?
Примерно тем же, чем лучше трамвайной ручки.Это вообще-то совсем разные вещи.
Что такое трамвайная ручка?
https://st3.depositphotos.com/1019087/15741/i/1600/depositph...
Вах! В отличии от доскера - офигенная, винтажная штучка! :)
Стоит сравнивать с openvz. Есть мнение, что хуже openvz быть ничего не может, в связи с чем сабж -- технический победитель.
Оценивать по ущербности low-end хостеров саму технологию изоляции... Это... ну это Опеннет, всё норм. Продолжайте...
Почему-то решения на основе lxc при всей ущербности у тех же самых помойных хостеров вполне норм. Можно сделать определённые выводы. Или это мне так "везло"?
Пока нет данных об оверсейле мощностей тех нод, где крутился OpenVZ, - никаких выводов делать нельзя.Тем более что OpenVZ появился раньше, клиенты на нём тоже, нода стоит не обслуженная уже лет десять, и железка там не вывозит. А на новую ноду с lxc собрали года три всего назад, lxc не позволял сделать такой оверсейл... И, в итоге, пользователи lxc живут чуть-лучше.
Такое вот у меня видение проблематики. Не претендую на точность взглядов, так как тоже не имею карманного помойного хостера, чтобы статистику выкатить.
ах как некрасиво, вы совсем забыли про vServer
то-есть Linux-VServer. даже сам уже забыл как называется, т.к. не пользовался лет 10
Самая большая проблема с LXC для хипстеров в отличие от docker - он не работает на их яблозондах.
работает (так же как докер - в вм)
на маке и винде докер работает в виртуалкет е ставиш виртуалнку - в нее убунту - в нее LXD
и вуаля - LXD работает на маке
Задание тебе - поднять там ipv6
Докер может одной командой запустить контейнер а лхд нет
LXD это система контейнерной виртуализации на базе готовых проверенных образовпоэтому мы не изучаем премудрости и нюансы такого тула как docker, а просто изучаем пару команд для управления контейнерами и используем стандартные средства ОС для конфигурации ПО в контейнере
>lxdэто тот который дырявый бай дезигн?
https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1829071
для локальной разработки мне ока для прода есть админы и облачные сервисы