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

"Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+/–
Сообщение от opennews (??), 05-Апр-20, 23:04
Компания 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
Ответить | Правка | Cообщить модератору

Сообщения

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

4. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	–3 +/–
Сообщение от Kroz (??), 06-Апр-20, 01:15
Чем LXC лучше docker?
Ответить | Правка | Наверх | Cообщить модератору

	5. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+1 +/–
	Сообщение от Аноним (5), 06-Апр-20, 01:24
	проще
	Ответить | Правка | Наверх | Cообщить модератору

	8. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+4 +/–
	Сообщение от бублички (?), 06-Апр-20, 03:17
	для простого и понятного примера, попробуй запусти в одном Docker-контейнере Nginx, PHP-FPM, MySQL и Postfix. да, в одном контейнере а не в 4 разных, что будут по TCP/IP друг с другом общаться и все впятером  гадить в syslog что крутится в 5-м. в LXC это делается как в любой стандартной OS, ибо служит для изоляции (контейнер) OS, в то время как Docker для изоляции приложения
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	12. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	–7 +/–
	Сообщение от Аноним (12), 06-Апр-20, 05:50
	что ты несешь, как настроишь, туда и будут "гадить", все, что может lxc, может и docker, но не наоборот
	Ответить | Правка | Наверх | Cообщить модератору

	18. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+18 +/–
	Сообщение от нах. (?), 06-Апр-20, 08:47
	> для простого и понятного примера, попробуй запусти в одном Docker-контейнере Nginx, PHP-FPM, > MySQL и Postfix. к сожалению, примерно 2/3 хлама, поставляемого в виде докер-образов именно так и сделаны. Включая, как ни смешно, docker registry. Ты еще забыл добавить в эту кучку мусора самодельную наколеночную замену init (да, да - что-то ведь должно весь этот мусор последовательно запускать) и cron (ибо ниасиляторы не могут настоящий, а периодические процессы таки им иногда нужны) А теперь попробуй корректно такой "контейнер" остановить по docker stop. "ой, база побилась" ? Ну, вот так у обезьянок - всё. Естественно, и от докерной автоматики, перезапускающей если упало, таким образом успешно избавляются, docker daemon умеет перезапускать только entrypoint, а не всю внутреннююю мусоруку. Еще очень модно при старте что-нибудь скачать из интернета и покомпилять - потому что макака не смогла это запихнуть куда надо, в dockerfile. Сколько макакам ни долбили что докер вовсе не предназначен быть эмулятором для запуска операционной системы целиком, это средство изоляции отдельной программы - даже нарочно наделав им грабель (любимый макакой systemd просто так внутри не запускается) - ничего не помогает. Включая макак, работавших в самом докере - еще раз см регистри. Но, к сожалению, поляна, как обычно, загажена - ни про какое lxc макака и не слышала, и не умеет, и уметь не хочет. При этом как раз все, что умеет делать докер, lxc тоже умеет. Включая и не ограничиваясь частичной изоляцией - без громождения прослоек overlay одной поверх другой.
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	31. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+/–
	Сообщение от бублички (?), 06-Апр-20, 11:06
	мне то ты зачем про это пишешь, да ещё в таком количестве? я применение Docker знаю, и где надо и возможно - пользуюсь им без лишних уродливых костылей, именно для изоляции приложения (к примеру RabbitMQ кластер, что деплоится автоматом со всеми необходимыми настройками из Dockerfile). где надо больше чем может Docker без костылей - пользуюсь LXC. где надо ещё больше - KVM. и всё прекрасно работает, жалоб нет, костылей избегаю
	Ответить | Правка | Наверх | Cообщить модератору

	23. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	–7 +/–
	Сообщение от YetAnotherOnanym (ok), 06-Апр-20, 09:28
	Очень хорошо настраивал в одном контейнере Haproxy, Zotonic (т.е. Erlang VM), PostgreSQL и OpenSSH. Контейнер лепил сам из голого Alpine. А что, у меня должны были возникнуть какие-то проблемы?
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	25. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+2 +/–
	Сообщение от anonymous (??), 06-Апр-20, 09:58
	Кроме того что ты идиот (догадайся сам почему), проблем никаких.
	Ответить | Правка | Наверх | Cообщить модератору

	29. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	–4 +/–
	Сообщение от YetAnotherOnanym (ok), 06-Апр-20, 10:37
	> Кроме того что ты идиот (догадайся сам почему), проблем никаких. То есть, кроме оскорблений, сказать нечего. Чего-то такого я и ожидал.
	Ответить | Правка | Наверх | Cообщить модератору

	32. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+/–
	Сообщение от бублички (?), 06-Апр-20, 11:10
	а что тебе ещё сказать? тем-более ты сам говоришь что ожидал подобного. а вот скажи, ожидаешь не от понимания ли что всё-таки используешь Docker не по назначению?
	Ответить | Правка | Наверх | Cообщить модератору

	41. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+/–
	Сообщение от YetAnotherOnanym (ok), 06-Апр-20, 12:58
	> используешь Docker не по назначению А я и математический анализ не по назначению использовать могу - согну проволоку в форме интеграла и достану ключи из унитаза. Если контейнер с 512МБ ОЗУ стОит примерно на треть дороже, чем контейнер с 256МБ, а контейнер с 1ГБ ОЗУ стОит немного более чем наполовину дороже, чем контейнер с 256МБ, то как раз таки надо быть идиотом, чтобы платить за 4 контейнера вместо одного.
	Ответить | Правка | Наверх | Cообщить модератору

	46. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	–1 +/–
	Сообщение от бублички (?), 06-Апр-20, 13:31
	тяжело тебе, ещё и кризис с коронавирусом. соболезнования
	Ответить | Правка | Наверх | Cообщить модератору

	52. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+/–
	Сообщение от YetAnotherOnanym (ok), 06-Апр-20, 14:52
	> тяжело тебе, ещё и кризис с коронавирусом. соболезнования Если у тебя есть возможность тратить деньги своего работодателя, не считая их, я за тебя рад, но учти одну простую вещь - долго такое счастье не длится.
	Ответить | Правка | Наверх | Cообщить модератору

	79. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+1 +/–
	Сообщение от www2 (??), 07-Апр-20, 09:51
	Зачем вам вообще Docker, если вы во главу угла ставите дешевизну хостинга? Для массового автоматизированного развёртывания есть Ansible, Chef, Puppet - можно настроить много виртуалок со всем необходимым внутри каждой виртуалки. Идея Docker в том, чтобы внутри него держать одно ПРИЛОЖЕНИЕ, а не всю нужную ему лабуду в придачу. Вы используете инструмент не по назначению, просто потому что это модно, при этом пытаетесь сэкономить деньги. С головой что-то явно не так.
	Ответить | Правка | Наверх | Cообщить модератору

	80. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+/–
	Сообщение от YetAnotherOnanym (ok), 07-Апр-20, 11:47
	Не только дешевизну. Крупные хостеры (Амазон, Гугл, Диджитал Оушн) за каким-то хреном требуют телефон, а мне не хочется привязывать свой телефон к сервисам организации, равно как и заморачиваться с покупкой корпоративной симки. ИБМ вообще в РФ не работает, некоторые принимали оплату с карты только по пайпал, который с какого-то хрена подвесил мою учётку. Поверьте, мне пришлось перерыть достаточно большой объём выдачи гугла, прежде чем остановился на hyper.sh, царствие ему небесное. Да, я много где читал, что в одном контейнере докера должно быть одно приложение, но нигде не было внятного и убедительного объяснения почему. Заодно всегда деликатно обходится вопрос о накладных расходах при обмене данными между контейнерами. Ну, а после того, как hyper.sh сдулся (а также сдувались облачные сервисы вендоров систем видеонаблюдения, умного дома и т.д.), я решил вообще на подобные сервисы забить и всё своё держать при себе.
	Ответить | Правка | Наверх | Cообщить модератору

	82. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+1 +/–
	Сообщение от Александр Друзь (?), 07-Апр-20, 14:32
	> Да, я много где читал, что в одном контейнере докера должно быть одно приложение, но нигде не было внятного и убедительного объяснения почему. Заодно всегда деликатно обходится вопрос о накладных расходах при обмене данными между контейнерами. Представь себе внутрикорпоративный продукт собственного производства. Бизнес заказывает функции, разработчики делают, админы деплоят и админят. Такие программы могут быть условно говоря двух типов: монолитные и микросервисные. Монолитное приложение - это одна большая программа выполняемая на одном большом хосте или ВМ. Все её модули и она сама находятся в оперативной памяти и выполняются на одном процессоре. Это очень быстро и удобно. Чтобы сделать такую софтину отказоустойчивой и сбалансировать её нагрузку тебе нужно создать вторую третью и т. д. сущность и поставить балансировщик. В зависимости от типа запросов к приложению наличия или отсутствия клиент-серверных привязок в рамках сессий или потоков датаграмм ты настроишь свои балансировщики на 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, прослоек в виде сети, всё работает напрямую вызывая функцию по имени из соседнего блока оперативной памяти. В реальности никаких бесконечных мощностей не будет и уперевшись в проблемы вертикального масштабирования, микросервисная архитектура будет выигрывать по соотношению производительность к стоимости владения. Кстати, обратите внимание, как процениваются облака и сравните с проценкой традиционного хостинга. А еще в реальности микросервисная архитектура может быть вредна (маленькое приложение разнесли на кучу еще более мелких в условиях плохой сети), не возможна (куча легаси монолитного вендорспецифичного софта), дорога (когда покупаются все контейнеры в облаках) и вообще это всё вопросы не вашего ума дела, это за вас решат разработчики корпоративного софта.
	Ответить | Правка | Наверх | Cообщить модератору

	85. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+/–
	Сообщение от YetAnotherOnanym (ok), 07-Апр-20, 17:27
	То есть, для "правильного" использования Докера приложение должно было быть написано под Докер. В моём случае этого нет, разнесение Haproxy, EVM с Zotonic'ом и PgSQL по разным контейнерам ничего из описанных плюшек не дало бы - собственно, об этом я уже писал. Мой сервис - это не Гугл, и не Фейсбук, и не Нетфликс, и не Нью-Йоркская фондовая биржа, и не Свифт, и не что-то подобное. Городить "правильный" пучок контейнеров - это была бы просто стрельба из пушки по воробьям.
	Ответить | Правка | Наверх | Cообщить модератору

	88. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+/–
	Сообщение от Аноним (88), 07-Апр-20, 18:15
	Контейнеры типа докера тут не нужно использовать вообще. Контейнеры ОС типа LXC у контейнерного хостера тут могут быть использованы и то только если хочется, можно ВМ. Просто есть матчасть, которую надо знать. В линуксах нету setup.exe, а людям этого очень хочется. Авторы, чтобы пользователь быстро установил и поднять демку у себя на локалхосте, предлагают как попало собраный самими авторами контейнер. Даже в документации пишут, что это "getting started", зачастую не указывая, что в проде так использовать докеры нельзя, ведь это само собой разумеющаяся истина. Но есть русские малограмотные админы, которые по английски-то даже не понимают, которые про докер что-то слышали и знают, что это контейнер и вот и получается то что получается. На венеде это "скачать бесплатно без смс на высокой скорости вишмастер_сетап.ехе". На линуксах это "скачать бесплатно без смс на высокой скорости вишмастер_докер.имг" Правильная установка Zotonic бывает в двух вариантах: 1. Без HA. Вогнать всё на одну разнесчастную виртуалку ну или максимум базу отцепить, чтобы за ресурсы не дрались. 2. С HA. Тогда нужна Haproxy, keepalived, zotonic/evm, postgresql в режиме мастер-слейв репликации. Если стоимость простоя сервиса для бизнеса ниже стоимости оплаты за кучу сущностей HA, значит бизнесу это не надо. ... просто докер тут лишний от слова совсем.
	Ответить | Правка | К родителю #85 | Наверх | Cообщить модератору

	87. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+/–
	Сообщение от бублички (?), 07-Апр-20, 17:40
	извини, но DO - самая бомжацкая помойка из всех возможных. буквально хостинг от Сифона и Бороды. про фирму твою (где нет CIO, CTO и т.п.) тоже всё понял - проект твой и его воплощение тоже подстать. я не с целью обидеть тебя лично. вопросов больше не имею
	Ответить | Правка | К родителю #80 | Наверх | Cообщить модератору

	77. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+3 +/–
	Сообщение от Аноним (77), 07-Апр-20, 06:26
	Идиота в зеркале увидишь.
	Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

	33. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+/–
	Сообщение от бублички (?), 06-Апр-20, 11:21
	и правда удобно? и не беда что файлы той-же базы PostgreSQL приходится держать где-то вне контейнера чтоб не исчезли при его рестарте? мигрировать с сервера на сервер такой контейнер с внешними файлами удобно? выкатывать новый для HA? а новые ключи для доступа по SSH как добавляешь? неужели руками? уже и не спрашиваю про новых пользователей кому надо дать доступ в твой контейнер. чего только не выдумают люди чтоб оправдать свою лень и нежелание узнавать что-то простое и полезное (в данном случае LXC)
	Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

	40. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	–1 +/–
	Сообщение от YetAnotherOnanym (ok), 06-Апр-20, 12:49
	> файлы той-же базы PostgreSQL приходится держать где-то вне контейнера Вольюм примонтирован. Работает. Не должен? > мигрировать с сервера на сервер Вот хз, мигрировал ли мой контейнер с одного физического сервера на другой - я его залил на хостинг, поднял и оставил работать. > выкатывать новый для HA Какой нахрен HA? Ты не знаешь мой юзкейс, а берёшься судить. Zotonic не умеет работать с пулом серверов БД, он коннектится одному серверу при старте и дальше работает с ним. Если поднять отдельный контейнер с haproxy, который будет раскидывать трафик на несколько инстансов Zotonic'а, каждому из них нужен свой Pg, а это означает мультимастер репликацию, которая сейчас в Pg делается только костылями разной степени уродливости. Для настоящей HA нужно серьёзно допилить Zotonic, чтобы он писал только в мастер, а для чтения выбирал слейва из пула, при этом имел бы возможность на ходу переключаться на нового мастера. Можно, конечно, иметь один Pg на несколько Zotonic'ов, но это нихрена никакой не HA, к тому же производительность всей системы упрётся в производительность Pg. > новые ключи для доступа по SSH Неактуально.
	Ответить | Правка | Наверх | Cообщить модератору

	45. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+/–
	Сообщение от бублички (?), 06-Апр-20, 13:24
	неправильный выбор технологий снизу и доверху впечатляет, полное отсутствие HA в принципе тоже. Docker там где нужен бы LXC, PostgreSQL (религия?) без всяких оснований вместо MySQL (Percona). HAProxy то для чего? SSH понятно тебе нужен, чтоб логи смотреть и процессами управлять, т.к. хостинг твой для бомжей (4 контейнера уже дорого) и видно даже лог твоего контейнера не отображает никаким образом (за дополнительную плату). надеюсь это dev или staging, за подобный production мучительно и долго убивал бы из рогатки клюквой. попадались мне такие проекты по наследству от всеразличных самоделкиных - смеялся и плакал, восхищаясь бесконечной глупости. даже поставил на столе портретик Эйнштейна
	Ответить | Правка | Наверх | Cообщить модератору

	51. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	–2 +/–
	Сообщение от YetAnotherOnanym (ok), 06-Апр-20, 14:46
	Дай-ка угадаю, ты когда-то прочёл одну-единственную хаутушку и с тех пор она завладела твоими мыслями и не отпускает ни на мгновенье, и всё, что тебе попадается, ты переделываешь по тому самому, одному-единственному когда-то прочитанному рецепту. А что касается подхода "заплати лишнее за ненужное, а то я буду на тебя смотреть как на бомжа" - уместна для "бутика", где торгуют вьетнамским барахлом под видом эксклюзивного хот-кутюр из Парижа.
	Ответить | Правка | Наверх | Cообщить модератору

	53. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	–2 +/–
	Сообщение от бублички (?), 06-Апр-20, 14:57
	это эмоции, таблеточки принимай как доктор предписал и смотри себе цветные сны про Париж и бутики. сейчас по весне много вашего брата повылезло, со всякими отклонениями
	Ответить | Правка | Наверх | Cообщить модератору

	57. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+/–
	Сообщение от Аноним (57), 06-Апр-20, 16:15
	Вам с такими взглядами о единственно возможном способе использования технологий сами знаете куда надо?
	Ответить | Правка | Наверх | Cообщить модератору

	62. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+2 +/–
	Сообщение от бублички (?), 06-Апр-20, 18:59
	возможно. но по крайней мере я не надеваю сапоги на голову руками что растут из ягодиц, как это делает YetAnotherOnanym, и не хвалюсь этим здесь и где бы то ни было
	Ответить | Правка | Наверх | Cообщить модератору

	81. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	–1 +/–
	Сообщение от YetAnotherOnanym (ok), 07-Апр-20, 11:55
	А ещё я иногда орехи гантелей колю, когда лень тащиться на кухню за орехоколом. Падай в обморок, ты шокирован :))
	Ответить | Правка | Наверх | Cообщить модератору

	83. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+/–
	Сообщение от Аноним (88), 07-Апр-20, 14:43
	Так-то можно и скриншоты в ексель вставлять, чтобы потом переслать по почте. Не удивлюсь, что и у таких вещей есть юзкейс, и многие так делают. Просто на техническом форуме фу таким быть.
	Ответить | Правка | Наверх | Cообщить модератору

	86. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	–1 +/–
	Сообщение от YetAnotherOnanym (ok), 07-Апр-20, 17:31
	> Так-то можно и скриншоты в ексель вставлять, чтобы потом переслать по почте. > Не удивлюсь, что и у таких вещей есть юзкейс, и многие > так делают. Просто на техническом форуме фу таким быть. С учётом того, насколько отвратительный дефолтный просмотрщик изображений в б-жественной десяточке - не удивлюсь, если кто-то использует такую схему.
	Ответить | Правка | Наверх | Cообщить модератору

	89. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+/–
	Сообщение от Аноним (88), 07-Апр-20, 18:21
	Те кто посылает скриншоты в екселе, не используют стандартный просмотрщик десяточки. У них есть ACDSee =)
	Ответить | Правка | К родителю #86 | Наверх | Cообщить модератору

	84. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+1 +/–
	Сообщение от Аноним (88), 07-Апр-20, 15:43
	> 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 из коробки, как-то странно...
	Ответить | Правка | К родителю #40 | Наверх | Cообщить модератору

	90. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+/–
	Сообщение от YetAnotherOnanym (ok), 07-Апр-20, 19:11
	> Подозреваю, вы плохо читали. 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. Не было там никакого распараллеливания ))) > не важно. Видимо контейнерной среды > нету толком никакой... Ага ))) Мне нужно было просто запустить свою приблуду где-то, где она будет доступна извне. Для этого я просто подобрал хостинг, который умеет гонять докеровские контейнеры. Понимаю, что у профессиональных микроскопистов вызывает страдание рассказ о том, как я когда-то забил микроскопом пару гвоздей, но что ж делать, если микроскоп у одного продавца оказался дешевле и удобнее для забивания гвоздей, чем молоток у другого.
	Ответить | Правка | Наверх | Cообщить модератору

	91. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+/–
	Сообщение от Аноним (88), 08-Апр-20, 01:40
	> Понимаю, что у профессиональных микроскопистов вызывает страдание рассказ о том, как я когда-то забил микроскопом пару гвоздей, но что ж делать, если микроскоп у одного продавца оказался дешевле и удобнее для забивания гвоздей, чем молоток у другого. Скорее жалость к человеку с ограниченными умственными возможностями, который ни постгрес не освоил, ни докер не понял, ни хостинг нормальный не смог найти за нормальную цену, про HA сочиняет небылицы и еще и кичится собственным невежеством, будто так и надо, с опломбом, дескать, "какие тут проблемы?", а когда люди ему грубо говорят "идиот", обижается на оскорбления... Я тут отвечаю длинными постами, чтобы другие болезные не начитались вашей дурости. Вас только медикаментами править. Приходилось иногда таких вот сразу на собеседованиях отсекать, причём не только ввиду полного непрофессионализма, но также и вопиющей неадекватности
	Ответить | Правка | Наверх | Cообщить модератору

	92. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+/–
	Сообщение от YetAnotherOnanym (ok), 08-Апр-20, 10:32
	Вооот, ещё очередной страдалец отметился. > с опломбом Ещё с каким!
	Ответить | Правка | Наверх | Cообщить модератору

	93. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+/–
	Сообщение от бублички (?), 08-Апр-20, 22:20
	апломбом, но в остальном согласен
	Ответить | Правка | К родителю #91 | Наверх | Cообщить модератору

	47. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	–1 +/–
	Сообщение от Аноним (47), 06-Апр-20, 13:32
	В чем проблема это сделать? Берешь любой менеджер процессов и вперед. Да можешь хость systemd взять.
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	67. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+2 +/–
	Сообщение от нах. (?), 06-Апр-20, 20:21
	например в том, что ты явно никогда даже не пытался. > Да можешь хость systemd взять. можешь, только работать он - внезапно, не будет.
	Ответить | Правка | Наверх | Cообщить модератору

	74. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+/–
	Сообщение от Аноним (74), 06-Апр-20, 23:55
	> например в том, что ты явно никогда даже не пытался. нет ты > только работать он - внезапно, не будет. будет
	Ответить | Правка | Наверх | Cообщить модератору

	56. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	–4 +/–
	Сообщение от Аноним (57), 06-Апр-20, 16:05
	запускаешь supervisord в качестве pid 1 и все остальные Nginx, PHP-FPM, MySQL и Postfix — через его конфиг. Нет никаких проблем.
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	63. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+/–
	Сообщение от Аноним (63), 06-Апр-20, 19:43
	systemd по всем параметрам лучше
	Ответить | Правка | Наверх | Cообщить модератору

	68. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	–1 +/–
	Сообщение от нах. (?), 06-Апр-20, 20:22
	до момента docker stop, ага, почти нет.
	Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

	78. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+/–
	Сообщение от Aquarius (ok), 07-Апр-20, 07:17
	А что мешает сделать так, чтобы они будучи в разных контейнерах общались не по TCP/IP, а через pipe?
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	11. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	–1 +/–
	Сообщение от Аноним (-), 06-Апр-20, 05:36
	у lxc есть unprivileged containers для запуска контейнеров без рута (хотя в lxd их поддержку, емнип, не завезли)
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	15. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+1 +/–
	Сообщение от microcoder (ok), 06-Апр-20, 07:22
	Всё завезли - security.privileged https://linuxcontainers.org/lxd/docs/master/instances
	Ответить | Правка | Наверх | Cообщить модератору

	13. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	–1 +/–
	Сообщение от Аноним (13), 06-Апр-20, 06:28
	гораздо стабильнее и сделано не через жопу
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	16. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+5 +/–
	Сообщение от Аноним (5), 06-Апр-20, 07:26
	обоснуй
	Ответить | Правка | Наверх | Cообщить модератору

	14. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+8 +/–
	Сообщение от microcoder (ok), 06-Апр-20, 07:11
	LXD запускает контейнер как виртуальную машину развернутую из образа и сохраняет измененное состояние контейнера между запусками (стартами контейнера), тогда как докер разворачивает контейнер налету из образа, а при остановке его уничтожает, т.е. не хранит его состояние между запусками. Все данные нужно выносить биндингами на хост или куда нибудь еще за пределы контейнера если нужно что-то сохранить, например логи сервисов или файлы БД MySQL который крутится в контейнере. Возможно докер можно настроить как LXD, но не интересовался такими подробностями. Соответственно, для файлов которые растут в контейнере, в том числе для файлов баз данных можно применить квоты на объёмы дискового пространства на уровне контейнера или дискового устройства контейнера (можно создать для /home одно устройство, для /var другое и т.д.) который располагается в томе BTRFS или другой ФС которая предоставляется на выбор при создании хранилища для контейнера. В докере придётся что-то мутить с этим, я не знаю как просто также сделать как в LXD. LXD эксплуатирует QEMU, что позволят управлять в одном флаконе как контейнерами, так и полноценными виртуальными машинами. Можно хоть Windows 10 развернуть как виртуальную машину и управлять этой машиной унифицированными инструментами (клиетом LXD). LXD является сервисом REST API, поэтому есть возможность создавать свои собственные запросы для управления контейнерами сторонними клиентами, например, через curl или создать свой web-клиент или использовать готовый. В LXD нет никакого dockerfile, не нужно изучать и запоминать лишние слои абстракций для запуска контейнера, так как LXD хранит состояние контейнера при перезапуске. Например, для открытия TCP портов в контейнере нужно это явно прописать в докерфайле изучив тонкости этой премудрости, тогда как в LXD это делается штатными инструментами дистрибутива из которого развернут этот контейнер. Docker можно запустить в контейнере LXD :)
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	17. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+4 +/–
	Сообщение от microcoder (ok), 06-Апр-20, 08:23
	В дополнении, LXD может запускать контейнеры в непривелегированном режиме, это когда внутренний пользователь, например root имеет UID=0, но для хоста на котором крутится этот контейнер внутренний root будет равным UID + SubUID = 1000000, и таким образом, если root сможет "выйти" из контейнера, то на хосте он не будет иметь привелегии root. Есть ли такое в Docker?
	Ответить | Правка | Наверх | Cообщить модератору

	19. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+2 +/–
	Сообщение от нах. (?), 06-Апр-20, 08:58
	> В дополнении, LXD может запускать контейнеры в непривелегированном режиме сколько раз уже этот "непривелегированный режим" сам по себе вел к local root? ;-) Потому что на самом деле он очень даже привиллегированный - это юникс, детка, хотя бы еще отчасти, не рут не может делать массу вещей - поэтому вся размазня с uid mapping призвана замазать тот факт, что на деле у тебя при этом появляется сто рутов, и на каждой их операции система вынуждена пристально вглядываться "этот рут - тут рут, или надо его обломать?" - разумеется, подобная схема лажала и будет лажать, где-нибудь да ошибаясь в проверках. > Есть ли такое в Docker? к счастью, нет. Можно запускать контейнер вообще от обычного пользователя, просто не оставляя внутри средств поднятия полномочий, и дополнительно некоторые capabilities выключены из коробки даже для контейнеров, работающих от рута. Именно так оно и было задумано - докер писали как изоляцию одной задачи, насмешка над bsd jail, а не эмулятора в эмуляторе в эмуляторе. Нет рута - нет проблемы root escape. К сожалению, макаки так не умеют, 90% мусора с докерхаба не от рута не работают.
	Ответить | Правка | Наверх | Cообщить модератору

	20. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+/–
	Сообщение от microcoder (ok), 06-Апр-20, 09:10
	> сколько раз уже этот "непривелегированный режим" сам по себе вел к local root? > это юникс, детка Это важное замечание. Ничего совершенного нет, в том числе и сам kernel Linux не избавлен от дыр :) Баги приложений никто не отменял, но по дизайну - local root не допустим в "непривелегированном" режиме. > к счастью, нет. Ок
	Ответить | Правка | Наверх | Cообщить модератору

	95. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+/–
	Сообщение от rex (??), 26-Янв-21, 12:34
	в докере такое (userns) есть
	Ответить | Правка | Наверх | Cообщить модератору

	21. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+/–
	Сообщение от нах. (?), 06-Апр-20, 09:11
	> тогда как докер разворачивает контейнер налету из образа, а при остановке его уничтожает, т.е. > не хранит его состояние между запусками тут тебя тоже обманули - контейнер может быть персистентным, и сохраняться при остановке. Небольшая проблема в том, что если, опять, макака завела внутри целиком эмулятор операционной системы вместо одной задачи, причем задача ДОЛЖНА уметь корректно завершать работу по сигналу извне, docker stop выглядит не как shutdown, а как обрубание питания на ходу. Собственно, настоящий системный shutdown точно так же выглядит, это init снабжен кучей хитрой механики, плавно останавливающей демонов, в правильном порядке и дожидаясь завершения их работы. Но внутри докера нет такого init ;-) и, главное, места под него не предусмотрено. Каждый макак чуть поумнее типового вынужден сам себе изобретать - причем докер ему тут не помогает, а мешает. Например, в докерфайле нельзя задать таймаут шатдауна, отличающийся от дефолта. И если у тебя там что-то сложное, что просто так не выключить - остается только писать жалобные просьбы в документации - "останавливайте, пожалуйста docker exec stop, или хотя бы docker -t 20000 stop, иначе я за базу не ручаюсь". А система с нескучным restapi у нас называется k8s + openshift > Например, для открытия TCP портов в контейнере нужно это явно прописать в докерфайле не, не нужно. Так было задумано, когда-то давно, когда хотели чтобы докерфайл был единственным и законченным хранилищем всей метаинфы, что именно может понадобиться этой задаче. Это все сломали и выбросили еще на ранних этапах, вместе с persistent volumes и volume-from, точнее, объявили немодно-deprecated, и понаписали сверху еще две разных обертки, ни одну из которых тоже не доделали - некогда, смузи киснет, макака, задрав обос...ный хвост уже убежала в другой прожект.
	Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

	22. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+/–
	Сообщение от microcoder (ok), 06-Апр-20, 09:22
	Спасибо, что пояснили некоторые моменты, я за докер брался несколько лет назад, не пошло - выкинул его и взял LXD :) > макак Кто это такой, что за зверёк? :)
	Ответить | Правка | Наверх | Cообщить модератору

	24. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	–1 +/–
	Сообщение от Аноним (24), 06-Апр-20, 09:29
	> > макак > Кто это такой, что за зверёк? :) нах настолько зазвездился что начал говорить о себе в третьем лице
	Ответить | Правка | Наверх | Cообщить модератору

	26. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+2 +/–
	Сообщение от нах. (?), 06-Апр-20, 09:59
	раньше у нас их в сухумском обезьянопитомнике разводили, опыты по заражению чумой ставить - а потом как-то стало негуманно считаться, и их всех произвели в "разработчики". Теперь вот - чума, и вдобавок докер.
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

	27. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+/–
	Сообщение от microcoder (ok), 06-Апр-20, 10:04
	Какие страсти творятся в Сухум )) Был я у вас в 2016 - чудесный город, мне понравился, даже гопники налетевшие толпой понравились ))
	Ответить | Правка | Наверх | Cообщить модератору

	35. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+/–
	Сообщение от нах. (?), 06-Апр-20, 11:53
	в 16м вроде уже не было обезьян в питомнике. А доскер с системдой активно развились. Совпадение? Не думаю!
	Ответить | Правка | Наверх | Cообщить модератору

	28. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+/–
	Сообщение от YetAnotherOnanym (ok), 06-Апр-20, 10:36
	> Но внутри докера нет такого init ;-) и, главное, места под него > не предусмотрено. А чем тебя tini не устраивает?
	Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

	36. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+/–
	Сообщение от нах. (?), 06-Апр-20, 11:54
	Например, что он ничего не сможет сделать, если ему прилетит SIGTERM от docker stop. Никакой возможности задержать окончательный sigkill если это руками не предусмотрительно попросил набиравший
	Ответить | Правка | Наверх | Cообщить модератору

	42. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+/–
	Сообщение от YetAnotherOnanym (ok), 06-Апр-20, 13:01
	> Например, что он ничего не сможет сделать, если ему прилетит SIGTERM от > docker stop. Никакой возможности задержать окончательный sigkill если это руками не > предусмотрительно попросил набиравший Нууу, это обходимая проблема.
	Ответить | Правка | Наверх | Cообщить модератору

	69. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+/–
	Сообщение от нах. (?), 06-Апр-20, 20:24
	нет. Это вот в доскере не решается вообще никак в принципе. Баг дизайна. Ну или сознательный tradeoff (типа и нехрен всякие postgresы запускать таким образом, это ни разу не stateless ограниченное приложение, для которых, типа, изобретали докер), только я не верю что ляпатели на игогошечке хоть иногда бывали в сознании. Судя по остальным оставшимся от них кучкам.
	Ответить | Правка | Наверх | Cообщить модератору

	37. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+/–
	Сообщение от нах. (?), 06-Апр-20, 11:55
	Например, что он ничего не сможет сделать, если ему прилетит SIGTERM от docker stop. Никакой возможности задержать окончательный sigkill если это руками не предусмотрительно попросил набиравший stop - не завезли.
	Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

	48. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+/–
	Сообщение от pin (??), 06-Апр-20, 13:37
	> LXD > Все данные нужно выносить биндингами на хост или куда нибудь еще за пределы контейнера если нужно что-то сохранить А ты правильно понимаешь lxd/lxc?
	Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

	58. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+/–
	Сообщение от microcoder (ok), 06-Апр-20, 16:18
	Цитата взята из того места где говорил о докере, однако в LXC тоже можно выносить данные за пределы стораджа контейнера, а внтури монтировать как дисковое устройство.
	Ответить | Правка | Наверх | Cообщить модератору

	61. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+/–
	Сообщение от pin (??), 06-Апр-20, 17:44
	> Цитата взята из того места где говорил о докере, Видимо я не распарсил. Ок.
	Ответить | Правка | Наверх | Cообщить модератору

	38. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+2 +/–
	Сообщение от sage (??), 06-Апр-20, 12:40
	Docker — контейнер приложений (application container), LXC/LXD/OpenVZ — системные контейнеры (system container). Сделаны по-разному и для разного. Пересекаются технологически, но не идеологически. Docker не подходит и не предназначен для контейнеров с большим количеством демонов, как и не подходит LXC/Jail для запуска одной единственной программы, предварительно установив туда всю ОС. Мне гораздо чаще приходится запускать полноценные контейнеры, и я выбираю для этого LXD (и иногда systemd-nspawn/machined). Возможно, некоторые не знают о разнице подходов, и пытаются адаптировать неподходящий, но известный им инструмент (docker) под их задачу, что можно видеть по куче статей в интернете, где решают проблему init 1 в docker. Systemd не работает в Docker.
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	39. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+1 +/–
	Сообщение от sage (??), 06-Апр-20, 12:41
	Также см. https://www.linux.org.ru/forum/general/15607470
	Ответить | Правка | Наверх | Cообщить модератору

	49. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+/–
	Сообщение от Аноним (47), 06-Апр-20, 13:56
	> Systemd не работает в Docker. Это же из-за проблем с правами просходит. В LXC должно быть также? Под капотом же одно и то же.
	Ответить | Правка | К родителю #38 | Наверх | Cообщить модератору

	55. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+/–
	Сообщение от GentooBoy (ok), 06-Апр-20, 15:17
	LXD это не контейнеры это тулза для управления lxc и kvm теперь.
	Ответить | Правка | К родителю #38 | Наверх | Cообщить модератору

	64. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+/–
	Сообщение от Аноним (63), 06-Апр-20, 19:47
	> systemd  не работает в docker все прекрасно работает
	Ответить | Правка | К родителю #38 | Наверх | Cообщить модератору

	43. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+/–
	Сообщение от Аноним (43), 06-Апр-20, 13:12
	network.type=phys
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	60. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+/–
	Сообщение от trunk (?), 06-Апр-20, 17:27
	В частности тем, что есть в 32-разрядных дистрибутивах. Можео на старый сервер поставить.
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

1. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	–15 +/–
Сообщение от Аноним (1), 05-Апр-20, 23:04
Чем оно лучше flatpak?
Ответить | Правка | Наверх | Cообщить модератору

	2. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+12 +/–
	Сообщение от Аноним (2), 05-Апр-20, 23:15
	Примерно тем же, чем лучше трамвайной ручки. Это вообще-то совсем разные вещи.
	Ответить | Правка | Наверх | Cообщить модератору

	44. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+2 +/–
	Сообщение от Аноним (43), 06-Апр-20, 13:13
	Что такое трамвайная ручка?
	Ответить | Правка | Наверх | Cообщить модератору

	75. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+/–
	Сообщение от Аноним (75), 07-Апр-20, 02:22
	https://st3.depositphotos.com/1019087/15741/i/1600/depositph...
	Ответить | Правка | Наверх | Cообщить модератору

	76. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+/–
	Сообщение от _ (??), 07-Апр-20, 03:35
	Вах! В отличии от доскера - офигенная, винтажная штучка! :)
	Ответить | Правка | Наверх | Cообщить модератору

	3. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	–3 +/–
	Сообщение от Аноним (3), 05-Апр-20, 23:30
	Стоит сравнивать с openvz. Есть мнение, что хуже openvz быть ничего не может, в связи с чем сабж -- технический победитель.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	6. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+4 +/–
	Сообщение от Aliech (ok), 06-Апр-20, 01:31
	Оценивать по ущербности low-end хостеров саму технологию изоляции... Это... ну это Опеннет, всё норм. Продолжайте...
	Ответить | Правка | Наверх | Cообщить модератору

	7. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+/–
	Сообщение от Аноним (3), 06-Апр-20, 01:52
	Почему-то решения на основе lxc при всей ущербности у тех же самых помойных хостеров вполне норм. Можно сделать определённые выводы. Или это мне так "везло"?
	Ответить | Правка | Наверх | Cообщить модератору

	30. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+1 +/–
	Сообщение от Aliech (ok), 06-Апр-20, 11:06
	Пока нет данных об оверсейле мощностей тех нод, где крутился OpenVZ, - никаких выводов делать нельзя. Тем более что OpenVZ появился раньше, клиенты на нём тоже, нода стоит не обслуженная уже лет десять, и железка там не вывозит. А на новую ноду с lxc собрали года три всего назад, lxc не позволял сделать такой оверсейл... И, в итоге, пользователи lxc живут чуть-лучше. Такое вот у меня видение проблематики. Не претендую на точность взглядов, так как тоже не имею карманного помойного хостера, чтобы статистику выкатить.
	Ответить | Правка | Наверх | Cообщить модератору

	9. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	–1 +/–
	Сообщение от бублички (?), 06-Апр-20, 03:19
	ах как некрасиво, вы совсем забыли про vServer
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	34. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	–1 +/–
	Сообщение от бублички (?), 06-Апр-20, 11:37
	то-есть Linux-VServer. даже сам уже забыл как называется, т.к. не пользовался лет 10
	Ответить | Правка | Наверх | Cообщить модератору

59. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+/–
Сообщение от Аноним (47), 06-Апр-20, 16:40
Самая большая проблема с LXC для хипстеров в отличие от docker - он не работает на их яблозондах.
Ответить | Правка | Наверх | Cообщить модератору

	65. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+/–
	Сообщение от Аноним (63), 06-Апр-20, 19:49
	работает (так же как докер - в вм)
	Ответить | Правка | Наверх | Cообщить модератору

	73. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+/–
	Сообщение от Аноним (73), 06-Апр-20, 23:16
	на маке и винде докер работает в виртуалке т е ставиш виртуалнку - в  нее убунту - в нее LXD и вуаля - LXD работает на маке
	Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

	94. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 29-Апр-20, 04:18
	Задание тебе - поднять там ipv6
	Ответить | Правка | Наверх | Cообщить модератору

66. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+/–
Сообщение от Ддд (?), 06-Апр-20, 19:49
Докер может одной командой запустить контейнер а лхд нет
Ответить | Правка | Наверх | Cообщить модератору

	71. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+/–
	Сообщение от Аноним (73), 06-Апр-20, 23:14
	LXD  это система контейнерной виртуализации на базе готовых проверенных образов поэтому мы не изучаем премудрости и нюансы такого тула как docker, а просто изучаем пару команд для управления контейнерами и используем стандартные средства ОС для конфигурации ПО в контейнере
	Ответить | Правка | Наверх | Cообщить модератору

70. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	–1 +/–
Сообщение от Аноним (-), 06-Апр-20, 20:35
>lxd это тот который дырявый бай дезигн? https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1829071
Ответить | Правка | Наверх | Cообщить модератору

	72. "Выпуск инструментария управления контейнерами LXC и LXD 4.0"	+/–
	Сообщение от Аноним (73), 06-Апр-20, 23:15
	для локальной разработки мне ок а для прода есть админы и облачные сервисы
	Ответить | Правка | Наверх | Cообщить модератору

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

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